Einführung

Einige Linux-Dienste sind darauf ausgelegt, nach der Initialisierung zu beenden – das bringt Dienst-Monitore durcheinander. Wenn Sie einen solchen Dienst mit einem Dienst-Monitor in Level überwachen, erhalten Sie Fehlalarme. Die Lösung ist ein Skript-Monitor, der SubState anstatt ActiveState.

Warum Dienst-Monitore Fehlalarme auslösen

systemd verfolgt jede Unit über zwei Statusfelder: ActiveState und SubState. Dienst-Monitore prüfen ActiveState — Werte wie active, inactive, oder failed.

Das Problem: bestimmte Dienste beenden sich nach ihrer Arbeit und wechseln nie in einen dauerhaften active Zustand. Der wg-quick ist das häufigste Beispiel. Es konfiguriert die VPN-Schnittstelle und beendet sich dann. systemd zeichnet ActiveState als inactive (exited). Ein Dienst-Monitor sieht inactive und löst einen Alarm aus – obwohl das VPN korrekt läuft, die Schnittstelle aktiv ist und der Datenverkehr weitergeleitet wird.

SubState liefert eine genauere Aussage. Für Dienste wie wg-quick, ist ein gesunder SubState exited — erwartet und normal. Ein SubState von failed würde bedeuten, dass tatsächlich etwas schiefgelaufen ist. Die Prüfung von SubState direkt zu lesen ermöglicht es Ihnen, den Unterschied zu erkennen.

SubState mit einem Skript prüfen

Verwenden Sie systemctl show um den SubState für eine beliebige Unit zu lesen:

systemctl show -p SubState --value <unit_name>

Dies gibt eine einzelne Zeichenfolge zurück — running, exited, dead, failed, usw. — die Sie in einem Skript-Monitor auswerten können.

🖥️ PLATTFORMHINWEIS:

Linux: Wird auf jeder Distribution unterstützt, die systemd verwendet.
Windows / macOS: Nicht zutreffend. systemctl ist nur für Linux verfügbar.

Beispiel: Überwachung einer WireGuard-Schnittstelle

Das folgende Skript prüft, ob wg-quick@wg0 den erwarteten exited SubState. Ersetzen Sie den Namen durch Ihren tatsächlichen Unit-Namen, falls dieser abweicht.

#!/bin/bash

UNIT_NAME="wg-quick@wg0"
STATUS=$(systemctl show -p SubState --value $UNIT_NAME)

if [ "$STATUS" = "exited" ]; then
    echo "Service is running correctly."
    exit 0
else
    echo "ALERT: Service is not running. SubState: $STATUS"
    exit 1
fi

Das Skript gibt eine lesbare Statuszeichenfolge aus und beendet sich mit Code 0 (gesund) oder 1 (unerwarteter Zustand). Konfigurieren Sie den Skript-Monitor so, dass er auslöst, wenn die Ausgabe Enthält die Fehlerzeichenfolge „ALERT".

Monitor-Konfiguration:

Feld	Wert
Typ	Skript ausführen
Betriebssystem	Linux
Skript	Linux - WireGuard SubState-Prüfung
Skriptausgabe	Enthält
Wert	`ALERT`
Ausführungshäufigkeit	5 Minuten
Auslöseanzahl	2

💡 TIPP: Setzen Sie Auslöseanzahl auf 2 oder höher setzen, um Alarme durch vorübergehende Zustände während Dienstneustart oder Neustarts zu vermeiden.

Weitere Unit-Typen, die planmäßig beendet werden

wg-quick ist der häufigste Fall, aber all diese können dasselbe Fehlalarmmuster auslösen:

Oneshot-Dienste — führen eine Aufgabe aus und beenden sich; SubState wird sein exited bei gesundem Zustand
Timer-Units — werden nach einem Zeitplan ausgeführt; prüfen Sie ActiveState für die Timer-Unit selbst, nicht für den gestarteten Dienst
Type=forking-Dienste — übergeordneter Prozess beendet sich nach dem Starten eines untergeordneten Prozesses; SubState kann exited während der untergeordnete Prozess läuft

Für all diese Fälle ist ein Skript-Monitor, der SubState mit Ihrem bekannten Sollwert ist der richtige Ansatz.

Häufig gestellte Fragen

Mein WireGuard-Dienst wird in Level als nicht verfügbar angezeigt, aber der Datenverkehr wird korrekt weitergeleitet. Was passiert hier? wg-quick beendet sich nach dem Einrichten der VPN-Schnittstelle – das ist normal. Die Netzwerkschnittstelle bleibt aktiv, obwohl der Dienstprozess beendet wurde. Ein Dienst-Monitor sieht inactive und löst einen Alarm aus. Verwenden Sie einen Skript-Monitor, der SubState (der exited, der gesunde Wert) zurückgibt.
Wie erkenne ich, welchen SubState-Wert ich erwarten kann, wenn ein Dienst gesund ist? Führen Sie aus systemctl show -p SubState --value <unit_name> auf einem Gerät, auf dem der Dienst korrekt funktioniert. Was auch immer zurückgegeben wird, ist Ihre gesunde Ausgangsbasis. Erstellen Sie das Skript anhand dieses Werts.
Kann ich sowohl ActiveState als auch SubState im selben Monitor prüfen? Ja. Schreiben Sie das Skript so, dass es beide liest und fehlschlägt, wenn einer von beiden unerwartet ist. Dies gibt Ihnen eine breitere Abdeckung — Sie können Dienste erkennen, die unerwartet beendet wurden (SubState: failed) separat von Diensten, die einfach gestoppt sind (ActiveState: inactive).
Funktioniert dies auf Linux-Distributionen, die kein systemd verwenden? Nein. systemctl erfordert systemd. Bei Distributionen, die SysVinit oder Upstart verwenden, benötigen Sie andere Werkzeuge (z. B. service <name> status). Die meisten aktiv gepflegten Linux-Distributionen werden mit systemd ausgeliefert.

Verwandte Artikel

Erste Schritte mit Monitoren

Überwachung von systemd-Unit-Dateien unter Linux