Datadog 에러 수집과 알림 조건

일간 리포트에는 있는데 Slack 알림으로는 오지 않는 에러가 있었다. RUM에 찍힌 에러가 모두 신규 에러 알림의 대상은 아니었다.

수집 출처, 이슈 상태, 모니터 조건을 나눠서 정리했다. 아래 쿼리와 수치는 설명용 예시다. 실제 운영 설정이나 알림 테스트 결과는 포함하지 않았다.

RUM에 보이는 에러와 알림 대상은 다르다#

RUM의 에러 이벤트, Error Tracking의 이슈, 모니터의 알림은 따로 확인해야 한다. 에러 이벤트가 수집돼도 Error Tracking의 처리 조건에 맞지 않을 수 있고, 이슈가 있어도 모니터 조건에서 빠질 수 있다.

error.source는 에러가 어떤 방식으로 수집됐는지 나타낸다. 이름에 source가 있다고 더 심각한 에러라는 뜻은 아니다.

현재 공식 문서에서는 source, console, custom, report 중 스택 트레이스가 있는 에러를 Error Tracking 처리 대상으로 설명한다. console 에러라서 이슈로 잡히지 않는다고 단정하면 안 된다. 실제 이벤트에 스택이 있는지, 수집 규칙에서 제외됐는지도 확인해야 한다. 다만 브라우저 확장 프로그램에서 보낸 에러는 Error Tracking 처리 대상에서 제외된다.

참고: 브라우저 에러 수집, Error Tracking 문제 해결

New Issue와 High Impact#

New Issue는 최근 발생한 에러를 전부 알려주는 모니터가 아니다. 처음 발견하거나 재발한 이슈를 확인하는 용도다. 이미 확인한 에러가 계속 발생하는지도 보려면 High Impact 조건을 따로 봐야 한다.

Reviewed는 확인했다는 뜻이지 해결됐다는 뜻은 아니다. 담당자를 지정하는 것만으로 이 상태가 될 수도 있다. 따라서 에러가 계속 발생하는데 신규 알림만 오지 않는 상황이 가능하다.

New Issue에는 시점 조건도 있다. 공식 문서 기준으로 모니터 생성 또는 마지막 수정 이후에 생성·재발한 이슈를 대상으로 하고, 24시간 lookback을 적용한다. 예전에 있던 에러를 다시 발생시켰다는 이유만으로 신규 알림이 와야 하는 건 아니다.

그렇다고 이슈당 한 번만 알린다는 뜻도 아니다. 이슈를 For Review로 둔 채 그 이슈의 모니터 평가 상태가 OK와 ALERT를 오가면 다시 알림이 올 수 있다.

참고: Error Tracking 모니터 조건, 이슈 상태

이름이 비슷해서 헷갈리는 부분#

아래는 공식 문서의 High Impact 예제를 바탕으로 만든 쿼리다. 서비스 이름은 가짜 값이다.

error-tracking("service:example-web env:prod")
  .source("browser")
  .impact()
  .rollup("count")
  .by("issue.id")
  .last("1d") > 10

여기서 .source("browser")는 브라우저 쪽 이슈를 선택한다. 앞에서 본 error.source의 source, console 구분과는 다른 설정이다.

.new()도 에러에 붙이는 태그가 아니다. 모니터의 감지 방식이다. 자바스크립트에서 new Error()로 객체를 만드는 것과도 관계없다.

예제는 조건에 맞는 에러를 이슈별로 묶고, 최근 하루의 발생 횟수가 10회를 초과하면 알리는 조건이다. 전체 이슈를 더한 합계가 아니고, 정확히 10회인 경우도 포함하지 않는다. 줄바꿈은 읽기 쉽게 넣었다.

발생 횟수와 영향받은 세션 수#

한 세션에서 같은 에러가 20번 반복된 경우와 20개 세션에서 한 번씩 발생한 경우는 발생 횟수가 같다. 하지만 영향 범위는 다르다.

모니터는 발생 횟수뿐 아니라 영향받은 세션이나 사용자 수를 기준으로 설정할 수 있다. 위 예제의 count를 쓰면서 세션 수를 기준으로 알린다고 설명하면 안 된다. 무엇을 세는지, 얼마 동안 세는지, 이슈별인지 환경별인지까지 같이 읽어야 한다.

참고: 임계치 지표와 그룹 설정

알림이 안 올 때 확인할 순서#

바로 임계치를 낮추기 전에 다음 순서로 확인하면 원인을 좁히기 쉽다.

1. RUM 이벤트: 찾는 서비스·환경·시간 범위에 실제 이벤트가 있는지
2. Error Tracking 이슈: 수집 출처와 스택 등 처리 조건에 맞고 이슈로 묶였는지
3. 모니터 필터: 서비스·환경·제외 조건이 해당 이슈와 맞는지
4. 감지 방식과 상태: New Issue인지 High Impact인지, 이슈 상태와 생성·재발 시점이 조건에 맞는지
5. 집계 조건: 발생 횟수인지 세션 수인지, 평가 구간과 그룹별 임계치를 넘었는지
6. 알림 설정: 모니터가 실제로 ALERT가 됐는지, 음소거나 수신 대상 설정은 어떤지

특히 알림에서 제외하는 것과 수집을 막는 것은 다르다. 이슈를 Ignored로 바꾸면 해당 이슈의 모니터 알림은 음소거되지만 RUM 에러 이벤트는 계속 기록될 수 있다. RUM 전송 자체를 막는 beforeSend 필터와 구분해야 한다.

참고: Ignored 상태, RUM 에러 수집과 제외

이 노트는 공식 문서로 조건을 정리한 내용이다. 실제 설정을 바꿀 때는 개발 환경에서 수집된 이벤트와 이슈 상태를 확인하고, 모니터 평가부터 Slack 수신까지 별도로 검증해야 한다.

구축 과정은 프론트엔드 에러 알림 구축에 따로 적었다.