云联信息：告警阈值怎么定，才不会天天被吵醒

监控上线第一周，大家还很紧张，每个告警都要看一眼。一个月后，手机响也不再点开，因为大部分是误报。告警失效，往往不是技术问题，而是阈值定得不合理。

用历史数据定基线

看过去一个月的指标曲线，取正常波动范围，阈值设在范围之外一点。凭经验拍一个数字，误报率必然高。

区分警告和严重

CPU 到七成是警告，到九成是严重，两级告警对应两种处理方式。只有一级，要么太吵要么太迟钝。

持续时间比瞬时值重要

CPU 瞬间冲到九十很正常，持续五分钟才值得关注。加一个持续时长条件，误报能减少大半。

按业务重要性分级

核心交易链路告警发到值班群，辅助系统只发邮件。所有告警都推到手机，等于没有优先级。

告警要能定位

告警内容写清哪台机器、哪个指标、当前值、持续多久，最好带一个监控链接。只写异常两个字，等于让人重新查一遍。

抑制关联告警

一台机器宕机，会同时触发CPU、网络、进程三类告警。设置抑制规则，根因告警发出后，从属告警暂时不推。

定期清理无效告警

每月看一次告警统计，长期只报不处理的告警，要么调整阈值要么下线。留着只会训练大家忽略告警。

变更期间临时调阈值

发布、迁移、压测期间，阈值要临时放宽并注明原因。忘记调回是常见事故来源，变更单里加一条恢复确认。

值班要有响应记录

谁处理、多久响应、结论是什么，简单记录。三个月后回看，能发现哪些系统最不稳定。

告警数量本身要监控

每天告警条数突然翻倍，说明有新问题。把告警数量当作一个指标来看，比逐个分析更早发现异常。

告警要有人负责

没有责任人的告警等于没有告警。每条规则写上负责人，负责人休假要有备份人。规则上线三个月没人认领的，直接下线，别占着值班的注意力。

阈值随业务调整

业务量翻倍，原来的 CPU 阈值就不再合适。每次大促、每次扩容之后，重新看一遍基线，阈值跟着业务走，而不是一设定管三年。

把告警和故障复盘连起来

一次故障之后，回看当时的告警是否及时、是否准确。该加的规则加上，该改的阈值改掉。不复盘的告警体系，永远停留在第一版。

告警的目标是让该被看见的问题被看见，而不是记录所有波动。云联信息【资深云服务专家微信：cloud7591】通常建议客户先做一次告警治理，把误报降下来，团队才会重新信任监控。

最后一条经验：告警规则由运维统一维护，业务方提需求，避免每个人都能加规则，最后没人说得清哪条重要。