规则设计原则：告警规则的四大要素
聊到告警规则设计，我见过太多团队踩坑了。要么告警轰炸到没人看，要么真正出问题时静悄悄。其实说白了，一条好的告警规则，离不开四个核心要素：指标、阈值、持续时间、聚合窗口。这四个东西就像汽车的四个轮子，少一个都跑不稳。
核心观点：告警规则不是拍脑袋定的，而是基于数据特征和业务容忍度，反复调出来的。
1. 指标：选对数据是第一步
指标就是你要监控的原始数据。比如 CPU 使用率、接口延迟、错误日志数量。我个人习惯，选指标时遵循三个原则：
- 可量化：必须是数值，能比较大小。像「系统卡顿」这种主观描述不行。
- 可采集：能从日志、metrics 接口或 agent 里稳定拿到。我遇到过项目选了「数据库连接池等待数」，结果采集器每 5 分钟才拉一次，根本来不及反应。
- 可解释：指标异常时，团队能快速理解原因。比如「500 错误数」比「内部服务熔断计数」更直观。
我的经验：刚开始做监控时，我恨不得把所有指标都加上告警。结果一天收到 200 条，全是噪音。后来我只保留跟业务直接相关的 5-8 个核心指标，反而问题发现得更快了。
2. 阈值：红线划在哪里
阈值就是触发告警的临界值。这里有个常见的坑——静态阈值。比如 CPU 超过 80% 就告警。但你想过没有？有些服务高峰期 CPU 就是 90%，平时只有 20%。
我建议分两种情况处理：
| 阈值类型 | 适用场景 | 举例 |
|---|---|---|
| 静态阈值 | 指标有明确上限，比如磁盘使用率不能超过 95% | 磁盘 > 90% 告警 |
| 动态阈值 | 指标波动大，比如流量、延迟 | 基于过去 7 天同时间段均值 ±3σ |
| 复合阈值 | 需要多个条件同时满足 | 错误率 > 5% 且 QPS > 1000 |
避坑指南：我曾经给一个接口设了「延迟 > 200ms 告警」，结果发现这个接口本身就有 150ms 的基线。200ms 的阈值等于形同虚设。后来我改成「延迟 > 基线 + 50ms」，才真正有效。
3. 持续时间：别被瞬时抖动骗了
持续时间决定了指标异常要持续多久才触发告警。为什么要加这个？因为系统经常有瞬时抖动。比如网络偶尔丢一个包，CPU 突然飙升 1 秒又降下来。这些都不值得半夜叫醒人。
我一般这样设置：
- 关键业务指标：持续时间可以短一些，比如 30 秒。因为影响面大，宁可误报也不能漏报。
- 资源类指标：比如内存、磁盘，持续时间可以长一些，比如 5 分钟。因为这些指标变化慢，短时间波动通常能自动恢复。
- 日志错误：我习惯设 1 分钟。如果 1 分钟内连续出现 10 次 ERROR 日志，那肯定不是偶然。
一个真实案例：有次线上告警说「数据库连接数超过 80%」，持续了 3 分钟。我一看，原来是定时任务在跑批量查询。如果我把持续时间设成 5 分钟，这个告警根本不会发。所以持续时间不是越长越好，要结合业务节奏来调。
4. 聚合窗口：看多长一段数据
聚合窗口决定了你用什么时间粒度的数据来做判断。比如「过去 5 分钟的平均错误率」还是「过去 1 分钟的 P99 延迟」？
这里有个取舍：
- 窗口太小：比如 10 秒。数据波动大，容易产生大量抖动告警。
- 窗口太大：比如 1 小时。异常被平均掉了，等你发现时问题已经持续很久了。
我个人常用的窗口设置：
| 指标类型 | 推荐窗口 | 原因 |
|---|---|---|
| CPU/内存 | 5 分钟 | 变化慢，窗口太短容易误报 |
| 接口延迟 | 1 分钟 | 需要快速感知，但也要过滤毛刺 |
| 错误日志 | 1 分钟 | 错误通常突发，窗口太长会延迟发现 |
| 业务指标（如订单量） | 10 分钟 | 业务波动大，需要更稳定的趋势 |
一个小技巧：聚合窗口和持续时间可以配合使用。比如窗口设 1 分钟，持续时间设 3 个窗口。这样相当于「连续 3 分钟都异常才告警」，既过滤了抖动，又不会太迟钝。
四大要素如何配合？
嗯，到这里你应该明白了。这四个要素不是孤立的。我举个例子：
# 一个完整的告警规则示例
指标：http_request_duration_seconds（接口延迟）
阈值：P99 > 500ms
聚合窗口：1 分钟（计算过去 60 秒的 P99）
持续时间：连续 3 个窗口（即 3 分钟）
这条规则的意思是：如果过去 1 分钟内，接口的 P99 延迟超过 500ms，并且这种情况持续了 3 分钟，才触发告警。你看，四个要素缺一不可。
最后提醒一句：规则设计好之后，一定要放到预发环境跑几天。我见过太多规则在测试环境完美，上线第一天就炸了。为什么？因为测试流量跟真实流量完全不一样。先观察，再调优，最后才上生产。
公众号:蓝海资料掘金营，微信deep3321