밤새 경보 일흔 번이 울렸고 사용자는 아무 일도 겪지 않았다

목표

원인 기준 경보 네 개와 증상 기준 경보 하나를 실제 자료 위에서 세어 보고, 호출 수와 헛된 호출 시간을 근거로 무엇을 사람에게 보내고 무엇을 내릴지 결정합니다.

왜 중요한가

경보를 늘리는 일은 쉽고 줄이는 일은 어렵다. 어려운 이유는 근거가 없기 때문이다 — "이 경보 시끄럽지 않아?" 는 의견이지만 "이 경보는 12시간에 예순다섯 번 울렸고 그중 230분은 사용자가 아무 일도 겪지 않은 시간이었다" 는 자료다. 자료가 있으면 회의가 짧아진다. 그리고 같은 자료가 지속 시간 손잡이의 값도 정해 준다. 경보 설계는 임계값을 고르는 일이 아니라, 사람이 감당할 수 있는 호출 총량 안에서 무엇을 탐지할지 고르는 일이다.

단계

1. /root/obs-alert-symptom/rules/causes.yml 에 Prometheus 규칙 파일을 쓰세요. 그룹 이름은 causes 이고 경보 네 개가 들어갑니다. CauseQueueDepth 는 queue_depth{job="shop-api",queue="orders"} 가 100 을 넘을 때, CauseDiskPredict 는 node_filesystem_avail_bytes{job="node"} 의 최근 1시간 추세로 6시간 뒤를 예측했을 때 0 미만일 때, CauseLatencyTail 은 최근 5분 기준 p99 지연이 0.5초를 넘을 때, CauseTrafficLow 는 최근 5분 기준 초당 요청 수가 55 미만일 때 울립니다. promtool check rules 로 검사가 통과해야 합니다. 이 단계에서는 for: 를 붙이지 않습니다.
2. /root/obs-alert-symptom/count.py 를 만드세요. python3 count.py '<경보 식>' <for 분> 으로 부르면 최근 12시간을 1분 간격으로 훑어 episodes=<호출 수> minutes=<울린 분> 한 줄을 출력합니다. 조건이 참인 분이 연속으로 L분 이어졌을 때, L 이 for + 1 이상이면 호출 한 번으로 세고 울린 시간은 L - for 분입니다. for 를 주지 않으면 0 으로 봅니다.
3. /root/obs-alert-symptom/counts.tsv 를 만드세요. 머리글 없이 네 줄이고 각 줄은 탭으로 나눈 세 칸 <경보이름> <호출 수> <울린 분> 입니다. for 는 0 으로 두고, 1단계 규칙 파일에 쓴 네 경보를 이름 그대로 씁니다. 값은 2단계 도구로 구합니다.
4. 3단계에서 가장 많이 울린 경보 하나를 골라, for 를 0·5·15 분으로 바꿔 가며 다시 세세요. /root/obs-alert-symptom/for-effect.tsv 에 머리글 없이 세 줄, 각 줄은 <for 분> <호출 수> <울린 분> 입니다.
5. /root/obs-alert-symptom/rules/symptom.yml 에 symptom 그룹과 경보 SymptomErrorRatio 하나를 쓰세요. 조건은 최근 5분 기준 5xx 응답 비율이 1% 를 넘는 것이고, for: 5m 과 runbook_url 주석을 답니다. promtool check rules 를 통과시킨 뒤, 같은 식을 for 0 으로 세어 /root/obs-alert-symptom/symptom.txt 에 episodes=<수> minutes=<분> 한 줄을 적으세요.
6. /root/obs-alert-symptom/overlap.py 를 만드세요. python3 overlap.py '<원인 식>' '<증상 식>' 으로 부르면 최근 12시간을 1분 간격으로 훑어 cause_minutes=<원인이 참인 분> outside_minutes=<그중 증상이 참이 아닌 분> 한 줄을 출력합니다. 그 도구로 원인 경보 네 개를 각각 재서 /root/obs-alert-symptom/falsepages.tsv 에 탭으로 나눈 세 칸 <경보이름> <원인 분> <증상 밖 분> 네 줄을 적으세요.
7. /root/obs-alert-symptom/triage.tsv 에 다섯 줄을 적으세요. 각 줄은 탭으로 나눈 세 칸 <경보이름> <page|ticket|dashboard> <근거> 이고, 원인 경보 넷과 SymptomErrorRatio 를 모두 적습니다. 규칙은 둘입니다 — 증상 경보는 반드시 page, 그리고 6단계에서 증상 밖 분이 60분을 넘은 원인 경보는 page 로 둘 수 없습니다. 근거에는 앞 단계에서 얻은 숫자가 하나 이상 들어가야 하고 20자 이상이어야 합니다.
8. /root/obs-alert-symptom/rules/page.yml 에 7단계에서 page 로 분류한 경보만 담으세요. 그룹 이름은 page 이고, 각 경보에는 for: 가 5분 이상, labels 의 severity: page, annotations 의 runbook_url 이 있어야 합니다. promtool check rules 를 통과시킨 뒤, 그 경보들을 각자의 for 값으로 세어 호출 수를 모두 더한 값을 /root/obs-alert-symptom/after.txt 에 pages_after=<수> 한 줄로 적으세요.

참고

• 작업 디렉터리는 /root/obs-alert-symptom 입니다. 규칙 파일은 /root/obs-alert-symptom/rules/ 아래에 두세요 — /etc/prometheus/rules/ 에 두면 이 파드의 Prometheus 가 실제로 평가하기 시작합니다.
• 규칙 검사: promtool check rules <파일>. 쿼리 확인: promq "<PromQL>".
• 구간 자료: /api/v1/query_range 에 query·start·end·step 을 줍니다. 조건이 거짓인 시각에는 표본이 아예 없습니다.
• 흔한 실수: 조건이 참인 표본 수를 그대로 호출 수로 세는 것. 연속 구간 하나가 호출 한 번입니다.
• 흔한 실수: for 를 붙이면 탐지가 그만큼 늦어진다는 사실을 빼놓고 호출 수만 자랑하는 것.
• [Monitoring Distributed Systems (SRE Book 6장)](https://sre.google/sre-book/monitoring-distributed-systems/) · [Alerting on SLOs (SRE Workbook)](https://sre.google/workbook/alerting-on-slos/) · [Being On-Call (SRE Book 11장)](https://sre.google/sre-book/being-on-call/) · [Alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) · [HTTP API — range queries](https://prometheus.io/docs/prometheus/latest/querying/api/)

단계 8개

1. 원인 기준 경보 네 개를 규칙 파일로 쓴다
2. 몇 번 울렸을지 세는 도구를 만든다
3. 원인 경보 넷이 12시간 동안 몇 번 울렸나
4. 지속 시간 하나로 호출이 얼마나 줄어드나
5. 증상 기준 경보 하나를 쓴다
6. 사용자가 아무 일도 겪지 않은 시간에 몇 분이나 울렸나
7. 숫자를 근거로 호출·티켓·대시보드를 가른다
8. 호출용 규칙 파일만 남긴다