알림이 끊기는 세 경계 복구하기

목표

실제 k3s·Prometheus Operator에서 선택되지 않은 규칙, 발화만 한 알림, 통지하지 않는
Alertmanager를 차례로 고칩니다. 현재 파드의 장애·복구 웹훅을 실제로 수신한 뒤 증거의
부족과 모순을 구분하는 진단 함수를 구현합니다.

왜 중요한가

Kubernetes API가 규칙을 저장해 줬다고 Prometheus가 그 규칙을 읽었다는 뜻은 아닙니다.
발화했다고 사람에게 전달된 것도 아닙니다. 공식 구성의 각 경계를 직접 고치고 API로
조회해 봐야 잘못된 설정, 아직 반영 중인 상태, 실제 전달 실패를 구별할 수 있습니다.

개인 VM 안에 Operator v0.94.0·Prometheus v3.14.0·Alertmanager v0.34.0과 발급 앱이
준비됩니다. 실행 프로세스가 있는 k3s이며 KWOK가 아닙니다. 설치는 수분 걸릴 수 있습니다.
작업은 55분 예상입니다. 더 필요하면 만료 전에 시간을 연장하고, 종료 전 필요한 기록은
내려받으세요. VM과 파일은 세션 종료 때 회수됩니다. VM 밖 운영 클러스터에는 적용하지 않습니다.

준비된 것

• 네임스페이스 platform-monitoring, team-lab. 규칙 provision-ready, Prometheus/Alertmanager platform
• ServiceMonitor workbench: Service 라벨 app=workbench와 Service 포트 이름 web을 선택
• 규칙: platform_provision_ready == 0, for 10s, 경고 라벨과 설명. 식과 spec은 유지
• 메트릭·프로세스는 정상이어도 발급 의존성은 고장 낼 수 있는 가상 앱
• 관측 도구: python3 /opt/fixtures/cnpe_operator_lab.py
• VM 내부 포트: 앱 30088, Prometheus 30090, Alertmanager 30093

observe는 한 번 조회하고, capture 단계번호는 최대 150초 기다린 후 정해진 JSON을
저장합니다. 둘 다 설정을 고치지 않습니다. timeout이면 재설치하지 말고 현재 설정과
동작을 조사한 뒤 다시 관측하세요. grade 단계번호는 저장 파일을 수정하지 않습니다.

단계

1. 준비된 ServiceMonitor·PrometheusRule을 조회하고 capture 1로 /root/cnpe-alerts/baseline.json을 저장하세요. 메트릭 대상 up과 규칙의 API 저장을 확인합니다. 처음에는 규칙이 선택되지 않아 로드되지 않습니다. 나중에 다시 수집하면 그때의 실제 상태를 기록하며, 초기 실패를 꾸며 쓰지 않습니다.
2. team-lab 네임스페이스의 labhub.io/rules 라벨만 allowed로 고치세요. Prometheus의 선택자를 전체 네임스페이스로 넓히지 않습니다. capture 2로 namespace.json을 저장하고, 아직 다른 규칙 선택 조건이 남아 있는지 확인하세요.
3. team-lab의 PrometheusRule provision-ready에 platform=training 라벨을 붙입니다. 규칙의 spec은 바꾸지 않습니다. capture 3으로 selected.json을 저장하여 Prometheus API에 provision 규칙 그룹이 실제 로드됐는지 확인하세요.
4. VM 내부 발급 앱의 POST /mode에 JSON {"ready":false}를 보내 의존성 장애를 만드세요. capture 4로 firing.json을 저장합니다. 발급 응답은 503, Prometheus는 firing이지만 Alertmanager·웹훅에는 알림이 없는 상태를 확인합니다. 외부 서비스에는 장애를 주입하지 않습니다.
5. platform-monitoring의 Prometheus platform에 spec.alerting.alertmanagers를 추가하세요. namespace=platform-monitoring, name=alertmanager, port=web인 항목 하나입니다. 준비된 조회 RBAC는 유지합니다. capture 5로 received.json을 저장하여 Alertmanager 수신과 웹훅 미수신을 분리하세요.
6. /root/cnpe-alerts/alertmanager.yaml에 내부 receiver를 작성합니다. route.receiver=local-webhook, group_by=[alertname], group_wait=1s, group_interval=5s, repeat_interval=1h입니다. receivers의 local-webhook은 URL http://workbench.team-lab.svc:8080/hook과 send_resolved=true를 사용합니다. 같은 네임스페이스의 Secret alertmanager-platform, 키 alertmanager.yaml로 적용한 뒤 capture 6으로 notified.json을 저장하세요. 이 URL 밖으로 발송하지 않습니다.
7. 현재 파드의 firing 웹훅을 먼저 확인하세요. POST /mode에 {"ready":true}를 보내 복구하고 capture 7로 recovered.json을 저장합니다. 201 응답, 활성 알림 해소, 같은 파드의 firing·resolved 수신을 모두 확인합니다. 옛 파드의 resolved를 이번 복구로 인정하지 않습니다.
8. /root/cnpe-alerts/diagnose.py에 diagnose(e)를 구현하세요. 아래 진단 계약에 따라 문자열 한 개를 반환합니다. 관측 없음·모순·누락·숫자나 문자열로 쓴 불리언을 unknown으로 다루며, 저장·발화·수신을 한 성공으로 뭉치지 않습니다.

