Eigene Zabbix-Prüfungen: Aussagekräftige Messwerte statt Scheinsicherheit

Zuerst festlegen, was Erfolg bedeutet

Ein laufender Backupdienst beweist keine erfolgreiche Sicherung. Ein alter Erfolgsvermerk in einer Logdatei sagt nichts über den letzten Lauf aus. Prüfen Sie deshalb den relevanten Zeitraum, das erwartete Ergebnis und die Aktualität. Bevor Sie ein Skript entwickeln, sollten Sie außerdem vorhandene Zabbix-Items, Templates oder eine geeignete Anwendungsschnittstelle prüfen.

UserParameter gezielt einsetzen

Ein UserParameter verknüpft einen Item-Schlüssel mit einem vom Agenten ausgeführten Befehl. Dieser Ansatz ist sowohl beim klassischen Agenten als auch beim Agent 2 möglich. Der Aufruf läuft im Kontext des Agentendienstes; testen Sie daher mit dessen tatsächlichen Rechten und Umgebung.

Ausgabe und Exitcode unterscheiden

Bei UserParametern wird die Befehlsausgabe als Itemwert verarbeitet. Ein PowerShell-Skript, das lediglich mit exit 0 oder exit 1 endet, liefert dadurch noch keinen numerischen Messwert. Definieren Sie Ausgabeformat und Item-Datentyp ausdrücklich. Auch Fehlerausgaben des aufgerufenen Befehls können im zurückgegebenen Wert landen. Diagnosemeldungen mitten in einer Zahl oder einem JSON-Dokument machen die Ausgabe unbrauchbar.

Unbekannte Zustände sichtbar lassen

Eine nicht lesbare Datei oder ein abgelaufenes Zeitlimit ist nicht dasselbe wie eine erfolgreich geprüfte Anwendung. Unterscheiden Sie fachlichen Fehler, technischen Prüffehler und fehlende Daten. Ein Trigger für einen negativen Messwert genügt nicht, wenn die Abfrage gar keinen gültigen Wert mehr liefert.

Mehrere Werte strukturiert übertragen

Für zusammengehörige Ergebnisse kann eine strukturierte JSON-Ausgabe mit einem Master-Item und abhängigen Items geeignet sein. Legen Sie Feldnamen und Datentypen fest und prüfen Sie die Vorverarbeitung. Ein leeres oder ungültiges JSON muss erkennbar sein. Geheime Inhalte dürfen nicht versehentlich in Messwerte gelangen.

Beispiel: Einen nächtlichen Sicherungslauf bewerten

{
  "check_status": "ok",
  "job_result": "success",
  "last_success_unixtime": 1793236500,
  "message": ""
}

Diese Beispielantwort meldet einen erfolgreich ausgelesenen und erfolgreichen Auftrag. last_success_unixtime ist hier der Unix-Zeitstempel für den 29. Oktober 2026, 01:15 Uhr UTC. Das Master-Item speichert den JSON-Text. In der Vorverarbeitung der abhängigen Items extrahiert JSONPath beispielsweise $.check_status, $.job_result und $.last_success_unixtime. Zum Zeitstempel passt ein numerischer Itemtyp; die beiden Statusfelder bleiben Text.

{
  "check_status": "error",
  "job_result": null,
  "last_success_unixtime": null,
  "message": "Statusquelle nicht lesbar"
}

Die zweite Antwort beschreibt einen Fehler beim Prüfen. Sie ist keine Aussage über Erfolg oder Misserfolg des Sicherungslaufs. Definieren Sie für diesen Zustand eine eigene Meldung. Ein fehlender Zeitstempel darf nicht durch den aktuellen Zeitpunkt ersetzt werden: Das würde eine frische erfolgreiche Sicherung vortäuschen. Zusätzlich muss ausbleibende Erfassung über die Datenfrische erkennbar werden.

Berechtigungen und Eingaben begrenzen

Skripte sollten nur die benötigten Zugriffe erhalten. Schützen Sie die Dateien vor unberechtigten Änderungen und behandeln Sie übergebene Argumente als Eingaben, die validiert werden müssen. UnsafeUserParameters ist keine allgemeine Voraussetzung für eigene Skripte und sollte nicht pauschal aktiviert werden.

Mit einem Testplan abnehmen

Testen Sie Normalbetrieb, veraltete Daten, nicht erreichbare Quellen, fehlende Rechte, ungültige Ausgabe und Zeitüberschreitung. Prüfen Sie anschließend die vollständige Kette bis zur Benachrichtigung. Eine Speicherverbrauchsschwelle allein belegt beispielsweise nicht, dass ein Dienst fachlich funktioniert. Dokumentieren Sie genau, was Ihr Check nachweist und was nicht.