CPU 负载高，到底应不应该告警？
- 不告警吧，出了问题怕被怼，嫌你告警缺失
- 告警吧，好像全是噪音，工程师都自动忽略了
这是很多新手、甚至是老手的困惑。笔者做监控系统十多年了，分享一下个人观点，仅供参考。
成年人的世界没有非黑即白，如果要严肃的论述，就要加很多限定词，为了避免歧义拉齐认知，我先补充一点前置知识（原则）。
核心结论
- CPU 负载高不是天然应该告警，也不是天然不该告警，关键看它是否需要人处理。
- 如果告警触发后有明确 owner、处理动作、SOP 和 Dashboard，它就可以进入 Critical 或 Warning 链路。
- 如果团队看到 CPU 告警只会习惯性忽略，它就不应该强通知，最多作为 Info 事件保留排障线索。
- 所有告警规则都应该是 actionable，也就是“收到之后知道该做什么”。
前置知识（原则）
告警应该有不同的紧迫级别，有些公司甚至会规定 6 个级别（估计自己的工程师都捋不清楚…），通常我建议 3 个级别足够了：
- Critical：已经影响业务，立马需要处理。通常使用打扰性很强的多个告警通知媒介一起发告警消息，比如电话+短信+IM+邮件。比如电商业务订单量下跌严重，就是紧急告警。
- Warning：不用立马处理，可以自动建立工单，慢慢处理。但也必须要处理，如果不处理，可能会酿成大故障。通常也要发告警，只不过选用的通知媒介没有那么强的打扰性。比如重要机器的磁盘使用率已经 95%，可能再有 24 小时就要写满了；或域名证书再有 3 天就要过期了之类的。
- Info：仅生成告警事件，不用发告警通知，相当于是从海量指标里提取了一些稍微重要的信息。如果有故障发生，这些信息是作为故障排查的线索依据。比如某个 Pod 被驱逐漂移了；或者某个用户尝试登录系统的失败次数太多。
整体来看，可以分成两个大类：
- 要处理的：Critical、Warning
- 不用处理的：Info
其中，Info 不关键，可配可不配，完全可以等到后面你的监控、故障定位体系做得很精细化的时候再说。我们重点关注前面两个级别：Critical 和 Warning，这俩级别有个相同点，就是都！要！处！理！英文世界里通常称之为 actionable。
所以，CPU 负载高，到底要不要配置告警？
| 告警级别 | 是否需要通知 | 典型 CPU 场景 | 处理要求 |
|---|---|---|---|
| Critical | 需要强通知 | 已经影响业务，或核心服务 CPU 异常导致请求失败、延迟明显升高 | 立刻处理，配套电话、短信、IM 等强通知 |
| Warning | 需要弱通知或工单 | 趋势恶化但还未直接影响业务，例如持续高负载且容量余量不足 | 必须有人跟进，但不一定立刻叫醒 |
| Info | 通常不通知 | 偶发高负载、自动恢复、仅作为排障上下文的 CPU 事件 | 保留事件，供事故排查时关联 |
CPU 告警的制定逻辑
- 如果 CPU 告警产生之后，你们有后续处理动作，那就应该配置，即便这个动作是登录机器瞅一眼，出两句跟进结论，也算动作
- 如果没有后续动作就无需配置，比如看到了这个告警，习惯了，直接忽略了，这就不算动作，这个告警就不应该配置；或者，也可以配置，但是作为 Info 级别，仅生成告警事件，不做告警通知
其实，不仅仅是 CPU 告警，所有的告警规则配置，都是这个逻辑，所有的告警规则，都应该是 actionable 的。所以，理论上，每个告警规则都应该对应一个 SOP（处理预案），Prometheus 和夜莺的告警规则里都有个 Annotations 字段，典型的应该放到 Annotations 中的字段就是 SOP URL 和 Dashboard URL。
很多人看到这里，觉得，那这个工作量大了，每个告警规则都要整理 SOP（不同的公司 SOP 通常不同，一些中间件、数据库的部分 SOP 可能相同），之前就仅仅是从网上找了一些告警规则导入即可，以为就完事了，没成想还有这些活要干！
其实，相比搭建一套监控系统，这才是更有价值的事情啊！
一条 CPU 告警至少要配什么
如果决定配置 CPU 告警，建议至少补齐四类信息。
- 影响判断：这台机器、Pod 或服务对应什么业务，CPU 高会影响吞吐、延迟还是后台任务。
- 处理动作：收到告警后先看什么，例如进程占用、负载趋势、上下游请求量、是否刚发布。
- 定位入口：在告警注解里放 SOP URL 和 Dashboard URL，不要让值班人从空白页面开始找。
- 通知策略：Critical、Warning、Info 分开处理，不要让所有 CPU 越线都走同一条强通知链路。
判断 CPU 告警是否合理的检查表
- 收到这条告警后，是否有人必须处理？
- 值班人是否知道第一步该查什么？
- 告警是否能说明对象、环境、服务和当前值？
- 告警是否有 SOP URL 或 Dashboard URL？
- 过去一段时间里，这条告警是否经常被忽略？
- 如果把它降级为 Info，只保留事件不通知，会不会影响故障发现？
如果这些问题大部分答不上来，问题不在 CPU 指标，而在告警规则没有被设计成可处理事件。
FAQ
CPU 使用率一高就应该打电话吗？
不应该。CPU 高只是现象，是否打电话取决于业务影响和处理紧急度。已经影响核心业务时可以是 Critical；只是容量趋势或潜在风险时更适合作为 Warning；没有处理动作时不应强通知。
CPU 告警阈值应该统一吗？
不建议一刀切。不同服务的 CPU 使用模式不同，批处理、在线服务、网关、数据库和缓存的风险不同。更重要的是把阈值、持续时间、业务影响和处理动作放在一起设计。
没有 SOP 的 CPU 告警能不能先上线？
可以临时上线，但不应该长期这样运行。没有 SOP 的告警会把判断压力转给值班人，时间久了容易变成噪音。至少要在注解里补一个 Dashboard 入口和基本排查步骤。
结论
CPU 负载高是否告警，答案不是看指标名字，而是看告警是否可处理。能触发明确动作的 CPU 告警值得配置；没有 owner、没有 SOP、没有后续动作的 CPU 告警，即使阈值再漂亮，也只是把噪声推给值班人。
