Prometheus CPU 使用率飙升问题排查思路

资深运维人员可能会遇到这个问题：监控图上所有虚拟机的CPU使用率都“飙升”了，但业务实际上却很流畅。这通常不是虚拟机本身出了问题，而是Prometheus在“说谎”，也就是监控数据采集或处理环节出现了系统性故障。

其实你可以按照以下思路，从数据源头、数据处理到监控系统本身，逐步排查问题所在。

🔍 问题排查三步走

第一步：检查PromQL查询逻辑（最常见的“罪魁祸首”）

很多时候，问题出在我们用来计算CPU使用率的查询语句上。一个常见的CPU使用率计算公式是：
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)

这个公式的关键在于rate函数和它的时间范围（[5m]）。如果数据源本身有问题，这个公式就会计算出错。

• 检查点1：数据源是否平滑？rate函数计算的是时间段内的变化率。如果node_cpu_seconds_total这个原始指标因为采集失败而出现了长时间的平台期（数值不变），那么rate函数在进行外推计算时，会错误地夸大CPU的空闲值，进而导致计算出的使用率出现负数或异常的100%。你可以直接查询原始指标node_cpu_seconds_total{mode="idle"}，看看它的数据曲线是否平滑，有没有长时间持平的“台阶”。
• 检查点2：聚合维度是否正确？确保你的查询是按预期的维度（比如instance）进行聚合的。如果聚合方式有误，可能会将不同数据源的指标混在一起，计算出错误的结果。

第二步：检查数据源与采集（所有VM都异常，重点排查共性）

既然所有VM都出问题了，问题很可能出在它们共同依赖的环节上。

• Node Exporter是否正常？Node Exporter是部署在虚拟机上用于暴露CPU指标的程序。如果它自身卡死或响应缓慢，Prometheus抓取到的可能就是过时或错误的数据。在所有虚拟机上执行systemctl status node_exporter检查其状态。
• 网络与配置是否稳定？Prometheus Server需要定期（scrape_interval）去每个VM的Node Exporter抓取数据。如果网络出现波动，或者抓取配置（如metrics_path）不正确，都可能导致抓取超时或失败。检查Prometheus的Target页面（/targets），看是否有抓取失败的记录。
• 是否存在指标冲突？在一些复杂的虚拟化环境中（如OpenStack），可能存在多个数据源（如真实的ceilometer和用于测试的fake metrics）同时提供CPU数据。如果Prometheus在查询时没有正确聚合这些来自不同后端的指标，可能会错误地使用了接近0的值，从而在图上显示出异常的CPU占用率。

第三步：检查Prometheus自身健康状况（“监控系统”自己也需要被监控）

当监控系统本身不堪重负时，它处理数据的能力会下降，产出不可靠的结果。

• CPU是否过载？检查Prometheus自身的CPU使用率。如果rate(process_cpu_seconds_total[5m]) * 100的值持续超过70-80%，说明Prometheus自己已经处于高负载状态，可能无法正常处理所有查询和抓取任务。
• 查询是否太“重”？高基数（High-cardinality）指标或复杂的查询（特别是涉及histogram_quantile的查询）会消耗大量CPU资源。如果仪表盘（Dashboard）刷新频率过高，或者后台有大量报表查询，可能会持续推高Prometheus的CPU负载，导致其无法及时处理数据，最终反映在所有监控指标上。
• 资源是否足够？根据你的集群规模（Pod数量），检查分配给Prometheus的CPU和内存资源是否充足。如果资源不足，它的处理能力就会达到瓶颈。

💡 如何快速验证与解决