Open-Source-Monitoring: WSUS mit Prometheus überwachen

Zusätzlich lässt sich eine Fülle anderer Daten abrufen, etwa zu Active Directory, ADFS oder DNS. Bei Bedarf kann man sogar die Temperatur auslesen.

Collectors für bestimmte Metriken, die standard­mäßig nicht aktiv sind, kann man im Nachgang hinzuschalten. In diesem Beispiel werden wir Basiswerte eines WSUS-Servers auslesen. Eine vollständige Auflistung der verfügbaren Collectors gibt es auf GIT.

Installation des wmi_exporters

Der Download des Exporters befindet sich ebenfalls auf GIT unter den Releases. Je nach zu überwachendem System wählt man die x86- oder amd64-Version, beide gibt es als .exe und .msi.

Das Setup legt einen neuen Service namens WMI Exporter an, welcher im Autorun eine EXE ausführt, die wiederum unter C:\Program Files (x86)\wmi_exporter generiert wird. Sobald der Service läuft, präsentiert er über den Port 9182 bereits die blanken Metriken.

Nun gilt es, den Exporter an die eigenen Anforderungen anzupassen, indem man weitere Collectors aktiviert. Hier wollen wir einen WSUS-Server überwachen. Dabei prüfen wir, ob der Dienst läuft und wie es um den verfügbaren Speicherplatz steht, da dieser unter WSUS recht schnell volllaufen kann. Des Weiteren wollen wir einen Überblick über die RAM-Auslastung erhalten.

Dazu muss man den generierten Service modifizieren. Über das Kommando

sc qc wmi_exporter

lassen sich sämtliche Parameter des Exporters anzeigen.

Um weitere Collectors zu aktivieren, kopiert man zunächst den Wert des BINARY_PATH_NAME aus der vorherigen Abfrage am besten in einen Texteditor:

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

Hinter dem eigentlichen Programmpfad definiert man nun zusätzlich den Parameter collectors.enabled gemäß folgender 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

Neben den Standard-Collectors wie cpu, cs, logical_disk, etc. haben wir zusätzlich jenen für Memory aktiviert. Außerdem haben wir mit dem Parameter collector.service.services-where eine Überwachung für den Service WsusService implementiert.

Im nächsten Schritt übergeben wir die Änderungen an den Service. Dazu führen wir folgenden Befehl aus:

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"

Nachdem die Änderungen geschrieben wurden, muss man den Service neu starten. Anschließend erscheinen die zusätzlichen Metriken auf Port 9182, in der Abbildung unten jene für WSUS.

Die Daten sind dabei extrem detailliert, man erhält sämtliche Informationen des Knotens. Deshalb ist es essentiell, vor der Implementierung zu evaluieren, welche Metriken überwacht werden sollen.

Aus der Erfahrung heraus ist es dennoch ratsam, eher zu viele als zu wenige Metriken über den Exporter zu publizieren. Ändern sich die Anforderungen, dann kann man die Auswertung immer noch an der Dashboard-Software (in unserem Fall Grafana) konfigurieren, ohne die Quellsysteme anfassen zu müssen.

Anbindung an Prometheus

Nachdem der Exporter eingerichtet wurde, muss man die Konfigurations­datei von Prometheus anpassen. Dazu nehmen wir den zu überwachenden Host in das YML-File unter static_configs als Target auf.

Nach dem Speichern muss man den Prometheus-Service neu starten. Anschließend sammelt Prometheus nun die Metriken des WMI-Exporters.

WSUS-Metriken auswerten

Nun kann man über das Graph-Tool bereits die ersten gesammelten Metriken im zeitlichen Verlauf visualisieren. Wie bereits in den Rohdaten weiter oben zu sehen ist, sind die Metriken so aufgebaut, dass der Service über verschiedene Status betrachtet wird. Dabei hat der zutreffende immer den Wert 1, alle anderen 0. Uns interessiert vor allem der Status „OK“.

Mit folgender Abfrage können wir uns also eine Visualisierung ausgeben lassen:

wmi_service_state{status="running"}

Der Graph zeigt, dass der Server längere Zeit nicht lief, also den Wert 0 geliefert hat, und später wieder gestartet wurde.

Über wmi_os_physical_memory_free_bytes lässt sich der freie Arbeitsspeicher ermitteln. Prometheus arbeitet hierbei immer mit Bytes. Der Wert muss also noch angepasst werden, damit wir den GB-Wert präsentiert bekommen. Die finale Abfrage lautet also:

(wmi_os_physical_memory_free_bytes) / 1e+9

Nun soll der freie Speicherplatz auf dem Laufwerk D: in GB angezeigt werden. Wir geben also den entsprechenden Namen der Metrik an, reduzieren die Auswahl auf den Drive-Letter D: und rechnen von Bytes in GB um:

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

Der Graph zeigt in dem festgelegten Zeitintervall einen internen Copy-Job an, welcher den Speicherplatz schmälert.

Prometheus gibt bereits einen guten ersten Einblick in die gelieferten Metriken und kann diese auch bereits in einfacher Form mittels Graphen aufbereiten.