Perf: Add volume name label

[carlpett]

As per the TODO list on the wiki, I added volume labels to the perf collector. I also added a whitelist/blacklist functionality similar to what is used in other exporters, defaulting to excluding the _Total "meta-counter".

By the way, shouldn't the collector be named something like logical_disk rather than perf?

[brian-brazil]

I'd hardcode the _Total in the code itself, so that a user doesn't have to remember to explicitly exclude it.

[carlpett]

Good point. If the user actually wants a total, then they can use sum()

[carlpett]

I started looking a bit more carefully at the data we're getting here, and after doing a bit more reading on the PerfRaw* classes (https://msdn.microsoft.com/en-us/windows/hardware/aa392761(v=vs.71)#how_to_interpret_property_qualifiers), it seems there needs to be a bit of post-processing involving the value and the "base" value.
That will probably require a fair bit of refactoring of the collector, so maybe we should take that outside the scope of this PR (which was just about adding a label)?

[carlpett]

After yet another look, the _base stuff only applies to the avg* metrics, and we shouldn't expose those anyway, right?

[martinlindhe]

@carlpett: This is great!
So, will this expose all disks by default? I see you have added some configuration options.

I was also looking into this yesterday but ran out of time. My approach was to build the measure name from the drive letter, something like "perfc_disk_bytes_per_sec", "perfd_disk_bytes_per_sec" etc. How would one differentiate the measures with this patch?

Got to spin up a vm and try it out.
The "_Total" disk should not be exported.
Btw, patch greatly accepted. I agree we should go throughj the "perf" measures in detail in upcoming commits:

• several data points are probably unusable
• some need to be converted to base units (megabytes to bytes, etc)
• several should get names more in line with prometheus naming

[martinlindhe]

Also, the name "perf" just came from "Win32_PerfRawData_PerfDisk_LogicalDisk", and was short. "logical_disk" is pretty long. perhaps "io" is better?

[martinlindhe]

to summarize, additional points to be fixed mentioned here (also added to the wiki)
perf: hardcode "_Total" for always exlusion
perf: FreeMegabytes should be a ratio
perf: dont export Avg* and *_Base
thanks @brian-brazil & @carlpett

[carlpett]

Well yes, sort of :) This will expose all volumes (which maps to partitions unless you use Windows Logical volumes/software raid). Here's a sample from my machine:

wmi_perf_percent_free_space{volume="C:"} 62669
wmi_perf_percent_free_space{volume="D:"} 99522
wmi_perf_percent_free_space{volume="HarddiskVolume1"} 304
wmi_perf_percent_free_space{volume="HarddiskVolume3"} 95

HarddiskVolume1 is the "System reserved" partition for recovery tools in my case, which is not mounted to a drive letter, while HarddiskVolume3 is a secondary disk which I haven't had time to set up yet... I haven't tested drives mounted to a subpath (eg mounting a volume to d:\some\mountpoint), but I think that will still be called HarddiskVolumeX.
So it does not map to disks, as such. There is a PhysicalDisk family of counters for those (but then you don't get any mapping to drive labels, on the other hand).

I've got a fix for _Total already which I meant to add to the PR. Will submit as a separate patch in a minute.

[martinlindhe]

Okay, yes it looks better than what I had in mind :)

[brian-brazil]

On Unix anyway, the equivalent would only export mounted filesystems. I'd guess Windows should be the same.

How do you have a percentage free space over 100%?

[carlpett]

I tested the subpath mount, and it turns out well:

wmi_logical_disk_size_bytes{volume="C:"} 1.365508096e+11
wmi_logical_disk_size_bytes{volume="D:"} 1.37435807744e+11
wmi_logical_disk_size_bytes{volume="D:\\Test-Mountpoint"} 6.0018393088e+10

@brian-brazil This should mean that we could by default filter out anything like HarddiskVolume.+. As far as I can tell from looking at the raw data, the Name property is the only thing that changes when a volume is mounted vs non-mounted.

As for the strange data in the initial post, that was before any of the other work done in the #5, so it just contained the raw data from WMI.