摘要告警系统的目标不是把所有异常都通知给人,而是在真正需要人工介入时,准确、及时、可行动地提醒负责人。没有分级和降噪规则的告警系统,很容易演变成告警风暴:通知很多,真正有价值的信息很少,值班人员疲于应付,最终对告警失去信任。本文整理一套通用的告警分级与降噪规范,适用于 Prometheus、CloudWatch、Grafana、日志告警、云平台事件告警等场景。文中不包含任何内部地址、账号、密钥、服务名或业务敏感信息,可直接作为团队告警治理规范、SRE 手册或 CSDN 技术文章使用。一、为什么需要告警分级与降噪很多团队的告警系统一开始都很简单:指标超过阈值就通知,日志出现关键字就通知,云平台事件发生就通知。随着系统规模扩大,问题会越来越明显:同一个故障触发几十条重复告警。低优先级告警在半夜叫醒值班人员。告警消息只有现象,没有影响范围和处理建议。短暂抖动触发大量恢复又告警的通知。真正严重的问题被低价值告警淹没。告警长期无人处理,最终变成背景噪音。告警治理的目标是:该叫醒人的告警必须叫醒。 不该叫醒人的告警不要叫醒。 每一条告警都应该可判断、可定位、可行动。二、告警设计原则
告警分级与降噪规范:避免告警风暴的通用实践
摘要告警系统的目标不是把所有异常都通知给人,而是在真正需要人工介入时,准确、及时、可行动地提醒负责人。没有分级和降噪规则的告警系统,很容易演变成告警风暴:通知很多,真正有价值的信息很少,值班人员疲于应付,最终对告警失去信任。本文整理一套通用的告警分级与降噪规范,适用于 Prometheus、CloudWatch、Grafana、日志告警、云平台事件告警等场景。文中不包含任何内部地址、账号、密钥、服务名或业务敏感信息,可直接作为团队告警治理规范、SRE 手册或 CSDN 技术文章使用。一、为什么需要告警分级与降噪很多团队的告警系统一开始都很简单:指标超过阈值就通知,日志出现关键字就通知,云平台事件发生就通知。随着系统规模扩大,问题会越来越明显:同一个故障触发几十条重复告警。低优先级告警在半夜叫醒值班人员。告警消息只有现象,没有影响范围和处理建议。短暂抖动触发大量恢复又告警的通知。真正严重的问题被低价值告警淹没。告警长期无人处理,最终变成背景噪音。告警治理的目标是:该叫醒人的告警必须叫醒。 不该叫醒人的告警不要叫醒。 每一条告警都应该可判断、可定位、可行动。二、告警设计原则