告警风暴的成因：重复告警、抖动告警、间歇性告警的根因分析

告警风暴，说白了就是一瞬间告警像雪崩一样砸过来。我见过最夸张的一次，某电商平台大促期间，5分钟内涌入了12万条告警。值班同学直接懵了，屏幕上的告警列表滚都滚不动。嗯，这种场景下，真正重要的故障反而被淹没了。

要治理告警风暴，得先搞清楚它怎么来的。我个人习惯把告警风暴的根因分成三类：重复告警、抖动告警和间歇性告警。这三兄弟各有各的脾气，咱们一个一个拆解。

一、重复告警：同一个问题，反复报

重复告警是最常见、也最好理解的一种。你想想看，一个磁盘满了，监控每5秒采集一次，每次采集都触发告警。一分钟下来就是12条，一小时就是720条。这就是典型的重复告警。

我在项目中遇到过最离谱的一次，一个Nginx进程挂了，监控脚本每10秒检查一次进程状态，每次检查都发一条告警。结果一晚上生成了8000多条告警。后来一查，告警接收人早就把手机静音了——因为实在受不了那个震动频率。

根因分析：

• 监控粒度太细：采集周期设置过短，比如1秒、5秒。其实对于大多数基础设施指标，30秒到1分钟完全够用。
• 缺乏告警聚合：没有把相同主机、相同指标的告警合并成一条。比如“主机A磁盘使用率>90%”这种告警，应该只发一条，而不是每次采集都发。
• 恢复告警缺失：有些系统只触发告警，不触发恢复。结果告警一直处于“触发中”状态，系统就一遍遍重复发送。

二、抖动告警：指标在阈值边缘反复横跳

抖动告警比重复告警更恶心。它不是说一直报，而是报了又恢复、恢复了又报。你想想看，CPU使用率在89%和91%之间来回波动，阈值设的是90%。那结果就是：告警→恢复→告警→恢复……

这种告警对值班同学的心理伤害最大。我记得有一次，一个数据库的连接数在阈值附近波动，一晚上触发了200多次告警和200多次恢复。值班同学半夜爬起来看了三次，每次都是“看一眼，恢复了，继续睡”，然后刚躺下又响了。

根因分析：

• 阈值设置不合理：单阈值策略太脆弱。指标稍微波动一下就会触发。
• 缺乏“持续时长”判断：很多告警规则是“超过阈值就告警”，没有要求“持续超过阈值N分钟才告警”。
• 业务本身有周期性波动：比如每天早上8点、晚上8点有流量高峰，但阈值是固定的。

解决方案：

1. 使用“持续时长”参数：比如“CPU使用率>90%持续5分钟才告警”。
2. 设置“恢复延迟”：指标回落到阈值以下后，再等2分钟才发恢复通知。避免频繁切换。
3. 采用动态阈值：根据历史数据自动计算阈值，而不是拍脑袋定一个固定值。

三、间歇性告警：时有时无，最难排查

间歇性告警是最让人头疼的。它不像重复告警那样规律，也不像抖动告警那样频繁。它可能一天出现几次，每次持续几分钟，然后就自己消失了。你去看的时候，一切正常。你不管它，它又冒出来了。

我印象最深的一次，一个支付服务的错误率告警，每天下午2点到4点之间会出现3-5次，每次持续1-2分钟。我们排查了整整两周，最后发现是某个上游服务的GC停顿导致的。GC每次停顿几百毫秒，刚好导致支付请求超时，但GC一结束，服务又恢复正常了。

根因分析：

排查思路：

• 时间关联分析：把告警时间点和所有变更记录、定时任务、GC日志对齐。我习惯用时间轴图来对比。
• 指标关联分析：看告警发生时，其他相关指标有没有异常。比如错误率升高时，CPU、内存、网络有没有波动。
• 日志采样：在告警触发时，自动抓取相关服务的日志片段。很多间歇性问题，事后看日志是看不出来的。

四、三种告警的对比与治理策略

三种告警的根因不同，治理手段也不一样。我整理了一个对比表，方便你快速参考：

说白了，告警风暴的治理不是一蹴而就的。我个人习惯是：先治重复，再治抖动，最后攻坚间歇性。因为重复告警的治理成本最低、效果最明显。把重复告警干掉，告警量至少能降80%。

五、知识体系结构图

下面这张图展示了告警风暴的三种成因及其治理路径，你可以对照着梳理自己的告警体系：

嗯，到这里告警风暴的三种成因就讲清楚了。记住一个原则：告警不是越多越好，而是越准越好。把重复和抖动干掉，你的值班同学会感谢你的。