首先，不同级别的告警应该对应不同的处理逻辑，这样分级才有意义，比如通知渠道不同，通知范围不 同，或者介入处理的人的范围不同，处理时效不同 ，如果某两个级别对应完全一样的处理逻辑，就可以 合并成一个级别。 我的做法是把告警分成 3 个级别。 级别 通知渠道 说明 Critical 电话、短信、即时消息、邮件 影响收入的、影响客户的，必须立刻处理 Warning 的三级收敛机制，会有非常好的降噪效果，大幅减 少打扰。示意图如下： 监控系统会产生原始的告警事件（event），属于同一个告警的多个事件被合并成告警（alert），类似的告 警（比如某个标签相同，或者文本相似度很高）被合并成故障（incident），最终通知用户的是一个个故 障，大幅降低了打扰性。 不同的告警事件，通常有不同的分发逻辑，比如不同时段不同的分发逻辑：白天用短信通知，晚上用电话 "host=host1"]) 这个值姑且称为事件 Hash，相同 Hash 的事件就被聚合为一条告警。更复杂的是告警到故障的合并，当 前我们支持基于规则的聚合，后面会基于算法聚合： 比如基于告警规则标题做聚合，某一时刻，基础网络故障，有 1000 台机器同时报了失联告警，就可以很 方便地合并成一个故障，只通知这一个故障即可，大幅降噪减少通知打扰。 故障抖动 有的时候会出现一会告警一