Sentry 커뮤니티

• 가장 활성화된 센트리 관련 커뮤니티
• 영어라서 아쉬움
• 물어보고 싶은 걸 물어보면 빠른 답변을 준다고 함

• 실제로 해봤더니 1분도 안걸려서 답변이 달림
• 영어에 능통하다면 애용해보자

Sentry 실전

Sentry 초기화 함수

initSentry()

• 서비스에 Sentry를 설치해서 초기화하는 함수
• 앱 최상단에서 한 번만 실행

export function initSentry(config: SentryConfig) {
  const { dsn, environment, release } = config;

  if (!dsn) {
    console.warn('Sentry DSN값을 환경변수에서 찾지 못함.')

핵심 설정 값 설명

dsn

• Sentry 프로젝트 고유 ID

environment

• 실행 환경 명시
• 예: production, development

release

• 배포 버전 명시

사용 목적

• 어떤 버전에서 에러가 많이 발생했는지 추적 가능
• 배포 이후 에러 증가 시 문제 릴리즈 즉시 파악 가능

release 사용 예시

1.0.0 => 에러 0개
1.1.0 => 에러 1285개 (이 버전에서 대량 발생)
1.2.0 => 에러 2개 (문제 해결 확인 가능)

❓ 왜 위 3가지는 props로 받을까?

• dsn
  • 노출되면 안 되는 고유 ID 값
• environment
  • production / development
• release
  • 현재 배포 버전

integrations (확장 기능)

browserTracingIntegration()

• 페이지 로드 시간 측정
• API 요청 시간 측정

사용 목적

• 페이지 로딩 성능 분석
• API 병목 구간 파악
• 성능 개선 지표 확보

replayIntegration()

• 사용자 세션 녹화 기능 활성화
• 일종의 CCTV 개념

💡 세션이란?

• 사용자가 서비스를 들어와서 나갈 때까지의 모든 과정
• 브라우저를 닫기 전까지 하나의 세션
• 새로고침해도 세션은 유지됨

성능 및 추적 관련 옵션

tracesSampleRate

• 성능 추적 비율
• browserTracingIntegration()과 함께 사용

설명

• 1.0 → 모든 요청 100% 추적
• 프로덕션 환경 권장 값: 0.1 ~ 0.3

🤔 왜 0.1 ~ 0.3?

- 너무 많은 데이터 저장 시 Sentry 용량 부담
- 트랜잭션 추적은 수 KB 수준으로 가벼움
- 100%도 가능하지만 안전하게 0.1~0.3 권장
- 모든 사용자의 행동 패턴은 대체로 유사

tracePropagationTargets

• 어떤 서버 요청을 성능 추적할지 설정
• 백엔드 API의 baseURL 작성
• 현재는 localhost + 실제 서버 주소 사용

세션 리플레이 관련 옵션

replaysSessionSampleRate

• 일반 사용자 세션 녹화 비율

replaysOnErrorSampleRate

• 에러 발생 사용자 세션 녹화 비율

💡 에러 세션은 어떻게 녹화되는가?

replaysSessionSampleRate: 0.1
→ 전체 사용자 중 10%만 전체 세션 저장

replaysOnErrorSampleRate: 1.0
→ 에러 발생자는 100% 저장

❓ 에러 발생자는 어떻게 구분할까?

• 모든 사용자의 최근 60초 세션을 메모리 버퍼에 임시 저장
• 실제 영상이 아닌 이벤트 로그 형태

{ time: 1234, type: 'click', x: 100, y: 200 }
{ time: 1235, type: 'input', value: 'cat' }

• 크기: 약 2~5MB
• 실제 영상은 Sentry 서버에서 자동 변환

에러 발생 시 저장 흐름

전체 흐름 요약

1. 모든 사용자 → 최근 60초 세션을 메모리 버퍼에 저장
2. 에러 발생 시
   • 해당 시점 이전 60초 + 이후 전체 세션 저장
3. Sentry로 전송
4. 에러 전후 영상 확인 가능

## 🫅 시나리오 예시

### 👮 유저 A (에러 없음, 당첨)

1. 접속
2. 랜덤 추첨 (10%)
3. 당첨 → 실시간 Sentry 전송
4. 세션 종료
5. 영상 확인 가능

---

### 🥷 유저 B (에러 없음, 탈락)

1. 접속
2. 랜덤 추첨 (10%)
3. 탈락 → 메모리 버퍼에만 저장
4. 세션 종료
5. 영상 확인 불가

---

### 👰 유저 C (에러 발생)

1. 접속
2. 랜덤 추첨 탈락
3. 메모리 버퍼에 60초 저장
4. 에러 발생 🚨
5. `replaysOnErrorSampleRate: 1.0`
6. 이전 60초 세션 전송

왜 이런 구조로 설계했을까?

문제

❌ 에러를 미리 예측할 수 없음
"이 유저 5분 후에 에러 나니까 미리 녹화"
→ 불가능

해결

✅ 모든 사용자 최근 60초는 임시 저장
✅ 에러 발생 시 버퍼 내용 즉시 전송
✅ 이후 세션은 전부 저장

기타 옵션

enableLogs

• 콘솔에 찍히는 로그도 Sentry로 전송
• true / false 설정 가능
• Sentry.captureConsoleIntegration({ levels: ['error', 'warn'] }), 같이 사용해서 어떤 등급의 콘솔을 찍을 것인지 커스텀 가능
• throw Error ⇒ 자동 캡쳐
• captureException ⇒ 수동 및 커스텀 캡쳐
• throw Error로 처리해놓을 경우 자동으로 센트리에 기록되지만 그렇지 않은 경우를 파악하기 위해 error level 콘솔을 기록하면 처리하지 않은 에러까지도 기록할 수 있음

센트리 적용

export const captureException = (
  error: Error,
  context?: Record<string, unknown>,
) => {
  Sentry.captureException(error, context);
};

export const captureMessage = (
  message: string,
  level: Sentry.SeverityLevel = 'info',
) => {
  Sentry.captureMessage(message, level);
};

• 본인이 알림을 받고 싶은 에러에 적용

• 본인이 확인하고 싶은 정보 설정

export const fetchClient = async <TResponse, TBody = unknown>(
  endpoint: string,
  options?: FetchOptions<TBody>,
): Promise<TResponse>

• ex) fetch를 간단하게 만들어주는 유틸 함수
• httpError와 fetchError를 구분
  • 서버에서 설정해놓은 에러 응답 ⇒ httpError
  • 통신 요청에서 발생하는 에러 응답 ⇒ fetchError
• 🚨 구분 이유?
  • httpError도 error!
  • catch error에서도 잡히기 때문에 catch 부분에서는 네트워크 에러만 캡쳐할 수 있도록 해야 함
  • 그렇기 때문에 http와 fetch를 구분해서 캡쳐

센트리 그룹핑

• Sentry는 기본적으로 다음 정보를 기반으로 자동 그룹핑
  1. 에러 타입 (Error, TypeError, HttpError 등)
  2. 스택 트레이스 (함수 호출 경로)
  3. 에러 메시지 (일부)
• 문제는 에러 메시지에 동적 값이 포함되면 같은 종류의 에러도 다른 Issue로 분류된다는 점
• ex)
  • throw new httpError(${customMessage});
  • 에러 메시지를 작성하면 같은 http error라도 다른 에러로 취급하고 캡쳐
