Eigene Felder & Auswertung¶

Manchmal reicht ein Standard-Check fast, aber nicht ganz: Du willst dem Check einen eigenen Wert mitgeben — z. B. „welches Netzwerkprofil dieser Server haben soll" — und dann sagen, wie aus dem Ergebnis ein Status wird („wenn das Ergebnis nicht zum erwarteten Wert passt → CRITICAL"). Genau dafür gibt es im Check-Editor den Bereich „Eigene Felder & Auswertung". Kein Script, kein JSON — eine geführte Maske.

Vesana wendet die Auswertung zentral auf dem Server an: Agent oder Collector liefern nur den Rohwert/die Ausgabe, der Server bestimmt daraus den Status. Dadurch ist die Logik an einer Stelle und gilt für alle Hosts gleich.

Wo finde ich das?¶

Profile → ein Profil aufklappen → Check anklicken (oder + Check) → im Modal unten den Abschnitt „Erweitert: Eigene Felder & Auswertung" aufklappen.

Der Bereich hat zwei Teile:

Teil	Beantwortet die Frage
Eigene Felder	Welche Werte kann ich diesem Check mitgeben?
Auswertung	Wie wird aus dem Ergebnis OK / WARNING / CRITICAL?

Bestehende Checks bleiben unberührt

Ein Check ohne eigene Felder und ohne Auswerte-Vertrag verhält sich exakt wie bisher (der Check „urteilt selbst"). Du musst nichts anlegen — die Felder sind ein Angebot, kein Zwang.

Eigene Felder¶

Über „+ Feld" legst du ein Eingabefeld an. Pro Feld:

Feld	Bedeutung
Feld-Name (technisch)	Interner Name, automatisch in `snake_case` (z. B. `erwartetes_profil`). Diesen Namen referenzierst du später in der Auswertung und in Meldungen.
Beschriftung	Klartext-Label, das im Editor/Host angezeigt wird (z. B. „Erwartetes Profil").
Typ	Welche Art von Wert (siehe unten).
Geltung	Am Profil (fix) oder Pro Host (pro Host einstellbar) — siehe unten.
Optionen (Komma-getrennt)	Nur bei Typ Auswahl: die erlaubten Werte, z. B. `Public, Private, DomainAuthenticated`.
Standard	Vorbelegung, wenn nichts gesetzt ist.
Pflicht	Ob ein Wert gesetzt sein muss.

Feld-Typen¶

Auswahl im Editor	Wofür
Text	beliebiger Freitext
Ganzzahl	ganze Zahl (z. B. ein Port)
Dezimalzahl	Fließkommazahl
Ja/Nein	Schalter (an/aus)
Auswahl (Dropdown)	genau einer der vorgegebenen Werte aus Optionen
Passwort (verschlüsselt)	wie Text, aber maskiert und wird nie im Klartext zurückgegeben

Geltung: Am Profil vs. Pro Host¶

Das ist der wichtigste Schalter — er entscheidet, wer den Wert setzt:

Geltung	Hinweistext im Editor	Bedeutung
Am Profil	„Ein Wert für alle Hosts dieses Profils."	Der Wert ist fix in der Definition. Jeder Host, der dieses Profil nutzt, verwendet denselben Wert. Ändern = das Profil bearbeiten (eine Admin-Aktion, gilt sofort für alle).
Pro Host	„Jeder Host kann einen eigenen Wert setzen."	Das Feld ist nur eine Vorlage mit Standardwert. Jeder Host trägt seinen eigenen Wert in den Service-Einstellungen ein. Hosts ohne eigenen Wert nutzen den Standard.

Faustregel:

Am Profil → wenn der Wert für alle gleich ist (z. B. ein fester Schwellwert, ein API-Pfad).
Pro Host → wenn jeder Host etwas Eigenes erwartet (z. B. „dieser Server soll im Private-Profil sein, jener im Domain-Profil").

Pro Host ist das neue, eigentlich Spannende

„Pro Host" macht aus einem Check-Typ viele individuelle Soll-Werte — ohne pro Host einen eigenen Check zu bauen. Definition einmal im Profil, Soll-Wert pro Host.

Den Feldwert pro Host setzen¶

Felder mit Geltung Pro Host erscheinen direkt beim Host:

Host-Detail → Service bearbeiten (Stift) → Abschnitt „Pro-Host-Einstellungen" (nur für diesen Host).

Dort steht genau dieses Feld als Eingabe (z. B. ein Dropdown „Erwartetes Profil"). Trägst du hier Public ein, gilt das nur für diesen Host; alle anderen behalten ihren Standard bzw. ihren eigenen Wert.

Felder mit Geltung Am Profil erscheinen hier bewusst nicht

Die sind fix — sie lassen sich pro Host nicht überschreiben. Nur Pro Host-Felder sind hier editierbar.

Auswertung — wie wird der Status bestimmt?¶

Unter „Wie wird das Ergebnis bewertet?" wählst du eine von vier Auswerte-Arten:

Auswahl	Wofür
Eingebaut (Check urteilt selbst)	Standard. Der Check bestimmt seinen Status selbst (Ping, HTTP, Agent-CPU …). Kein Vertrag.
Numerisch (Schwellen)	Der Zahlenwert wird gegen Warn-/Critical-Schwelle geprüft.
Vergleich (Wert/Status)	Das Ergebnis (ein Text/Wert) wird mit einem erwarteten Wert verglichen — der „public/private"-Fall.
Script-Ausgabe	Status aus dem Exit-Code (Nagios) oder einem JSON-Feld.

Numerisch¶

Richtung: hoch = schlecht (Default) oder niedrig = schlecht.
Warnung ab / Kritisch ab: die Schwellen.

Bei „hoch = schlecht" gilt: Wert ≥ Kritisch → CRITICAL, sonst Wert ≥ Warnung → WARNING, sonst OK. Bei „niedrig = schlecht" umgekehrt (≤). Mindestens eine Schwelle muss gesetzt sein.

Vergleich (Wert/Status)¶

Hier vergleichst du das Ergebnis des Checks mit einem erwarteten Wert:

Feld	Bedeutung
Vergleich	ist gleich · ist eines von · enthält · passt auf Regex
Erwartet (aus Feld)	Den erwarteten Wert aus einem deiner Felder ziehen (z. B. `erwartetes_profil`) — so wird er pro Host auflösbar.
Erwarteter Wert	Alternativ ein fester Wert (wenn kein Feld gewählt ist).
Bei Treffer / Sonst	Welcher Status bei Übereinstimmung bzw. Abweichung (z. B. OK / CRITICAL).
Meldung (optional)	Freitext mit Platzhaltern.

Script-Ausgabe¶

Für Checks, die ein Script oder ein Nagios-Plugin ausführen (Agent oder Collector via SSH):

Format:
- Exit-Code (0/1/2) bzw. Nagios → der Exit-Code bestimmt den Status: 0 → OK, 1 → WARNING, 2 → CRITICAL, 3 → UNKNOWN.
- JSON-Feld → ein Wert wird per JSON-Pfad ($.usage) aus der Ausgabe gezogen. Mit Status aus = Schwelle (Zahl) wird er gegen Warn/Crit geprüft; mit Wert ist der Status wird der gelesene Wert direkt als Status interpretiert.

Voraussetzung für Collector-SSH-Scripts

Damit der Exit-Code ankommt, muss der Collector aktuell sein (ab v1.9.1). Self-Hoster-Collectoren aktualisieren sich automatisch.

Den Feldwert in der Auswertung verwenden¶

Es gibt zwei Wege, einen Feldwert tatsächlich zu nutzen.

Als Soll-Wert im Vergleich¶

In der Auswerte-Art Vergleich wählst du bei „Erwartet (aus Feld)" dein Feld. Der Server löst den Wert dann für den jeweiligen Host auf (also den pro Host gesetzten Wert) und vergleicht das Check-Ergebnis dagegen.

In Meldungen (Platzhalter)¶

Im Feld „Meldung (optional)" kannst du Platzhalter in geschweiften Klammern verwenden:

Platzhalter	Wird ersetzt durch
`{value}`	das ausgewertete Ergebnis (die Zahl bei Numerisch, der Ergebnis-Text bei Vergleich)
`{unit}`	die Einheit, falls vorhanden
`{feldname}`	der effektive Wert des Feldes `feldname` (für diesen Host)

Beispiel-Meldung:

Profil ist {value}, erwartet {erwartetes_profil}

Auf einem Host mit Soll-Wert Private und Ergebnis Public wird daraus: „Profil ist Public, erwartet Private".

Der Feld-Name muss exakt stimmen

expected_param und {platzhalter} verweisen über den technischen Feld-Namen. Ein Tippfehler (oder ein Feld, das es nicht gibt) löst zu „nichts" auf — der Vergleich schlägt dann fehl bzw. der Platzhalter bleibt stehen.

Unter der Haube: woher der „effektive" Wert kommt

Der pro Host genutzte Wert wird in dieser Reihenfolge bestimmt (später gewinnt):

Standard aus der Feld-Definition
Pro-Host-Wert aus den Service-Einstellungen
(selten) ein von einer Policy aufgelöster Wert

Eine Änderung am Pro-Host-Wert greift ab dem nächsten Check-Zyklus (in der Regel innerhalb weniger Minuten).

Durchgespielt: „Erwartetes Netzwerkprofil" pro Host¶

Das klassische Beispiel — jeder Windows-Server soll in einem bestimmten Netzwerkprofil laufen, und welches, ist pro Host verschieden.

1. Im Profil-Check definieren (Editor → Erweitert):

Feld anlegen: Name erwartetes_profil, Typ Auswahl, Optionen Public, Private, DomainAuthenticated, Geltung Pro Host, Standard Private.
Auswertung auf Vergleich stellen: Vergleich ist gleich, Erwartet (aus Feld) = erwartetes_profil, Bei Treffer = OK, Sonst = CRITICAL, Meldung Profil ist {value}, erwartet {erwartetes_profil}.

2. Pro Host den Soll-Wert setzen (Host-Detail → Service bearbeiten → Pro-Host-Einstellungen):

Host	„Erwartetes Profil"
Server A	`Public`
Server B	(nichts → Standard `Private`)

3. Was Vesana daraus macht — der Check (z. B. ein Agent-Script) liefert das tatsächliche Profil zurück, der Server vergleicht:

Host	Ergebnis	erwartet	Status	Meldung
Server A	`Public`	`Public`	OK	„Profil ist Public, erwartet Public"
Server B	`Public`	`Private`	CRITICAL	„Profil ist Public, erwartet Private"

Ein Check-Typ, zwei verschiedene Soll-Zustände — ohne Duplikate.

Gut zu wissen¶

Eingebaut = Edge entscheidet. Ohne Auswerte-Vertrag kommt der Status direkt vom Agent/Collector. Erst ein Vertrag (Numerisch/Vergleich/Script-Ausgabe) verlagert die Status-Logik auf den Server.
Unvollständige Verträge werden abgelehnt. Numerisch braucht mindestens Warnung oder Kritisch; Vergleich braucht ein erwartetes Feld oder einen festen Wert — sonst zeigt der Editor beim Speichern einen Fehler.
Secrets bleiben lokal. Passwort-Felder und Pro-Host-Werte wandern nicht mit, wenn du einen Host als Profil speicherst oder ein Profil exportierst — geteilt werden nur die Definitionen.
Robust by design. Kann der Server einen Vertrag nicht anwenden (z. B. kaputtes JSON), wird der Check UNKNOWN statt eines Absturzes.