IIS collector

[carlpett]

This is a first draft of an IIS collector from Win32_PerfRawData_W3SVC_WebService. In contrast with other classes, this one actually exposes counters, so it was fairly straightforward.

Some sample output:

wmi_iis_non_anonymous_users_total{site="ASecondTestForTest"} 0
wmi_iis_non_anonymous_users_total{site="Default Web Site"} 0
# HELP wmi_iis_not_found_errors_total TotalNotFoundErrors
# TYPE wmi_iis_not_found_errors_total counter
wmi_iis_not_found_errors_total{site="ASecondTestForTest"} 1
wmi_iis_not_found_errors_total{site="Default Web Site"} 2
# HELP wmi_iis_rejected_async_io_requests_total TotalRejectedAsyncIORequests
# TYPE wmi_iis_rejected_async_io_requests_total counter
wmi_iis_rejected_async_io_requests_total{site="ASecondTestForTest"} 0
wmi_iis_rejected_async_io_requests_total{site="Default Web Site"} 0
# HELP wmi_iis_requests_total TotalRequests
# TYPE wmi_iis_requests_total counter
wmi_iis_requests_total{method="COPY",site="ASecondTestForTest"} 0
wmi_iis_requests_total{method="COPY",site="Default Web Site"} 0
wmi_iis_requests_total{method="DELETE",site="ASecondTestForTest"} 0
wmi_iis_requests_total{method="DELETE",site="Default Web Site"} 0
wmi_iis_requests_total{method="GET",site="ASecondTestForTest"} 2
wmi_iis_requests_total{method="GET",site="Default Web Site"} 30
wmi_iis_requests_total{method="HEAD",site="ASecondTestForTest"} 8
wmi_iis_requests_total{method="HEAD",site="Default Web Site"} 0

There are two metrics exposed that I'm not sure if they are useful? I can include them if we can see some use-case:

    ServiceUptime                 uint32 //The length of time the Web Service has been running
    MeasuredAsyncIOBandwidthUsage uint32 // Measured bandwidth of asynchronous I/O averaged over a minute.

[carlpett]

Forgot to niceify the help strings, it's on it's way

[carlpett]

Fixed and squashed

[martinlindhe]

I think we should leave out the ones with dubious value, at least until someone can specify a use/need for them (they are trivial to add later on)

Let me know when this is no longer WIP so I can merge it.
Also, in order for anyone to be able to start rely on this (wmi_exporter), we need to stabilize the exported metrics. Might be worth giving them some extra thought, so they hopefully stand the test of time.

[martinlindhe]

Also, please update the README with this new collector

[carlpett]

Yup, let's skip those two for now. I'm quite satisfied with the names of the metrics in this one, since they more or less map directly to the perfmon names which should make them easy to pick up for most people. Any specific names you were thinking about?

[martinlindhe]

No, nothing in particular :)

[carlpett]

Rebased on master, ready for merge after review

[martinlindhe]

appveyor says

collectors\logical_disk.go:18: subsystem redeclared in this block
previous declaration at collectors\iis.go:22

[martinlindhe]

Also I would like to clear out the path going forward with regards to non-OS level collector data in this project.

I don't mind merging this, but @brian-brazil brought up the point before that "the prometheus way" is to run one collector per service, and that would mean (iirc) either:

• some way of generalizing the wmi_collector, and ability to run two of them on same box, one for OS level data, one for IIS, using different command line flags (see Automatically convert WMI metrics to prometheus #12)

or

• a separate wmi_iis_collector project

Personally I feel this is a engineering overhead and don't see much issue of just merging this, assuming we can turn it off

[carlpett]

I'll check the compilation failure.

Regarding the separation of collectors, I started looking at just copying the solution node_exporter has for enabling/disabling collectors, but it requires some adaptation so I haven't had time to do it yet. I think this is the most pragmatic way, but the alternative is to split this into a library and then using that to implement different exporters. The "purist" way would have separate wmi_exporter processes per IIS site in this example, but that will carry a quite heavy performance impact.

[martinlindhe]

I also feel the performance impact of running multiple collectors is an issue, and would rather have the monitoring solution doing minimal impact on the machine being monitored. Hey, that's why I considered prometheus in the first place.

[martinlindhe]

Regarding the separation of collectors, we can land this patch and then sort it out with another commit. I can look into that unless you are already on it.

[carlpett]

I fixed the compilation failure (scoping issue), so it looks fine now, apart from being "always on". It'd be great if you could look at that feature, I'm pretty swamped at work right now, so I'll probably not have time to even start until next week.

[martinlindhe]

Great, I'll look into it. Do you think you have time to help with reviewing a PR for it?