알림 기반 모니터링
Source: Hacker News
팀들은 보통 인프라 모니터링을 “메트릭을 연결하고” “대시보드를 구축하는” 프로젝트와 연관 짓습니다.
실제로 거의 모든 모니터링 플랫폼에서 대시보드는 일등 시민입니다. 팀들은 이를 작업의 주요 산출물로 보는 경우가 많습니다. 빛나는 차트와 텔레메트리 행을 보는 것이 생산적인 느낌을 줍니다. 벽에 있는 거대한 TV에 띄우면 멋진 사무실 아트가 됩니다. 하지만 그래프를 하루 종일 보는 사람은 없습니다.
인프라 모니터링의 진정한 핵심은 대시보드가 아니라 알림입니다.
다른 플랫폼들은 알림을 사후 생각—시각화라는 “진짜 작업”이 끝난 뒤 체크하는 체크박스로—여기지만, 우리는 알림이 바로 전체 목적이라고 믿습니다. 알림은 운영의 중추입니다.
실패부터 시작하기
알림을 설정할 때 대부분의 팀은 이미 가지고 있는 메트릭부터 시작합니다. 사용 가능한 데이터 포인트 목록을 보고 다음과 같이 묻습니다:
“이 서버들의 CPU 사용량은 가지고 있어. 임계값은 얼마로 잡아야 할까? 합리적인 평가 기간은 어떻게 설정해야 할까?”
이것이 바로 소음이 많고 신뢰할 수 없는 시스템이 되는 정확한 이유입니다. 실제로 신뢰할 수 있는 시스템을 구축하려면 근본 원리부터 시작해야 합니다.
메트릭을 살펴보는 대신, 서비스 자체를 바라보세요. 스스로에게 다음 질문을 해보세요:
- 사용자가 서비스를 이용할 때 실제로 서비스가 실패했음을 나타내는 행동은 무엇인가?
- 서비스가 곧 실패할 가능성을 예측하게 하는 행동은 무엇인가?
- 일반적으로 어떤 메트릭 행동이 서비스 실패를 나타내거나, 더 나아가 예측할 수 있을까?
Tip
Simple Observability는 설정을 빠르게 시작할 수 있도록 알림 템플릿 카탈로그를 제공합니다. 이 템플릿들은 여러분의 특정 환경에 맞춰진 것은 아니지만, 아래에 설명된 반복적인 강화 과정의 훌륭한 기반이 됩니다.
늑대 소리를 외친 소년 단계
알림을 설정할 때, 팀은 보수적으로 접근하는 경향이 있습니다. 최적의 임계값을 아직 알지 못하기 때문에, 이해할 수 있게도 안전하게 행동하려 합니다. 하지만 이는 보통 많은 오경보를 발생시킵니다.
처음에는 알림을 감당할 수 있습니다. 그러나 실시간 시스템의 현실이 다가옵니다:
- 새벽 2시 정각에 실행되는 크론 작업이 3분 동안 CPU를 급증시킵니다. Ping…
- 무작위 봇 크롤러가 몇 개의 죽은 링크를 방문해 오류 비율을 올립니다. Ping…
- 데이터베이스 백업이 짧은 지연을 일으키지만 몇 초 안에 사라집니다. Ping…
몇 개를 확인해 보니 “실제” 문제는 아니라는 것을 깨닫고 다시 작업에 복귀합니다. 알림은 멈추지 않고, 배경에서 꾸준히 울리는 소음이 되어 무시하게 됩니다.
결국 Slack 채널이나 이메일 폴더가 알림으로 가득 차서 어느 알림이 실제로 발생했는지 구분할 수 없게 됩니다. “뭔가 실제로 문제가 있는 걸까? 아니면 또 다른 화요일일 뿐일까?”
이것이 알림 피로—모니터링이 제대로 설정되지 않았을 때 팀에게 스며드는 느낌입니다.
위험 구역은 전체 팀이 모니터링을 전혀 신뢰하지 않게 되는 순간입니다. 이는 늑대 소리를 외친 소년 이야기를 떠올리게 합니다. 팀이 시스템을 믿지 않게 되면서 전체 시스템이 실패합니다.
What to do about it
Fixing alert fatigue isn’t about finding a better math formula for your thresholds. It’s about putting clear systems in place, based on two simple principles:
Zero tolerance for false alarms
- If an alert can be ignored, it should not be an alert.
- Alerts should be actionable. If no action can or should be taken, the alert is unnecessary.
- Enforce a strict zero‑tolerance policy on false alarms. If an alert fires and no action was needed, either delete it or refine it until it only fires when human intervention is required.
Continual improvements
- You cannot build a perfect monitoring system on day one. You don’t yet know every way your infrastructure will fail, and you can’t predict every edge case.
- Instead of trying to architect the perfect system from the start, design a process that makes your system smarter over time. Treat alert rules as living code that must be maintained, just like unit tests.
In practice, it looks like this:
- Weekly reviews: Teams regularly meet and review every incident triggered by the monitoring system.
- Frequent pruning: If an alert was a false alarm, delete it immediately. If it didn’t help, it’s noise.
- Root cause analysis: If a real incident happened but the monitoring system didn’t catch it until it was too late, perform a root‑cause analysis. Identify the earliest metric that signaled the failure and create a new alert for that behavior so you can catch it earlier next time.
By iteratively hardening your monitoring, you make alerts a core part of your engineering culture while reducing the total number of incidents.