区分已触发的告警与已送达的通知

一句话总结

Prometheus firing、Alertmanager 接收、Webhook 到达和业务恢复是不同证据。即使告警名称相同，也不能把另一个 Pod 的 resolved 算成本次事故恢复。

为什么需要它

规则加载后 Prometheus 显示 firing，但通知服务器没有请求，因为 Prometheus 没有配置向 Alertmanager 发送。修好连接后 Alertmanager API 出现告警，Webhook 仍为空，因为选中的 receiver 没有真实发送目标。前一边界成功不能批准后一边界；应调查最后确认位置与最早丢失位置之间，而不是扩大故障或降低阈值。

工作原理

表达式为某标签集合返回结果时，该目标告警 active。有 for 时，条件需在每次评估持续成立，先 pending 后 firing。因此 for: 10s 不是从安装命令后简单计时，首次有效评估时间也有影响。参阅Prometheus 规则文档。

Prometheus 到 Alertmanager 的连接，与 Alertmanager 到真实 receiver 的通知分别配置。Alertmanager 负责 grouping、inhibition、silence 和发送，参阅官方告警概览。练习用个人 VM 内 HTTP Webhook，检查实际收到的请求，而不是配置界面或成功提示。

最后确认	尚未看到	优先调查
规则已保存	运行实例中的规则组	选择范围、配置应用
Prometheus firing	Alertmanager 对应目标	连接、发现权限、网络路径
Alertmanager 收到	Webhook 请求	route、receiver、发送失败
Webhook firing 到达	同一目标恢复与业务成功	依赖恢复、新评估、resolved 发送

空 receiver 也可能语法有效，因此必须验证它是否执行所需发送。Secret 名称与内部 key 必须符合消费者契约；真实 API key 和密码不得复制到源码、截图或观测记录。

现场表现

准备实验更换新 Pod 后再次制造相同故障，一个 Webhook group 同时包含新 Pod firing 和旧 Pod resolved，alertname、lab 标签相同。因此“只要有一个 resolved 就恢复”的判断错误，必须按当前 Pod 标签逐项比较 alerts。

还要区分 group status 与 group 内各 alert status。多目标被分组时，单个 group 状态不能代表全部目标。生产环境需约定事件身份标签，以及重启前后是否连接或拆分。练习把 rule UID、pod UID 写入观测文件，防止误用其他执行记录，但这不是证明文件真实性的数字签名。

API 错误后的空对象不能解释为正常无告警。输入缺失或矛盾时应返回 unknown 并重做查询；数字 0 与布尔 False 也不能混用。历史事故记录和当前状态用途不同：恢复后 API 可无 active 告警，但报告仍需保留 firing 和接收证据；不能用当前状态覆盖历史，也不能用旧正常 JSON 证明当前正常。最终恢复要重查业务响应和 active 状态。

下一步

练习会分别保存：只有 Prometheus firing、到达 Alertmanager、到达 Webhook、恢复四个时点，并用严格布尔契约编写诊断器，测试缺失、矛盾、错误类型。外部通知、高可用和生产 SLO 不在证明范围内。