Prometheus 告警静默：静默不是把问题关掉

Prometheus 告警静默：静默不是把问题关掉

一、静默容易被滥用

Prometheus Alertmanager 支持 silence，非常适合维护窗口、已知故障和重复告警处理。但静默如果没有边界，很容易把真实问题一起关掉。最危险的是“先静默再说”，事后没人记得恢复。

静默不是把问题关掉，而是有条件地减少通知。

二、静默要写清范围

flowchart TD A[告警] --> B[服务] A --> C[实例] A --> D[环境] A --> E[时间窗口]

静默条件要尽量精确。只静默某个服务、某个实例、某个集群、某个时间窗口，不要用过宽 matcher。

silence: alertname: HighCpuUsage service: payment-api cluster: prod-a duration: 2h

过宽静默会掩盖其他真实异常。

三、原因和负责人必须填写

每条静默都要有原因、负责人和结束时间。没有负责人，就没人对恢复负责。

silence_metadata: reason: node_maintenance owner: sre-oncall expires_at: required

长期静默应该进入治理列表，定期清理。

四、静默不等于停止记录

静默只是不通知人，告警事件和指标仍然要记录。维护窗口内如果出现更严重症状，也应该能在事后复盘中看到。

silence_policy: suppress_notification: true keep_event_record: true allow_critical_override: true

对于特别高危告警，比如数据丢失、备份失败、证书即将过期，不应该轻易静默。

最后，静默要和变更系统联动。维护开始自动创建，维护结束自动过期，比手工创建更可靠。

静默还要支持审计。谁创建、为什么创建、影响了哪些告警、是否在到期前手工延长，都应该可以追踪。没有审计的静默，很容易变成风险黑洞。

silence_audit: creator: required reason: required affected_alerts: recorded extension_history: recorded

还要避免静默链路上的所有告警。比如维护数据库时，可以静默某些连接失败告警，但 SLO 燃烧率、数据一致性、备份失败仍应保留。维护不是风险豁免。

最后，静默到期前可以提醒负责人。如果维护还没结束，就明确延长；如果已经结束，自动恢复通知。

还要区分 silence 和 inhibition。silence 是人为静默，inhibition 是根据告警关系自动抑制下游告警。比如集群网络故障时，可以抑制大量服务探活失败，但不能把根因告警也静默掉。

alertmanager_policy: silence: manual_or_change_window inhibition: topology_based root_alert: never_suppressed

静默策略应定期报表化。统计哪些服务静默最多、哪些告警长期被静默、哪些静默经常延期，这些都是治理信号。

最后，值班交接时要同步当前静默。下一班不知道哪些告警被静默，就等于少了一部分系统视野。

五、总结

Prometheus 告警静默要限定范围、填写原因和负责人、设置过期时间，并保留事件记录。

静默不是把问题关掉。它只是让通知更克制，不能让风险消失。