Prometheus Alertmanager分级告警

Prometheus 原生的告警机制在触发后，所有告警都平铺直叙地发送出去，这在生产环境中是一场灾难。当一个大面积故障发生时，运维人员会瞬间被成百上千条“CPU使用率过高”、“服务不可达”的告警淹没，根本分不清哪个是根源问题，哪个是连带现象。解决这个问题的唯一有效手段，就是在 Alertmanager 中构建一套基于标签的分级告警路由树，让不同严重级别、不同业务线的告警走完全不同的通知通道和收敛策略。

分级告警不是简单地在告警名字里写上“严重”或“警告”，而是要把严重程度变成结构化数据。在 Prometheus 的告警规则中，必须定义一个名为 severity 的标签，其值严格限定为 critical、warning、info 三级。这个标签是后续一切路由决策的锚点。同时，为了区分基础设施故障和业务故障，还需要一个 team 或 component 标签，比如 team: "platform" 或 team: "order-service"。只有把 severity 和 team 这两个维度交叉，才能构建出立体的分级体系，否则单靠一个 severity 标签，你仍然无法把数据库宕机的 critical 告警和支付网关宕机的 critical 告警分发给不同的人。

Alertmanager 的路由配置是一个树状结构，它通过 labels 匹配规则进行深度优先遍历。根路由是所有告警的入口，必须设置一个兜底接收者。在根路由之下，通过 routes 字段嵌套子路由，每个子路由用 match 或 match_re 来捕获特定标签的告警。关键点在于 continue 参数：如果设置为 false，告警一旦被某个分支匹配，就不会再继续向下匹配其他同级分支；如果设置为 true，告警会继续流转，可能被多个接收者处理。在分级告警场景中，通常需要把 critical 告警同时发送到钉钉群和电话通知，而 warning 告警只发到钉钉群，这时就要在 critical 分支设置 continue: true，让它同时命中两个子路由。

分级告警的另一个核心能力是告警抑制。当某个集群的网络分区故障触发了一堆“节点不可达”的 critical 告警时，那些依赖这些节点的服务必然会触发“服务健康检查失败”的 warning 告警。如果不做抑制，warning 告警会形成严重的噪音。Alertmanager 的 inhibit_rules 配置允许你定义源告警和目标告警的抑制关系：源告警匹配 severity="critical" 且 alertname="NodeDown"，目标告警匹配 severity="warning" 且 alertname="ServiceUnhealthy"，只要两者的 instance 或 cluster 标签相同，warning 告警就会被自动静默。这种层级抑制机制能自动过滤掉 90% 以上的次生告警，让运维人员只看到根因。

告警分组是防止消息爆炸的最后一道防线。在路由配置中，group_by 参数决定了哪些标签组合会聚合成一条通知。对于 critical 级别的告警，应该按 alertname 和 cluster 分组，确保同一集群的同类严重故障合并成一条消息，而不是按 instance 分组，否则每台机器都会产生一条独立通知。对于 warning 级别的告警，可以按 alertname 和 severity 分组，进一步降低通知频率。group_wait 和 group_interval 参数需要根据级别动态调整：critical 告警的 group_wait 应该设为 10 秒，几乎立即触发；warning 告警则可以设为 30 秒甚至 1 分钟，给系统一定的自愈时间窗口。repeat_interval 对于 critical 告警建议设为 1 小时，持续未恢复就反复提醒，而 info 告警可以设为 4 小时甚至更长，避免低优先级告警频繁打扰。

分级告警最终要落到不同的通知渠道上。critical 告警需要即时触达，通常对接企业微信、钉钉机器人、飞书机器人的 Webhook，同时调用语音电话接口或者短信网关。warning 告警只需发送到即时通讯群组即可。info 告警甚至可以不发通知，只写入日志或事件管理系统。在 Alertmanager 的 receiver 配置中，每个级别对应一个独立的接收器，接收器内部可以同时配置多种通知后端。这里有一个容易忽略的细节：Webhook 请求的 JSON 结构需要根据不同的接收端做定制化处理，Alertmanager 默认的模板变量可以提取告警的标签、注释、开始时间等信息，通过 Go 模板语法重新组织成下游系统要求的格式。

