▪︎ 제공 정보
- Exception & Message: 에러가 발생한 코드 라인과 에러 및 로그 메시지
- Device: 이벤트 발생 장비 정보 (name, family, model, memory 등)
- Browser: 이벤트 발생 브라우저 정보 (name, version 등)
- OS: 이벤트 발생 OS 정보 (name, version, build, kernelVersion 등) (유저가 사용하는 OS)
- Breadcrumbs: 유저가 오류 발생시 거친 과정 및 경로
- Performance: 성능 지표
▪︎ 가격
▪︎ 운영 환경 구분
Sentry.init({
environment: process.env.NODE_ENV,
});
▪︎ Sentry for Vue
Sentry.vueRouterInstrumentation(router)- 라우팅 관련 에러 추적: 사용자가 페이지 이동 중에 발생하는 에러를 자동으로 캡처.
- 성능 모니터링: 페이지 로딩 시간 및 기타 성능 관련 문제를 추적
lifecycle hooks 추적- activate, create, unmount, mount, update
- 각 컴포넌트 마다 얼마나 걸려서 잘 렌더링 됐는지 알 수 있는듯?
▪︎ 알려진 단점
- 이름과 메시지
- 기본적으로 에러는 기본 에러객체로 표현된다.
실제로 별다른 설정 없이 에러를 던지면 아래 사진과 같은 에러들이 수집 소스맵이 없는 에러의 경우 번들링되고 minify된 코드가 보여기 때문에 디버깅이 쉽지 않다.
그러므로 에러 커스텀의 필요하고 에러의 이름과 메시지는 명확히 파악되어야 한다.
- 과도한 로깅
- 에러 모니터링 툴의 로거는 샘플링 레이트를 넘지 않는 모든 에러를 잡아야 하지만, 꼭 필요한 에러만 알림으로 알려주고 해결할 수 있도록 리마인드 해야한다.
또한 권고사항대로 Sentry로 앱 전체를 감싸게되면 앱 내에서 발생하는 모든 오류를 잡아준다.
하지만 서비스가 커지다보면 그 에러의 종류가 많아지게 되고 throw만하고 catch는 안하는 상황 속에서 많은 에러들이 우후죽순 로깅되게 된다.
거기에 다양한 라이브러리에서 던져지는 에러들까지 합쳐지면 거의 에러를 방치하는 수준이 되어 버림
▪︎ 모니터링
오류 상세 정보
컴포넌트 정보
슬랙 연동 지원해주고 아래처럼 알림 규칙을 정할 수 있어보임
▪︎ 도입 할만한가?
-
비용은 한달에 삼만원 정도
-
센트리를 양치기소년으로 만들면 안됨
- scope를 잘 나눠서 UI, API 에러 구분을 확실하게 하고 유의미한 에러만 트레킹 할 수 있도록 필터
- 이를 지키다 보면 에러 핸들링 부분이 더 탄탄하게 개선될 것 같다.
-
WebView 환경에서 더 빛을 발할 듯 싶다.
- 크로스 브라우징 뿐만아니라 Device, OS 추적으로 문제 해결
