CPU使用率持续过高需结合user+system、iowait、load average、steal等多维指标综合判断：user+system超80%表明真繁忙，iowait>20%说明等待磁盘，load>核心数表示任务积压，steal>5%提示云环境被超卖；告警应分层设置，避免仅凭单一百分比误判。
CPU 使用率持续过高，不能只看“百分比”数字，得结合负载、进程行为和业务基线综合判断。监控不是为了报警而报警，而是为了在影响服务前识别异常模式。
CPU 使用率监控的关键指标与含义
单看 top 显示的 %CPU 容易误判。真正要盯住的是这几个维度：
- user + system：加起来长期超过 80%，说明计算或系统调用确实繁忙；若 user 占比高，多是应用逻辑问题；system 高则可能频繁系统调用、锁竞争或中断过多
- iowait：持续 >20% 就要警惕——这不是 CPU 真忙，而是它在等磁盘响应，此时负载会虚高，但 CPU 实际空闲
- load average：必须对照 CPU 核心数看。4 核机器 load > 4 表示平均有超 4 个任务在争抢 CPU（含等待状态），即使 %CPU 没满，系统也可能卡顿
- steal：云环境里 >5% 就该查是否被宿主机超卖，常见于突发流量后性能骤降
怎么设置合理告警阈值
一刀切的“>90% 告警”在实际中容易漏报或误报。推荐分层设定：
- 警告级：CPU 使用率 >70% 或 load > 核心数 × 0.7，触发初步检查（如自动抓取 top -bn1、pidstat -u 1 5）
- 严重级：CPU >90% 且持续 3 分钟，或 iowait >50%，或 load > 核心数 × 1.5，触发人工介入流程
- 特别注意：单进程 %CPU 接近 100% × 核心数（如 4 核机器上某 java 进程占 390%），大概率是死循环或 GC 卡顿，应优先定位 PID
内存配合看 CPU 才能避免误判
CPU 高有时是内存不足的“副作用”。比如：
- Java 应用频繁 Full GC 时，CPU user 会飙升，同时内存使用率居高不下、swap 使用量上升
- Linux 内存压力大时，内核会更激进地回收 page cache，引发大量 writeback，推高 system 和 iowait
- 建议告警组合设置：CPU >80% + 内存可用率 500MB，三者同时满足才发高级别告警
实用监控脚本与轻量落地方式
不依赖复杂平台，也能快速上线有效监控：
- 用 mpstat -P ALL 2 每 2 秒采样一次，观察各核心是否不均衡（某核 100% 其余全 idle，很可能是单线程瓶颈）
- 写个简易检查脚本，每分钟执行：pidstat -u 1 3 | awk '$8 > 80 {print $1, $8}'，输出持续超 80% 的 PID 和占用率
- 对 Java 服务，加 JVM 参数 -XX:+PrintGCDetails -Xloggc:/var/log/gc.log，GC 日志暴增常是 CPU 飙升前兆
- 用 vmstat 1 看 cs（上下文切换）列，>5000/秒就要查线程数是否失控（如 Spring Boot 默认 Tomcat 线程池未限流）
