Monitoring-Scripts¶

Wenn die eingebauten Check-Typen nicht reichen — ein eigenes Backup-Tool, ein herstellerspezifisches CLI, eine REST-API — sind Monitoring-Scripts der Weg.

Konzept¶

Scripts liegen zentral in Vesana (Script-Bibliothek) und werden zur Laufzeit an Agent oder Collector ausgeliefert. Auf der Maschine selbst liegt nichts.

Ein Script ist ein Script — egal wo es läuft. Dasselbe Bibliotheks-Script kann als agent_script (Agent auf der Maschine) oder als ssh_script (Collector per SSH) laufen; beide werten nach dem am Script deklarierten Ausgabeformat aus. Über SSH laufen Python-Scripts mit dem Python-Interpreter, Shell-Scripts fallen automatisch auf sh zurück, wenn das Gerät kein bash hat (ESXi, Appliances).

Ein Script speist viele Checks. Was sich pro Gerät unterscheidet (Pfad, Zeitfenster, Ausnahmeliste), deklariert das Script als einstellbaren Wert — jeder Check füllt seine Felder selbst aus. Den Script-Rumpf pro Check zu kopieren ist damit nicht mehr nötig; eine Verbesserung am Original erreicht so alle Checks.

Grenzwerte gehören an den Check, nicht ins Script. Warning/Critical stehen im Block „Urteil über Schwellwerte" des Checks — pro Gerät überschreibbar, sofort wirksam. Das Script gibt nur den Messwert aus.

Mitgelieferte und eigene Scripts¶

	Mitgeliefert	Eigene
Herkunft	Vesana selbst oder ein importiertes Community-Profil	selbst angelegt oder als Kopie eines mitgelieferten Scripts
Sichtbarkeit	global — für alle Tenants	gehören dem Tenant; ein Script eines anderen Tenants lässt sich nicht an eigene Checks hängen (ab v1.9.437)
Bearbeiten	ja — danach ist das Script „modifiziert" und bekommt keine Updates mehr	ja

Ein Script aus einem Community-Profil wird bei einem Profil-Update mit aktualisiert, solange du seinen Inhalt nicht selbst geändert hast. Selbst angepasste Scripts bleiben unangetastet und werden im Update-Ergebnis getrennt ausgewiesen (Community Hub).

Ein Script anlegen¶

Scripts (Hauptnavigation; die Bibliotheks-Seite sehen Super-Admins) → Neues Script, oder aus einem Check heraus über Als eigenes Script (siehe unten).

Feld	Bedeutung
Name	eindeutig pro Tenant
Beschreibung	wofür das Script da ist
Interpreter	PowerShell, Bash, Python — bestimmt, welchen Hosts das Script angeboten wird (Windows: PowerShell/Python, Linux: Bash/Python)
Output-Format	Nagios, Text, JSON (siehe unten)
Script	der Inhalt, im großen Editor-Fenster mit Zeilennummern; Zeilen mit `# @vesana-param` sind hervorgehoben

Das Editor-Fenster zeigt neben dem Code die erkannten einstellbaren Werte und warnt, wenn ein deklarierter Wert im Script nie gelesen wird (das Feld hätte keine Wirkung).

Ausgabeformate¶

Nagios¶

Exit-Code bestimmt den Status: 0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN. Optional Perfdata nach |:

STATUS - Beschreibung | label1=wert;warn;crit label2=wert

#!/bin/bash
LOAD=$(awk '{print $1}' /proc/loadavg)
if (( $(echo "$LOAD > 5" | bc -l) )); then
  echo "CRITICAL - Load $LOAD | load1=$LOAD;1;5"; exit 2
elif (( $(echo "$LOAD > 1" | bc -l) )); then
  echo "WARNING - Load $LOAD | load1=$LOAD;1;5"; exit 1
fi
echo "OK - Load $LOAD | load1=$LOAD;1;5"; exit 0

Die erste Perfdata-Metrik ist der Messwert des Checks (Graph, Schwellwerte). Die Perfdata steht nicht in der Meldung.

Text¶

Freier Text, Status nur über den Exit-Code (0 = OK, alles andere CRITICAL). Die erste Zahl in der Ausgabe wird als Messwert genommen.

#!/bin/bash
if [ -f /tmp/maintenance ]; then
  echo "Wartungsmodus aktiv"; exit 1
fi
echo "Normalbetrieb"; exit 0

JSON¶

Strukturierte Ausgabe, Status frei wählbar:

import json
print(json.dumps({
  "status": "OK",              # OK / WARNING / CRITICAL / UNKNOWN
  "message": "Backup von gestern um 02:14",
  "value": 42,                 # optional, Messwert
  "unit": "%",                 # optional
  "series": {"C:": 42, "D:": 13.5},          # optional, siehe unten
  "details": {"jobs": [{"name": "Daily", "status": "ok"}]}   # optional, siehe unten
}))

Serien und Details¶

