GitLab 프론트엔드 팀은 gitlab.com 사용자에게 UI가 어떻게 동작하는지 모니터링하기 위해 Sentry를 관측 도구로 사용합니다.

GitLab.com은 Admin > Metrics and profiling > Sentry에서 GitLab의 Sentry 인스턴스로 보고하도록 구성되어 있습니다.

모니터링하는 데이터는 Errors와 Performance 두 가지입니다.

Sentry 사용 시작하기#

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

처음 로그인한 뒤 Join a team을 선택하여 #gitlab 팀에 참여할 수 있습니다. 팀 페이지의 YOUR TEAMS 아래에 #gitlab 이 표시되는지 확인합니다.

오류 보고#

Sentry UI에서 "events" 라고도 부르는 오류는 사용자가 브라우저에서 겪는 비정상적이거나 예기치 않은 런타임 동작의 사례입니다.

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시간 동안 canary와 프로덕션에서 보고된 오류를 확인할 수 있습니다.

목록에서 오류를 선택하면 자세한 내용을 볼 수 있으며, 가능하다면 해결 방안까지 제안합니다.

오류 데이터 탐색#

팀원은 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

성능 모니터링#

GitLab은 BrowserTracing을 사용하여 성능 지표를 Sentry에 보고합니다.

최근 24시간 성능 데이터를 방문하여 필터로 범위를 좁혀 더 자세히 살펴볼 수 있습니다.

Sentry 인스턴스 인프라#

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