资深运维人员可能会遇到这个问题监控图上所有虚拟机的CPU使用率都“飙升”了但业务实际上却很流畅。这通常不是虚拟机本身出了问题而是Prometheus在“说谎”也就是监控数据采集或处理环节出现了系统性故障。其实你可以按照以下思路从数据源头、数据处理到监控系统本身逐步排查问题所在。 问题排查三步走第一步检查PromQL查询逻辑最常见的“罪魁祸首”很多时候问题出在我们用来计算CPU使用率的查询语句上。一个常见的CPU使用率计算公式是100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance) * 100)这个公式的关键在于rate函数和它的时间范围[5m]。如果数据源本身有问题这个公式就会计算出错。检查点1数据源是否平滑rate函数计算的是时间段内的变化率。如果node_cpu_seconds_total这个原始指标因为采集失败而出现了长时间的平台期数值不变那么rate函数在进行外推计算时会错误地夸大CPU的空闲值进而导致计算出的使用率出现负数或异常的100%。你可以直接查询原始指标node_cpu_seconds_total{modeidle}看看它的数据曲线是否平滑有没有长时间持平的“台阶”。检查点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和内存资源是否充足。如果资源不足它的处理能力就会达到瓶颈。 如何快速验证与解决可疑环节快速验证方法解决方案PromQL查询1. 在Prometheus UI中直接查询原始指标node_cpu_seconds_total{modeidle}观察曲线是否有长时间持平的异常。2. 简化查询去掉rate和聚合看看基础数据是否正常。优化查询语句调整rate函数的时间窗口。如果是数据源问题则需要修复底层数据采集。Node ExporterSSH登录到任意一台“异常”的虚拟机执行top命令查看实际的CPU使用率。如果top显示正常则重启Node Exporter服务systemctl restart node_exporter。数据抓取访问Prometheus Web UI的/targets页面检查所有VM对应的node_exporter任务状态是否为UP。检查网络连通性修正Prometheus配置文件中的抓取路径或超时设置。Prometheus自身在Prometheus UI中查询自身指标•rate(process_cpu_seconds_total[5m]) * 100•prometheus_tsdb_head_series(查看当前活跃的时间序列数量)如果自身CPU过高需要排查是否有“重”查询或者通过降低抓取频率、减少不必要的指标采集使用metric_relabel_configs丢弃高基数标签来优化性能。