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

从业务影响和处理动作决定 CPU 告警条件、级别和通知方式，为每条需要处理的规则补上排查预案。

最后校对于 2026-10-11

读完这页，你会决定哪些 CPU 异常值得通知人，并为告警写出接到消息后应该做什么。

## 先看有没有处理动作[​](#actionable "先看有没有处理动作的直接链接")

CPU 负载高，既可能是正常的批量任务，也可能导致请求延迟或任务积压。 只问“超过多少就告警”无法判断是否值得打扰人；先问收到告警后有没有明确动作。

* 已经影响业务：需要立即处理，考虑紧急级别。
* 尚未影响业务，但会在可预见时间内耗尽资源：安排处理，考虑工作时间通知。
* 只是排障线索：可以保留事件或看板，不一定需要发通知。

每条需要处理的规则都应该对应一个负责团队和可执行预案。长期收到却没人处理的告警，需要调整条件、级别或接收人。

## 级别与通知是两件事[​](#severity "级别与通知是两件事的直接链接")

夜莺 v9 使用 S1 / S2 / S3。团队需要约定级别含义，再通过通知规则决定渠道、接收人和筛选条件。

| 示例约定                       | 处理方式                   |
| ------------------------------ | -------------------------- |
| S1：业务已受影响，立即行动     | 值班人员、强提醒渠道       |
| S2：需要处理但可以等到工作时间 | 团队消息、任务跟进         |
| S3：信息或诊断线索             | 按需要保留事件或低打扰通知 |

这是团队约定示例，不是级别自带的发送行为。把规则标成 S3，不会自动变成“只记录、不通知”；还要检查它关联的通知规则及级别筛选。

## 选择 CPU 信号[​](#signal "选择 CPU 信号的直接链接")

CPU 使用率、load average、运行队列和容器 CPU throttling 描述的是不同现象。 load average 包含其他等待状态，不等于 CPU 使用百分比；不同核数的机器也不能简单比较同一个负载阈值。

先确认指标含义和基线，再结合业务延迟、错误或积压判断影响。批处理机器长期高利用率，可能是预期行为。 选择持续时长以覆盖正常抖动，在[即时查询](https://n9e.github.io/zh/docs/query/metric-explorer.md)检查真实样本，再启用规则。

## 写一个可执行预案[​](#runbook "写一个可执行预案的直接链接")

预案至少包含：

1. 如何确认业务影响，查看哪个服务看板。
2. 如何确认异常主机、容器和进程。
3. 谁负责处理，什么情况下升级给另一团队。
4. 有哪些经过授权和演练的缓解动作。
5. 如何确认恢复，是否需要后续容量调整。

把 SOP URL 和 Dashboard URL 写到规则的附加信息中，接收人可以直接从消息进入相关上下文。 阈值和预案要一起维护；变更业务模式后，旧阈值可能不再有意义。

## 下一步[​](#next "下一步的直接链接")

* [标签、附加信息与事件身份](https://n9e.github.io/zh/docs/concepts/labels-annotations.md)
* [告警最佳实践](https://n9e.github.io/zh/docs/alerting/best-practices.md)
* [通知规则](https://n9e.github.io/zh/docs/notifications/rules.md)