8단계 진단 계약

e에는 observed·selected·loaded·firing·received·notified·recovered 일곱 실제 bool이
모두 필요합니다. received·notified는 같은 장애가 해당 경계를 통과한 이력이고,
firing은 현재 발화 여부입니다. 이 함수는 이미 대조된 증거 요약을 입력받습니다.

• 타입·필수 필드가 틀리거나 observed=False이면 unknown
• selected=False: 이후 다섯 필드가 전부 False이면 not_selected, 아니면 unknown
• selected=True, loaded=False: 이후 네 필드가 전부 False이면 not_loaded, 아니면 unknown
• selected·loaded=True에서 recovered=True: firing=False, received·notified=True일 때만 recovered
• 같은 조건에서 recovered=False, notified=True: firing·received=True일 때만 notified
• notified·recovered=False, received=True: firing=True일 때만 receiver
• received·notified·recovered=False: firing=True이면 delivery, False이면 inactive
• 위에 적힌 '때만' 조건을 못 맞춘 조합은 unknown

참고

정상 메트릭 수집 up은 업무 성공의 지표가 아닙니다. 이 실습 gauge는 의존성 상태를
재현하는 값이지 운영 SLO가 아닙니다. 그룹의 status만으로 개별 알림의 상태를 정하지 마세요.
이번 단계 기록은 rule UID·pod UID·규칙 내용과 대조합니다. 파드를 다시 만들었다면
관측도 다시 해야 합니다. 이 파일 비교는 암호학적 원격 증명이거나 부정행위 방지 장치가 아닙니다.
1·4·5·6단계는 보존한 과거 관측을, 2·3·7단계는 현재 상태도 확인합니다. 정상 복구 후에도
과거 장애 기록을 정상 JSON으로 덮어쓰지 마세요. 수신 기록은 앱 메모리에만 있으며 재시작하면 사라집니다.
단계 준비는 앞 구성만 요청하고 현재 답이나 관측 파일은 만들지 않습니다. 7단계는
복구하기 전에 firing 수신을 먼저 기다리세요. 8단계는 독립적인 코드 과제입니다.

외부 웹훅·이메일·채팅 발송, 고가용성 알림 경로, 실사용자 SLO 검증은 다루지 않습니다.
공식 문서: [규칙 선택](https://prometheus-operator.dev/docs/developer/alerting/) ·
[ServiceMonitor 문제 해결](https://prometheus-operator.dev/docs/platform/troubleshooting/) ·
[알림 상태](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/).

단계 8개

1. 메트릭과 저장된 규칙 구별
2. 네임스페이스 선택 좁게 고치기
3. 라벨을 고치고 실제 로드 확인
4. 발화했지만 전달되지 않는 장애
5. Alertmanager에 연결하고 수신 확인
6. 내부 웹훅으로 실제 발송
7. 이번 장애의 복구인지 대조
8. 빈 증거를 성공으로 바꾸지 않는 진단기