Sentry를 이용한 에러 추적기 with kakao

17__COLIN·2024년 5월 19일
0

BOOK-STUDY

목록 보기
9/9
post-thumbnail

스터디에서 에러 바운더리를 얘기하면서, Sentry를 위해 에러 바운더리를 도입했다는 이야기를 접하였습니다.

에러 바운더리를 활용한 에러 처리

  • 에러 바운더리 : 리액트 컴포넌트 트리에서 에러가 발생할 때 공통으로 에러를 처리하는 리액트 컴포넌트
  • 에러 바운더리를 사용하면 리액트 컴포넌트 트리 하위에 있는 컴포넌트에서 발생한 에러를 캐치하고, 해당 에러를 가장 가까운 부모 에러 바운더리에서 처리하게 할 수 있다.
  • 에러 바운더리는 에러가 발생한 컴포넌트 대신에 에러 처리를 하거나 예상치 못한 에러를 공통 처리할 때 사용할 수 있다.

이때, Sentry 자체를 처음 접하게 되어, 추가로 공부해 알아보고 싶었습니다.

스터디 발표 차례에서 이를 정리해 발표하면 좋을 것 같아 kakao에서 발표한 Sentry 도입 영상을 정리해보았습니다.


# Kakao가 겪어야 했던 상황들

  • 특정 이슈 감지, 원인 파악, 해결까지 많은 시간이 소요됨

  • 이때, 대부분의 시간을 원인 파악에 소요함

  • 이는 좋지 않은 사용자 경험을 제공함

⇒ 에러 추적을 개선해보자!

# Frontend에서의 에러

스크린샷 2024-05-16 오후 5 04 21

  • 데이터 영역에서의 에러, 화면 영역에서의 에러는 충분히 조심하고 방어할 수 있다.

  • 그러나 외부요인(네트워크, 브라우저 등)에 의한 에러, 런타임 에러는 예측하기 힘듦.

  • 이런 에러들을 트래킹하고 신속하게 대응해 UX를 개선할 수 있지 않을까 생각함

# 에러 추적을 개선해보자!

에러 추적을 위해 다음과 같은 흐름으로 개선 작업을 진행함

스크린샷 2024-05-16 오후 5 07 32

1. 에러 데이터 쌓기

프론트엔드 모니터링 툴 중, Sentry를 사용함

Sentry


스크린샷 2024-05-16 오후 5 10 31

  • 실시간 로그 취합 및 분석 도구이자 모니터링 플랫폼
  • 로그에 대한 다양한 정보를 제공하고 시각화 도구를 통해 발생한 이벤트들을 쉽게 분석할 수 있도록 도와줌
  • 다양한 플랫폼을 지원

Sentry는 기본적으로 두 가지 이벤트 전송 api를 제공함.

  • captureException

    • 에러 객체나 문자열을 전송
  • captureMessage

    • 문자열만 전송

이렇게 수집한 에러 데이터는 검색도 어렵고 구분하기도 어려웠음

⇒ Sentry 자체에서 제공하는 기능들이 다양함. 이를 활용해보기로 함.

Scope

Sentry는 기본적으로 scope 단위로 데이터를 관리함

스코프는 자동으로 관리되지만 잘 활용한다면 이벤트마다 추가 정보를 전송할 수 있음

  • configureScope

    • 글로벌 스코프와 비슷한 맥락

    • 공통 정보를 데이터 전송에 활용할 수 있음

    • 현재 범위 내에서 데이터를 재구성하는데 사용

  • withScope

    • 로컬 스코프와 비슷한 맥락

    • 복제본을 생성해서 추가 정보를 병합한 뒤에 이벤트를 전송함

    • 한 번의 범위 내에서 데이터를 재구성할 때 사용

Context

  • 이벤트에 임의의 데이터를 연결할 수 있는 context를 이용해 추가 정보를 전송

  • 검색은 할 수 없고 해당 이벤트가 발생한 이벤트 로그에서 확인 가능

스크린샷 2024-05-18 오후 1 39 26

Cusomized Tags

  • 에러 추적을 신속하게 하기 위해 검색이 중요한 요소임

  • tag는 키와 값이 쌍으로 이루어진 문자열

  • tag는 인덱싱이 되는 요소 ⇒ 이벤트에 빠른 접근 가능 ⇒ 이슈 검색 및 트래킹을 신속하게 진행할 수 있음

스크린샷 2024-05-18 오후 1 41 39

~> 태그 값은 검색 뿐만 아니라 알람 설정에도 활용 가능

