在事件处理方面,一般我们会遇到两个痛点,一个是告警事件太多,被过度打扰,另一个是重要告警疏漏,无法闭环处理。
告警太多的常见原因
最常见的原因,是告警规则设置得不合理。比如很多规则触发了告警之后,实际没有后续动作,只是起到常态化通知的效果,不需要排查,也不需要止损,甚至连个长线的 TODO 都没有。这类告警多了人就疲了,当重要的告警来临的时候,也容易忽略。这样的规则如果不经过治理,日积月累,就会产生很多无用的告警。
第二个常见的原因是底层出问题导致所有的上层依赖都告警,越是底层影响越大,比如基础网络如果出问题,发出几万条告警都是正常的。
第三个原因是渠道错配。一些不重要的告警也使用打扰性很高的渠道发出,用户可能会觉得单一渠道不可靠,想用多个渠道同时发送的方式来保障告警触达率,这也属于告警规则配置不合理的范畴。
第四个原因是预期内的维护动作导致的。比如程序升级变更,如果进程重启时间过长,可能会导致关联的服务告警,或者某个机器重启,忘记提前屏蔽了,也会产生一堆关联告警。
每个规则都应该对应具体的 Runbook
Runbook 就是告警处理手册,也就是告警触发之后,应该细化排查哪些方面,按照一个什么方式执行动作,应该有一个手册参考。如果告警发生之后没有后续动作,那这个告警的意义就不大了。
不紧急的告警,也必须要有动作,虽然这个动作可能不是立马执行处理,但至少要创建个低优先级的工单之类的,或者提高告警阈值,等问题严重一些再告警。对于只是想通知一下的告警,其实都不算告警,只能看做是一种另类的报表和巡检手段,这样的“告警”就按照报表和巡检的逻辑来处理,比如把这类“告警”发到一个单独的邮件组或者单独的聊天群组,平时都不用关注,只要每天早上上班或晚上下班之前稍微看一眼就行,这样就可以减少打扰。
每个告警都应该合理分级
首先,不同级别的告警应该对应不同的处理逻辑,这样分级才有意义,比如通知渠道不同,通知范围不同,或者介入处理的人的范围不同,处理时效不同 ,如果某两个级别对应完全一样的处理逻辑,就可以合并成一个级别。
如果 Critical 的告警规则很多,大概率也有问题,说明系统架构不够鲁棒,出点什么事都要立刻介入,系统没有自愈能力。这样的系统,需要配备更多运维人员,而且还很难跟老板讲清楚价值。怎么办?这就需要制定运维准入规则,哪个系统要交给运维人员来运维,首先要提供一些信息。
- 相关联系人,出了问题能够及时找到人,联系不上的话得能直接联系研发领导。
- 服务相关信息,比如代码仓库、系统架构、依赖哪些服务、依赖哪些系统参数、哪些 JVM 参数、常见问题还有处理办法等等。
然后进行准入评审,如果系统架构有明显问题,就没办法通过准入要求,不接受运维,如果老板要求必须接,那就只能加人了,或者明确说明在架构调整好之前,不负责 SLA。如果老板不接受沟通,那就跳槽吧,老板根本不懂运维、不懂稳定性还不信任你。
告警规则支持生效时间的配置
不同公司的业务相差很大,比如券商,交易时间段内需要高优保障稳定性,但是非交易时段,有些进程直接停掉也无所谓。但如果是监控系统,数据是时时刻刻都在上报的,没有高峰低谷,需要时刻保证高可用。
重复告警支持最大次数和发送频率
有些告警短时间没法恢复,可能会重复发送。比如一分钟检查一下某个指标,如果超过阈值就告警,从某个时刻开始,触发了阈值,一分钟之后发出第一条告警,但是短时间没有恢复,持续了 10 分钟,监控系统在第二分钟检查的时候发现还是告警状态,可能还会发出一条告警,但是这个告警的重要性就远不如第一条,完全可以不用通知。通过设置发送频率,可以做到比如 1 小时之后再检查,如果 1 小时之后还是没有恢复,再发出第二条告警,这样告警数量就大幅减少了。
告警事件支持屏蔽配置
一般就是在做一个预期的维护动作之前,提前把相关告警屏蔽掉,免得在维护期间又收到告警。告警屏蔽一般有两种配置方式,一个是配置成未来的一个时间段,一个是配置成周期性时间段。未来的一个时间段,就是用来应对刚才介绍的预期内维护行为的,周期性时间段比较特殊,比如每天凌晨 1 点到 5 点不需要告警,或者周末不需要告警,就可以配置成周期性屏蔽规则。
告警事件支持抑制配置
告警抑制的典型使用场景是一个指标配置两条策略,不同的优先级和阈值,如果高优先级的告警触发了,低优先级的告警就被抑制,不再重复发送了。
告警事件聚合发送逻辑
事件降噪发送最有效的技术手段,其实就是聚合发送,能够起到立竿见影的效果。用户的告警规则配置得太乱,系统是没办法左右的,但是短时间触发很多告警,系统是可以通过技术手段聚合之后再发送的。
事件聚合一般是根据两三个维度的信息进行聚合运算,比如告警接收者的维度、时间的维度、指定的某个标签的维度(比如产品线),也可能不指定聚合标签,只使用接收者维度和时间维度,这样聚合率会更高。
从告警聚合通知角度来看,只根据接收人和时间两个维度做聚合就够了,这样的聚合率最高,被打扰的次数最少。虽然会把多种告警消息混杂在一起通知给用户,显得有些混乱,但是用户一般也不会在短信、邮件、即时通信软件里期待分门别类的事件查看效果。想要更好的查看效果,可以去页面上看,页面上有更大的操作区,想怎么聚合就怎么聚合,想怎么看就怎么看。告警都已经发生了,大概率是要打开电脑处理的,都已经打开电脑了,在页面上查看一下也是顺其自然的。
标签:高效,聚合,运维,降噪,发送,维度,告警,比如 From: https://blog.51cto.com/key3feng/7437371