这次测试监控通知，Prometheus 已经显示 FIRING，我却以为邮件配置失败。最后在垃圾邮件里找到了通知。这个经历让我开始按链路排查，而不是看到没收到就立即重写配置。
哪个软件决定发告警
Prometheus 定时计算规则，条件满足并持续达到 for 指定时间后，告警进入 FIRING，再发送给 Alertmanager。Alertmanager 负责接收、分组、去重和通知。Grafana 面板变红，不等于这条邮件链路已经触发。
常见状态分别是：
- INACTIVE：当前条件不成立。
- PENDING：条件成立，仍在等待持续时间。
- FIRING：持续时间满足，告警已激活。
for: 2m 的意思是条件连续成立两分钟，不是每两分钟发一次邮件。
本站通知参数的含义
邮件配置在 /etc/alertmanager/alertmanager.yml。本站采用 163 SMTP 的 465 端口与隐式 TLS，授权码单独存放，不写进公开文档。不同版本对配置字段支持可能不同，修改前应使用当前安装版本的 amtool 检查。
路由的几个值尤其值得分清：
| 参数 | 作用 |
|---|---|
| group_by | 按哪些标签把告警放进同一组 |
| group_wait | 新告警组首次通知前等待多久 |
| group_interval | 同组变化后再次发送所需的间隔 |
| repeat_interval | 同一批告警持续未恢复时重复提醒间隔 |
| send_resolved | 是否发送恢复通知 |
本站首次分组等待为 15 秒，重复提醒间隔为 4 小时。这些是通知行为，与规则中的 for 不同。静默和抑制也可能阻止通知，因此 FIRING 不保证马上收到一封独立邮件。
没收到时按四层检查
先看 Prometheus 规则是否 FIRING，再确认它配置了正确的 Alertmanager 地址；然后看 Alertmanager 有没有收到告警、路由是否匹配、有无 SMTP 错误；最后查收件箱、垃圾箱和过滤规则。
journalctl -u prometheus -u alertmanager --since '30 minutes ago' --no-pager日志用于判断连接、认证、TLS 和发送错误。分享日志前删掉邮箱和秘密字段，不能把授权码贴出来让别人排查。
测试要验证整条链路
使用临时、清楚标记的测试规则验证通知，比直接停止线上数据库更容易控制影响。测试成功后，从主配置移除测试文件引用，检查配置，再清理测试规则并重载。恢复通知也应检查，避免长期留下一个永远 FIRING 的测试告警。
这次邮件已经实际送达，问题出在邮箱分类。另一条边界也要记住：Prometheus 与 Alertmanager 都在网站同一台机器，整机断电时它们也无法继续发邮件，外部探测仍然有独立价值。
验证规则与通知各自负责什么
amtool check-config /etc/alertmanager/alertmanager.yml 检查配置结构，不能证明 SMTP 凭据有效。promtool 检查语法也不证明规则语义正确。验收应记录告警进入 FIRING、Alertmanager 接收、邮箱送达及恢复通知；用明确测试规则完成，不必停止线上数据库。参考：Prometheus 告警规则。
内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。
评论 (0)