Alertmanager

Prometheus가 경보를 "감지"한다면, Alertmanager는 그 경보를 받아 중복 제거·그룹화·라우팅한 뒤 receiver(webhook/Discord/Slack/email)로 발송하는 시스템이다.^[1] 핵심 역할은 경보 발송 자체가 아니라 "어떤 경보를 어디로, 어떻게 묶어서 보낼 것인가"를 결정하는 것이다.

• 상위 탐색 경로: Devtools Overview.
• 운영 배포 경계: GitHub Actions Workflow와 함께 alert rule·routing 변경의 검증 및 배포 책임을 분리한다.

flowchart LR
  Prom["Prometheus
alert rule 평가"]
  Am["Alertmanager"]
  Route["route
severity 분기"]
  Recv["receivers
Discord/Webhook/Slack"]
  Prom -->|fire alerts| Am
  Am --> Route
  Route --> Recv

핵심 요소

inhibition은 다른 firing alert의 존재로 notification을 억제하는 규칙 기반 관계이고, silence는 운영자가 matcher와 기간을 지정해 잠시 notification을 억제하는 명시적 운영 조치라고 볼 수 있다. 둘을 같은 기능으로 취급하면 장애 대응 중 억제 원인을 추적하기 어렵다.

기본 설정 구조

• global.resolve_timeout은 경보가 해결되었다고 판단 후 "Resolved" 알림을 보내기까지의 시간이다.^[2]
• route.group_wait는 최초 경보 발생 후 그룹핑 대기 시간, group_interval은 기존 그룹에 새 경보 추가 시 전송 주기, repeat_interval은 같은 경보 반복 전송 주기다.^[2:1]

severity 기반 라우팅 + Discord 패턴

severity 라벨로 라우팅 분기를 하면 Critical/Warning을 서로 다른 receiver로 보낼 수 있다. 다만 severity는 Alert Rule에서 추가한 값 기준으로 분기된다는 점이 핵심이다 — Alert rule에서 severity: critical을 달지 않으면 라우팅이 동작하지 않는다.^[3]

route:
  receiver: "webhook-handler"
  group_by: ["alertname", "instance"]
  group_wait: 30s
  group_interval: 3m
  repeat_interval: 2h
  routes:
    - match:
        severity: critical
      receiver: "discord-critical"
    - match:
        severity: warning
      receiver: "discord-warning"

receivers:
  - name: "discord-critical"
    discord_configs:
      - webhook_url: "https://discord.com/api/webhooks/XXXXX"
  - name: "discord-warning"
    discord_configs:
      - webhook_url: "https://discord.com/api/webhooks/YYYYY"

Webhook receiver는 send_resolved: true로 해결됨 알림도 전송할지 제어할 수 있다. Alertmanager가 보내는 JSON은 version, status(firing/resolved), alerts[](labels + annotations) 구조다.^[4]

Inhibit Rule 예시

inhibit_rules:
  - source_match:
      alertname: "ApiDown"
    target_match:
      alertname: "High5xxRate"
    equal: ["instance"]

ApiDown이 firing이면 같은 instance의 High5xxRate 경보가 자동으로 억제된다.^[5] 이는 상위 에러 발생 시 하위 경보를 억제하는 예시이며,^[5:1] 하위 증상 알람이 사용자를 혼란시키는 것을 막는다는 목적은 이 page의 해석이다.

실행 전 검증

alertmanager --config.file=alertmanager.yml --log.level=debug
# 또는
amtool check-config alertmanager.yml

amtool check-config로 YAML 문법을 사전 검증하면 설정 오류를 배포 전 잡을 수 있다.^[6]

설정 예시의 경계

• Discord webhook, receiver URL, route label, inhibit rule은 조직의 incident policy와 secret 관리 방식에 따라 달라진다.
• Alertmanager는 alert를 수집하는 component가 아니라 Prometheus rule이 만든 alert를 group, route, inhibit, deliver하는 component다.

Prometheus가 Alert rule 평가만 담당하고, 발송 라우팅·중복 억제·해결 알림은 Alertmanager가 별도 스펙(alertmanager.yml)으로 다룬다. 이 분리 덕분에 알림 채널 변경이 Prometheus 재설정 없이 가능하다고 볼 수 있다.

흔한 실수

• route.receiver 기본 라우터를 정의하지 않으면 → 매칭되지 않은 경보가 사라진다.
• severity 라벨을 Alert Rule에서 추가하지 않고 라우팅만 설정하면 → 분기가 안 된다.
• group_wait/group_interval을 너무 짧게 설정하면 → 경보 폭주 시 Discord가 rate-limit에 걸린다.
• inhibit_rules의 equal 조건을 잘못 설정하면 → 의도치 않은 경보까지 억제된다.
• maintenance 중 silence를 만들지 않고 route를 임시 수정하면 → 종료 후 원래 notification policy를 복구하지 못한다.
• send_resolved: true 없이 두면 → 모든 firing 후 해결 알림을 빼먹어 장애 종료 시점을 모른다.
• Spring Boot webhook receiver가 Alertmanager JSON 포맷을 잘못 파싱하는 경우도 흔하다.

관련

• Prometheus: Alert rule 평가 결과(firing/resolved)를 Alertmanager로 보낸다. severity 라벨은 rules.yml에서 추가한다.
• 장애 자동 대응의 안전장치: webhook receiver가 경보를 받은 뒤 조치를 실행할 때 필요한 인증·쿨다운·허용 목록·승인 장치를 다룬다. Alertmanager는 전달까지만 맡고 실행 안전성은 receiver 쪽 설계에 있다.

출처

테스트 질문

• route, receivers, grouping, inhibit의 각 역할은 무엇인가?
• severity 라벨 기반 라우팅이 동작하려면 어디에서 severity를 설정해야 하는가?
• inhibit_rules의 equal 필드가 왜 필요한가?
• send_resolved: true를 켜지 않으면 어떤 정보를 놓치는가?