Prometheus 告警治理减少告警风暴比多加规则更重要一、告警风暴的本质是相关性没处理好Prometheus 告警规则写起来很容易配一个expr设一个for持续时间再配上labels和annotations告警就上线了。但很多团队的告警系统用着用着就变成了告警风暴一个数据库慢查询触发了数据库告警、应用延迟告警、队列积压告警、用户体验告警……最后值班人员的手机被轰炸到关机。告警风暴的本质不是规则写多了而是没有处理好告警之间的相关性。数据库慢查询是根因其他都是次生告警。如果不能把根因告警和次生告警区分开值班人员就要在告警风暴中手动找根因效率极低。告警治理的第一原则能聚合的告警一定要聚合能抑制的告警一定要抑制。二、告警聚合用标签把相关告警归类graph TD A[原始告警] -- B{判断是否同类} B --|是| C[聚合到同一个 Alert Group] B --|否| D[单独发送] C -- E[发送一条聚合告警] D -- F[发送单条告警] G[告警聚合配置] -- H[按 service severity 聚合] G -- I[按 cluster namespace 聚合] G -- J[按 alertname 聚合] style C fill:#bfb,stroke:#333 style E fill:#bbf,stroke:#333Prometheus 的 Alertmanager 提供了强大的告警聚合能力核心是route配置中的group_by字段。我们团队的实践是按服务 严重等级聚合同一个服务的同一严重等级的告警在 5 分钟内发生的聚合到一条通知里。# alertmanager.yml 关键配置 route: group_by: [service, severity] group_wait: 30s # 等待 30s让相关告警一起到达 group_interval: 5m # 聚合窗口 5 分钟 repeat_interval: 4h # 已发送的告警4 小时内不重复发送 routes: # P0 告警立即发送不聚合 - match: severty: critical group_wait: 0s receiver: p0-oncal # 非 P0 告警按服务聚合 - match_re: service: .* group_by: [service, severity] receiver: default按拓扑关系聚合如果一个服务的告警是因为下游服务故障导致的应该只发下游服务的告警。我们在服务拓扑中标注了dependency标签Alertmanager 会根据拓扑关系自动抑制上游服务的告警。三、告警抑制根因告警之外的不要重复发告警抑制是比聚合更进一步的手段。如果 A 告警的发生必然导致 B 告警那 B 告警就应该被抑制。Alertmanager 的inhibit_rules就是干这个的# alertmanager.yml 抑制规则配置 inhibit_rules: # 如果同一个服务有 critical 告警抑制 warning 告警 - source_match: severty: critical target_match: severty: warning equal: [service] # 如果集群级别告警比如整个集群网络故障抑制该集群内所有服务的告警 - source_match: alertname: ClusterNetworkDown target_match_re: alertname: .* equal: [cluster] # 如果节点告警抑制该节点上所有 Pod 的告警 - source_match: alertname: NodeDown target_match_re: alertname: .* equal: [node]抑制规则要谨慎配置否则会漏掉重要告警。我们的做法是先在 staging 环境运行一周观察抑制效果确认没有误抑制后再推到生产。四、告警质量评估四个关键指标告警系统上线后要持续评估告警质量。我们关注四个指标1. 告警准确率Precision发出的告警中有多少是真的需要人工介入的目标≥ 90%计算方法人工确认需要处理的告警数 / 总告警数优化方法删除误报率高的告警规则提高for阈值2. 告警召回率Recall生产事故中有多少被告警捕获到了目标≥ 95%计算方法告警捕获的事故数 / 总事故数优化方法补充监控盲区降低告警阈值3. 告警平均响应时间MTTR从告警触发到开始处理的平均时间。目标P0 5min, P1 15min优化方法优化 on-call 排班改进告警通知渠道4. 告警疲劳度每个 on-call 人员平均每天收到多少条告警目标≤ 5 条/天不包括自动恢复的告警优化方法提高告警阈值删除低价值告警# 告警质量评估脚本简化版 from datetime import datetime, timedelta from prometheus_api_client import PrometheusConnect prom PrometheusConnect(urlhttp://prometheus:9090, disable_sslTrue) def calculate_alert_quality(start: datetime, end: datetime): 计算指定时间段的告警质量指标 # 查询所有触发的告警 alerts prom.get_alerts(start_timestart, end_timeend) total_alerts len(alerts) valid_alerts sum(1 for a in alerts if a[labels].get(valid) true) captured_incidents sum(1 for a in alerts if a[labels].get(incident_id)) precision valid_alerts / total_alerts if total_alerts 0 else 0 recall captured_incidents / total_incidents(start, end) # 假设有 incident 管理系统 return { total_alerts: total_alerts, precision: f{precision:.2%}, recall: f{recall:.2%}, avg_alerts_per_day: total_alerts / (end - start).days, } def total_incidents(start: datetime, end: datetime) - int: 从 incident 管理系统查询事故总数示例代码 # 实际实现要对接你们的 incident 管理系统 return 42 # 假设值五、总结Prometheus 告警治理的核心不是多加规则而是减少告警数量、提高告警质量。聚合和抑制是两大核心手段告警质量要持续评估四个关键指标准确率、召回率、响应时间、疲劳度要定期review。落地时的关键三点告警必须能聚合、根因告警之外的要抑制、告警质量要量化评估。做到这三点告警系统才是运维的助手做不到就只是另一个需要被管理的噪声源。