[모니터링] 저트래픽 서비스 4계층 관측 비율 대신 절대건수

부제: 하루 몇십 요청짜리 서비스에서 비율 임계값이 무의미한 이유

모니터링을 계층으로 쌓았다.
호스트(자원이 한계인가), 컨테이너, 컴포넌트(DB·redis 내부), 그리고 서비스(앱이 요청을 제대로 처리하나).

계층을 나눈 데는 이유가 있고, 알림 임계값을 정하는 데는 더 큰 고민이 있었다.

계층마다 다른 질문

각 계층은 서로 다른 질문에 답한다.

호스트는 "서버 자원이 한계인가"를 본다. CPU·메모리·디스크의 사용률과 포화다.
컨테이너는 그 자원이 어느 컨테이너로 갔는지를 나눈다.
컴포넌트는 DB·redis 같은 내부 부품이 건강한지를 본다.

그런데 여기까지로는 정작 중요한 게 안 보인다.
"앱이 사용자 요청을 실제로 성공시키고 있나."
호스트가 멀쩡해도 앱은 500을 뱉고 있을 수 있다.

그래서 마지막 계층을 서비스로 뒀다.
요청의 처리율·에러·응답시간을 본다. 사용자가 체감하는 건 결국 이 계층이다.

비율로 알림을 걸면 깨진다

문제는 알림이었다.
교과서적인 방식은 "에러율이 몇 % 넘으면 알림"이다.

이 서비스엔 그게 안 맞았다.
핵심 API가 하루에 스무 번 남짓 불린다. 트래픽이 아주 낮다.

낮은 트래픽에서 비율은 무너진다.
10분 동안 요청이 한 건 왔는데 그게 실패하면 에러율은 100%다.
그게 장애일까, 그냥 우연한 한 건일까. 비율만으론 구분이 안 된다.
요청이 0건이면 아예 분모가 0이라 비율을 계산할 수도 없다.

몇 %가 아니라 몇 건

그래서 알림은 비율이 아니라 절대건수로 걸었다.
"10분 동안 5xx가 한 건이라도 늘면" 같은 식이다.

이건 분모가 0이든 1이든 깨지지 않는다.
실패가 실제로 몇 건 생겼는지만 보기 때문이다.
비율은 버리지 않았다. 대신 알림이 아니라 대시보드와 기준선(baseline)을 잡는 데만 썼다.
추세를 눈으로 볼 땐 비율이 유용하고, 사람을 깨우는 임계엔 절대건수가 맞다.

곁들인 원칙 몇 가지

계측을 얹으면서 몇 가지 선을 그었다.

새 컨테이너는 만들지 않았다.
앱과 nginx가 각자 자기 지표를 노출하고, 수집기가 그걸 직접 긁어 가게 했다.

라벨에 사용자·요청 단위를 넣지 않았다.
그러면 지표 조합이 무한히 늘어나(카디널리티 폭발) 수집기가 감당을 못 한다.

같은 걸 두 번 재지 않았다.
LLM 응답 시간·비용은 별도 관측 도구가 전담하니, 여기선 중복 계측하지 않았다.

정리

• 모니터링을 호스트·컨테이너·컴포넌트·서비스 4계층으로 나눠, 각 계층이 다른 질문에 답하게 했다
• 알림 임계는 비율이 아니라 절대건수로 — 저트래픽에선 분모가 0/1이라 비율이 깨진다
• 비율은 알림이 아니라 대시보드·기준선에만 사용
• 새 컨테이너 0, 사용자·요청 라벨 금지(카디널리티), 이중 계측 금지

모니터링 교과서는 대개 큰 트래픽을 전제한다.
하루 몇십 요청짜리 서비스에선 "몇 %"가 아니라 "몇 건"으로 봐야 알림이 제대로 운다.