本篇是《Prometheus 从入门到生产实践》第 14 / 24 篇。配置以文中版本与环境前提为准，实验和故障均为教学场景。完整程序、配置及校验范围见配套实验包。
Prometheus 负责判断当前是否异常，Alertmanager 负责决定这条异常怎样通知人。两者分工后，规则不需要知道每个团队的邮箱和机器人地址，通知侧也能对一场故障产生的大量事件进行归并。
1. 一条告警的通知路径
通知链路可以拆为：规则 firing → Prometheus 发给 Alertmanager → 路由选择 receiver → 分组与静默、抑制处理 → 接收端接受并展示。某一环有告警，不意味着下一环已经成功。
本机实验的 Prometheus、Alertmanager、webhook 端口分别是 19090、19093、18085。它们都在同一主机原生运行时，127.0.0.1 才指向同一网络环境；放进不同容器或 Pod 后，需要改成相应可达地址。
通知功能的整体职责可参考 Alertmanager 官方介绍。
2. 从一份完整但克制的配置开始
保存 b-alertmanager.yml：
route:
receiver: lab-webhook
group_by: ['alertname', 'job', 'environment']
group_wait: 10s
group_interval: 1m
repeat_interval: 15m
routes:
- receiver: lab-webhook
matchers:
- 'severity="critical"'
group_wait: 5s
receivers:
- name: lab-webhook
webhook_configs:
- url: http://127.0.0.1:18085/alerts
send_resolved: true
inhibit_rules:
- source_matchers:
- 'severity="critical"'
target_matchers:
- 'severity="warning"'
equal: ['alertname', 'job', 'instance', 'environment']
它把所有告警先交给默认 webhook；critical 路由仍使用同一实验接收器，只缩短首次等待，方便观察路由行为。生产中应把 receiver 换成获准使用的接收服务，并明确值班归属。
运行前检查：
amtool check-config b-alertmanager.yml
启动独立实验实例时使用：
alertmanager --config.file=b-alertmanager.yml \
--storage.path=./am-data \
--web.listen-address=127.0.0.1:19093 \
--cluster.listen-address=
这个单实例练习显式不启动集群监听；高可用成员通信留到后面的章节。不要将本实验数据目录与现有 Alertmanager 共用。
3. 将 Prometheus 连接到 Alertmanager
在现有 prometheus.yml 合并以下片段：
alerting:
alertmanagers:
- static_configs:
- targets: ['127.0.0.1:19093']
规则是前一篇的 DemoTargetDown。先启动配套 webhook_demo.py，再加载两边配置，停止专用 demo exporter 形成可控异常。预期 Prometheus 先 pending，达到 for 后 firing，Alertmanager 收到实例，接收终端随后出现 webhook JSON。
webhook_demo.py 只用于教学确认收到 POST，不等同于邮件或聊天平台已经通知到人。后续接入真实渠道时，还要检查签名、鉴权、状态码与平台限流。
4. 三个时间参数各管一段
| 参数 | 含义 | 本例取值 |
|---|---|---|
| group_wait | 新组首次发送前收集相关事件的等待 | 10 秒 |
| group_interval | 对既有组检查新增或恢复变化的周期 | 1 分钟 |
| repeat_interval | 组没有变化、故障仍在时安排重复提醒 | 15 分钟 |
repeat_interval 受到组检查节奏和数据保留等条件影响，不是完全独立的秒表。for 属于 Prometheus，group_wait 属于 Alertmanager，把两个值同时调大，会一起增加首条通知延迟。
本例为快速观察而使用较短时间，不是通用生产推荐。参数精确定义见 Alertmanager 配置参考。
5. 分组既不能太碎，也不能过粗
group_by 中的标签决定通知组。加入 instance，通常会让每台主机各自形成组；只按 alertname 分组，又可能把不同环境混在一起。本例至少保留告警名、job 和 environment。
通知组中可能有多个成员，每个成员仍有自己的标签、开始时间和状态。一个组摘要写着 firing，不表示其中没有已经 resolved 的实例。接收端应按各条 alert 解析，而不是靠一句标题改变所有工单状态。
子路由默认命中后停止继续匹配同级后续路由，只有明确设置 continue 才会继续。修改路由时先画出树，避免同一实例意外通知多个团队或根本没走到想要的分支。
6. 静默、抑制和恢复分别是什么
静默用于有范围、有截止时间的暂时不通知，例如已知维护。它不删除原始告警，也不修复指标。创建静默时必须核对匹配标签、起止时间和负责人，结束后确认没有留下过宽范围。
抑制描述“某类更根本的告警存在时，不重复提醒相关次级告警”。本例 critical 可以抑制同一告警名、job、instance、environment 的 warning；如果不同维度缺失或取值不一致，就可能匹配错误或根本不生效。相等标签双方都缺失时也可能视为相等，因此设计时要保证这些维度真实存在。
send_resolved 允许 webhook 接收恢复，不保证条件解除瞬间就发到人。若告警在首次 group_wait 内就解决，可能根本没有形成第一次 firing 通知；这是预期时序的一部分。
7. 通知去重不是业务事务
接收端不能假定一条告警在整个生命周期中只会收到一次。网络超时、重试、组件重启和多副本切换，都可能让同一状态再次送达。让接收端按告警指纹、稳定标签和状态管理同一事件，比每收到一次就新建一张工单更稳妥。
同时，不应仅凭收到一条 resolved 就删除全部上下文。它需要对应到原有实例，并保留此前的开始时间、负责人和处理记录。组内可能混有已解决与未解决成员，通知模板也可能只展示其中一部分，这就是为什么接收器应处理完整负载而不只截取标题。
重复提醒的目的，是让尚未解决的影响继续被看见；它不能替代认领、升级和交接机制。值班团队需要明确收到以后由谁确认、什么时候转交、何时升级，以及外部通知平台不可用时的替代路径。
8. 路由变更怎样验证才有意义
把准备处理的标签组合写成一个小表：实验环境的 warning、生产环境的 critical、缺少负责团队的未知事件。对每种组合说明预期接收器、组范围和是否应被抑制，再与实际匹配结果比较。
根路由提供一个明确的兜底接收器很重要。新增服务没有匹配专门团队时，事件应落到可检查的地方，而不是消失。兜底接收器也不能长久代替资产归属，否则所有团队都收到一份消息，反而没有人真正负责。变更后既验证新增实例，也核对既有告警的接收范围，避免只测试新对象。
对静默的验收不只是“现在没响”。还要确认只有计划中的事件被静默、其他服务照常发送、到期后能恢复。抑制同理：保持告警可见，确认它是被哪条更高级事件抑制，并在源事件解除后观察次级通知是否按预期处理。
如果需要保留 Alertmanager 状态，数据目录也有自己的运维要求。重启后是否保留静默和通知去重信息，与部署和存储配置有关。清空目录不是一种正常的“取消静默”方法，容易破坏原本可以解释的通知历史。
9. 查看状态，而不是只等手机响
可以只读查询：
amtool --alertmanager.url=http://127.0.0.1:19093 alert query
amtool --alertmanager.url=http://127.0.0.1:19093 silence query
若 Prometheus firing 但 Alertmanager 没有实例，查地址、网络和通知错误；若实例存在但 receiver 不收，查路由、静默、抑制、分组时序和接收端日志。
练习分别改变 severity、environment，再比较分组与抑制结果。只在实验标签范围里操作，记录首次异常、firing、首次 webhook、条件恢复和恢复 webhook 的时间，便能解释“为什么这条消息此刻才出现”。
上一篇：告警规则进阶：持续时间、稳定标签、缺失数据与单元测试 · 系列目录 · 下一篇：安全边界：TLS、认证、凭据与管理 API