GitLab의 프론트엔드 개발에서 Sentry 모니터링
GitLab 프론트엔드 팀은 사용자들이 gitlab.com에서 UI의 성능을 모니터링하는 관측 도구로 Sentry를 사용합니다.
GitLab.com은 우리의 Sentry 인스턴스를 관리자 > 메트릭 및 프로파일링 > Sentry에서 보고하도록 구성되어 있습니다.
우리는 오류와 성능 두 종류의 데이터를 모니터링합니다.
Sentry 사용 시작
우리의 Sentry 인스턴스는 https://new-sentry.gitlab.net/에 있습니다. Sentry에는 GitLab 팀원만 접근할 수 있습니다.
첫 로그인 후에는 팀 참여를 선택하여 팀 페이지에서 #gitlab 팀에 가입할 수 있습니다.
오류 보고
오류는 Sentry UI에서 “이벤트”로 알려진 것으로, 사용자들이 브라우저에서 경험하는 비정상적이거나 예상치 못한 런타임 동작의 인스턴스입니다.
GitLab은 Sentry Browser SDK를 사용하여 오류를 우리 Sentry 인스턴스에 gitlabcom-clientside 프로젝트 아래 보고합니다.
알려진 오류 보고
Sentry에 오류를 보고하는 가장 흔한 방법은 captureException(error)를 호출하는 것입니다. 예를 들어:
import * as Sentry from '~/sentry/sentry_browser_wrapper';
try {
// 런타임에서 실패할 수 있는 코드
} catch (error) {
Sentry.captureException(error)
}
어떤 경우 오류를 보고해야 하나요? 우리는 신경 쓸 필요가 없거나 제어할 수 없는 오류를 보고하고 싶지 않습니다. 예를 들어, 사용자가 양식을 잘못 작성했을 때 유효성 검사 오류를 보고해서는 안 됩니다. 그러나 해당 양식 제출이 서버 오류로 실패하는 경우에는 Sentry에서 알아야 하는 오류이지요.
기본적으로 로컬 개발 인스턴스에는 Sentry가 구성되어 있지 않습니다. Sentry로의 호출은 디버깅을 위해 콘솔에 [Sentry stub] 접두어가 붙은 상태로 표시됩니다.
처리되지 않은/알려지지 않은 오류
또한, 우리 페이지의 모든 곳에서 처리되지 않은 오류는 자동으로 캡처됩니다.
오류 모니터링
오류가 캡처되면 Sentry에 나타납니다. 예를 들어, 지난 24시간 동안 캐너리와 프로덕션에서 보고된 오류를 볼 수 있습니다.
디렉터리에서 어떤 오류든 선택하여 자세한 내용을 볼 수 있습니다… 그리고 이를 해결하기 위한 제안을 이상적으로 하시면 됩니다!
gprd와 gprd-cny 환경으로 오류를 필터링하는 것을 권장합니다.오류 데이터 조회
팀원들은 Sentry의 Discover 페이지를 사용하여 예상치 못한 문제를 찾을 수 있습니다.
추가로, 우리는 대시보드를 만들어 가장 많은 오류를 발생시키는 기능 범주 및 페이지를 보고하는데 사용합니다.
프론트엔드 엔지니어 팀원들은 오류 데이터를 살펴보고 사용자 인터페이스의 오류를 줄이는 방법을 찾는 것을 권장받습니다. Sentry는 또한 오류가 발생할 때 알림을 받고 싶어하는 사람들을 위해 경고를 제공합니다.
오류 필터링
하루에 수천 건의 보고서를 받기 때문에 팀원들은 자신의 작업 영역에 따라 오류를 필터링할 수 있습니다.
우리는 오류를 식별하는 데 도움이 되는 두 가지 추가적인 사용자 정의 태그로 오류를 표시합니다:
-
feature_category: 페이지의 기능 영역. (예:code_review_workflow또는continuous_integration.) 소스:gon.feature_category -
page: 페이지를 렌더링하기 위해 컨트롤러에서 호출된 메서드의 식별자. (예:projects:merge_requests:index또는projects:pipelines:index.) 소스:body_data_page.
프론트엔드 엔지니어 팀원들은 그룹 및/또는 페이지에 관련된 오류를 필터링할 수 있습니다.
성능 모니터링
우리는 BrowserTracing을 사용하여 성능 지표를 Sentry에 보고합니다.
지난 24시간 동안의 성능 데이터를 방문하여 필터를 사용하여 자세히 알아보실 수 있습니다.
도움말