Level

  • 이벤트마다 level을 설정하여 이벤트의 중요도를 식별할 수 있음

  • fetal, error, warning, log, info, debug, critical로 severity를 설정할 수 있음

예제 1. API 인터널 서버 에러

스크린샷 2024-05-18 오후 1 45 20

  • 중요도를 높여 추적하기 위해 Error 등급으로 설정

  • 전송된 이벤트는 시각화 도구에서 확인 가능

예제 2. API 타임아웃 에러의 레벨 설정하기

스크린샷 2024-05-18 오후 1 46 14

  • 인터널 서버 에러보다는 중요도를 낮춰 식별해야 함
    ⇒ Warning 등급으로 설정

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

Issue Grouping

스크린샷 2024-05-18 오후 1 50 24

  • 각각의 이벤트들은 내재화 된 그룹화 알고리즘에 의해 생성된 fingerprint를 가지고 있음

  • fingerprint가 동일한 이벤트는 자동으로 하나의 이슈로 그룹화되며 재설정할 수 있음

  • 간혹 이슈가 예상과 다르게 보여 재설정이 필요한 경우가 있음
    ← ex: API 응답이 서로 다른 상태값을 가지게 되어도 내재화된 알고리즘에 의해 그룹화됨

이렇게 에러 데이터를 쌓는 작업 후 에러 상황을 빠르게 감지하기 위해 Severity 기준 설정과 그에 따른 모니터링이 필요함

2. Severity 기준 설정 및 모니터링

알람 조건 설정하기

스크린샷 2024-05-18 오후 1 53 01

  • When : 모니터링할 이슈의 유형 지정

  • If : when 조건이 충족된 후, if 조건의 필터를 확인해 이슈를 트리거함

  • Then : when과 if 조건이 충족되면 슬랙과 같은 툴로 알람을 전송함


EX: API 에러에 대한 알람 조건 설정하기

스크린샷 2024-05-18 오후 1 54 37

~> 위의 조건들을 조합하여 아래와 같이 설정 가능함.

스크린샷 2024-05-18 오후 1 55 37

3. 에러 데이터 분석

에러 데이터 수집 전 세웠던 가설

스크린샷 2024-05-18 오후 1 56 50

스크린샷 2024-05-18 오후 1 57 32

  • api에 대한 에러가 대부분일것이다 ⇒ 가설 적중

  • apiNotFoundError의 경우 약속된 에러 케이스들이 섞여 있었음

⇒ 이는 빈번하게 발생할 수 있기 때문에 무분별한 수집은 데이터 분석에 방해가 될 수 있다는 인사이트를 얻을 수 있었음

~> 유의미한 데이터를 수집하자

⇒ 언제 에러데이터를 쌓는 것이 좋을지 생각해보게 되었음

유의미한 데이터를 수집하자

스크린샷 2024-05-19 오전 1 00 10

  • chunk load 에러나 network 에러는 사용자에 환경에 따라 발생할 수 있기 때문

  • timeout 에러는 수집하는데, cs를 대응하거나 사용자 경험을 개선할 수 있는 지표를 체크하기 위함임

서버와의 로그 분석 정합성 높이기

  • 견고한 추적을 위해 추가적인 작업 진행

  • 서버와 약속된 custom header를 추가하여 API를 요청함

  • 이는 에러 상황 시 서버 로그와 프론트엔드에 남은 데이터를 서로 대조하여 분석의 정합성을 높일 수 있음

스크린샷 2024-05-19 오전 1 01 32

4. 분석 결과에 따른 개선

  • QA 과정에서 발생하지 않았던 특정 기기와 특정 브라우저 버전에 대한 에러 발견

    ⇒ 폴리필을 추가하는 등의 대응이 가능 ⇒ 사용자 경험 개선

  • 장애 탐지 시간, 원인 파악, 해결까지의 시간이 줄어들었음

  • 오류 추적 시 디바이스 디버깅으로 특정 상황을 재현하지 않고도 로그를 통해 빠른 파악이 가능

    ⇒ 개발자 경험도 좋아졌으며 특히 QA 이슈를 해결할 때 많은 도움이 됨

  • 빈번하게 발생하는 오류에 대한 분석의 필요성을 느끼게 됨

  • 임계치에 대한 고민이 생김

    • 어느 정도의 수치가 적절하며

    • 어느 수치 이상부터 장애 상황으로 보아야 할지

profile
조금씩 꾸준히

0개의 댓글