告警阈值怎样定？

访客性能优化 2026-06-06 00:28:54 1

本文目录导读：

这是一个很专业的问题，告警阈值设置得不好，要么会导致告警风暴（全是垃圾信息，让运维人员麻木），要么会导致漏报（系统挂了却没反应）。

制定告警阈值通常遵循 “一稳、二配、三动、四静” 的原则，下面从方法论到具体数值,给出一个实用的指南。

核心原则：避免两个极端

黄金标准：告警是为了让工程师在系统“即将出问题但还能补救”的时候收到通知。

做法：根据经验或业界标准直接设置固定值。
示例：
- CPU使用率 > 80% （持续5分钟）
- 内存使用率 > 90%
- 磁盘使用率 > 85% （特别是根分区）
- 5xx错误率 > 1% （持续1分钟）
优点：快速生效,清晰易懂。
缺点：缺乏弹性，比如深夜流量低谷，CPU 80%可能是异常；大促时CPU 95%可能是正常的。

做法：系统自动学习过去7天/30天的历史数据，计算出基线，并根据标准差（如±3σ）动态调整。
示例：
- 突增/突降：访问量突然比过去1小时的平均值高出300% 或降低90%（可能代表爬虫攻击或服务挂掉）。
- 上升趋势：内存使用率在30分钟内从50%线性增长到70%（可能内存泄漏）。
优点：能适应业务波动,非常精准。
缺点：需要平台支持（如Prometheus + Anomaly Detection）。

做法：对比“昨天的此刻”或“上周的今天”。
示例：
- 当前QPS（每秒查询率）比昨天同一时刻下降 > 50%（可能上游挂了）。
- 当前P99延迟比上周同一时刻增加 > 100%（系统变慢了）。
优点：能屏蔽业务的周期性波动（如白天高、晚上低）。

以下是经过大量系统验证的经验值（通常分为警告（Warning） 和 严重（Critical） 两级）：

指标	警告（Warning）	严重（Critical）	备注
CPU使用率	> 80% （持续5分钟）	> 95% （持续2分钟）	注意IO Wait，如果IO Wait高但CPU低，也可能是磁盘问题
内存使用率	> 80%	> 90%	特别注意Java/Go的堆内内存和Off-Heap比例
磁盘使用率	> 80%	> 90%	系统分区（/）建议设为75% Warning，90% Critical
磁盘IOPS	> 80% 最大能力	> 90% 最大能力	云服务器通常有IOPS上限
网络带宽	> 80% 带宽上限	> 90% 带宽上限	注意入口和出口流量要分开
P99延迟	基线值 x 2	基线值 x 5	例如接口平时100ms，200ms告警，500ms严重
错误率	> 1%	> 5%	HTTP 5xx或业务错误
API成功率	< 9%	< 5%	关键支付接口甚至要求99.99%
GC次数/频率	Full GC > 1次/小时	Full GC > 5次/10分钟	或Young GC时间占总时间 > 20%
TCP连接数	> 最大连接数的 70%	> 最大连接数的 90%	注意TIME_WAIT状态连接占比

不要只设一个阈值。
- 设置 Duration（持续时间）：CPU 95%持续1秒可能是尖刺,持续5分钟就是真问题。
- 至少要设置一个持续时间窗口，rate(error[5m]) > 0.01。
比绝对值更重要的是变化率。
- “当前延迟是100ms” 不一定是问题。
- “当前延迟是100ms，但1分钟前是20ms，增加了5倍” 这是大问题。
为“0”设置告警。
- 有时候没有告警才是最可怕的。QPS突然降为0（服务挂了）、日志突然停止输出（磁盘写满或程序死锁）、心跳包消失。
区分“可用性”和“性能”。
- 服务可用但极慢，可能比服务完全不可用更糟糕，接口返回200，但耗时10秒，用户全跑了。性能阈值应比可用性阈值更严格。
告警必须有Action。
- 如果收到告警，你只能看着系统慢慢变好而无法操作，那么这个告警就是噪音。
- 标准：收到告警后，你能回答“我需要重启服务”或“我需要扩容”,否则就调低级别或删除。