Windows_exporter: Discussion: Scope of wmi_exporter

[carlpett]

Background

With the contribution of #320, we need to make a decision on what scope we want the wmi_exporter to have.

Up until now, we've exclusively provided metrics extracted from WMI, and avoided adding other potentially useful metrics or gathering methods as out-of-scope.
This has allowed us a clear focus and way-of-working, and high similarity between different collectors leading to ease of contributing new ones.
On the down side, WMI isn't exactly easy to work with, has a non-trivial impact on host performance and we've seen a wide variety of weird bugs where the user needs to repair registry configurations or similar.

Alternatives

As I see it, we have two choices:

1. Stay with exposing only data gathered through WMI. This means turning down #320 and similar proposals, and suggesting they be separate, dedicated exporters instead.
2. Become a generic "Windows exporter", taking in anything useful, through any interface available.

On the Linux side, the Prometheus ecosystem strongly leans towards alternative 1, with hundreds of specific exporters, and individual machines often running several ones.

Way forward

We don't have any formal decision-making process for wmi_exporter at this time, so I would like to gather input both from maintainers and users on this topic before we come to some conclusion. I'll add my personal thoughts as a comment below.

[carlpett]

I'm undecided as of yet, and looking forward to hearing others' thoughts.

On one side (and probably coloured by the majority of my systems being Linux-based) I personally prefer having small, well-defined exporters and deploying them where relevant (alternative 1). There is typically less configuration per exporter (or none at all), the code tends to be simpler, and bugs/crashes in a single exporter have a smaller impact on overall monitoring.

On the other hand, we've seen that a lot of our users typically don't have a configuration management system at all, and having to deploy multiple exporters could possibly lead to not being able to use Prometheus at all.
Additionally, there seems to be relatively few developers in the Windows/Prometheus intersection. Would we be able to sustain multiple projects?

cc: @martinlindhe @brian-brazil

[brian-brazil]

An additional thing to consider is that a "Windows exporter" nominally includes every possible application that runs on Windows, so you'd end up as an uberagent.

[lars-nielsen]

Hi i'm new to the prometheus, and even Go, i just came here for some windows metrics :)

But i'd like to tune in as a user if I may.

This was the most relevant exporter when i searched for a "windows exporter". WMI/CIM is highly generic, so one could argue that this exporter already is a "generic Windows exporter".

Adding export features that has a significantly other lifecycle than windows can be hard to maintain, which is why i was suprised to see MSSQL / Vmware support - even through WMI. - I agree uberagenting will most likely have a negative impact on the exporter as a whole.

I would prefer focus on roles/features that are lifecycle bound to windows (DNS / AD / and so on), and keep to apis that are updated with windows . WMI / HCS / etc

[brian-brazil]

That's kinda like saying that the JMX exporter should monitoring all JVM-based applications, rather than sticking to just JMX. Just like with WMI, the JMX exporter allows you to access anything you can via JMX.

[pete-leese]

Fork the project.

Wmi exporter and a generalised Windows exporter, there is a lot of potential to be had here which will only increase the popularity of Prometheus.

[carlpett]

@VR6Pete I'm not sure I follow? You mean splitting it into "two" (or more), or abandoning the current?

As I mentioned, on of the things that worry me is that I'm not sure there is a sufficient developer base to spread resources thinner. So for that reason, there might be cause to try to keep things together.

On the other hand, the "uberagent" approach, if we drop the WMI requirement, will have quite the risk to become unmaintainable anyway due to technology sprawl.

---

@lars-nielsen Thanks for the feedback!

I would prefer focus on roles/features that are lifecycle bound to windows (DNS / AD / and so on), and keep to apis that are updated with windows . WMI / HCS / etc

This is another possible angle. As you note, we currently accept anything that registers a WMI provider. Another way would be to focus on the OS roles/features, regardless of the way they expose their stats.

[avonwyss]

As a user on Windows I prefer having one exporter for everything which is "service-level", e.g. not specifically application metrics.

However, I think that metrics which are available via performance counters should rather be collected via those since I believe that these have less overhead and they don't suffer from the 16-minute-lockup and similar WMI issues.

As for future development, I think that having some configuration language for the collector which allows to define any WMI and perfmon metrics to expose would be great and pretty future-proof.

[carlpett]

@avonwyss Yes, those WMI issues are part of the background here. Not just the lock-ups, but also scrapes getting data smeared out over a long period, as well as the occasional "Invalid class/query".

[sachinmsft]

Having hard requirement of WMI is not good as we know that WMI calls are expensive. If feasible we can re implement some of the common collectors to use perf counters instead of WMI and can go away with hard WMI requirement.
and in my opinion having single exporters for all the collectors is good compared to having multiple small exporters as all the collectors are optional and they are as good as having multiple exporters in single repository.

[SubodhBhargava]

I think it'd be very helpful for the Windows community (users, customers, developers, partners) to have a single exporter for all OS level metrics that include system, hyper-v, and containers.

[martinlindhe]

This software came to be and got its rather uninspiring name just from the need to export some Windows metrics to Prometheus. At the time I looked around on what was available and was not yet aware of the performance and stability issues of WMI that we've seen since.

For the usefulness of the project I think we should maybe not draw a hard line at WMI. Maybe "os level metrics" or something could be a better stated goal.
However, we need to stay focused and not bolt just anything on.

I don't think forking is a good way forward as dev resources are already spread thin.
For example https://github.com/leoluk/perflib_exporter should maybe have become part of our exporter rather than a separate thing.

[martinlindhe]

Expressed above is my personal opinions here. As I'm not much involved in the project atm, I don't think my words should have more weight here, and I am happy with decisions made by @carlpett and @brian-brazil

[brian-brazil]

It's not my project, I just chime in every now and then :)

[carlpett]

So, activity seems to have tapered off here, so it seems we can reasonably now summarize the concerns raised and opinions:

---

Most comments seem to favour a third option, somewhere between the two ones initially posted: Stop being WMI-exclusive, but restrict the scope to only be "OS components". This should then provide a guideline for what new functionality to accept and what falls outside. Pure application metrics, for example, would not qualify, while Windows Server roles would.

This would mean green light for the container metrics contributed in #320, as well as looking into how we can start utilizing performance counters and other similar alternatives to address our WMI issues (such as #270, #259, #89 etc).

---

Let me know if you feel the above does not accurately represent a summarization of the comments (by necessity it does not align with all comments, but I have tried to create a full picture). If there is no major disagreement at the end of the week, this would be our new scope going forward.

[carlpett]

Well, that seems to settle it :smile: