通过jmx exporter采集JVM指标时jconsole与Prometheus CPU使用率不一致问题

1. 当前查询表达式的统计口径问题 #

你目前使用的irate(process_cpu_seconds_total[1m]) * 100，计算得到的是进程占用CPU时间与单个CPU核心时间的占比，并非jconsole展示的整机口径CPU使用率。

举个直观的例子：

• 当你的Java进程100%占满1个物理核心时，这个表达式的计算结果为100%
• 如果运行环境的CPU总核心数为4核，同一时刻jconsole展示的进程CPU使用率仅为25%

两者天然存在倍数差异，这个倍数等于运行节点的CPU总核心数。

补充说明：jconsole展示的进程CPU使用率，直接读取JVM内置的com.sun.management.OperatingSystemMXBean的getProcessCpuLoad()返回值，该方法的统计逻辑是：进程累计消耗的CPU时间 / （系统可用CPU核心数 * 统计周期墙钟时间），返回0~1之间的小数，换算成百分比就是整机维度的进程CPU占比，不存在单核心的基准差异。

2. 对齐jconsole口径的查询修正 #

要让Grafana的数值和jconsole匹配，需要在现有表达式基础上，将结果除以节点的CPU总核心数。修正后的表达式为：
(irate(process_cpu_seconds_total[1m]) * 100) / on() group_left() machine_cpu_cores

• 表达式里的核心除法因子，代表节点可用的CPU总核心数：如果你的监控体系中集成了node_exporter，可以直接使用machine_cpu_cores指标；如果完全依赖jmx exporter采集指标，可替换为jmx exporter默认暴露的system_cpu_available_processes指标
• 使用on() group_left()是因为两个指标的标签维度不完全匹配：process_cpu_seconds_total是进程维度的指标，CPU核心数指标是节点维度的全局指标，通过不带标签匹配的全局关联，才能正确完成除法计算

3. 其他容易造成数值偏差的细节 #

• 采集窗口长度：如果你的jmx exporter采集间隔大于15s，1m的irate窗口可能因为样本点太少，平滑掉瞬时CPU峰值，导致展示数值略低于jconsole，这种情况可以适当将窗口拉长到2m~5m缩小差异
• 采集时间差：jconsole是和JVM进程同主机的实时采集，Prometheus是周期性拉取指标，两者采集时间点不完全同步带来的5%以内的数值偏差属于正常范围，不属于逻辑错误
• 指标来源一致性：process_cpu_seconds_total是jmx exporter直接从JVM的OperatingSystemMXBean获取的累计进程CPU时间，和jconsole的指标来源完全一致，不存在数据源层面的数值偏差

内容的提问来源于stack exchange，提问作者DeKekem