In version 2.3 we moved to a SigarProxy singleton for interacting with Sigar.  This exacerbates an issue we have in PerCpu metric collection.  The fundamental issue is that Sigar has coarse-grained cpu metric collection, gathering all metrics for all cpu's at the same time.  Our metric model is fine grained, we want to be able to collect an individual metric for a specific resource at a resource-metric specific schedule interval.

The problem here is that for multiple CPU's (by default, the same metrics are enabled with the same schedules) we end up making sequential calls to Sigar's getCpuPercList().   Sigar's implementation is not wrong, but it's not conducive to our approach.  Sigar uses the previous and current cpu info gathering to compute the cpu usage percentages.  For the CPU-0 component things work well, the interval is (at least in the default settings case) what was set in the schedule. But, for CPU-1..N the cpu cycle diff may be 0. Meaning that the two cpu gathers performed by Sigar are identical since they are performed at practically identical times.  This results in divBy0 NaN values for the percentage metrics.  Even if NaN values are not returned the sample size (the cpu cycle diff) will be tiny and the values are probably not useful. The expectation is that the values reported for all CPU's represent the usage over the interval defined for the metric.

Prior to 2.3 each CpuComponent accessed its own Sigar instance, this prevented the issue to the level of severity that we are seeing now, although it may be the case that the metrics still did not report on the expected intervals.