CPU 负载高，到底应不应该告警？
从业务影响和处理动作决定 CPU 告警条件、级别和通知方式，为每条需要处理的规则补上排查预案。
最后校对于
读完这页，你会决定哪些 CPU 异常值得通知人，并为告警写出接到消息后应该做什么。
先看有没有处理动作
CPU 负载高，既可能是正常的批量任务，也可能导致请求延迟或任务积压。 只问“超过多少就告警”无法判断是否值得打扰人；先问收到告警后有没有明确动作。
- 已经影响业务：需要立即处理，考虑紧急级别。
- 尚未影响业务，但会在可预见时间内耗尽资源：安排处理，考虑工作时间通知。
- 只是排障线索：可以保留事件或看板，不一定需要发通知。
每条需要处理的规则都应该对应一个负责团队和可执行预案。长期收到却没人处理的告警，需要调整条件、级别或接收人。
级别与通知是两件事
夜莺 v9 使用 S1 / S2 / S3。团队需要约定级别含义，再通过通知规则决定渠道、接收人和筛选条件。
| 示例约定 | 处理方式 |
|---|---|
| S1：业务已受影响，立即行动 | 值班人员、强提醒渠道 |
| S2：需要处理但可以等到工作时间 | 团队消息、任务跟进 |
| S3：信息或诊断线索 | 按需要保留事件或低打扰通知 |
这是团队约定示例，不是级别自带的发送行为。把规则标成 S3，不会自动变成“只记录、不通知”；还要检查它关联的通知规则及级别筛选。
选择 CPU 信号
CPU 使用率、load average、运行队列和容器 CPU throttling 描述的是不同现象。 load average 包含其他等待状态，不等于 CPU 使用百分比；不同核数的机器也不能简单比较同一个负载阈值。
先确认指标含义和基线，再结合业务延迟、错误或积压判断影响。批处理机器长期高利用率，可能是预期行为。 选择持续时长以覆盖正常抖动，在即时查询检查真实样本，再启用规则。
写一个可执行预案
预案至少包含：
- 如何确认业务影响，查看哪个服务看板。
- 如何确认异常主机、容器和进程。
- 谁负责处理，什么情况下升级给另一团队。
- 有哪些经过授权和演练的缓解动作。
- 如何确认恢复，是否需要后续容量调整。
把 SOP URL 和 Dashboard URL 写到规则的附加信息中，接收人可以直接从消息进入相关上下文。 阈值和预案要一起维护；变更业务模式后，旧阈值可能不再有意义。