治理告警风暴，告警降噪的一些典型手段

被告警折磨的SRE 2023-04-18 08:06:10

很多公司希望提升服务稳定性，而上线了各类监控系统，指标的、链路的、日志的，而且只是指标层面可能就会有多个监控系统，这么多监控系统、这么多监控目标，如果没有良好的治理，很快就会产生告警风暴的问题，如何通过一些手段达到告警降噪的效果呢？

在现代化的互联网架构中，告警是监控系统中最为重要的一部分，可以帮助运维人员及时发现并解决问题，确保服务的可用性和稳定性。但是，随着业务的不断扩大和系统的不断升级，告警数量也会快速增加，导致告警风暴的出现，给运维人员、研发人员带来了很大的困扰。因此，如何有效地治理告警风暴，降低告警噪音，成为了运维工作中的一个重要问题。

思路

治理告警风暴和告警降噪需要从以下几个方面进行思考：

告警策略：需要根据业务特点和实际情况，合理制定告警策略，防止因过于严格的告警策略导致过多无用告警产生。
告警优先级：根据业务的重要程度和影响范围，合理设置告警优先级，确保关键告警能够及时通知运维人员。
告警分类：对告警进行分类，能够让运维人员更加清晰地了解问题的性质和紧急程度，不同的告警需要不同的通知媒介和紧急程度，也能够使告警处理更加高效。
告警处理：需要建立完整的告警处理流程，确保告警能够得到及时处理和解决，如果能做到自动化的告警自愈那就更好了。

典型手段

治理告警风暴和告警降噪有以下典型技术手段：

告警去重：对于重复的告警，需要进行去重处理，减少无效告警的产生。
告警压缩：对于短时间内产生大量的告警，可以进行告警压缩，将多个告警合并为一个，降低告警噪音。
告警屏蔽：对于一些已知的无害告警，可以进行告警屏蔽，避免因此产生不必要的干扰。
告警分级：对告警进行分级处理，将关键告警优先展示，降低无用告警的干扰。
告警抑制：如果监控数据同时触发了高级别的告警规则和低级别的告警规则，则只发送高级别的告警。

以上内容是 Notion 的建议，我略微做了补充修正，下文是我的实战建议。

优化告警策略

优化告警策略是最为釜底抽薪的办法，大量告警产生大概率是告警策略本身就有问题。很多告警发出来，只是起到一个通知的作用，而告警接收者无需产生动作，那这个告警策略是否合理就很值得深究。通常来说，告警规则里建议配置Runbook，也就是预案SOP的链接，这样告警之后，处理人员看到这个预案内容就可以一步一步去操作。Runbook预置率可以作为一个很关键的告警策略量化分析指标，预置率太低，一定是有问题的。Grafana、Nightingale 等系统在配置告警规则的时候，都支持附加字段，允许用户随意配置额外的字段信息，但是Runbook这个字段是内置的，可见其重视程度。

业务告警和资源告警区别对待

比如A告警是订单量下跌，B告警是某个机器的CPU飙高，哪个更重要？一目了然吧。老板更关注哪个？一目了然吧。A告警产生，说明公司核心业务有故障，直接造成了资损，老板可能很快就会收到投诉电话。B告警产生，可能在 Kubernetes 平台的自动处理之下，相关业务 Pod 很快就被自动调度走了。所以业务指标应该有 VIP 级别的对待方式，这类指标通常被称为北极星指标，是全公司员工共同努力的方向。Flashcat 产品中就专门有个子模块叫北极星，就是因为这类指标实在是太重要了。应该有更高优的处理机制，有更完备的告警规则，有更好的展示方式。

监控系统太多，相关逻辑不完备怎么办

很多公司都有多套监控系统，但是监控系统通常把重心放在了数据采集、时序库、告警规则的管理、监控大盘等功能上面。对于告警事件产生之后的后续处理逻辑关注较少。有些监控系统或多或少也会做一些，但是整体来看，监控系统的这方面的能力良莠不齐。所以，我们更推荐的做法是建立统一的告警事件OnCall中心，在这个产品里，来完成告警事件聚合降噪、排班OnCall、认领、升级、协同，等一些列逻辑，这样一来，监控系统只需要产生告警事件就好了，不奢望做更多的事情，这个统一的OnCall中心来完成后续的事件处理。这个产品主要解决两个大问题，一个是告警事件的分发触达，一个是良好的协同。

告警事件的分发触达，可以支持灵活的通知策略，比如 P1、P2 的高优告警有自己的通知、聚合规则，P3、P4 的低优告警有自己的通知、聚合规则。协同这块，一个是体现在与钉钉、飞书、企微的良好打通，一个是事件流转、信息共享。这方面相关的产品大家可以关注一下 PagerDuty 和 FlashDuty。