• 하나의 이슈로 묶어서 담당자를 정하거나 해당 에러 발생 목록을 확인하는 것이 중요하기 때문에 커스텀 그룹핑 필요

커스텀 그룹핑 방법

• finger print를 적용하면 Sentry에서 해당 설정으로 그룹핑을 적용
• 같은 finger print 값을 가진 에러들끼리 하나의 이슈로 묶여서 기록
• ex)
  • http 에러 + error status ( 400 ~ 500 )
  • fetch 에러 ( 통신 에러 )
  • 소켓 연결 에러
  • 소켓 내부 에러 ( 소켓 통신 내부에서 발생하는 에러 )

        
        
    captureException(httpError, {
        tags: {
          error_type: 'http_error',
          status_code: String

• 그룹핑된 에러는 하나의 이슈로 취급

• 하나의 이슈지만 소켓 내부에서 발생한 에러들이 하나의 이슈로 취급되서 출력되는 것을 확인 ( 방이 꽉참, 방이 존재하지 않음 등)

🚨🚨🚨 트러블 슈팅

• 같은 http error인데 왜 2개의 이슈?

• 첫 번째: HttpError → HTTP error! status: 404 (프로젝트 R)
• 네 번째: HttpError → HTTP error! status: 404 (프로젝트 9)

• 센트리는 배포 시점에 따라서 다른 프로젝트로 인식
• 프로젝트 9는 이전 코드에서 캡쳐된 에러 프로젝트 R은 최근 코드에서 캡쳐된 에러
  • ❓ 9냐 R이냐가 중요한 것은 아님 코드 변경 순서대로 1~Z까지 할당
• 따라서 같은 에러라도 코드 시점에 따라서 다른 에러로 인식해서 이슈가 구분된 것

• 이전 코드에서 발생한 이슈를 지워버리기
• 2개를 merge하여 하나의 이슈로 만들기
• 자동 해결은 없음 위 2가지 방법 모두 수동

부록

이슈를 이메일로 확인하기

• 이슈 알림은 다른 설정 없이도 회원가입한 이메일로 자동으로 전송! (off 가능)

• 이슈 알림 워크플로우에서 On, Off, Only Subscibed Issues 선택 가능
• 구독한 이슈만 알림을 받는 것도 가능

• 이슈에 종모양을 키거나 끄는 것으로 간단하게 구독 여부 설정 가능

• 메일로 잘 오는 것을 확인

⭐ 추가 꿀팁

• 어떤 프로젝트에서는 세션 캡쳐에서 페이지 디자인이 그대로 적용되지 않는 경우가 있음

  

• 어떤 프로젝트에서는 페이지 디자인 그대로 캡쳐 적용

  

• 두 프로젝트의 차이
  • 스타일 적용 X - 외부 css 파일 style 태그로 불러오기
  • 스타일 적용 O - 인라인 방식인 tailwind로 스타일 적용
• Sentry는 화면 요소만 캡쳐하기 때문에 외부 파일은 불러올 수 없음
• 인라인 방식으로 화면 요소에 직접 적용이 되어 있어야 불러올 수 있음

• 인라인 방식으로 직접 적용하기
• 설정 수정

Sentry.replayIntegration({
  maskAllText: false,
  blockAllMedia: false,
  
  // 👇 외부 스타일시트 포함
  recordCanvas: true,
  inlineStylesheet: true,  // 인라인 스타일시트로 변환
  
  // 👇 특정 도메인 CSS 가져오기 허용

• 외부 스타일 시트를 가져오도록 설정하는 방법도 있지만 인라인 방식으로 추가한 스타일 코드보다 성능 저하 ⇒ 캡쳐한 페이지에 필요하지 않은 css 스타일 코드가 포함된 파일까지도 가져올 수 있음

결론

• 아직까지는 큰 이점을 모르겠음
• 정말 많은 에러가 터지고 내가 너무 바빠서 모든 것을 확인하기 어려운 상황이 되어야 이점을 느낄 것 같음
• 근데 지금은 에러도 많이 안터지고 내가 해당 프로젝트에만 몰두하고 있기 때문에 설정하기 어렵고 읽기 복잡한 차트라고만 생각이 듦
• 인원 초대도 무료 버전은 1명만 가능