告警通知时如何做到最佳降噪效果

被告警折磨的SRE 2023-04-19 12:06:10

比如在某个凌晨1点30分,突然爆发了300条告警,具体类别和数量如下:

  • 1条交换机网口的状态告警
  • 10条机器失联告警
  • 100个服务成功率告警,有a服务、b服务、c服务、d服务
  • 100个服务延迟告警,有e服务、f服务、g服务
  • 89个连接失败告警,有e服务、f服务、g服务、h服务

这个公司有OnCall团队或运维团队,作为告警接收的第一层团队,所以,这300个告警会一次性推给值班人员张三。张三要是一下子收到300条短信或电话,那显然是很酸爽的,手机可能一直处于被呼叫的状态,都没有办法联系其他人。这就爆发了强烈的通知降噪的需求。

典型的做法

很多厂商的典型的做法是对告警事件做归类,比如按照告警规则,这300个告警事件可以归为5个,如果按照服务归类,可能归类为9个,还有一些厂商采用文本聚类,可能最终归为x个。于是,最终的效果就变成了,作为接收人的我,一次性收到了x个告警,每个告警消息里会告知一些概要信息。这个做法如何?

我的期望

我作为用户,我就想,如果最终就归为1条就好了,既节省了电话、短信的通知费用,也减少了对值班人员的打扰。但是,如果所有消息都聚拢在一个通知里,这个通知的内容就会很简略,这是否是个问题呢?其实还好,原因如下:

  • 相比根据告警规则、服务聚类,确实减少了一些信息,但也没有减少太多。在这一点上来看,半斤八两
  • 实际上,我们要想看具体的告警事件详情,一定是在页面上看的,而不是在短信里或者电话里。而页面上应该要支持聚类,且支持自定义聚类规则,比如 Prometheus alertmanager 或者 Nightingale 都支持类似的展示方式,下面是个例子

告警通知时如何做到最佳降噪效果-告警聚合视图

OK,既然如此,那我们就可以直接把这300条告警归类为1条,然后把处理链接返给用户,用户收到之后,消息里的提示大概是:

xx 告警了,共 300 条,最高级别 Critical,处理链接 https://xxxx

底层逻辑

上面的做法其实就是 FlashDuty 的做法,欢迎大家试用,作为一个统一的事件 OnCall 中心,既可以支持告警聚合降噪,也支持排班、认领、升级、协同等其他功能。上面的降噪逻辑:其实是区分对待了通知降噪和查看降噪,通知降噪做到极致,就通知一条。查看降噪是在页面上根据聚合规则做聚合展示,让用户一目了然的知道有哪些类别的告警事件。相得益彰。

快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat
FlashDuty
Flashduty