Question about


If I look at the documentation for metricbeat I see the definition of as:

The percentage of CPU time spent by the process since the last update. Its value is similar to the %CPU value of the process displayed by the top command on Unix systems.

When I'm capturing those statistics using Metricbeat 5.2.2 on Windows hosts and I create a chart out of those stats in Kibana using the average of per process, the stacked bar come up to be more than 100%. That doesn't seem to match what I'm expecting. I'm expecting a breakdown of the active CPU% distributed between all the active process. Here's an example:

Thank you!


How many CPUs / Cores do you have?

Those particular VMs have 4 CPU assigned.

I remember we had some discussions about this in the past but I couldn't find the Github issue :frowning: I think if you have 4 CPU, the total will be 400%. That means you would have to divide all values by 4.

@andrewkroh Is that correct?

That would be one overachieving VM! :smile: The problem is that I would have to create some sort of calculated field based on the number of vCPU in that VM in order to get something meaningful across the board. I'll try to dig which metric is being grabbed in Windows to get this.

I think on Windows there is a discrepancy with what is reported on Linux. IIRC on Windows you get 100% max, no matter how many cores there are. I would think that the reason the bars in the chart sum to >100% is because the x-axis buckets include data from multiple sample periods.

At the lowest level in Metricbeat here's where certain CPU related data is grabbed from the system.

cpu metricset data:
core metricset data:
process metricset cpu data:

If you review this an have any recommendations for changes or updates to our documentation please let use know.

With windows performance counters you can grab the cpu usage per core

\Processor Information(0,1)\% Processor Time
\Processor Information(0,2)\% Processor Time
\Processor Information(0,3)\% Processor Time
\Processor Information(0,4)\% Processor Time

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.