Windows Metrics?

[batmanama]

I think there's a solid use case for many of our apps, but I also need to deal with a significant (600+) Windows install base. Has anyone used Prometheus to monitor Windows? Would it be best to use a push gateway or is it feasible to hack in WMI support for scraping?

[Brian Brazil]

On 30 January 2016 at 00:10, batmanama <xiled...@gmail.com> wrote:

I think there's a solid use case for many of our apps, but I also need to deal with a significant (600+) Windows install base. Has anyone used Prometheus to monitor Windows?

I believe we've got a few users using Prometheus on Windows systems.

Would it be best to use a push gateway or is it feasible to hack in WMI support for scraping? 

A node exporter equivalent for Windows would be the best approach. Is this supported in Go, and if not which languages is it supported in?

--

Brian Brazil

www.robustperception.io

[xiled...@gmail.com]

It looks like there's a go implementation out there https://github.com/StackExchange/wmi/ so it probably wouldn't be too hard to bring into node exporter. How do your users use Prometheus for their Windows devices?

[Andrew OBrien]

A windows node exporter-like implementation exists in the form of scollector[0]. Depending on your topology this, combined with the scollector exporter[1] may give you a leg up.

I agree that including this functionality in node exporter natively is the better approach but the above is thought I'd mention it just in case you need something quickly.

Andrew

[0] https://github.com/bosun-monitor/bosun/tree/master/cmd/scollector

[1] https://github.com/tgulacsi/prometheus_scollector

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew OBrien]

s/the above is //g

[kel...@gmail.com]

在 2016年1月30日星期六 UTC+8上午8:10:40，batmanama写道：

> I think there's a solid use case for many of our apps, but I also need to deal with a significant (600+) Windows install base. Has anyone used Prometheus to monitor Windows? Would it be best to use a push gateway or is it feasible to hack in WMI support for scraping?

