Alertmanager 最佳实践

告警的价值不在于发现所有变化，而在于让正确的人在正确时间采取正确动作。Alertmanager 的路由、分组、静默和抑制必须服务于这一目标。

1. 告警分级规范

级别	含义	典型动作
Critical	已造成或即将造成明显用户影响	立即 OnCall 响应与升级
Warning	需要关注或在工作时段处理	团队 IM/工单，跟踪趋势
Info	信息性事件	看板、日报或变更记录，不打扰值班

分级含义应在团队内统一。同一个告警在不同环境通常使用不同路由，而不是随意改变严重度语义。

2. 告警设计原则

• 有意义：告警对应用户影响、SLO 风险或需要明确处置的容量问题。
• 可行动：有负责人、运行手册、Dashboard/日志链接和下一步检查路径。
• 可验证：在测试环境验证 firing、resolved、路由、静默与接收器。
• 低噪声：使用持续时间、最小流量、分组和根因抑制，避免短暂抖动。

3. 告警治理

定期审查长期 firing、无人认领、频繁静默、重复通知和不再使用的 Receiver。每次重大故障后复盘告警是否足够早、是否可行动、是否存在噪声和是否需要更新抑制/路由规则。

配置、模板、Secret 引用、团队映射和接收器均应进入版本控制与变更流程。临时 Silence 必须关联维护窗口，永久屏蔽应被视为缺陷并排期解决。

4. 企业生产实践

建立 OnCall 值班表、升级链路、通知渠道冗余、变更静默流程和事件响应分级。平台团队维护公共路由、通知网关与可观测性基线；应用团队维护服务标签、规则和运行手册；业务团队确认业务指标与影响阈值。

监控 Alertmanager 自身、Prometheus 规则评估、接收器发送失败、通知网关、值班平台和外部依赖。关键告警链路不可只由自身监控，应有独立探针或第二套检查路径。

5. 经验总结

最常见的问题不是“没有告警”，而是重复、无主、不可行动、路由错误或通知失效。通过稳定标签、最小权限、配置即代码、定期演练和明确责任，可让告警从噪声变成可靠的故障响应工具。