比如在某个凌晨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 中心，既可以支持告警聚合降噪，也支持排班、认领、升级、协同等其他功能。上面的降噪逻辑：其实是区分对待了通知降噪和查看降噪，通知降噪做到极致，就通知一条。查看降噪是在页面上根据聚合规则做聚合展示，让用户一目了然的知道有哪些类别的告警事件。相得益彰。