分级告警体系要真正落地，告警规则本身的注释和文档化必不可少。每条告警规则必须明确填写 annotations 中的 summary 和 description，而且 description 要遵循固定的模板：故障现象、影响范围、排查步骤、应急处理方案。对于 critical 级别的告警，description 的第一行必须是应急操作指令，因为值班人员收到电话通知时，往往只能看到消息摘要，没有时间点开详情。例如，数据库连接池耗尽的 critical 告警，description 应该直接写“立即执行：登录主库执行 SHOW PROCESSLIST，确认是否有慢查询阻塞连接池，必要时 KILL 阻塞查询，然后检查应用侧是否有连接泄漏”。这种把操作手册嵌入告警信息的做法，能大幅缩短故障响应时间。

静态阈值在复杂的业务场景中往往不够用。比如某个接口的延迟在白天高峰时段 200ms 是正常的，但在凌晨低峰时段 200ms 就是异常。这时需要引入 Prometheus 的记录规则和预测性告警。先用记录规则计算出过去 7 天同一时段的历史均值和标准差，然后在告警规则中用当前值减去历史均值再除以标准差，得到一个偏离度指标。偏离度超过 2 倍标准差触发 warning，超过 3 倍标准差触发 critical。这种动态基线的方法能让分级告警更智能，大幅降低误报率。但要注意，记录规则的计算开销较大，需要合理设置评估间隔，避免给 Prometheus 造成过大的查询负载。

分级告警体系上线后，不能一劳永逸。必须建立告警质量的度量指标：每周统计各 severity 级别的告警数量、误报率、平均响应时间、静默时长占比。如果发现 critical 告警中有 30% 都是自动恢复的瞬时抖动，说明阈值设置过于敏感，需要调整告警规则的 for 持续时间或者阈值本身。如果某个 warning 告警从未被关注过，要么提升它的级别，要么直接删除。告警分级是一个需要持续运营的过程，每个季度都应该做一次全量告警规则的复盘，把无效告警清理掉，把新发现的故障模式纳入监控。只有形成这种闭环，分级告警体系才能越用越精准，而不是变成又一个无人维护的配置垃圾。

# Alertmanager 分级路由配置示例
route:
  receiver: 'default-receiver'
  group_by: ['alertname', 'cluster']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  routes:
    - match:
        severity: critical
      receiver: 'critical-receiver'
      continue: true
      group_wait: 5s
      group_interval: 5s
      repeat_interval: 30m
      routes:
        - match:
            team: platform
          receiver: 'platform-critical'
        - match:
            team: order-service
          receiver: 'order-critical'
    - match:
        severity: warning
      receiver: 'warning-receiver'
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
    - match:
        severity: info
      receiver: 'info-receiver'
      group_wait: 1m
      group_interval: 10m
      repeat_interval: 12h

inhibit_rules:
  - source_match:
      severity: critical
      alertname: NodeDown
    target_match:
      severity: warning
      alertname: ServiceUnhealthy
    equal: ['cluster', 'instance']

分级告警的最终目的是把正确的告警在正确的时间推送给正确的人。这需要与 OnCall 排班系统打通。critical 告警触发后，Alertmanager 调用 OnCall 系统的 API，OnCall 系统根据当前排班表找到值班人员，先发即时通讯消息，如果 5 分钟内未确认，自动升级为电话呼叫，如果仍然未响应，逐级上报到二线值班和团队负责人。warning 告警则只创建工单，不触发电话呼叫。info 告警直接静默或归档。这种三级递进的响应机制，配合 Alertmanager 的路由树，构成了完整的告警全生命周期管理。实现时要注意，OnCall 系统的 API 调用必须设置超时和重试机制，避免因为 OnCall 系统本身故障导致告警通知丢失。

分级告警不是配置层面的雕花，而是运维理念的转变：从无差别轰炸到精准打击，从被动响应到主动设计。当一个体系能把 1000 条告警压缩成 3 条精准通知，并且每条通知都自带操作手册时，故障处理时间从小时级降到分钟级就不再是空谈。这套方法论在 Kubernetes 集群、微服务架构、混合云环境中都经过了充分验证，唯一需要持续投入的就是标签规范的维护和告警规则的定期修剪。