Feature: Services states about windows_exporter HOT 9 CLOSED

Hi @mikenowak,
Thanks for the suggestion. I had a look, and it looks like it should be quite straightforward. Initially, I'd say we would only expose name and state, the other properties seem less useful. Do you agree about that?

from windows_exporter.

Hi @carlpett,

Agreed, yes - thats pretty much all that I am after.

from windows_exporter.

Alright, I have a working prototype now. Some choices made:

• I went with the service name instead of the display name, which makes it somewhat less easy to parse (name="igfxcuiservice1.0.0.0"...), but I think there is no guarantee that a display name is unique.
• I'm lower-casing everything
• I expose the start_mode as a separate metric, which should make for easy alerting if something isn't in the state you want it to.

Example output:

# HELP wmi_service_start_mode The start mode of the service (StartMode)
# TYPE wmi_service_start_mode gauge
wmi_service_start_mode{name="aelookupsvc",start_mode="manual"} 1
wmi_service_start_mode{name="alg",start_mode="manual"} 1
wmi_service_start_mode{name="aphidmonitorservice",start_mode="auto"} 1
wmi_service_start_mode{name="appidsvc",start_mode="manual"} 1
[...]
# HELP wmi_service_state The state of the service (State)
# TYPE wmi_service_state gauge
wmi_service_state{name="aelookupsvc",state="running"} 1
wmi_service_state{name="alg",state="stopped"} 1
wmi_service_state{name="aphidmonitorservice",state="running"} 1
wmi_service_state{name="appidsvc",state="stopped"} 1

Looks ok?

from windows_exporter.

Hi @mikenowak and thanks for the suggestion. Our excellent @carlpett is already on the ball, reviewing his patch now!

from windows_exporter.

@mikenowak Could you give v0.1.3 a spin? We just pushed this release containing the service collector

from windows_exporter.

Good day @martinlindhe, @carlpett,

thank you for quick turnaround - truly outstanding!

I verified this to work on Win2013 R2 and Win2016 Server.

Here is one more question as my knowledge is incomplete because so far focused on gathering metrics rather than visualising data.

Is there any real benefit of the node_exporter approach (which exposes all the possible statuses for a given service and a gauge) versus solution implemented herein?

node_systemd_unit_state{name="syslog.service",state="activating"} 0
node_systemd_unit_state{name="syslog.service",state="active"} 0
node_systemd_unit_state{name="syslog.service",state="deactivating"} 0
node_systemd_unit_state{name="syslog.service",state="failed"} 0
node_systemd_unit_state{name="syslog.service",state="inactive"} 1

from windows_exporter.

@mikenowak It does not matter, as far as I am aware. Prometheus will consider any absent series as zero. However, the case could be made that it would be clearer to always expose all the series. It would also ensure that any other consumers of the endpoint (I'm aware of at least one other client) work the same, as I'm not sure if this is required behavior. I'll have a look at it.

from windows_exporter.

@mikenowak We merged an update which exposes all the states/start modes for clarity

from windows_exporter.

Thanks, confirmed to work as expected.

from windows_exporter.