If I look at the documentation for metricbeat I see the definition of system.process.cpu.total.pct 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 system.process.cpu.total.pct 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:
I remember we had some discussions about this in the past but I couldn't find the Github issue I think if you have 4 CPU, the total will be 400%. That means you would have to divide all values by 4.
That would be one overachieving VM! 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.
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
...
...
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.