告警规则设计：如何编写精准的告警规则，避免误报和漏报
告警规则写不好，运维就天天被"狼来了"折磨。要么半夜被假告警吵醒，要么真出事了收不到消息。我这些年踩过的坑不少，今天把经验掰开揉碎讲给你听。
告警规则的核心三要素
我个人习惯把告警规则拆成三块：维度、阈值、窗口。这仨配合不好，必然出问题。
| 要素 | 定义 | 常见翻车点 |
|---|---|---|
| 维度 | 监控的对象（实例、集群、地域、服务） | 维度太粗，多个实例混在一起；维度太细，一个实例波动就告警 |
| 阈值 | 触发告警的数值边界 | 静态阈值一刀切，业务高峰期必然误报 |
| 窗口 | 持续多久才算事件 | 窗口太短，瞬态抖动变告警；窗口太长，真实故障响应慢 |
误报与漏报的根源分析
误报和漏报，本质上就是规则没对齐真实故障场景。我把它归结为三类原因：
- 阈值与业务脱节——你拿CPU 80%当红线，但你们业务高峰期就是跑85%的，这规则不炸才怪。
- 忽略时间序列特征——突发尖峰、周期性波动、缓慢爬升，这三种模式需要的规则完全不同。
- 依赖单一指标——光看内存使用率不够，得结合GC频率、连接数一起看。
举个例子：我曾遇到一台机器内存告警每10分钟响一次，上了大盘一看，原来是Java应用在FullGC前会瞬间冲高，GC完就回落。这不是故障，是JVM的正常行为。把阈值提上去、加上持续时间条件后，再没误报过。
精准告警规则的设计原则
我总结了四条原则，按优先级排：
- 先降噪再告警——用聚合、滑动窗口、同比/环比对比消除瞬态噪声。比如"过去5分钟平均错误率 > 0.1%，且同比昨天同一时段上涨3倍"。
- 多指标联合判断——单指标告警是病，得治。比如磁盘使用率超过85% + inode耗尽速度快于1%/小时才告警，避免被定期清理脚本误触。
- 设置收敛与抑制——同一故障不要重复告警。可以用"每30分钟内只发一次"或"依赖关系抑制"（上游挂了，下游的告警自动静默）。
- 能数学就不经验——用百分位数（P99/P95）代替平均值，用标准差计算动态基线。比如"请求延迟超过P99阈值的1.5倍持续1分钟"，比设一个固定500ms聪明得多。
我记得有一次处理Redis慢查询告警，原始规则是"slowlog 数量 > 10"。但业务大促时slowlog数量轻松破百，全是正常读请求。后来改成"慢查询耗时 > 100ms的占比超过5%且连续2分钟"，这个规则一直用到今天都没改过。
实战：从业务指标到告警规则
下面这张图展示了我常用的设计流程：从原始指标到最终落地的告警规则需要经过四步加工。
一个典型案例：CPU告警的演变
拿CPU使用率告警来说，我经历过三个版本：
| 版本 | 规则 | 效果 |
|---|---|---|
| V1 | CPU > 80% 立即告警 | 误报率70%。业务初始化、定时任务、发布部署都触发 |
| V2 | CPU > 80% 持续5分钟告警 + 排除每天凌晨3-4点的定时任务窗口 | 误报降至30%。但还是有发布时短暂高负载的假告警 |
| V3 | CPU > 80% 持续5分钟 且 负载偏离过去7天同期P95基线2个标准差 | 误报降至5%以下，漏报控制在1%以内 |
V3版本的核心思路是：让它知道什么是"反常"。说白了，你的服务正常高峰期就是跑75%，偶尔冲到80%没问题。但如果是凌晨低谷期从20%突然蹦到80%，那多半有问题。这个逻辑用PromQL写出来就是：
# 原始值高于80%且高于基线2个标准差
avg by(instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])) > 0.8
and
avg by(instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))
>
( avg_over_time(avg by(instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))[7d:5m] )
+ 2 * stddev_over_time(avg by(instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))[7d:5m] ) )
avg_over_time和stddev_over_time算出动态基线。这样业务增长或正常波动时，基线自动调整，不会因为业务扩容而突然告警。缺点是计算资源开销大，建议只在核心服务上用。
嗯，这里要注意：动态基线也不是万能的。如果服务长期波动剧烈，标准差很大，就会导致告警门槛太高而漏报。这时可以改用百分位数，或者对指标做预处理——比如先做平滑再算基线。
我后来还试过一种做法：多维度交叉验证。不只看CPU，还看同一时间段的QPS、错误率、GC次数。如果CPU高但QPS也同步升高，那可能是正常的业务高峰；如果CPU高但QPS下降、错误率上升，那才是真故障。这个多指标联合条件写起来复杂，但一旦命中，100%是事故，运维团队再也不用猜了。
最后送你一句话：告警规则不值得一步到位。先写个能用的，然后每周复盘告警准确率，把误报的规则逐一打磨。我带的团队有个规矩：每个人每月必须优化两条规则，要么降低误报率，要么缩短告警延迟。半年下来，告警的S/N比提升了10倍。