You can refter to this: [wmi_exporter](https://github.com/martinlindhe/wmi_exporter)
This is the recommended plugin as the same of node_exporter.
I have the same needs of windows monitor and working on it now.
Hope helps.

[dmi...@ymail.com]

Try this new WMI exporter, more details here: https://goo.gl/B5yUCR - written in .NET Core 2, does not require any code generation and can collect metrics locally or remotely from Windows hosts or containers. Note that WMI exporter on GitHub requires code generation for WMI metrics and must be deployed locally.

[Ben Kochie]

For the record, "Deploying locally" is part of the Prometheus design pattern.  Centrally proxying metrics is an anti-pattern.

On Wed, Sep 13, 2017 at 1:33 AM, dmitrio via Prometheus Developers <prometheus...@googlegroups.com> wrote:

Try this new WMI exporter, more details here: https://goo.gl/B5yUCR - written in .NET Core 2, does not require any code generation and can collect metrics locally or remotely from Windows hosts or containers. Note that WMI exporter on GitHub requires code generation for WMI metrics and must be deployed locally.

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.
To post to this group, send email to prometheus-developers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/ef10ce35-fe9c-41c6-b6ee-d5cd27b01d88%40googlegroups.com.

[dmi...@ymail.com]

You mean that node exporter is anti-pattern? The one I mentioned is equivalent to node-exporter for Windows and it does support deployment on the host or as container (identical to node exporter.

On Tuesday, September 12, 2017 at 9:13:58 PM UTC-7, Ben Kochie wrote:
> For the record, "Deploying locally" is part of the Prometheus design pattern.  Centrally proxying metrics is an anti-pattern.
>
>
> On Wed, Sep 13, 2017 at 1:33 AM, dmitrio via Prometheus Developers <prometheus...@googlegroups.com> wrote:
> Try this new WMI exporter, more details here: https://goo.gl/B5yUCR - written in .NET Core 2, does not require any code generation and can collect metrics locally or remotely from Windows hosts or containers. Note that WMI exporter on GitHub requires code generation for WMI metrics and must be deployed locally.
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
>
> To post to this group, send email to prometheus...@googlegroups.com.

[Carl Pettersson (BN)]

Just as a clarification, the wmi_exporter does not require code generation to use. Let us know if there is some documentation which makes it seem that way!

Best,
Carl

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/98a06f00-0ca1-4b10-8a31-4888326b7cd3%40googlegroups.com.

[dmi...@ymail.com]

Perhaps you can clarify this one: https://github.com/martinlindhe/wmi_exporter/tree/master/tools/collector-generator

[Ben Kochie]

The design idea is that exporter should be installed locally, and setup 1-to-1 with the target to be monitored.  This way there is basically no "network" between the exporter and the target.

The "standard" wmi_exporter and the official node_exporter follow this pattern.

On Wed, Sep 13, 2017 at 7:17 AM, dmitrio via Prometheus Developers <prometheus...@googlegroups.com> wrote:

You mean that node exporter is anti-pattern? The one I mentioned is equivalent to node-exporter for Windows and it does support deployment on the host or as container (identical to node exporter.

On Tuesday, September 12, 2017 at 9:13:58 PM UTC-7, Ben Kochie wrote:
> For the record, "Deploying locally" is part of the Prometheus design pattern.  Centrally proxying metrics is an anti-pattern.
>
>

> On Wed, Sep 13, 2017 at 1:33 AM, dmitrio via Prometheus Developers <prometheus...@googlegroups.com> wrote:
> Try this new WMI exporter, more details here: https://goo.gl/B5yUCR - written in .NET Core 2, does not require any code generation and can collect metrics locally or remotely from Windows hosts or containers. Note that WMI exporter on GitHub requires code generation for WMI metrics and must be deployed locally.
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.
>

> To post to this group, send email to prometheus...@googlegroups.com.

>
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/ef10ce35-fe9c-41c6-b6ee-d5cd27b01d88%40googlegroups.com.
>
>
>
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.
To post to this group, send email to prometheus-developers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/98a06f00-0ca1-4b10-8a31-4888326b7cd3%40googlegroups.com.

[dmi...@ymail.com]

It is a right idea and exporter I mentioned does follow this pattern. However, there are scenarios when WMI metrics need to be accessed remotely and exposed as target. In such edge cases, exporter can become a "proxy" as long as it exposes target with cached and timestamped data.

On Tuesday, September 12, 2017 at 10:48:47 PM UTC-7, Ben Kochie wrote:
> The design idea is that exporter should be installed locally, and setup 1-to-1 with the target to be monitored.  This way there is basically no "network" between the exporter and the target.
>
>
> The "standard" wmi_exporter and the official node_exporter follow this pattern.
>
>
>
> On Wed, Sep 13, 2017 at 7:17 AM, dmitrio via Prometheus Developers <prometheus...@googlegroups.com> wrote:
> You mean that node exporter is anti-pattern? The one I mentioned is equivalent to node-exporter for Windows and it does support deployment on the host or as container (identical to node exporter.
>
>
>
> On Tuesday, September 12, 2017 at 9:13:58 PM UTC-7, Ben Kochie wrote:
>
> > For the record, "Deploying locally" is part of the Prometheus design pattern.  Centrally proxying metrics is an anti-pattern.
>
> >
>
> >
>
> > On Wed, Sep 13, 2017 at 1:33 AM, dmitrio via Prometheus Developers <prometheus...@googlegroups.com> wrote:
>
> > Try this new WMI exporter, more details here: https://goo.gl/B5yUCR - written in .NET Core 2, does not require any code generation and can collect metrics locally or remotely from Windows hosts or containers. Note that WMI exporter on GitHub requires code generation for WMI metrics and must be deployed locally.
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
>
> >
>

> > To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

>
> >
>
> > To post to this group, send email to prometheus...@googlegroups.com.
>
> >
>
> > To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/ef10ce35-fe9c-41c6-b6ee-d5cd27b01d88%40googlegroups.com.
>
> >
>
> >
>
> >
>
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

>
> To post to this group, send email to prometheus...@googlegroups.com.
>

[dmi...@ymail.com]

For example, I need the following query:

SELECT * FROM Win32_PerfFormattedData_BizTalkMessageBoxHostCounters_BizTalkMessageBoxHostCounters

With "standard" WMI exporter:

1. Generate code for that counter to extend it using (https://github.com/martinlindhe/wmi_exporter/tree/master/tools/collector-generator).
2. Build custom version exporter

With new WMI exporter (https://goo.gl/B5yUCR)
1. Modify configuration file and restart. (no code generation required)

Please let me know if my understanding is not correct.

Best.

[Carl Pettersson (BN)]

Yes, in that way you would be correct. I understood you as claiming code generation was necessary for anyone, while I would say that it is only for extending the exporter (and PRs for new classes are gladly accepted!).
The reason we have not added ad-hoc queries is that from experience the raw data that windows gives you from a WMI query is seldom that well suited for direct ingestion. Almost all the classes we support today requires some amount of mathematical adjustment, or splitting/joining multiple values, as well as doing proper labelling/naming.

Best regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/c71abc13-6371-4aa6-b6d9-da34f3cd2a15%40googlegroups.com.

[dmi...@ymail.com]

Thanks for confirming that "standard" WMI exporter does require code generation for MWI metrics it does not support out of the box. This means that with "new" WMI exporter there is simply no need to create PRs for new classes:)

I do not see all WMI metrics as equal. While you are correct that raw WMI metrics do require formulas for adjustment, the "cooked" set and metrics including ones from a specific provider ( BizTalk provider is just one example) are computed, which makes them suitable for collection.

Best.

[Richard Hartmann]

I didn't look at either implementation in detail, respectively at all
in the other case.

Generally speaking, there's an argument to be made that a descriptive
configuration language to rework somewhat generic values into metrics
Prometheus understands is more flexible than generated code.
snmp_exporter comes to mind

As a general point of order, it's more common to refer to projects by
their name, i.e. [martinlindhe/]wmi_exporter &
[infragravity/]sonar-docker instead of connotations like "old",
"standard", or "new".


Richard

[dmi...@ymail.com]

I am not saying that sonar is better than WMI exporter - every choice has its pros and cons.
As far as configuration language vs generated code, Microsoft designed WMI API (including .NET framework) with support of queries without need to generate code for every possible WMI metric. So, perhaps they had reasons for doing that.

Best.

[dmi...@ymail.com]

In case if someone interested, samples for using Sonar are on gitHub: https://github.com/infragravity/sonar-docker.
Best.