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 / aus der Bibliothek	Eigene
Herkunft	Vesana selbst (Mitgeliefert) oder ein installiertes Profil der Vesana-Bibliothek (Aus dem Hub)	Selbst angelegt oder als Kopie eines anderen 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
Bearbeiten, löschen	nur Super-Admins — danach ist das Script „modifiziert" und bekommt keine Updates mehr; Tenant-Admins legen eine Kopie an	mit den Script-Permissions

Ein Script aus einem Bibliotheksprofil 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 (Vesana-Bibliothek). Die Bibliothek liefert nur von Vesana signierte Versionen.

Die Script-Bibliothek¶

Scripts in der Hauptnavigation (nur für Super-Admins sichtbar) listet alle Scripts, 50 je Seite, mit der Trefferzahl:

Suche über Name und Beschreibung.
Filter nach Tenant (auch „Global (System)"), Interpreter, Herkunft (Mitgeliefert · Aus dem Hub · Selbst angelegt) und Verwendung — „Nicht verwendet" heißt: kein aktiver Check führt das Script aus und kein Profil-Check verweist darauf.
Die Spalte Verwendung nennt je Script, wie viele aktive Checks es gerade ausführen und in wie vielen Profilen es steckt.
Die Spaltenköpfe sortieren (Name, Interpreter, Ausgabe, Tenant).

Bearbeiten, Duplizieren und Löschen stehen rechts in der Zeile und im Rechtsklick-Menü.

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 bzw. unter den globalen Scripts; ein schon vergebener Name wird abgelehnt
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. Die erste Zahl in der Ausgabe wird als Messwert genommen; mit Exit-Code 0 urteilen danach die Schwellwerte.

Exit-Code	Status
0	OK
1	WARNING
2	CRITICAL
3 oder anderer	UNKNOWN

Die Zuordnung ist am Agent, über SSH und über die API dieselbe (Nagios-Konvention). Ein Script, das am Agent bisher mit Exit-Code 1 oder 4 und höher endete, wurde dort als CRITICAL gewertet und erscheint jetzt als WARNING bzw. UNKNOWN.

#!/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), Script (SSH) (ssh_script) oder Script (API) (api_script) → unter Konfiguration das Script auswählen. Die Auswahl hat eine Suche und zeigt nur Scripts, die zum Betriebssystem des Hosts passen (bei api_script Bash und Python, weil der Collector das Script ausführt). 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 im Tenant des Geräts 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 Bibliotheksprofil wird durch Für alle Checks zu einem lokal geänderten Script und bekommt keine Updates aus der Bibliothek 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 die geänderte Konfiguration mit ihrem nächsten Abruf.

Identitätsbestätigung: Wer ein Script anlegt oder seinen Code bzw. Interpreter ändert (auch „Nur dieses Gerät" und ein Profil-Import, der Code mitbringt), bestätigt vorher seine Identität — Passkey, Code oder Passwort, jedes Konto, auch Super-Admins. Eine Bestätigung gilt 15 Minuten für die Sitzung; Name oder Beschreibung zu ändern verlangt keine. Abschaltbar ist das unter Admin → Anmeldung & Sicherheit → 2FA & Sitzungen, Details: Sitzungen.

Agent Lock: Ist am Host die lokale Freigabe eingeschaltet, läuft ein geändertes Script erst nach Freigabe am Host; bis dahin läuft die zuletzt freigegebene Fassung weiter.

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, als api_script unter dem Dienstkonto des Collectors.

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.

Wer den Rumpf oder den Interpreter eines Scripts ändert oder das Script löscht, wirkt auf alle Hosts, deren Checks es benutzen — dafür braucht er die Script-Rechte auf allen diesen Hosts. Fehlt sie auf einem, antwortet die Oberfläche mit „Keine Script-Berechtigung auf allen Ziel-Hosts“ und ändert nichts; Name, Beschreibung und Ausgabeformat bleiben ohne diese Prüfung änderbar.

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. Checks, die darauf zeigen, laufen bis dahin nicht und zeigen „Script nicht gefunden".

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