预警通知告警去重与合并：避免告警风暴

核心交换机一抖动，几十台服务器同时报 CPU 高、磁盘满、端口不通，值班人手机几分钟内被几十通语音电话打爆，反而找不到真正的根因。这就是典型的告警风暴。预警通知接进来之前，必须先做好去重与合并。

告警风暴是怎么产生的

监控系统每发现一个异常就独立发一条告警，上游一个故障会扇出成下游无数个症状告警。如果这些告警都直接打到预警接口，不仅浪费通道资源，更严重的是让值班人陷入信息过载。去重合并做在客户端这一层，比让每个监控系统各自处理更统一。

去重与合并的实现思路

核心是在业务侧加一层"告警网关"：相同指纹的告警在时间窗内只发一次，多个相关告警聚合成一条。下面用 Python 演示一个去重：

import time
seen = {}

def should_send(fingerprint, window=60):
    now = time.time()
    last = seen.get(fingerprint, 0)
    if now - last < window:
        return False
    seen[fingerprint] = now
    return True

def on_alert(host, metric):
    fp = "%s:%s" % (host, metric)
    if not should_send(fp):
        return
    requests.post("https://api.ihuyi.com/voice/vm", data={
        "account": APIID, "password": APIKEY,
        "mobile": oncall_mobile, "content": "%s %s异常" % (host, metric)
    })

合并降噪的常用策略

• 按主机加指标做指纹，30 到 60 秒内同一指纹只发一次。
• 同机房、同故障域的告警聚合成一条摘要，例如"机房 A 内 12 台主机离线"。
• P2 级告警攒批发送，P0 级告警立即穿透。
• 根因告警通知一线值班，衍生告警只在工单里记录，不再打电话。

举个实际例子：核心交换机抖动后，挂在它下面的 20 台服务器同时上报"端口不通"。如果不做合并，值班人会在一分钟内接到 20 通语音电话；合并后只发一条"接入交换机 S1 下联 20 台设备离线"，值班人直奔交换机排查即可。这种聚合需要在告警网关里维护一张"主机到故障域"的映射表。

去重规则需要定期回顾

去重指纹和时间窗不是配好就一成不变的。上线一段时间后，要回顾哪些告警被合并后反而延误了响应、哪些指纹粒度过粗把不同故障合在了一起。把误合并的案例补充进规则，去重策略会越用越准。互亿无线的发送记录和回调状态是回顾规则好坏的数据来源。

去重不等于漏报

去重是合并相似告警、抑制重复噪音，而不是把告警吞掉。合并后仍要明确告诉值班人"影响了哪些对象、根因可能是什么"。互亿无线支持短信留痕加语音强提醒的组合，把合并后的摘要用短信发清楚，再用一通语音电话叫醒值班人即可。

指纹设计的粒度

去重指纹太粗会把不同故障合并，太细又压不住风暴。常见做法是主机加指标做指纹，再按故障域聚合。例如同一交换机下联的 20 台主机报"端口不通"，指纹各不相同，但故障域相同，聚合后只发一条摘要。

合并摘要怎么写

摘要要写清楚三件事：哪个故障域、影响多少对象、关键的一条是什么。例如"接入交换机 S1 下联 20 台设备离线，首条 web-10 端口不通"。值班人听到就知道直奔交换机，而不是逐台排查。

互亿无线按成功计费，合并后发送量下降，成本也随之降低。

去重规则的回顾机制

去重指纹和时间窗上线后要定期回顾。可以每月导出一次被抑制的告警，看有没有该发没发、不该合并却合并了。把误判案例补充进规则，系统会越用越准。互亿无线的发送记录和回调状态就是回顾的数据来源。

去重的目标是降噪，不是吞告警。合并后摘要里仍要写清根因和影响面，值班人看到一句话就知道该往哪查。

去重与漏报的平衡

时间窗太短压不住重复，太长又可能漏报新故障。建议从 60 秒起步，观察回调数据后微调。P0 告警不受抑制窗口限制，始终穿透，避免为了降噪把真正紧急的告警也吞掉。

去重后的发送内容

合并后的摘要要短信发清楚、语音叫醒人。短信写全影响面，语音只点关键一条，值班人一听就知道往哪查。

这套去重合并逻辑做在告警网关层，长期复用、统一回顾，是治理告警风暴的起点。

治理告警风暴，先从去重合并开始，注册免费试用搭建你的告警网关。