CPU 负载高，到底应不应该告警？

CPU 负载高，到底应不应该告警？

• 不告警吧，出了问题怕被怼，嫌你告警缺失
• 告警吧，好像全是噪音，工程师都自动忽略了

尴尬...

成年人的世界没有非黑即白，如果要严肃的论述，就要加很多限定词，为了避免歧义拉齐认知，我先补充一点前置知识（原则）。

前置知识（原则）

告警应该有不同的紧迫级别，有些公司甚至会规定 6 个级别（估计自己的工程师都捋不清楚...），通常建议 3 个级别足够了：

• Critical：已经影响业务，立马需要处理。通常使用打扰性很强的多个告警通知媒介一起发告警消息，比如电话+短信+IM+邮件。比如电商业务订单量下跌严重，就是紧急告警。
• Warning：不用立马处理，可以自动建立工单，慢慢处理。但也必须要处理，如果不处理，可能会酿成大故障。通常也要发告警，只不过选用的通知媒介没有那么强的打扰性。比如重要机器的磁盘使用率已经 95%，可能再有 24 小时就要写满了；或域名证书再有 3 天就要过期了之类的。
• Info：仅生成告警事件，不用发告警通知，相当于是从海量指标里提取了一些稍微重要的信息。如果有故障发生，这些信息是作为故障排查的线索依据。比如某个 Pod 被驱逐漂移了；或者某个用户尝试登录系统的失败次数太多。

整体来看，可以分成两个大类：

• 要处理的：Critical、Warning
• 不用处理的：Info

其中，Info 不关键，可配可不配，完全可以等到后面你的监控、故障定位体系做得很精细化的时候再说。我们重点关注前面两个级别：Critical 和 Warning，这俩级别有个相同点，就是都！要！处！理！英文世界里通常称之为 actionable（感觉很精确）。

所以，CPU 负载高，到底要不要配置告警？

CPU 告警的制定逻辑

• 如果 CPU 告警产生之后，你们有后续处理动作，那就应该配置，即便这个动作是登录机器瞅一眼，出两句跟进结论，也算动作
• 如果没有后续动作就无需配置，比如看到了这个告警，习惯了，直接忽略了，这就不算动作，这个告警就不应该配置；或者，也可以配置，但是作为 Info 级别，仅生成告警事件，不做告警通知

其实，不仅仅是 CPU 告警，所有的告警规则配置，都是这个逻辑，所有的告警规则，都应该是 actionable 的。所以，理论上，每个告警规则都应该对应一个 SOP（处理预案），Prometheus 和夜莺的告警规则里都有个 Annotations 字段，典型的应该放到 Annotations 中的字段就是 SOP URL 和 Dashboard URL。

很多人看到这里，觉得，那这个工作量大了，每个告警规则都要整理 SOP（不同的公司 SOP 通常不同，一些中间件、数据库的部分 SOP 可能相同），之前就仅仅是从网上找了一些告警规则导入即可，以为就完事了，没成想还有这些活要干！

其实，相比搭建一套监控系统，这才是更有价值的事情啊！

本文作者：秦晓辉，夜莺开源项目创始人，极客时间专栏《运维监控系统实战笔记》作者，目前在监控、可观测性领域创业。