작은 회사의 모니터링 — 무엇을 보고 무엇을 무시하는가

모니터링 도구를 처음 도입하면 지표를 최대한 많이 수집하고 싶어진다. CPU, 메모리, 디스크, 네트워크, 응답 시간, 에러율, 커넥션 수… 수집할 수 있는 건 다 수집했다. 그러고 나서 알게 된 것은, 지표가 많다고 모니터링이 잘 되는 게 아니라는 사실이었다.

지표가 너무 많으면 생기는 문제

대시보드에 그래프가 가득 차면 뭘 봐야 할지 모른다. 정상 상태와 비정상 상태를 구분하는 기준이 없으면 그래프는 그냥 선의 묶음이 된다. 알림을 많이 설정해놓으면 자주 울리고, 자주 울리면 무감각해진다.

우리 팀도 초기에 이 함정에 빠졌다. 알림이 너무 자주 와서 결국 알림 채널 자체를 무시하게 됐고, 중요한 장애를 늦게 인지한 일이 한 번 있었다.

우리가 실제로 보는 것

지금은 기본 세 가지에 집중한다.

첫 번째는 오류 응답 비율이다. 5xx 응답이 평소보다 급증하면 서비스에 실질적인 문제가 생겼다는 신호다. 개별 에러 로그보다 비율을 보는 게 노이즈를 줄인다.

두 번째는 응답 지연이다. P95 또는 P99 기준으로 응답 시간이 임계치를 넘으면 알림이 온다. 평균값은 이상치에 묻히기 때문에 쓰지 않는다.

세 번째는 디스크 사용량이다. CPU나 메모리는 순간적으로 치솟아도 자동 회복되는 경우가 많다. 디스크는 다르다. 꽉 차면 서비스가 멈추고 복구가 번거롭다.

무시하는 것들

CPU 사용률은 웬만해선 알림을 걸지 않는다. 배치 작업이나 GC가 돌 때마다 치솟고, 대부분 자연스럽게 내려온다. CPU 알림은 거의 항상 오탐이었다.

JVM 힙 사용량, 스레드 수 같은 런타임 지표는 트러블슈팅 중에는 유용하지만 상시 모니터링 대상으로는 적합하지 않다. 그 숫자가 뭘 의미하는지 맥락 없이 보면 판단이 어렵다.

알림은 사람이 행동할 수 있는 것만

알림 설계의 기준을 하나로 정했다. 알림을 받았을 때 즉각 행동해야 하는 것만 알림으로 설정한다. “이상하네, 지켜봐야겠다” 수준이라면 알림이 아니라 대시보드에서 주기적으로 확인하는 방식으로 처리한다.

이 기준을 적용하니 실질적인 알림 수가 크게 줄었고, 알림이 오면 진짜 확인해야 하는 상황이 됐다.

모니터링은 많이 수집하는 것이 아니라, 중요한 것을 빠르게 발견하는 것이 목적이다.

— by slecs