Hostmetrics receiver on Windows: metric system.disk.io_time wrong

[arno-hc]

I am using Opentelemetry collector contrib v0.144, Prometheus and Grafana. In Grafana I am using a dashboard to show host metrics collected from a linux and a windows host.
One panel shows Disk Busy% which is calculated as

rate(system_disk_io_time_seconds_total{$host_label="$host"}[$__rate_interval])

(the metric name is now prometheus style).

For Linux it seems to work, for Windows I get values like 600% for a disk that has no iops.

I had a look at the code in disk_scraper_windows.go.
I think this calcuation is not correct

s.mb.RecordSystemDiskIoTimeDataPoint(now, precision.Scale(uint64(now-s.startTime), time.Nanosecond)-precision.Scale(uint64(values[i]), time.Nanosecond*100), instance)

The used performance counter delivers %Idle Time. In order to calculate the seconds spent one would have to the scrape interval for which the percent value was derived.

Can thsi be solved here or should thsi metric not be exposed for Windows?

[arno-hc]

Sorry, not an answer ('Edit' does not let me change the original question), I just want to give more description, to point out where my confusion is.

% Idle Time reports the percentage of time during the sample interval that the disk was idle.

But, what is the sample interval?

in disk_scraper_windows.go:

			case idleTime:
				s.mb.RecordSystemDiskIoTimeDataPoint(now, precision.Scale(uint64(now-s.startTime), time.Nanosecond)-precision.Scale(uint64(values[i]), time.Nanosecond*100), instance)

This is as formula, where %IdleTime: [0 - 100]: (note that IdleTime is % and not seconds)

	disk_active_seconds ~= (now-startTime) seconds - '%IdleTime'

where e.g. precision.Scale(55, time.Nanosecond*100) results in 0.0000055. So %IdleTime is actually neglectable.

Is somewhere %IdleTime transformed to nanoseconds? But then I am missing the sample interval of the performance counter value.
Is my understanding of the formula correct?

[vergissberlin]

Your reading of the formula is right, but the premise is off: "% Idle Time" is a PERF_100NSEC_TIMER_INV counter, and its raw value is not a percentage - it's a cumulative count of 100ns idle ticks. The percentage perfmon shows is what Windows computes from two raw samples. So elapsed_ns minus raw_idle_100ns is a sound way to derive active time, and there is no sample interval to divide by, because the raw counter is monotonic rather than interval-scoped.

Which makes the interesting question what values[i] actually holds at that line. Your observation that scaling 55 gives 0.0000055 suggests a cooked/formatted value (0-100) is arriving there instead of the raw counter - and in that case io_time would grow at roughly wall-clock rate, so rate() would sit near 1.0 regardless of real disk activity. That matches your "busy on an idle disk" symptom better than a scaling bug does.

Two things worth ruling out before treating it as a receiver bug: whether the counter is read raw or formatted, and whether the Grafana panel is overlaying several device series (including _Total) - six overlaid series is a common way to get a 600%-looking panel out of values that are individually near 1.