告警体系：Alertmanager、PagerDuty、OnCall 与分级抑制

凌晨 3 点，值班手机响了。不是一次。是 87 次。同一个上游依赖超时引发了连锁反应——87 条告警，其中 85 条是下游服务”我也超时了”的抱怨，只有最后 2 条是说”上游 Connection Pool 耗尽了”——真正的根因。值班人花了 40 分钟在手机屏幕上翻到第 86 条。

这不是虚构。这是几乎所有团队在告警体系建设的道路上必然要经过的阶段。“告警太多了”和”告警不够灵敏”是同一个问题的两面——你没有对告警做结构化的治理。Alertmanager 提供了所有需要的机制（grouping、inhibition、silence）——但使用机制的前提是设计思路的改变：告警的目标不是”尽可能快地通知每一件可能的事情”，而是”只在高置信度的用户影响事件上、以正确的紧急程度、通知到正确的轮值人员”。

一、告警体系的分层架构

从 Prometheus Alerting Rule 到值班手机的完整路径：

Rules：Prometheus alerting rules 定义”什么算异常”。每一条 rule 应该生成带有 severity、team、runbook_url 三个必须标签的 alert。

Routing：Alertmanager 根据 label 把告警发送到正确的 receiver。路由树结构——按 team 或 severity 分叉。

Grouping：把同一根源的多条告警合并成一条通知。例如某个 cluster 挂了，可能产生几百条 per-Pod 告警——grouping 会把它们压缩为一封邮件/一条 Slack 消息。

Inhibition：如果某条 critical 告警已经触发，抑制所有由其导致的 warning 告警。例如 NetworkDown 抑制 TargetDown、KubeletDown 抑制 PodNotReady。

Silence：计划内维护窗口期间屏蔽已知的噪音告警——不触发、不通知、不升级。

Notification：Email / Slack / 电话 / PagerDuty / 钉钉 / 飞书 webhook。

On-Call Rotation：谁在什么时候负责。“follow-the-sun”（全球团队每 8 小时轮换）vs “每周轮换”。

Escalation：N 分钟后无 ack → 自动通知 backup 或上级。

二、告警规则设计的铁律

每一条告警必须满足四大条件：

1. Actionable：收到告警的人知道该做什么。每一条告警必须有一个 runbook 链接——打开的页面告诉值班人”打开这个 Dashboard → 确认这个指标 → 如果 X 执行 Y”。
2. 有 Owner：告警的 team label 明确指向负责团队。没有 owner 的告警等于没有告警——因为没人会响应。
3. 有优先级：severity: critical|warning|info。critical 是”用户正在受影响”（Page 电话），warning 是”趋势异常但未达 SLO 红线”（Slack 通知），info 是”信息通告”（仅 Dashboard 显示）。
4. 有 Runbook：runbook_url 标签指向排障手册。凌晨三点被叫醒的人没有认知资源去”从头调试”——runbook 必须告诉他前三个要查的东西。

反例：CPU > 80% 设成 critical page。CPU 高不一定影响用户——你应该告的是 SLO Burn Rate，不是 CPU。

三、Alertmanager 的核心配置

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s        # 等同类告警到齐再发送
  group_interval: 5m     # 同组告警的最小发送间隔
  repeat_interval: 4h    # 如果没被 resolve，多久重发一次
  receiver: 'slack-sre'
  routes:
    - match: {severity: critical}
      receiver: 'pagerduty-sre'
      continue: true
    - match: {team: checkout}
      receiver: 'slack-checkout'

inhibit_rules:
  - source_match: {alertname: NetworkDown, severity: critical}
    target_match: {alertname: TargetDown}
    equal: ['cluster']

group_wait 设太短是新手最常犯的错误——同组告警还没到齐就发出去了，导致多条重复通知。repeat_interval 不设的话，告警会一直重复发送直到被 resolve——默认值不是 0。

inhibit_rules 是抑制的核心。上面的规则说：如果 NetworkDown critical 告警已触发，抑制同 cluster 的所有 TargetDown 告警——因为网络断了所有 target 都会不可达，给每个 target 发一条告警没有任何意义。

四、告警分级：Page vs Ticket vs Chat vs Log

关键原则：只有正在消耗 SLO 预算的事件才发 Page。CPU 高、内存高、磁盘满——这些是信息，不是告警。SLO Burn Rate 是唯一应该触发电话告警的条件——因为只有它和”用户正在受影响”是等价概念。

五、告警质量的持续治理

告警体系如果不做持续治理，会在 6–12 个月内退化到”所有告警都被 mute 或 ignore”。治理指标：

• 告警频率：每 on-call shift 触发的告警数。正常 < 5/shift——如果超过，说明告警规则过敏感。
• 误报率：false positive / total alerts。正常 < 20%——如果超过，说明告警规则设计有缺陷。
• 告警归因率：每条 alert 事后是否关联到了具体的 Incident 或标注为 false positive。没有归因的告警是”幽灵告警”——你不知道它是不是曾经代表过一个真实问题。

推荐的治理节奏：每周 review 触发频率最高的 5 条告警规则——如果是 false positive 就调低敏感度，如果是真实但不需要立即响应的就降级到 ticket。每季度做一次告警规则清理 Sprint——杀掉从未触发过或触发频率 > 100 次/月但从没被 ack 过的规则。

六、工程坑点

Alertmanager 单点故障。如果唯一的 Alertmanager 实例挂了，所有告警静默丢失。最小高可用部署：3 副本 + gossip mesh。Prometheus HA pair 各连接各自的 Alertmanager。

飞书/钉钉 webhook 超时或限流。webhook 返回 429 时 Alertmanager 会静默丢弃那条通知——这就是”告警触发了但值班人没收到”的最常见原因。配 send_resolved: false 确保恢复通知即使在中间环节丢失也不会影响新的告警。

group_wait 设太短 + group_interval 不设。每个新 label 组合都触发新通知——告警风暴。

七、关键概念回顾

• Grouping / Inhibition / Silence：Alertmanager 治理三元组。用好了，告警不会风暴——用不好，凌晨三点 87 条通知。
• Page 只用于 SLO Burn Rate：CPU、内存、磁盘——是信息不是告警。
• 持续治理：每周 review Top-5 高频告警，每季度清理失活规则。

八、下一步

告警发了，存储账单也到了。下一篇 存储与成本：如何通过采样、下采样、冷热分层和压缩把可观测性账单控制住。

上一篇：SLO 工程：错误预算、Burn Rate、多窗口告警

下一篇：可观测性存储与成本

参考资料

1. Prometheus, Alertmanager Documentation, https://prometheus.io/docs/alerting/latest/alertmanager/
2. PagerDuty, Operations Guide, https://response.pagerduty.com/
3. Google, Site Reliability Engineering, Chapter 5: Alerting on SLOs