Open source monitoring: monitor WSUS with Prometheus

Prometheus metrics as a graphAfter you have successfully set up a Prometheus server, you can connect Windows computers to monitor them in the future. To do this, a so-called is installed on the source system Exporter. In order to call up certain metrics, you activate the relevant ones Collectors of an exporter.

The wmi_exporter is the preferred choice among Windows exporters. As the name suggests, it obtains the values ​​via Windows Management Instrumentation (WMI). Standard metrics such as CPU, memory or disk utilization are also available.

In addition, a wealth of other data can be accessed, such as on Active Directory, ADFS or DNS. If necessary, you can even read the temperature.

Collectors for certain metrics that are not active by default can be added afterwards. In this example we will read out the basic values ​​of a WSUS server. There is a complete list of the available collectors on GIT.

Installation of the wmi_exporter

The download of the exporter is also on GIT under the releases. Depending on the system to be monitored, choose the x86 or amd64 version, both are available as .exe and .msi.

The setup creates a new service called WMI exporter which executes an EXE in the autorun, which in turn under C: Program Files (x86) wmi_exporter is generated. As soon as the service is running, it already presents the bare metrics via port 9182.

After starting the service, wmi_exporters already provides basic metrics

Now the task is to adapt the exporter to your own requirements by activating additional collectors. Here we want to monitor a WSUS server. We check whether the service is running and what the available storage space is, since it can run up quite quickly under WSUS. We also want to get an overview of RAM usage.

To do this, you have to modify the generated service. About the command

sc qc wmi_exporter

all parameters of the exporter can be displayed.

Display parameters of the exporter service with sc.exe

To activate further collectors, the best thing to do is to copy the value of BINARY_PATH_NAME from the previous query into a text editor:

"C: Program Files (x86) wmi_exporter wmi_exporter.exe" --log.format logger: eventlog? Name = wmi_exporter --telemetry.addr: 9182

The parameter is now also defined behind the actual program path collectors.enabled according to the following syntax:

"C: Program Files (x86) wmi_exporter wmi_exporter.exe " --collectors.enabled "cpu, cs, logical_disk, net, os, service, textfile, memory " --collector.service.services-where "Name LIKE '' WsusService% '" --log.format logger: eventlog? Name = wmi_exporter --telemetry.addr: 9182

In addition to the standard collectors such as cpu, cs, logical_disk, etc. we also have that for Memory activated. We also use the parameter collector.service.services-where a monitoring for the service WsusService implemented.

In the next step, we transfer the changes to the service. To do this, we execute the following command:

sc config wmi_exporter binPath = "" C: Program Files (x86) wmi_exporter wmi_exporter.exe "--collectors.enabled " cpu, cs, logical_disk, net, os, service, textfile, memory "- collector.service.services-where "Name LIKE 'WsusService%' " --log.format logger: eventlog? name = wmi_exporter --telemetry.addr: 9182 "

Modify exporters to enable collectors for the WSUS service

After the changes have been written, the service must be restarted. The additional metrics then appear on port 9182, in the figure below those for WSUS.

The exporter now begins to collect metrics for WSUS using the additional collector.

The data is extremely detailed, you get all the information about the node. It is therefore essential to evaluate which metrics to monitor before implementation.

From experience, however, it is advisable to publish too many rather than too few metrics about the exporter. If the requirements change, the evaluation can still be configured on the dashboard software (in our case Grafana) without having to touch the source systems.

Connection to Prometheus

After the exporter has been set up, you have to adjust the Prometheus configuration file. To do this, we add the host to be monitored to the YML file static_configs as a target.

Include the WSUS server in the configuration of Prometheus

After saving, you have to restart the Prometheus service. Prometheus then collects the metrics of the WMI exporter.

Evaluate WSUS metrics

Now you can use the graph tool to visualize the first collected metrics over time. As can already be seen in the raw data above, the metrics are structured in such a way that the service is viewed via different statuses. The correct one always has the value 1, all others 0. We are particularly interested in the status “OK”.

With the following query we can have a visualization output:

wmi_service_state {status = "running"}

Graphical representation of the availability of the WSUS service

The graph shows that the server has not been running for a long time, ie has returned the value 0, and was started again later.

over wmi_os_physical_memory_free_bytes the free working memory can be determined. Prometheus always works with bytes. The value has to be adjusted so that we can get the GB value presented. The final query is:

(wmi_os_physical_memory_free_bytes) / 1e + 9

Visualization of free memory

Now the free space on the D: drive should be displayed in GB. So we give the corresponding name of the metric, reduce the selection to drive letter D: and convert bytes to GB:

(wmi_logical_disk_free_bytes {volume = "D:"}) / 1e + 9

Disk space metric diagram on drive D:

The graph shows an internal copy job in the specified time interval, which reduces the storage space.

Prometheus already gives a good first insight into the delivered metrics and can also prepare them in simple form using graphs.

You might like

About the Author: Jan Gruber

Leave a Reply

Your email address will not be published. Required fields are marked *