← 모든 글

알람이 너무 많으면 아무도 안 본다 — 임계값을 다시 정한 이유

알람 피로가 쌓이면 진짜 장애 알림도 묻힌다. threshold tuning 실전 회고.

알람 채널에 하루 200건이 넘어가던 시점이 있었다. 아무도 안 봤다. 정확히는, 보긴 했는데 #alerts 채널을 자동으로 읽음 처리하는 습관이 팀 전체에 생겼다.

그러다 실제 API latency 급등을 12분 늦게 잡았다. 채널에 알림이 와 있었다. 그냥 묻혔던 것이다.

무엇이 문제였나

당시 임계값 설정 방식은 간단했다. 서비스 처음 뜰 때 “일단 빡빡하게” 잡아두고, 이후 조정 없이 운영. p95 latency 가 300ms 초과하면 알람, CPU 60% 넘으면 알람, 메모리 70% 넘으면 알람.

문제는 서비스가 1년 동안 자랐다는 거다. 트래픽 패턴이 바뀌었고, p95 기준 평균이 원래 200ms 에서 280ms 로 올라가 있었다. 그러니 정상 상태에서도 300ms 를 자주 건드렸다. CPU 도 배치 작업이 하나 추가된 이후로 상시 65% 였다.

임계값이 현실을 반영하지 못한 채로 굳어 있었던 것. 알람이 “이상하다”가 아니라 “그냥 항상 오는 것”이 됐다.

먼저 노이즈 규모를 측정했다

2주치 알람 로그를 뽑아서 유형별로 분류했다. 직접 세다가 포기하고 간단한 Python 스크립트 짰다.

  • CPU 60% 알람: 하루 평균 67건. 그 중 실제 조치가 필요했던 건 2건.
  • p95 latency 300ms 알람: 하루 평균 88건. 조치 건수 4건.
  • 메모리 알람: 하루 평균 41건. 조치 건수 0건.

노이즈 비율이 98%였다. 숫자를 보고 나니 오히려 허탈했다. 팀이 알람을 무시하게 된 건 태도 문제가 아니었다. 설계 문제였다.

이 분석 자체가 꽤 충격이었던 게, 나는 막연히 “알람이 좀 많긴 하지” 정도로 느꼈는데 실제 수치는 그보다 훨씬 심각했다. 측정 안 하면 감각이 둔해진다는 걸 다시 확인했다.

임계값 재설정 기준을 새로 잡았다

무작정 숫자를 올리는 건 답이 아니다. 그렇게 하면 진짜 이상 신호를 놓친다. 기준이 필요했다.

우리가 정한 원칙은 세 가지였다.

첫째, 최근 30일 p99를 기준선으로 잡고, 그 1.5배를 초과할 때 알람. latency 예시로 하면 p99 가 320ms 라면 480ms 초과 시 알람. 일시적 spike 가 아니라 실질적 이탈을 잡겠다는 뜻이다. 기준을 p99 로 올린 건 의도적이었는데, p95 는 정상 트래픽에서도 너무 자주 눌렸다.

둘째, CPU 와 메모리는 절대값보다 추세를 본다. 단일 수치가 높은 것보다, 15분 이동평균이 계속 우상향하는 쪽이 훨씬 위험하다. Prometheus rule 에 increase() 함수 써서 추세 기반으로 바꿨다.

셋째, 알람 하나당 대응 절차를 반드시 붙인다. 절차가 없는 알람은 발행 금지. 이걸 강제하니 “이 알람 왜 있지?” 싶은 것들이 저절로 정리됐다.

적용 직후 숫자가 어떻게 바뀌었나

변경 적용 후 첫 주 기준.

  • 일 평균 알람: 196건 → 23건. 88% 감소.
  • 평균 초동 대응 시간: 14분 → 6분. 알람이 줄자 진짜 알람에 집중이 됐다.
  • 놓친 장애: 첫 2주 기준 0건. 이전 같은 기간에 2건이었다.

숫자만 보면 깔끔하다. 실제로는 처음 며칠이 불안했다. 알람이 안 오니까 “혹시 설정이 잘못된 거 아닌가?” 하는 느낌. 팀원 한 명이 “채널이 너무 조용한데 괜찮은 거 맞죠?” 했는데, 그게 오히려 정상이라는 걸 몸으로 다시 익혀야 했다.

놓치기 쉬운 함정 하나

임계값을 올리면서 생기는 진짜 위험은 따로 있다. dead man’s switch 가 없어지는 것이다.

알람이 아예 안 오는 상태가 “정상이라 안 온 건지” vs “파이프라인이 죽어서 안 온 건지” 구분이 안 된다. 이전에 한 번 Prometheus scrape 가 조용히 멈췄는데 알람이 없으니 하루 넘게 몰랐다.

그래서 heartbeat 알람을 별도로 달았다. 매 5분마다 특정 메트릭이 들어오는지 확인하고, 2 cycle 이상 없으면 “수집 파이프라인 이상” 알람. 이건 임계값 튜닝과 별개로 꼭 있어야 하는 안전망이다. 알람 수를 줄이면서 이 부분을 빠뜨리면 오히려 역효과가 난다.

다음 한 가지

30일마다 임계값 기준선을 자동으로 재계산하는 스크립트를 만들어두고, 수동 리뷰 없이 방치하지 않기. 지금은 사람이 분기에 한 번 보자고 말만 해두고 있는데, 지난번에 “말만 하는 회의 없애기로 했던 것” 이번엔 진짜 스크립트로 굳힌다.


🛒 이 글과 어울리는 추천 상품

위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.