告警风暴会淹没真正的问题 网络抖动一次，可能在两分钟内冒出几百条告警：每台机器的接口超时、每个探针的探测失败都重复报警。值班人员手机被短信轰炸，反而漏掉了真正需要处理的那条。预警通知API本身发送很快，但如果上游不做去重与合并，再快的通道也…
告警风暴会淹没真正的问题
网络抖动一次，可能在两分钟内冒出几百条告警：每台机器的接口超时、每个探针的探测失败都重复报警。值班人员手机被短信轰炸，反而漏掉了真正需要处理的那条。预警通知API本身发送很快，但如果上游不做去重与合并，再快的通道也只会放大噪音。互亿无线预警通知API支持合并后批量发送，关键是在上游做好去重。
本文说明告警去重与合并的常见策略与文案写法。
去重与合并策略
- 同事件去重：以"对象+级别+指标"为键，短时间内相同告警只通知一次。
- 时间窗口合并：把1分钟内同对象的多条告警合并成一条汇总通知。
- 根因收敛：下游服务告警往往由上游故障引起，优先通知根因，抑制派生告警。
import time
seen = {}
def should_send(key, ttl=60):
now = time.time()
if key in seen and now - seen[key] < ttl:
return False
seen[key] = now
return True
合并后怎么写通知
合并后的短信应包含故障对象数量与代表性描述，例如：
- 合并短信：【告警】10台服务器接口超时，首条：订单服务502。
- 合并语音：检测到十台服务器接口超时，请优先排查订单服务。
去重不等于忽略
去重窗口怎么定
去重窗口太短，挡不住重复告警；太长，又可能漏掉后续真正需要关注的新事件。建议常规告警用60到120秒窗口，同一对象同一指标在窗口内只发一次；对于持续恶化的指标，比如磁盘使用率从85%涨到95%，可以在跨越阈值时重新通知一次。这样既抑制了刷屏，又不丢失重要变化。
合并后的通知要保留足够信息：合并了几条、代表性事件是什么、建议先查哪里。值班人员看到一条汇总就能判断影响面，而不是对着上百条重复短信发呆。互亿无线按成功计费，合并后发送条数减少，费用也相应下降。
常见去重键的设计
去重键通常由几个字段拼接而成：监控对象IP、告警指标名称、告警级别。同一对象同一指标在窗口期内反复触发，只发送一次。对于持续恶化的情况，可以在指标跨越新阈值时再发一条，既降噪又不丢失变化。
合并时把窗口期内的同类告警聚合成一条，文案里写清数量和代表性事件。这样值班人员看到一条汇总就能判断影响面，而不是被上百条重复短信淹没。
去重的实际效果
做好去重合并后，值班人员收到的告警数量通常能下降一大截，但关键告警一条不少。被抑制的重复告警仍记录在系统里，只是不再重复发短信。故障恢复后发一条汇总，说明期间共合并了多少条，让值班人员对影响面有数。
去重键设计要结合自己的监控对象，太粗会漏掉不同事件，太细又挡不住重复。上线后根据实际告警形态微调窗口和键。
静默窗口的设置
对同一告警设置静默窗口，窗口内只通知首次，后续重复触发不再打扰。窗口结束或故障恢复时再发一条收尾。这样值班人员不会被同一个问题反复叫醒，同时关键信息也没有遗漏。窗口长短根据业务容忍度调整。
去重合并不是一次性脚本，而是要长期运行的规则。建议每周回顾一次被合并的告警，看看合并逻辑是否合理，有没有把不同事件错误合并，或漏掉了该通知的新变化。规则随着业务演进而持续微调，效果才会越来越好。
每周回顾合并规则，是让去重逻辑长期有效的必要维护。
去重规则上线后要持续观察，既不能压掉重要新事件，也不能留太多重复告警。根据实际告警形态调整窗口和键，是一个不断贴近业务的过程。
被合并的告警仍在系统中留痕，事后复盘可查，不会因为降噪而丢失细节。
持续微调去重规则，让它既挡得住重复告警，又不漏掉关键新事件。
去重合并让值班人员在告警洪峰中仍能抓住主线，处理效率反而更高。
去重窗口内要记录被合并的告警数量，故障恢复后发一条"已恢复，期间共N条告警"的汇总。互亿无线按成功计费，去重后发送量下降，费用也随之降低。注册免费试用，用测试条数验证合并通知的文案与触达效果。