Ein Script kann mehr melden als einen Wert:

Serien — mehrere Zahlen, die im Verlaufs-Graph als einzeln wählbare Serien erscheinen (per Klick auf die Legende vergleichen). Bei Nagios: alle Perfdata-Tokens (| 'C:'=42% 'D:'=13%), bei JSON der Schlüssel series. Der Hauptwert bleibt die erste Metrik bzw. value.
Details — ein freies details-Objekt in der JSON-Ausgabe (Liste laufender Websites, Backup-Jobs, Replikationspartner …). Der Klick auf den Check zeigt es generisch: Objekt-Listen als Tabelle, Einzelwerte als Schlüssel/Wert. „Was hat der Check tatsächlich gesehen?" statt nur gut/schlecht.
Geräte-Snapshot — trägt die Check-Konfiguration einen snapshot_type, füllen die Details die Geräte-Visualisierung (z. B. das NAS-Diskbay-Panel im UGREEN-Profil, ganz ohne SNMP). Details: Geräte-Kompatibilität.

Beides funktioniert über Agent und SSH.

Ein Script an einen Check binden¶

Check-Typ Script (agent_script) oder Script (SSH) (ssh_script) → unter Konfiguration das Script auswählen. Die Auswahl hat eine Suche und zeigt nur Scripts, die zum Betriebssystem des Hosts passen. Unter dem gewählten Script stehen die einstellbaren Werte und die Vorschau „Das Script bekommt damit".

Zeigt ein Check auf ein Script, das im Papierkorb liegt, steht dort sofort „Script nicht gefunden" — statt eines Namens, der nicht mehr gilt.

Bei agent_script gibt es zusätzlich Lokaler Pfad (ein Script, das schon auf der Maschine liegt) und Inline Script (Inhalt direkt am Check) — beide mit Interpreter und Output-Format am Check. Für alles, was mehr als ein Gerät betrifft, ist die Bibliothek der bessere Ort.

Den Inhalt direkt am Check bearbeiten¶

Der Bleistift an der Script-Karte öffnet den Inhalt im großen Editor-Fenster. Vor dem Speichern steht, wie viele Checks an diesem Script hängen, und du wählst Speichern für:

Auswahl	Wirkung
Für alle Checks	ändert das Bibliotheks-Script — Verbesserungen kommen überall an (der Normalfall)
Als eigenes Script	legt eine Kopie in der Bibliothek an und hängt nur diesen Check daran
Nur dieses Gerät	eigener Rumpf nur für diesen Check; bekommt keine Updates mehr

Ein Script aus einem Community-Profil wird durch Für alle Checks zu einem lokal geänderten Script und bekommt keine Hub-Updates mehr — für eine Ergänzung, die nur ein Gerät braucht, ist Nur dieses Gerät der passendere Weg.

Am Agent wirkt eine Script-Änderung sofort (der Host wird angestoßen); Collector holen ihre Konfiguration jede Runde.

Rechte¶

Scripts laufen mit den Rechten des Agent-Dienstes — unter Linux typischerweise root, unter Windows LocalSystem. Über SSH laufen sie als der am Host hinterlegte SSH-Benutzer.

Wer Scripts anlegen darf, führt Code auf den Geräten aus

Das Anlegen und Bearbeiten von Scripts steuern die Permissions monitoring_scripts.create / .edit / .delete. Ob ein Benutzer script-fähige Checks auf einem Host anlegen darf, steuern zusätzlich seine Script-Rechte (Benutzer → Script-Rechte: alle erreichbaren Tenants, eine Auswahl nach Tenant/Tag/Host, oder keine; ohne eigene Einstellung gilt der Rollen-Standard — Admin: alle erreichbaren Tenants, sonst keine). Sie gelten für Script-Checks ebenso wie für Checks mit eigenem Kommando („Eigenes Kommando" am Agent, „Kommando mit Auswertung" über SSH, Nagios-Plugins) — ab v1.9.437 auch für Letztere. Ping-, HTTP- und SNMP-Checks brauchen sie nicht. Details: Rollen & Permissions, Härtung.

Duplizieren, löschen, Papierkorb¶

Duplizieren (Scripts-Seite) erzeugt eine eigene Kopie — der übliche Weg, ein mitgeliefertes Script abzuwandeln, ohne es von Updates abzuhängen.
Löschen legt das Script in den Papierkorb; es ist danach weder über Direktlinks abrufbar noch bearbeitbar und lässt sich aus dem Papierkorb wiederherstellen (ab v1.9.437). Checks, die darauf zeigen, laufen bis dahin nicht.

Audit¶

Script-Änderungen landen im Audit-Log (Admin → Protokolle & Support → Audit-Log) mit altem und neuem Wert.

Anschluss¶

Einstellbare Werte an Scripts — Werte deklarieren, lesen, ausfüllen
Check-Typen-Referenz — Auswertung, Schwellwerte, Messwert
Rollen & Permissions