addidig custom metrics about windows_exporter HOT 11 CLOSED

I'm a bit split. While this would be very flexible and thus useful, most of the work of adding a new set of WMI counters is the data massaging, conversions and labeling logic, which you wouldn't be able to control with this approach.
Maybe it would be a better use of time to improve the collector generator and otherwise make it easier to contribute?
That said, with some careful design consideration, this feature could possibly be made to work well.

from windows_exporter.

I agree, it sounds really useful! @carlpett do you have any input?

from windows_exporter.

This comes up quite often. Perhaps we should look into the what requirements/design considerations would be.

from windows_exporter.

Configurable counters sounds like a very good idea! The limitation of having to use the generator WMI Exporter rather than configuration is the only reason we are currently looking into Telegraph instead. If we can help in some way let me know.

from windows_exporter.

@lindhor I've done a few rounds of this, and can't really come up with something I'm satisfied with. So some inspiration and/or discussions of use-cases would be very valuable!

Here are the things I think should be solved by a configurable source, in order to replace the coded approach we currently use (and which I think other "dynamic" implementations currently don't do?):

• Only query a class once: If there are a dozen different metrics you want from a given class, we should get them all in the same query. WMI queries are not free (or even very cheap), so either the exporter needs to be smart enough to bundle stuff up, or the configuration format needs to enforce it.
• Set correct data types: Either the user should be able to indicate the type (counter/gauge/etc) in config, or we need to infer it from WMI metadata.
• Merge multiple metrics: CPU time counters for instance should all be reported under the same metric but different labels.
• Proper labeling support: Both possible to extract from the data as well as given in the config directly.
• Rename metrics: Related to above, names should be mapped away from the (often misleading) WMI names, for example Win32_PerfRawData_PerfOS_Processor.PercentIdleTime -> cpu_seconds_total.
• Some fixed transformations: There are a lot of transformations that we do a lot, such as converting from Windows timestamps to Unix timestamps. This should be possible to do in the configured format as well. Some of the ones we currently do in code are "hard"/not general-purpose, such as for the AD collector where we have float64(dst[0].DRAHighestUSNCommittedHighpart<<32)+float64(dst[0].DRAHighestUSNCommittedLowpart). Should these metrics simply be dropped if we move to a configuration format?

If we do not achieve at least most of this, then I don't see much value over someone simply using the node_exporter's textfile_collector and dumping the WMI data via script instead.

from windows_exporter.

from windows_exporter.

Thanks for the feedback!

Have a way to specify that all or specified available performance monitor counters in a group should be polled, i.e. all CPU counters. Similar to what you can select in the Performance Monitor GUI. I’m not sure if that is the same as you describe in your first bullet below. And in a similar way to specify that all or specified instances should be retrieved.

Agree in principle. Some things that needs to be thought about: There are several non-relevant properties (Frequency_Object etc), how to filter them out reliably - is it enough with a static list? And how to create the query in this very dynamic case? A initialization query which fetches the data structure?
As for the filtering, possibly something similar to the which-flags we have in some collectors?

Specify that caching should be used per ”query” so that really slow queries can still be retrieved efficiently, probably with a configurable cache timeout period.

We currently don't do any caching. I think adding that would be a fully separate change.

Possibly have support for generic WMI queries to be able to ask for things like installed software etc. It could possibly map WMI result fields to labels, similar to name and state are mapped for wmi_service_state.

I thought a bit about about this earlier, but it seemed like a very hard thing to formulate in configuration. Any ideas?

from windows_exporter.

I believe we've decided not to do this, so I'm closing this.

from windows_exporter.

I would like to revisit this-

The custom wmi metric situation is currently addressed 2 ways.

1. The generator requires a bespoke compile of the exporter. This is unsavory, because organizations shouldn't have to maintain a fork just to get metrics. Nor should we assume the metrics they are after are what the general community wants so they aren't really worthy of a PR back to upstream.

2. A text file that is generated by some outside process. This brings its own circular problems into the fold. Using powershell/interpreter language is way more expensive to run, and then if I am in a compiled language, I am really now doing what this app should do, export metrics. Then I have all the other issues, task scheduling, file handling, et al, which this exporter handles superbly.

I think even in a rudimentary form, you should be able to add a wmi metric in some ad-hoc form. If the end user wants to take a perf hit fine. This is part is more part of the 10% of the 90-10 that the project satisfies. Sure, optimizations can always come in, but I think if there are counters people just want to get at, as they would easilyt do through the generator, but shouldn't need to dabble in go compilation as a freelance activity.

from windows_exporter.

I was envisioning something akin to this:
https://github.com/eskibars/wmibeat

from windows_exporter.

Open PR in telegraf:
influxdata/telegraf#11250

from windows_exporter.