알림의 성공 기준은 감지가 아니라 조치다

한 줄 요약

알림 규칙은 inactive → pending → firing 상태 기계를 돌고, Alertmanager 는 받은 알림을 Wait → Dedup → Retry → Inhibit → Silence → Notify 순서로 처리합니다. 이 두 파이프라인의 어디에서 알림이 사라지는지를 알면 "왜 알림이 안 왔는가"를 3분 안에 좁힐 수 있습니다.

왜 이게 필요했나

온콜이 무너지는 전형적인 경로는 이렇습니다. 사고가 하나 나면 회고에서 "이걸 미리 알았어야 했다"는 결론이 나오고 알림이 하나 추가됩니다. 2년이면 규칙이 300개가 되고, 슬랙 채널에는 하루 400건이 쌓이고, 온콜은 밤에 세 번 깨어나 세 번 다 아무것도 하지 않고 다시 잡니다.

하루 400건 중 실제 조치가 필요한 것이 4건이면 정밀도는 1% 입니다. 이 상태에서 사람이 학습하는 최적 전략은 "일단 무시하고 나중에 확인"이고, 그것이 합리적이기 때문에 더 위험합니다. 훈련이나 각오로 되돌릴 수 없습니다.

그래서 실무 목표를 숫자로 둡니다. 12시간 교대당 페이지 2건 이하, 페이지의 조치 전환율 70% 이상. 이 둘을 넘으면 알림을 추가할 때가 아니라 삭제할 때입니다.

어떻게 동작하나

알림 상태 기계

inactive --(표현식 매칭)--> pending --(for 경과)--> firing --(매칭 해제)--> resolved                              |                              +--(중간에 거짓)--> inactive  (타이머 0 으로 초기화)

for 의 핵심은 연속입니다. 중간에 한 번이라도 거짓이 되면 타이머가 0 으로 돌아갑니다. 이것이 플래핑을 막는 원리입니다. 여기서 흔한 잘못된 조언이 있습니다. "오탐이 많으니 for 를 30분으로 늘리자." 동작은 하지만 탐지가 30분 늦어지고, 사고가 25분 만에 끝나면 알림이 아예 울리지 않습니다. 그리고 진짜 문제는 남습니다 — 표현식 자체가 노이즈를 보고 있다는 사실입니다.

올바른 순서는 긴 창의 rate 로 노이즈를 평활화하고, 짧은 창을 AND 로 걸어 진행 중임을 확인하고, for 는 마지막에 2~5분만 걸어 스크레이프 결측 한두 번을 흡수하는 것입니다. 긴 창을 이미 쓰는데 for 가 15분을 넘으면 창 설계가 잘못된 것입니다.

firing 인 알림은 매 평가 주기마다 Alertmanager 로 재전송됩니다. 그때 endsAt 을 현재 시각 + 4 × evaluation_interval 로 잡아, 다음 전송이 오기 전에 만료되지 않게 합니다. 프로메테우스가 죽으면 알림이 자동으로 resolved 되는 이유가 이 만료 설계입니다.

Alertmanager 파이프라인

| 단계 | 하는 일 | 놓치기 쉬운 점 |
| --- | --- | --- |
| Wait | 그룹이 새로 생기면 group_wait 만큼 모은다 | 기본 30초 |
| Dedup | 이미 보낸 알림인지 notification log 로 확인 | HA 는 gossip 으로 이 로그를 공유 |
| Retry | 실패 시 지수 백오프 재시도 | |
| Inhibit | source 가 firing 이면 target 을 막는다 | equal 레이블이 같아야 성립 |
| Silence | 사람이 만든 사일런스와 매칭 | 만료 없는 사일런스는 삭제해야 할 알림의 신호 |
| Notify | 실제 전송 | |

세 가지 타이머의 차이가 시험 단골입니다. group_wait 은 새 그룹의 첫 전송 전 대기(기본 30초), group_interval 은 기존 그룹에 새 알림이 추가됐을 때의 전송 간격(기본 5분), repeat_interval 은 변화가 없는 그룹을 다시 상기시키는 간격(기본 4시간)입니다.

group_by 에 무엇을 넣느냐가 알림 개수를 결정합니다. 인스턴스 단위로 묶으면 파드 수만큼 알림이 오고, 서비스나 SLO 단위로 묶어야 사람이 읽을 수 있는 개수가 됩니다.

억제와 사일런스는 자주 헷갈립니다. 억제는 설정 파일에 적힌 규칙 기반 자동 차단이고, 사일런스는 사람이 UI 나 API 로 만드는 일시 차단입니다. 둘 다 알림을 막지만 UI 에서는 여전히 보입니다.

다중 윈도 번 레이트는 SRE 워크북의 표준 조합입니다.

| 예산 소진 | 긴 창 | 짧은 창 | 임계 번 레이트 | 대응 |
| --- | --- | --- | --- | --- |
| 2% | 1시간 | 5분 | 14.4 | 즉시 호출 |
| 5% | 6시간 | 30분 | 6 | 즉시 호출 |
| 10% | 1일 | 2시간 | 3 | 티켓 |
| 10% | 3일 | 6시간 | 1 | 티켓 |

짧은 창은 긴 창의 12분의 1로 잡는 것이 관례입니다. 짧은 창의 역할은 민감도가 아니라 해소 속도입니다. 짧은 창이 없으면 사고가 끝난 뒤에도 긴 창이 창 길이만큼 알림을 유지합니다.

현장에서 만나는 모습

for: 를 빼먹은 규칙 하나 때문에 하루 50건 넘는 알림이 쏟아진 적이 있습니다. 결과는 예상대로였습니다 — 사람들이 그 알림을 무시하기 시작했고, 무시가 습관이 되자 같은 채널의 진짜 신호도 함께 묻혔습니다. 알림 하나의 정확도가 아니라 온콜 전체의 반응 속도가 망가진 것입니다.

저트래픽 구간도 반복되는 함정입니다. 5분에 요청 3건이 들어오는 새벽에 1건이 실패하면 오류율은 33% 가 되어 모든 번 레이트 임계값을 한 번에 넘습니다. 최소 트래픽 조건을 AND 로 걸어야 유령 알림이 사라집니다. 트래픽이 아예 0 이면 비율이 NaN 이 되어 알림이 조용히 없어지는데, 그 경우는 처리량 급감 알림이 따로 잡아야 합니다.

그리고 페이지에는 런북을 강제합니다. 새벽 3시에 깨어난 사람은 창의력을 발휘할 상태가 아닙니다. 필요한 것은 확인할 것 세 가지와 조치 두 가지가 적힌 문서입니다. CI 게이트로 severity=page 인데 runbook_url 이 없는 규칙을 찾아 빌드를 깨면, 이 규율이 사람 기억에 의존하지 않게 됩니다.

다음 실습에서 할 것

/root/pca-alerting/ 아래에 Alertmanager 라우팅 트리와 억제 규칙을 쓰고, 빠른 소진과 느린 소진 두 개의 번 레이트 알림을 만듭니다. 마지막에는 런북 누락을 잡아내는 CI 게이트 스크립트를 직접 작성하고, 정상 파일은 통과시키고 런북 없는 파일은 막는지 확인합니다.