Sentry

하니·2025년 2월 11일

React 길잡이

목록 보기

7/21

장애가 발생하면 인프라, 데이터, 프론트엔드, 백엔드 중 어디에서 문제가 발생했는지 알 수 없으므로, 우선 장애의 원인을 파악하는 것이 중요하다.
✔️ 프론트엔드에서의 오류
데이터 영역 / 화면 영역 / 외부요인 / 런타임

예상할 수 없는 네트워크 이슈, 특정 브라우저 버전, 단말기 OS 업데이트
크롬의 쿠키 정책 변경, Safari 특정 버전의 Indexed DB API 버그, 또는 정말 특이한 케이스에서만 발생하는 런타임 오류

목표

⛳️ 에러 추적을 개선해보자!
에러 데이터 쌓기 ▶︎ Severity 기준 설정 및 모너링 ▶︎ 에러 데이터 분석 ▶︎ 분석 결과에 따른 개선

1. 에러 데이터 쌓기

Sentry는 실시간 로그 취합 및 분석 도구이자 모니터링 플랫폼이다.

이벤트 로그에 대한 다양한 정보 제공
- Exception & Message : 이벤트 로그 메시지 및 코드 라인 정보
- Device : 이벤트 발생 장비 정보
- Browser : 이벤트 발생 브라우저 정보
- OS : 이벤트 발생 OS 정보
- Breadcrumbs : 이벤트 발생 과정
비슷한 오류 통합Issue Grouping
다양한 알림 채널 지원 ex) Slack, Teams, Jira, Github ..

install & configure

NEXT에 Sentry 적용하기

Cature errors

captureException, captureMessage 두 가지 이벤트 전송 API를 제공한다.

captureException : error 객체나 문자열 전송 가능
captrueMessage : 문자열 전송 가능

1-2. 풍부한 데이터 쌓기

기본적인 기능들을 이용하여 에러 데이터는 쌓았는데 검색도 어렵고, 구분하기도 어렵기 때문에 Sentry가 제공하는 기능들을 사용해 설정을 더 해준다.

Scopes, Transaction Name, Add Context, Breadcrumbs, Customized Tags, Issue Grouping, Level

💠 Scope

Sentry는 scope 단위로 이벤트 데이터를 관리한다.
이벤트가 전송되면 해당 이벤트의 데이터를 현재 scope의 추가 정보와 병합한다.

일반적으로 자동으로 scope을 관리하지만, 잘 활용하면 각 이벤트마다 의미 있는 정보를 추가적으로 전송할 수 있다.

Sentry에서의 scope은 configureScope과 withScope 2가지로 나누어 설정할 수 있다. configureScope으로는 공통 정보를, withScope으로는 각 에러 상황 시 추가 정보를 전송한다.

configureScope

글로벌 scope과 비슷한 맥락으로 현재 범위 내에서 데이터를 재구성하는데 사용한다.

이벤트 전송에 있어 공통적으로 사용되는 정보가 있다면 이 설정을 사용하면 된다.

예제) 사용자 정보, 웹뷰 타입 정보

withScope

로컬 scope로 한 번의 범위 내에서 데이터를 재구성할 때 사용한다.
이 scope를 사용하게 되면 현재 범위의 복제본이 생성되어 설정한 추가 정보를 병합한다.

오류에 따라 서로 다른 데이터를 추가적으로 전송해야 할 때 유용하다. ex) API로 발생한 오류, 문법 오류, 라이브러리로 발생한 오류

예제) API 에러에 대한 태그와 레벨 정보

💠 Context

context를 통해서도 추가 정보를 전송할 수 있다. 이벤트에 임의이 데이터를 연결할 수 있는 기능이다.
context로 전송하는 데이터는 검색할 수 X기 때문에 해당 이벤트가 발생한 이벤트 로그에서만 확인할 수 있다.

예제) API 요류
API 오류의 경우 요청 데이터와 오류 응답 데이터를 제일 먼저 확인하고 싶을 것이다. 이런 정보는 SDK에서 기본적으로 제공하지 않기 때문에 context를 이용하여 추가 정보를 전송해준다.

❓ withScope과 context의 차이가 뭐지?
withScope : 임시 scope를 만들어서 특정 에러에만 정보를 추가하는 것
일시적인 변경을 적용하는 용도 (ex. 특정 API 오류에서만 태그를 추가)
context : 연관된 데이터를 하나의 객체로 그룹화해서 보여주는 것
이벤트의 메타데이터를 추가하는 용도 (ex. API 요청/응답 데이터를 기록)

💠 Customized Tags

tag : 키와 값이 쌍으로 이루어진 문자열
tag는 인덱싱이 되는 요소이기 때문에 관련 이벤트에 빠르게 접근할 수 있고, 이슈 검색 및 트래킹을 신속하게 진행할 수 있다.

예제) API 오류
network, timeout, not found, internal server error ...
networ와 일반 API 오류를 구분하여 tag를 설정하면 구분하여 이슈를 파악할 수 있다.

이슈 알람을 받을 수 있는 조건에 특정 tag 조건을 설정하여 원하는 알람을 생성할 수 있다.

예제) API 관련 에러를 빠르게 검색하기 위해 에러의 타입과 API 에러 유형을 의미하는 2개의 태그값을 추가해준다.

💠 Level

이벤트마다 level을 설정하여 이벤트의 중요도를 식별할 수 있다.
기본적으로 다음과 같은 에러 level을 정의하고 있다.

export declare enum Severity {
  Fatal = 'fatal',
  Error = 'error',
  Warning = 'warning',
  Log = 'log',
  Info = 'info',
  Debug = 'debug',
  Critical = 'critical',
}

이렇게 에러 유형에 따라 중요도를 설정하게 되면 이슈 그룹핑이나 알람 조건을 세분화하여 설정하는데 도움이 된다.

예제)
API internal server 에러는 중요도를 높여 추적하기 위해 Error등급으로 설정한다.
API timeout 에러는 중요도를 낮춰 식별하기 위해 Warning등급으로 설정한다.

💠 Issue Grouping

Sentry에서 각 이벤트는 fingerprint를 가지고 있다.

fingerprint : Sentry에서 오류를 그룹화하는 방식을 결정하는 기능(기준)
fingererprint는 이벤트 내에 수집된 정보들을 기반으로 내재되어 있는 그룹화 알고리즘으로 생성되어, fingerprint가 동일한 이벤트들은 자동으로 하나의 이슈로 그룹화된다.

❗️ 내재화된 알고리즘이 기반하여 자동으로 그룹화하기 때문에 이벤트들이 예상한 것과 다른 이슈로 보여질 때가 있다.

예제) API 에러 처리
하나의 API에서 발생할 수 있는 오류는 400, 404, 500 .. 다양하다. 하지만 요청 url이 같으면 Sentry는 HTTP status가 다르더라도 같은 이슈로 그룹화한다. 이렇게 되면 각 HTTP status별로 발생하는 이벤트 분포 확인, 이벤트 검색, 이슈 분석이 어려워진다.

➡️ HTTP method(GET, POST), status(400, 404, 500), url을 fingerprint 조건으로 설정해주면 된다.