告警风暴治理：阈值与持续时间

凌晨三点手机连环震动，早上醒来几十条未读告警，服务却什么事都没有。这不是故障太多，是阈值和持续时间没设计好，告警风暴就是这么养出来的。 一、毛刺为什么全变成了告警 备份任务、日志切割、批量编译，每台机器都有瞬时尖峰。阈值定成"超一点就报"，这些毛刺全数变成告警，统计意义上的告警绝大多数属于这类噪音，白占值班注意力。告警风暴还有个副作用：通知渠道被占满，真正的告警反而发不出去。告警一多人就疲，真故障混在噪音里反而没人看，等于没有监控。 二、持续时间是第一道过滤 Prometheus 的告警规则有 for 参数，CPU 超过 90% 配 for: 5m，两三分钟的尖峰自然被滤掉；Zabbix 的触发器支持多次采样确认，思路相同。给每个阈值配一段持续时间，是成本最低的降噪手段。持续时间太长也有代价，真实故障的发现会被推迟，五到十分钟对多数指标是平衡点。 三、分级让轻重有序 把告警分成三档：提醒档，比如磁盘 80%，工作时间处理；警告档，磁盘 85%、CPU 持续偏高，当天处理；严重档，服务不可达、磁盘 95%，立刻电话通知。档位越高，打扰手段越硬，夜班只让严重档进电话。分级标准写进值班手册，新人也照单执行，不靠个人经验临场分级。同一指标在不同时段可以有不同阈值，业务高峰适当放宽。 四、静默与收敛 变更窗口提前设静默，避免例行重启触发一串告警，静默要有到期时间，忘关的静默比告警更危险。同一根源的故障做收敛：一台交换机断了，把下面三十台机器的全部告警合并成一条根源事件，常用手段是按标签分组，同类合并计数，详情进面板看。 最后一条纪律：每条告警都必须对应一个明确的处理动作，写不出来就先降级为提醒。告警不是越多越安全，是越准越安全。