告警收敛杂谈

简述

     无论使用哪种监控系统，随着监控项规模的增值，告警的数量也会增多，此时如果我们不对告警进行收敛，可能会因为告警泛滥，超出了接收人的精力范围，可能会导致接收人厌烦告警或者对告警产生质疑，最终导致监控系统的利用价值的降低。

告警收敛的实施位置

      告警是由监控系统产生，经过告警系统，最终到达接收人的设备上，因此告警收敛的实施位置可以分为监控系统和告警系统两点。

      对于监控系统来说，像常见的zabbix或者promethus都提供了告警收敛的功能，使用监控系统提供的功能能一定程度上满足用户的需要，但是如果想添加一些自定义的收敛策略，监控系统往往是不支持的，此时我们可以在告警系统上来做，因为告警系统往往都是公司自己开发的。

告警收敛策略

告警收敛一般会以时间维度和属性维度来做，像zabbix监控系统就是按照时间维度来收敛的，如下图

 zabbix的收敛方式是，随着步骤的增加，我们可以设置不通的发送频次，从而达到告警收敛的效果。

promethus的收敛方式相对zabbix比较丰富些，可以基于分组，标签，时间三种方式达到告警收敛。

相对监控系统来说，告警收敛是告警系统的重要一环，下面是我个人考虑的一个告警收敛流程，如下图：

• 垃圾告警过滤，比如告警脚本逻辑问题导致的告警比如（出现负数，空值等）、过期的告警
• 告警动态定级，我们往往把告警级别提前定义好，一般分为重要、中度、轻度级别，但是如果同等级别的告警相遇，哪个优先处理呢？ 一个轻度的告警遇到一个中度的告警，这个时刻这个中度告警是不是就相当于重要告警，优先处理？所以我感觉要提供一个动态定级的功能，为告警处理人提供一个处理优先级参考，感觉有点像根因分析
• 告警聚合，我们可以将多个告警按照主机维度、接口调用维度、告警等级等维度进行聚合，将合并后的告警推送给接收人。最好维度可以按需进行切换，比如我接收到一个主机维度的告警（告诉我这台机器的内存快用完了，接口成功率低），那我可能还想用接口调用维度看一下，这个接口是否影响了其他接口
• 按照监控项属性进行分组，意思是说业务的告警发送给业务人员，机器的告警发送到机房管理员。如果一条告警既有业务属性又有机器属性，那么这条告警应该发送给业务人员和机器人员，让大家了解一下影响范围
• 告警推送到责任人，相信大家都做过将告警推送到一个群里吧，当告警很多时，效率可以说极低，并且人很累
• 告警升级，当责任人一段时间内没处理相应的告警，应该升级一下，到另一个责任人
• 告警解除，告警解除时候，也应该通知到处理人

今天的文章告警收敛杂谈分享到此就结束了，感谢您的阅读。