added new metrics for vcenter receiver VM performance related met…

[samiura]

Description

This PR adds the following VM performance metrics for vcenter.

1. vcenter.vm.cpu.time
2. vcenter.vm.network.multicast.packet.rate
3. vcenter.vm.network.broadcast.packet.rate

More information on these metrics can be found here. and also succinctly described here

#37488

Testing

The metrics were scraped from a test vCenter environment, and golden test files were updated accordingly to reflect the addition of the metric.

Documentation

Documentation was updated according to the metadata.yaml

[StefanKurek]

I think it mostly looks pretty good now, but I still have a couple of questions for possible improvements.

[StefanKurek]

@samiura something doesn't look quite right with the CPU Times FYI. I would have expected the values to all be < 100. So there's probably still some work to figure out what's going on with the data there.

Also after digging a bit, the cpu.wait.summation included idle state's wait time too if you look at the description here in this link(Total CPU time spent in wait state.The wait total includes time spent the CPU Idle, CPU Swap Wait, and CPU I/O Wait states.)

Well even then it should be less than 100 by itself if we were calculating correctly (and the simulator is giving valid numbers....which it may not be).

Just thinking out loud, are we sure the summation are taken over 20s time period for api-version 7.0 and 8.0? Just thinking out loud.

So, according to Broadcom (Vmware's parent) the default vcenter setting for intervals is 20seconds. I wonder whether that is the case for VCSim.

I have pushed a new commit and instead of assuming 20 second interval rate for gathering performance metrics, I have getting that interval period from VSphere API as we have done for VSANMetrics gathering in the code.

@samiura The interval for performance metrics is hardcoded in the receiver to be 20s FYI. Even so, your suggestion is good practice. I'm curious if it changes the values you're seeing from the simulator?

[samiura]

@samiura something doesn't look quite right with the CPU Times FYI. I would have expected the values to all be < 100. So there's probably still some work to figure out what's going on with the data there.

Also after digging a bit, the cpu.wait.summation included idle state's wait time too if you look at the description here in this link(Total CPU time spent in wait state.The wait total includes time spent the CPU Idle, CPU Swap Wait, and CPU I/O Wait states.)

Well even then it should be less than 100 by itself if we were calculating correctly (and the simulator is giving valid numbers....which it may not be).

Just thinking out loud, are we sure the summation are taken over 20s time period for api-version 7.0 and 8.0? Just thinking out loud.

So, according to Broadcom (Vmware's parent) the default vcenter setting for intervals is 20seconds. I wonder whether that is the case for VCSim.
I have pushed a new commit and instead of assuming 20 second interval rate for gathering performance metrics, I have getting that interval period from VSphere API as we have done for VSANMetrics gathering in the code.

@samiura The interval for performance metrics is hardcoded in the receiver to be 20s FYI. Even so, your suggestion is good practice. I'm curious if it changes the values you're seeing from the simulator?

I have not seen any values over 100 as it should logically be the case. It seems to be sane. Not sure why but I think it looks solid now (screenshots updated). Also, from I am running just the default valuedvcsim binary without any parameters to make things simplistic.

[StefanKurek]

@samiura Sounds good! Chances are the simulator was ignoring our request for a 20s interval and was using something else instead. So now that that interval is dynamically part of the calculation, we're good. This shouldn't come up in a real environment, but the code is safer either way. Thanks for all the work!

[pjanotti]

LGTM

[pjanotti]

Adding ready to merge label since it was already approved by a code owner.