记录一次线上 CPU 打满的排查过程，思路比结论更值得复用。
「一次 CPU 100% 告警的完整定位过程」提醒我们一个朴素的事实：监控告警与可观测体系靠的不是临场发挥，而是平时的体系化建设。告警是否准确、日志是否齐全、权限是否收敛，决定了故障来临时是从容处置还是手忙脚乱。
现象
云监控告警某台 ECS 的 CPU 持续 100%，接口时延明显飙升，部分请求超时。
定位进程
用 top 找到高 CPU 进程。如果是 Java 应用，用 top -Hp PID 找到高 CPU 线程，再用 jstack 打印线程栈定位到具体代码；如果是陌生脚本或异常进程，要警惕挖矿木马。
分析根因
本例最终定位到一条未走索引的全表扫描 SQL 被高频调用，导致数据库与应用线程双双堆积，CPU 被拖满。
处置
先限流 / 临时扩容顶住压力，再给相关查询字段加索引、对热点数据加缓存，优化后 CPU 回落到正常水位。
复盘与预防
上线前用 explain 审查慢 SQL，加慢查询监控与告警，压测覆盖热点接口，把问题拦在发布前。
小结：CPU 打满只是表象，顺着"进程 → 线程 → 调用栈 → 根因"逐层下钻，才能找到真正的问题源头。
定位工具要按层递进，不要一上来就抓包
CPU 打满时最容易犯的错误是工具乱跳：一会儿看监控面板、一会儿登机器抓包，时间花在切换上下文而不是缩小范围上。稳定的做法是按层递进，每一层只回答一个问题，答案清楚了再进下一层。
- 整机层：先分清是用户态高还是内核态高、是单核打满还是全核打满。用户态高多指向应用代码，内核态高要看系统调用、网络软中断与上下文切换，单核打满常见于单线程瓶颈或中断未分散到多核。
- 进程与线程层：定位到高 CPU 进程后继续下钻到线程，多次采样打印线程栈并对比，看热点是固定在同一处代码，还是不断变化的等待与锁竞争。
- 调用与数据层：把可疑调用与慢查询日志、缓存命中率、外部接口耗时对齐，确认是计算密集、被数据库拖住，还是下游依赖变慢导致线程堆积。
- 排除非性能因素：陌生进程、异常外连、计划任务里出现的未知脚本，要按入侵应急流程处理，不要当成性能问题继续调参数。
压测环境与线上环境的差异也要记住：同样的代码，线上有真实的数据分布、并发与脏数据，很多问题只在生产暴露。所以定位过程中尽量保留现场快照，包括线程栈、执行计划、监控曲线与关键日志片段，复盘时才有据可查，也才能沉淀成下一次可直接复用的处置手册。
一份可执行的日常清单
- 暴露面盘点：定期梳理对外端口与服务，关闭不必要的开放。
- 权限最小化：账号与密钥按最小权限分配，定期回收闲置权限。
- 告警治理：清理长期无人响应的告警，保证留下的告警都值得处理。
- 预案演练：对高频故障场景准备处置预案并定期演练。
清单不复杂，难在坚持；而监控告警与可观测体系的差距，恰恰体现在坚持上。
把监控告警与可观测体系交给更专业的协作方
安徽卓牛为客户提供云上的安全加固、监控体系搭建与运维托管服务，能够结合阿里云安全与可观测产品，帮助团队建立可持续的运维安全体系，而非一次性整改。
若你希望就「一次 CPU 100% 告警的完整定位过程」涉及的内容做一次现状评估，可通过官网在线客服联系安徽卓牛，获取针对性建议。