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 告警静默要限定范围、填写原因和负责人、设置过期时间并保留事件记录。静默不是把问题关掉。它只是让通知更克制不能让风险消失。