GitLab 프론트엔드 팀은 gitlab.com 사용자들의 UI 성능을 모니터링하기 위해 Sentry를 관측 도구로 사용합니다.

GitLab.com은 관리자 > 메트릭 및 프로파일링 > Sentry에서 당사의 Sentry 인스턴스에 보고하도록 구성되어 있습니다.

모니터링하는 데이터는 오류와 성능, 두 가지입니다.

Frontend Observability Working Group은 Sentry 활용 방식을 개선하기 위해 노력하고 있습니다. GitLab 팀원은 이슈 #427402에서 피드백을 제공할 수 있습니다.

Sentry 사용 시작하기#

당사의 Sentry 인스턴스는 https://new-sentry.gitlab.net/에 있습니다. Sentry에는 GitLab 팀원만 접근할 수 있습니다.

첫 로그인 후 팀 참여를 선택하여 #gitlab 팀에 합류할 수 있습니다. 팀 페이지의 YOUR TEAMS 아래에 #gitlab이 표시되는지 확인하세요.

오류 보고#

오류는 Sentry UI에서 “이벤트”라고도 불리며, 사용자가 브라우저에서 경험하는 비정상적이거나 예상치 못한 런타임 동작의 인스턴스입니다.

GitLab은 Sentry Browser SDK를 사용하여 프로젝트 gitlabcom-clientside의 당사 Sentry 인스턴스에 오류를 보고합니다.

알려진 오류 보고#

Sentry에 오류를 보고하는 가장 일반적인 방법은 captureException(error)를 호출하는 것입니다. 예시:

import * as Sentry from '~/sentry/sentry_browser_wrapper';

try {
  // Code that may fail in runtime
} catch (error) {
  Sentry.captureException(error)
}

언제 오류를 보고해야 하나요? 신경 쓰지 않아도 되거나 제어할 수 없는 오류는 보고하지 않는 것이 좋습니다. 예를 들어, 사용자가 양식을 잘못 작성했을 때 발생하는 유효성 검사 오류는 보고하지 않아야 합니다. 그러나 서버 오류로 인해 양식 제출이 실패하는 경우, 이는 Sentry에 알려야 하는 오류입니다.

기본적으로 로컬 개발 인스턴스에는 Sentry가 구성되어 있지 않습니다. Sentry 호출은 스텁 처리되어 디버깅을 위해 [Sentry stub] 접두사와 함께 콘솔에 표시됩니다.

처리되지 않은/알 수 없는 오류#

또한, 모든 페이지에서 처리되지 않은 오류를 자동으로 캡처합니다.

오류 모니터링#

오류가 캡처되면 Sentry에 나타납니다. 예를 들어 카나리 및 프로덕션 환경에서 지난 24시간 동안 보고된 오류를 확인할 수 있습니다.

목록에서 아무 오류나 선택하면 더 자세한 내용을 볼 수 있으며… 가능하다면 해결 방법을 제안해 보세요!

환경 데이터에 스팸이 일부 포함되어 있으므로, gprd 및 gprd-cny 환경으로 오류를 필터링하는 것을 권장합니다.

오류 데이터 탐색#

팀원은 Sentry의 Discover 페이지를 사용하여 예상치 못한 문제를 찾을 수 있습니다.

또한, 어느 기능 카테고리와 페이지에서 오류가 가장 많이 발생하는지 등의 데이터를 보고하는 대시보드를 만들었습니다.

엔지니어링 팀원은 오류 데이터를 탐색하고 사용자 인터페이스의 오류를 줄이는 방법을 찾도록 권장됩니다. Sentry는 오류 발생 시 알림을 받고 싶은 사람들을 위한 알림 기능도 제공합니다.

오류 필터링#

하루에 수천 건의 보고를 받으므로, 팀원은 자신의 작업 영역을 기반으로 오류를 필터링할 수 있습니다.

오류의 출처를 식별하는 데 도움이 되도록 두 가지 추가 사용자 정의 tags로 오류를 표시합니다:

• feature_category: 페이지의 기능 영역입니다. (예: code_review_workflow 또는 continuous_integration.) 소스: gon.feature_category

• page: 페이지를 렌더링하기 위해 컨트롤러에서 호출된 메서드의 식별자입니다. (예: projects:merge_requests:index 또는 projects:pipelines:index.) 소스: body_data_page

프론트엔드 엔지니어링 팀원은 자신의 그룹 및/또는 페이지와 관련된 오류를 필터링할 수 있습니다.

전역 로드 코드에 대한 feature_category 재정의#

feature_category 태그는 현재 페이지의 Rails 컨트롤러 카테고리를 반영하는 gon.feature_category에서 자동으로 설정됩니다. 이는 페이지별 코드에는 잘 작동하지만, 모든 페이지에서 실행되는 전역 로드 JavaScript에는 문제를 일으킬 수 있습니다.

다음과 같은 경우 feature_category 태그를 재정의하세요:

• 모든 페이지에 로드되는 경우 (예: 슈퍼 사이드바, 네비게이션, 또는 전역 검색).

• 여러 기능 영역에 걸쳐 내장된 경우 (예: 어디서나 사용 가능한 AI 기능).

• 그렇지 않으면 사용자가 있는 페이지에 따라 다른 카테고리를 상속받게 될 경우.

재정의 없이는 전역 로드 코드의 오류가 현재 페이지를 기반으로 무작위 기능 카테고리 버킷에 보고되어 추적하고 올바른 팀에 할당하기 어려워집니다.

feature_category를 재정의하려면 captureException을 호출할 때 명시적인 feature_category 태그를 전달하세요:

import * as Sentry from '~/sentry/sentry_browser_wrapper';

try {
  // Code that may fail at runtime
} catch (error) {
  // Override gon.feature_category as this code loads on all pages
  Sentry.captureException(error, { tags: { feature_category: 'navigation' } });
}

오류가 발생한 페이지가 아닌 코드를 소유한 기능 카테고리를 사용하세요. 예시:

• 슈퍼 사이드바 코드 → navigation

• 전역 검색 → global_search

• 추적 유틸리티 → product_analytics

성능 모니터링#

BrowserTracing을 사용하여 성능 메트릭을 Sentry에 보고합니다.

지난 24시간의 성능 데이터를 방문하고 필터를 사용하여 자세히 알아볼 수 있습니다.

Sentry 인스턴스 인프라#

GitLab 인프라 팀이 Sentry 인스턴스를 관리하며, 아키텍처 및 데이터 관리에 대한 자세한 내용은 런북 문서에서 확인할 수 있습니다.