在事件处理方面，一般我们会遇到两个痛点，一个是告警事件太多，被过度打扰，另一个是重要告警疏漏，无法闭环处理。

告警太多的常见原因

最常见的原因，是告警规则设置得不合理。比如很多规则触发了告警之后，实际没有后续动作，只是起到常态化通知的效果，不需要排查，也不需要止损，甚至连个长线的 TODO 都没有。这类告警多了人就疲了，当重要的告警来临的时候，也容易忽略。这样的规则如果不经过治理，日积月累，就会产生很多无用的告警。

第二个常见的原因是底层出问题导致所有的上层依赖都告警，越是底层影响越大，比如基础网络如果出问题，发出几万条告警都是正常的。

第三个原因是渠道错配。一些不重要的告警也使用打扰性很高的渠道发出，用户可能会觉得单一渠道不可靠，想用多个渠道同时发送的方式来保障告警触达率，这也属于告警规则配置不合理的范畴。

第四个原因是预期内的维护动作导致的。比如程序升级变更，如果进程重启时间过长，可能会导致关联的服务告警，或者某个机器重启，忘记提前屏蔽了，也会产生一堆关联告警。

每个规则都应该对应具体的 Runbook

Runbook 就是告警处理手册，也就是告警触发之后，应该细化排查哪些方面，按照一个什么方式执行动作，应该有一个手册参考。如果告警发生之后没有后续动作，那这个告警的意义就不大了。

不紧急的告警，也必须要有动作，虽然这个动作可能不是立马执行处理，但至少要创建个低优先级的工单之类的，或者提高告警阈值，等问题严重一些再告警。对于只是想通知一下的告警，其实都不算告警，只能看做是一种另类的报表和巡检手段，这样的“告警”就按照报表和巡检的逻辑来处理，比如把这类“告警”发到一个单独的邮件组或者单独的聊天群组，平时都不用关注，只要每天早上上班或晚上下班之前稍微看一眼就行，这样就可以减少打扰。

每个告警都应该合理分级

​首先，不同级别的告警应该对应不同的处理逻辑，这样分级才有意义，比如通知渠道不同，通知范围不同，或者介入处理的人的范围不同，处理时效不同 ，如果某两个级别对应完全一样的处理逻辑，就可以合并成一个级别。

如果 Critical 的告警规则很多，大概率也有问题，说明系统架构不够鲁棒，出点什么事都要立刻介入，系统没有自愈能力。这样的系统，需要配备更多运维人员，而且还很难跟老板讲清楚价值。怎么办？这就需要制定运维准入规则，哪个系统要交给运维人员来运维，首先要提供一些信息。

• 相关联系人，出了问题能够及时找到人，联系不上的话得能直接联系研发领导。
• 服务相关信息，比如代码仓库、系统架构、依赖哪些服务、依赖哪些系统参数、哪些 JVM 参数、常见问题还有处理办法等等。

然后进行准入评审，如果系统架构有明显问题，就没办法通过准入要求，不接受运维，如果老板要求必须接，那就只能加人了，或者明确说明在架构调整好之前，不负责 SLA。如果老板不接受沟通，那就跳槽吧，老板根本不懂运维、不懂稳定性还不信任你。

​告警规则支持生效时间的配置

​不同公司的业务相差很大，比如券商，交易时间段内需要高优保障稳定性，但是非交易时段，有些进程直接停掉也无所谓。但如果是监控系统，数据是时时刻刻都在上报的，没有高峰低谷，需要时刻保证高可用。

​重复告警支持最大次数和发送频率

​有些告警短时间没法恢复，可能会重复发送。比如一分钟检查一下某个指标，如果超过阈值就告警，从某个时刻开始，触发了阈值，一分钟之后发出第一条告警，但是短时间没有恢复，持续了 10 分钟，监控系统在第二分钟检查的时候发现还是告警状态，可能还会发出一条告警，但是这个告警的重要性就远不如第一条，完全可以不用通知。通过设置发送频率，可以做到比如 1 小时之后再检查，如果 1 小时之后还是没有恢复，再发出第二条告警，这样告警数量就大幅减少了。

告警事件支持屏蔽配置

一般就是在做一个预期的维护动作之前，提前把相关告警屏蔽掉，免得在维护期间又收到告警。告警屏蔽一般有两种配置方式，一个是配置成未来的一个时间段，一个是配置成周期性时间段。未来的一个时间段，就是用来应对刚才介绍的预期内维护行为的，周期性时间段比较特殊，比如每天凌晨 1 点到 5 点不需要告警，或者周末不需要告警，就可以配置成周期性屏蔽规则。

告警事件支持抑制配置

​告警抑制的典型使用场景是一个指标配置两条策略，不同的优先级和阈值，如果高优先级的告警触发了，低优先级的告警就被抑制，不再重复发送了。

告警事件聚合发送逻辑

事件降噪发送最有效的技术手段，其实就是聚合发送，能够起到立竿见影的效果。用户的告警规则配置得太乱，系统是没办法左右的，但是短时间触发很多告警，系统是可以通过技术手段聚合之后再发送的。

事件聚合一般是根据两三个维度的信息进行聚合运算，比如告警接收者的维度、时间的维度、指定的某个标签的维度（比如产品线），也可能不指定聚合标签，只使用接收者维度和时间维度，这样聚合率会更高。

从告警聚合通知角度来看，只根据接收人和时间两个维度做聚合就够了，这样的聚合率最高，被打扰的次数最少。虽然会把多种告警消息混杂在一起通知给用户，显得有些混乱，但是用户一般也不会在短信、邮件、即时通信软件里期待分门别类的事件查看效果。想要更好的查看效果，可以去页面上看，页面上有更大的操作区，想怎么聚合就怎么聚合，想怎么看就怎么看。告警都已经发生了，大概率是要打开电脑处理的，都已经打开电脑了，在页面上查看一下也是顺其自然的。

​ 此文章为8月Day14学习笔记，内容来源于极客时间《运维监控系统实战笔记》，推荐该课程。