Zum Inhalt

Check-Typen-Referenz

Diese Seite ist die Referenz aller Check-Typen, die Vesana kennt — sortiert danach, wer sie ausführt.

Jeder Check läuft in genau einem von drei Modi: passiv (Collector im Kundennetz), agent (Agent auf der Zielmaschine) oder aktiv (der Vesana-Server prüft selbst — Aktiver Collector, in der Oberfläche „Active-Checker"). Ein Netzwerk-Check liefert überall dasselbe Ergebnis — nur wer ihn ausführt, ändert sich. Ein passiver Check auf einem Host ohne Collector wird automatisch auf den aktiven Modus umgelegt, statt unausführbar zu bleiben.

Für jeden Check-Typ gibt es genau einen Feldsatz — „Check hinzufügen", der Profil-Editor und „Check bearbeiten" zeigen dieselben Felder. Was dort nicht steht, liest die Ausführung auch nicht. Das Feld Ziel erscheint nur bei Typen, die es lesen (HTTP-Checks bringen ihr Ziel als URL selbst mit).

Server-Prüfungen bleiben draußen

Checks, die der Vesana-Server selbst ausführt, erreichen keine Server-internen Adressen (Loopback, Docker-Netze, eigene Interface-Adressen) — außer der Check wurde von einem Super-Admin gespeichert. Ein Ziel im Server-Netz weist Vesana schon beim Speichern ab, nicht erst beim Lauf. Ein eigener Collector im Kundennetz prüft sein Netz uneingeschränkt (ab v1.9.437). Details: Aktiver Collector.

Wie ein Check seinen Status bildet

Jeder Typ urteilt auf eine von vier Arten. Danach richtet sich, ob die Felder Schwellwert Warning/Critical überhaupt bedienbar sind:

Urteil Bedeutung Schwellwert-Felder
Schwellwerte Der Check liefert eine Zahl; Warning/Critical entscheiden. sichtbar, wirksam
Urteilt selbst Der Check kennt seinen Status (Port offen/zu, Dienst aktiv/inaktiv). Es gibt keine verwertbare Zahl. ausgeblendet — sie hätten keine Wirkung
Urteilt selbst + Messwert Kommando- und Script-Checks: der Check setzt den Status selbst und liefert eine Zahl. Die Schwellwerte greifen zusätzlich auf den Messwert und können den Status nur verschärfen, nie entschärfen. sichtbar; gesperrt mit Grund, solange das Script keinen Zahlwert liefert
Eigene Grenzen in der Konfiguration SSL-Zertifikat (Tage bis Ablauf) und Internetlinie (Prozent vom Soll) tragen ihre Grenzen in typ-eigenen Feldern. gesperrt — die allgemeinen Schwellwerte würden hier Dauer-CRITICAL erzeugen

In der Check-Ansicht und in der Konfiguration steht das Urteil als ein Satz im Block „Urteil über Schwellwerte", direkt bei dem, was gemessen wird: 71 % ≥ 50 % ⇒ WARNING · Warnung ab 50 % · Kritisch ab 80 % — aus dem Profil „Generic Linux Server". Die Meldung des Checks trägt dieselbe Begründung, sobald der Schwellwert den Status erklärt — auch wenn Agent oder Collector den Status schon selbst gesetzt haben.

Netzwerk-Checks

Katalog-Bereinigung (v1.9.449)

Einige Typen erscheinen nicht mehr unter „Einzelne Checks“, laufen aber für bestehende Checks unverändert weiter und bleiben im Editor bearbeitbar: vsphere (Legacy, ersetzt durch api_script), snmp_storage (legt der Geräte-Scan an; von Hand deckt snmp mit Bezugs-OID dasselbe ab), snmp_disk_status/snmp_disk_temp (feste Synology-OIDs — das Profil „Synology NAS“ der Vesana-Bibliothek liest die Platten per Walk) und ssh_command (identisch mit ssh_custom).

Laufen über den Collector (passiv) oder den Aktiven Collector (aktiv). Kein Agent nötig.

ping — Ping

ICMP-Ping zum Gerät: Erreichbarkeit und Antwortzeit (ms). Je Lauf gehen drei Pakete raus: kommt keine Antwort, ist der Check CRITICAL; geht nur ein Teil verloren, ist er WARNING mit dem Verlust in Prozent. Die Meldung nennt immer das Ziel und n/m replies, die Details zeigen min/avg/max und Verlust. Der Messwert ist die Antwortzeit; Schwellwerte Warning 100 ms / Critical 500 ms (Vorgabe). Läuft auch im Agent-Modus — dann pingt der Agent das Feld Ziel (nur im Agent-Modus) (target) von der Maschine aus.

port — Port-Check

Prüft, ob ein TCP-Port erreichbar ist. Feld Port (port). Urteilt selbst.

Feld Erwartung (expect): Port muss erreichbar sein (Vorgabe, offen = OK) oder Port muss geschlossen sein — dann ist ein offener Port CRITICAL. Für Dienste, die absichtlich abgeschaltet sind (z. B. SSH an einem NAS): der geschlossene Port ist dort der gewollte Zustand, nicht die Ausnahme.

http — HTTP/HTTPS

Aufruf einer URL (url) mit Status-Code-Prüfung. Der Messwert ist die Antwortzeit (ms), Schwellwerte 1000 / 5000 ms (Vorgabe). {host} in der URL wird durch die Adresse des Geräts ersetzt.

Die Meldung nennt immer, was geprüft wurde: GET https://example.com → HTTP 200 in 12 ms (expected 2xx/3xx). Die Erwartung ist einstellbar (ab v1.9.449):

Feld Wirkung
Erwarteter Status-Code (expected_status) Leer: 2xx/3xx sind OK, 4xx WARNING, 5xx CRITICAL. Gesetzt (200, 200-299, 2xx, 200,204, 401, any): nur die genannten Codes sind OK, alles andere CRITICAL. Eine Seite, die Anonyme mit 403 abweist, prüft man mit 403.
Antwort muss enthalten (content_match, Regex) Fehlt das Muster im Antwort-Rumpf, ist der Check CRITICAL — auch bei HTTP 200 („irgendwas antwortet“ ist nicht „die Anwendung läuft“).
Methode (method) GET (Standard) oder HEAD (kein Rumpf, keine Inhaltsprüfung).
Weiterleitungen nicht folgen (no_redirects) Dann zählt die 3xx-Antwort selbst; sonst wird bis zu 10-mal gefolgt.
TLS-Zertifikat nicht prüfen (tls_skip_verify), Zeitlimit (timeout, Standard 10 s) für selbstsignierte Geräte-Oberflächen bzw. langsame Endpunkte.

Die Check-Details zeigen URL, finale URL nach Weiterleitungen, Status-Code, Erwartung, Antwortzeit, Server- und Content-Type-Header, Größe, bei HTTPS die Restlaufzeit des Zertifikats und das Ergebnis der Inhaltsprüfung.

http_json — HTTP-API (JSON/Text)

Ruft eine URL auf und zieht einen skalaren Wert aus der Antwort. Kommt in der Regel über Geräteprofile mit vorbelegter Konfiguration (z. B. Sonos, OPNsense) und ist im freien Katalog nicht wählbar; bearbeiten lässt er sich wie jeder andere Check.

Feld Schlüssel Bedeutung
URL url {host} wird durch die Adresse des Geräts ersetzt, {host_hostname} durch seinen Hostnamen
Methode method GET (Vorgabe) oder POST
Anmeldung auth leer (Vorgabe) oder device_api — meldet sich mit Benutzer + Passwort aus dem Geräte-API-Zugang des Hosts per HTTP-Basic an (z. B. OPNsense, TrueNAS, UniFi: Schlüssel + Geheimnis statt Token-Header). Fehlt das Konto am Gerät, meldet der Check UNKNOWN statt eines 401, das nach Geräte-Störung aussieht
Wert-Pfad (JSON) value_path Pfad auf den Messwert (Schreibweise unten)
Wert-Muster (Regex) value_regex Alternative zum JSON-Pfad für Text-/XML-Antworten; die erste Klammer-Gruppe ist der Wert
Mehrere Treffer verdichten value_regex_aggregate erster Treffer (Vorgabe), Anzahl Treffer, Summe, Maximum, Minimum, Durchschnitt
Teiler-Pfad (JSON) divisor_path Wert ÷ diesem Wert — z. B. belegt ÷ gesamt
Skalierungsfaktor value_scale Faktor auf den Wert
Einheit · Beschriftung unit · label Anzeige
Antwort muss enthalten content_match Fehlt der Text in der Antwort, ist der Check CRITICAL — prüft, ob wirklich das erwartete Gerät antwortet
TLS-Zertifikat nicht prüfen tls_skip_verify für selbstsignierte interne Endpunkte
Anfrage-Rumpf body nur bei POST

Zugangsdaten wie ein API-Token oder das Geräte-API-Konto hängen am Host, nicht am Check. Sie gehen nur an die eigene Adresse des Geräts (IP, DNS-Name, {host}); zeigt die URL auf ein anderes Ziel, meldet der Check UNKNOWN mit Begründung, statt die Zugangsdaten dorthin zu schicken. Eine Weiterleitung auf einen anderen Server nimmt sie ebenfalls nicht mit.

Antwortet das Gerät mit einem Fehler (ab HTTP 400), nennt die Meldung, was das Gerät dazu sagt (Statuszeile bzw. message/error/detail aus dem JSON-Rumpf), nicht nur den Code. Antworten über 1 MiB werden gekappt; der Check meldet dann UNKNOWN mit Klartext statt eines falschen Werts.

Nur skalare Werte

Ein numerischer Treffer wird zum Messwert (Graph, Schwellwerte); ein Text-Treffer landet in der Meldung und kann über einen Vergleich mit einem Erwartungswert beurteilt werden. Objekte und Listen werden nicht unterstützt — außer als Anzahl (#, siehe unten).

Mehrere Treffer verdichten — was „Anzahl Treffer" von den übrigen Formen unterscheidet

Anzahl Treffer zählt, wie oft das Muster in der Antwort auftaucht — ohne Treffer ist der Messwert 0, nicht UNKNOWN: „kein Treffer" ist hier die Aussage (z. B. wie viele Dienste "running":0 melden). Summe / Maximum / Minimum / Durchschnitt werten dagegen die gefundenen ZAHLEN aus und brauchen mindestens eine — kein numerischer Treffer bleibt UNKNOWN.

Schreibweise von value_path

Kein volles JSONPath, sondern eine kleine, vorhersagbare Auswahl:

Schreibweise Bedeutung
a.b Feld in einem Objekt
a.0 / a[0] Element einer Liste (negative Indizes zählen von hinten)
a[k=v] Liste filtern: nur Elemente, deren Feld k gleich v ist
a[k!=v] dasselbe verneint
a[k^v] Feld k ist Text und beginnt mit v
a[k!^v] dasselbe verneint
a# Anzahl der Elemente (bzw. Länge von Objekt/Text)

Filter lassen sich aneinanderreihen, sie gelten dann alle gleichzeitig (UND). So werden aus einer Liste zählbare Werte:

data[type=qemu][status=running]#                            # laufende VMs
data[type=vzdump][saved=1][status!=OK][status!^WARNINGS]#   # fehlgeschlagene Backups

Präfix statt Gleichheit, wenn der Text eine Zahl enthält

Proxmox schreibt in status entweder OK, einen Fehlertext oder WARNINGS: 3 — mit der Anzahl im Text. Auf Gleichheit ist so ein Wert nicht zu greifen; [status^WARNINGS] trifft ihn unabhängig von der Zahl.

ssl_certificate — SSL-Zertifikat

Prüft ein TLS-Zertifikat und überwacht seinen Ablauf. Läuft passiv, aktiv oder über den Agent. Vorgabe-Intervall 6 Stunden.

Feld Schlüssel Vorgabe Bedeutung
Hostname / Domain hostname – Name, auf den das Zertifikat ausgestellt ist — wird verbunden und geprüft (SNI). Leer = DNS-Name bzw. IP des Geräts
Port port 443
Verbindungsziel (optional) connect_to – nur, wenn die Verbindung zu einer anderen Adresse aufgebaut werden soll; geprüft wird weiter gegen den Hostnamen
WARNING ab Restlaufzeit unter (Tage) warn_days 30
CRITICAL ab Restlaufzeit unter (Tage) crit_days 14
Selbstsignierte Zertifikate erlauben allow_self_signed aus kein Alarm bei selbstsigniertem Zertifikat oder Namens-/Ketten-Abweichung; der Ablauf wird trotzdem überwacht
OCSP-Sperrprüfung check_ocsp aus zusätzlich beim Aussteller prüfen, ob das Zertifikat widerrufen wurde
Zeitlimit (Sekunden) timeout – unter „Erweitert"

Die Grenzen stehen in den Tage-Feldern

Der Messwert ist die Restlaufzeit in Tagen. Die allgemeinen Schwellwert-Felder sind bei diesem Typ gesperrt — auch per API, Sammel-Bearbeiten oder Profil-Import gesetzte Werte erreichen die Ausführung nicht. Vorher erzeugten sie Dauer-CRITICAL.

internet_line — Internetlinie (Speedtest)

Down-/Upload gegen die gebuchte Bandbreite, Ping unter Last, Paketverlust, öffentliche IP. Eigene Seite: Internetlinien überwachen. Auch hier gilt: Grenzen (WARNING/CRITICAL unter % vom Soll) leben in den eigenen Feldern, die allgemeinen Schwellwerte sind gesperrt.

vsphere — VMware ESXi (API) (Legacy)

Liest einen ESXi-Host über die vSphere-API — CPU, Speicher, Datastores, VMs, Uplinks, Hardware-Zustand; braucht keinen Shell-Zugang, ein Konto mit der Rolle „Read-only" genügt. Bleibt für bestehende ESXi-Profile stehen und wird weiter ausgeführt. Bei Vollster Datastore wird ein Datastore mit einem Eintrag unter Eigene Grenzen je Datastore (Name:warn:crit, % und Dezimalkomma erlaubt) nach diesen Grenzen beurteilt, alle übrigen nach den Schwellwerten des Checks; ein Eintrag ohne lesbare Grenze stellt den Datastore nicht frei, die allgemeinen Grenzen gelten und die Meldung nennt den Eintrag. Eine abgelehnte Anmeldung wird wie bei SSH 15 → 30 → 60 Minuten lang nicht wiederholt. Für neue ESXi-Checks gilt api_script (siehe unten) — derselbe Weg über die API, aber als Script in der Bibliothek statt als fest verdrahteter Go-Typ, damit man den Rumpf selbst lesen und anpassen kann.

api_script — Script (API)

Ein editierbares Script aus der Script-Bibliothek, das der Collector lokal ausführt und das sich selbst an einer Geräte-API anmeldet — für Geräte mit API, aber ohne (nutzbare) Shell. So arbeiten die Profile für ESXi, Proxmox VE und Proxmox Backup Server. Typisches Beispiel: ESXi — ein Monitoring-Konto mit der Rolle „Read-only" darf sich zwar per API anmelden, aber nicht in die Shell (die ESXi-Zugriffsrechte hängen an der Rolle, nicht an einem „Shell access"-Häkchen). ssh_script scheidet damit aus (der Rumpf liefe AUF dem Zielgerät, das genau diese Shell nicht hergibt); agent_script scheidet aus, weil das Gerät keinen Agent tragen kann (Appliance). api_script schließt die Lücke: der Collector führt den Rumpf bei sich aus, der Rumpf spricht selbst mit der Geräte-API.

Der Rumpf greift die API selbst per HTTP(S) an (bei ESXi über SOAP); Ziel und Zugangsdaten kommen als Umgebungsvariablen an:

Umgebungsvariable Herkunft
VESANA_TARGET Adresse des Geräts
VESANA_API_USER / VESANA_API_PASSWORD Geräte-API-Konto des Hosts; ohne eigenes API-Konto greifen ersatzweise die SSH-Zugangsdaten des Hosts. Beides geht nur an die eigene Adresse des Geräts — ist am Check ein abweichendes Ziel eingetragen, meldet der Check UNKNOWN mit Begründung
VESANA_API_PORT Feld API-Port (port, Vorgabe 443)
VESANA_API_INSECURE Feld TLS-Zertifikat nicht prüfen (tls_skip_verify) — für Appliances mit selbstsigniertem Zertifikat (ESXi ab Werk)

Dazu kommen die einstellbaren Werte des Scripts als VESANA_<NAME>. Das Script sieht sonst keine Umgebung des Collectors; seine Ausgabe ist auf 1 MiB begrenzt. Auswertung und Werte-Extraktion laufen über denselben Vertrag wie bei den Kommando-/Script-Checks — siehe Auswertung bei Kommando- und Script-Checks. Intervall-Vorgabe 5 min.

ESXi über die vSphere-API: Ein Script misst je Check eine Messgröße (CPU, Speicher, vollster Datastore, nicht erreichbare Datastores, laufende/nicht laufende VMs, Laufzeit, Verbindungszustand/Wartungsmodus, Uplinks ohne Verbindung, Hardware-Sensoren, Gesamtzustand, Neustart erforderlich). Die passenden Stellschrauben erscheinen nur bei ihrer Messgröße: VMs bzw. Datastores bzw. Uplinks bzw. Sensoren ausnehmen, Laufzeit in Tagen oder Stunden, Wartungsmodus als OK/WARNING/CRITICAL, kleine Datastores überspringen und Per-datastore limits (NAME:warn:crit; die Felder des Scripts sind englisch beschriftet). Ein Datastore mit eigener Grenze wird nach dieser beurteilt; der Messwert ist der vollste Datastore ohne eigene Grenze, und die Meldung nennt zusätzlich den insgesamt vollsten samt seinen Grenzen.

SNMP-Checks

Was der Wert BEDEUTET, steht an einer Stelle

snmp, snmp_oid und snmp_string haben in der Konfiguration den Block Interpretation: Zuordnung eines Zustandswerts (Wert → Bezeichnung → Status), Umrechnung eines Messwerts (Faktor, Versatz, Einheit, Darstellung) und Bewertung eines Texts — mit Vorschau und OID-Katalog. Die Felder unten in diesem Abschnitt sind der technische Unterbau dazu. Bedienung, Beispiele und Fehlerbilder: SNMP-Interpretation.

Voraussetzung: Host mit IP-Adresse und SNMP-Zugangsdaten. Alle SNMP-Typen haben unter „Erweitert" das Feld Community (abweichend) (community) — nur ausfüllen, wenn genau dieser Check eine andere Community braucht als das Gerät.

snmp, snmp_oid und snmp_string haben zusätzlich das Feld Darstellung des Werts (value_format) — rechnet den rohen Zahlwert für die MELDUNG um, der Messwert selbst (und damit die Schwellwerte) bleibt unverändert:

Wert Bedeutung
Zahl wie gemessen (Vorgabe) keine Umrechnung
Zeitdauer aus Timeticks duration_ticks — Timeticks (1/100 s, z. B. sysUpTime) werden zu Sekunden; „17993930" wird „2d 1h 58m". Alt-Schreibweise unit: ticks gilt weiter
Zeitdauer aus Sekunden duration_s — Messwert bleibt Sekunden, Meldung als Dauer
Bytes lesbar (KB/MB/GB) bytes — Messwert bleibt Bytes (Schwellwerte gelten in Bytes)
SI-Vorsatz vor der Einheit si — k/M/G/T vor der Einheit, 1000000000 bit/s wird „1.0 Gbit/s"

Jede gewalkte Zeile unter „Details" sichtbar

SNMP-Checks, die eine Tabellen-Spalte abfragen (snmp mit walk_oid, snmp_row_watch), zeigen im Status-Panel unter „Details" jede Zeile mit Bezeichnung und Wert (bis zu 50, darüber steht die Anzahl der weiteren Zeilen). Bei Verdichtung Maximum/Minimum ist die Zeile markiert, die den Status bestimmt hat.

snmp — SNMP-Abfrage

Eine einzelne OID oder eine ganze Tabellen-Spalte abfragen und zu einem Zahlwert verdichten. Schwellwerte entscheiden.

Feld Schlüssel Bedeutung
OID oid eine einzelne OID
Ausweich-OID fallback_oid antwortet die OID oben mit „nicht vorhanden" (noSuchObject/noSuchInstance/endOfMibView), liest der Check diese OID — Meldung/Details nennen dann die Ausweich-OID als Quelle. Nur für die einzelne OID, nicht beim Tabellen-Walk. Details: SNMP-Interpretation.
Tabellen-Spalte (Walk-OID) walk_oid statt einer OID eine ganze Spalte lesen und zu einem Wert verdichten
Verdichtung aggregate Maximum (Vorgabe), Minimum, Durchschnitt, Summe, Anzahl Zeilen
Einheit · Skalierungsfaktor · Versatz unit · scale · offset Anzeige bzw. z. B. 0.001 für mW → W; Versatz wirkt NACH dem Faktor (Kelvin → °C: −273.15). Beim Tabellen-Walk wirkt der Versatz bei Maximum/Minimum/Durchschnitt je Zeile, bei Summe nicht; bei Prozent (Bezugs-OID/-Spalte) und „Anzahl Zeilen“ wirken Faktor, Versatz und Darstellung gar nicht — der Editor blendet sie dann aus und sagt warum
Darstellung des Werts value_format siehe oben — bei Tabellen-Walk nicht bei Verdichtung „Anzahl Zeilen" und nicht, wenn eine Bezugs-Spalte (Prozent) gesetzt ist

Unter „Erweitert" der Rest des Walk-Vertrags, der die guten Geräteprofile ausmacht. Die Felder, die nur für eine Tabellen-Spalte gelten, erscheinen erst, wenn eine Walk-OID eingetragen ist:

Feld Schlüssel Bedeutung
Bezugs-Spalte (Walk-OID) · Bezugs-OID (einzeln) total_walk_oid · total_oid zweite Größe als Bezug — der Wert wird dann Prozent (Wert ÷ Bezug × 100)
Bezug umdrehen (frei statt belegt) invert rechnet 100 − Prozent, für Spalten, die den freien Anteil melden
Zeilen bis zu diesem Wert überspringen skip_below für Tabellen, die −1 oder 0 melden, wenn ein Sensor fehlt
Namens-Spalte (OID) label_column_oid Klartext-Namen der Zeilen — Voraussetzung für Filtern und Beschriften
Namen ausschließen (enthält) label_exclude Zeilen, deren Name einen der Begriffe enthält, fliegen raus
Nur diesen Namen überwachen label_match genau diese Zeile beobachten; fehlt sie, ist das CRITICAL, nicht UNKNOWN
Gleichnamige Zeilen zusammenfassen distinct_label

snmp_string — SNMP-Text

OID als Text lesen und gegen einen erwarteten Wert prüfen. Urteilt selbst; ist der Text eine reine Zahl, wird sie zusätzlich als Messwert geführt (dann greifen auch Schwellwerte). Braucht ein selbst gesetztes Regex-Muster zu lange, meldet der Check UNKNOWN mit Klartext statt eines falschen Urteils.

Feld Schlüssel Bedeutung
OID oid
Erwarteter Wert match_value
Erwarteten Wert als Regex behandeln is_regex ohne Haken muss der Text exakt übereinstimmen
CRITICAL, wenn er zutrifft fail_if_match dreht die Logik um: Treffer = Fehler
Status je Wert / Bezeichnung je Wert value_map / value_labels Zahlwert → Status bzw. → Klartext für die Meldung; ein Wert ohne Zuordnung ist Status ohne Zuordnung (unmapped_status, Vorgabe WARNING), nie still OK
Einheit · Skalierungsfaktor · Versatz · Darstellung des Werts unit · scale · offset · value_format für Zahlwerte — Darstellung siehe oben

Bitmasken auswerten

Für OCTET-STRING-Bitmasken (z. B. hrPrinterDetectedErrorState) trägt der Check pro gesetztem Bit Klartext und Schwere: Bitmaske: Bit → Klartext (bit_labels), Bitmaske: Bit → Schwere (bit_severity, WARNING oder CRITICAL je Bit) und Bitmaske: Meldung ohne gesetztes Bit (bits_ok_message). Die drei Felder stehen unter „Erweitert“ und lassen sich im Formular bearbeiten; ist bit_labels gesetzt, urteilt der Check über die Bits statt über Text oder Zuordnung. Bestehende Checks ohne Bitmaske verhalten sich unverändert.

snmp_oid — SNMP-Zustand / Einzelwert (OID)

Erzeugt vom SNMP-Sensor-Picker (Discovery-Walk → „Als Check übernehmen"). Trägt wie snmp das Feld Ausweich-OID (fallback_oid, siehe oben). Verzweigt über den Wert-Typ (value_type):

  • gauge (Vorgabe): Zahlwert, Schwellwerte gelten wie bei snmp. Feld Darstellung des Werts (value_format, siehe oben) rechnet die Meldung um.
  • status: der Wert ist eine Kategorie — OK-Werte / WARNING-Werte / CRITICAL-Werte (ok_values/warn_values/crit_values) bestimmen den Status, ein nicht gelisteter Wert ist Status ohne Zuordnung (unmapped_status, Vorgabe WARNING). Die Schwellwert-Felder sind in diesem Modus gesperrt (der Messwert ist nur der Code des Zustands). Für einzelne Werte gibt es hier nur OK, WARNING und CRITICAL; UNKNOWN lässt sich nur über Status ohne Zuordnung wählen.

Die Zuordnung Zahl → Klartext (value_labels) wird im Block Interpretation gepflegt, siehe SNMP-Interpretation.

snmp_storage — SNMP-Speicher (hrStorage) (nicht mehr im Katalog)

Vom Sensor-Picker erzeugt: Auslastung eines Volumes in Prozent aus drei OIDs (OID belegt / OID Gesamtgröße / OID Blockgröße — oid_used/oid_size/oid_unit). Schwellwerte 80 / 90 % (Vorgabe), Intervall 5 min.

snmp_interface — SNMP-Interface-Status

Betriebszustand eines Interfaces (ifOperStatus) über den Interface-Index (if_index). Urteilt selbst; kommt über Profile und den Sensor-Picker.

snmp_table — SNMP-Tabellen-Abzug

Liest eine ganze SNMP-Tabelle als Momentaufnahme (Geräte-Snapshot) — Grundlage für Portkarte, NAS-Diskbay, USV- und Firewall-Panel. Feld Art des Abzugs (snapshot_type). Kommt über Profile.

snmp_table_state — Schlechtester Zustand einer Tabelle

Liest eine Status-Spalte (walk_oid) und meldet den schlechtesten Eintrag anhand von Werte, die OK/WARNING/CRITICAL bedeuten. Unter „Erweitert": Namens-Spalte, Namens-Filter (name_filter, mit Filter-Wirkung einschließen/ausschließen) Zeilen-Indizes überspringen (ignore_indexes) und Zahl → Klartext (state_labels, Bezeichnungen für Meldung und Detail-Tabelle). Kommt über Profile. Unter „Details" stehen ALLE Einträge der Tabelle, nicht nur die mit einem Problem.

snmp_row_watch — SNMP-Eintrag-Wächter

CRITICAL, wenn ein benannter Eintrag aus einer SNMP-Tabelle verschwindet — typisch: ein SonicWall-VPN-Tunnel. Standard-OIDs sind vorbelegt; du trägst nur den Namen des Eintrags (label_match, z. B. den VPN-Policy-Namen) ein. Kommt über Geräteprofile.

snmp_bandwidth — Schnittstellen-Auslastung (Bandbreite)

Wie voll ist eine Leitung? Auslastung einer Schnittstelle als Rate (Änderung der Zähler je Sekunde) in Prozent der Geschwindigkeit oder in Mbit/s, dazu Fehler und Verwerfungen je Minute. Die Schnittstelle wird über ihren Namen gewählt, nie über die Nummer. Schwellwerte entscheiden. Bedienung und Fehlermeldungen: Bandbreite und Zähler.

Feld Schlüssel Bedeutung
Schnittstellen interface_mode name (Vorgabe) = eine Schnittstelle · all = alle, die am stärksten belastete zählt
Schnittstelle interface Name, wie das Gerät ihn meldet — das Feld bietet die bekannten Namen an
Name aus match_column ifName (Vorgabe), ifDescr, ifAlias — welche Spalte den Namen trägt
Messgröße metric utilization (Vorgabe), errors oder discards (je Minute)
Richtung direction max (Vorgabe, die höhere zählt), in, out
Einheit unit_mode percent (Vorgabe) oder mbit
Bezugsbandbreite (Mbit/s) reference_mbit statt der Port-Geschwindigkeit, z. B. die gebuchte Bandbreite einer Internetleitung
Schnittstellen ausschließen · Auch ohne Verbindung · Auch virtuelle label_exclude · include_down · include_virtual nur bei all

Der erste Wert kommt nach einem Intervall (eine Rate braucht zwei Messungen). Läuft nur über einen Collector bzw. den Aktiven Collector — ohne ihn meldet der Check das im Klartext.

snmp_counter — SNMP-Zähler als Rate

Ein beliebiger Zähler (Counter32/Counter64) als Änderung je Sekunde — OID einzeln oder Tabellen-Spalte (walk_oid) mit Verdichtung (aggregate: max/min/avg/sum), Namens-Spalte, Ausschlüssen und label_match wie bei snmp. Faktor (scale) wirkt auf die Rate je Sekunde (60 = je Minute), Einheit (unit) leer = /s. Schwellwerte entscheiden. Details: Bandbreite und Zähler.

snmp_disk_status / snmp_disk_temp — Platten (SNMP) (nicht mehr im Katalog)

Status bzw. Temperaturen aller Platten per SNMP-Walk (Synology). Status urteilt selbst; Temperatur mit Schwellwerten 45 / 55 °C (Vorgabe).

SSH-Checks

Der Collector meldet sich per SSH am Gerät an und führt ein Kommando aus. Die SSH-Zugangsdaten werden am Host gepflegt; jeder SSH-Check hat unter „Erweitert" die Felder SSH-Benutzer / SSH-Passwort / SSH-Port / SSH-Ziel (abweichend) — nur ausfüllen, wenn genau dieser Check sich anders anmelden soll (etwa über ein Sprungziel im selben Netz). Die Zugangsdaten des Geräts gehen nie an ein abweichendes Ziel; dort gehört das Passwort an den Check.

Serverschlüssel: Beim ersten Kontakt merkt sich Vesana den SSH-Serverschlüssel. Ein Check mit abweichendem Ziel bekommt dafür einen eigenen Eintrag (Ziel + Port), statt den des Geräts zu überschreiben. Ändert sich der Schlüssel später, meldet der Check SSH_HOST_KEY_MISMATCH und das Status-Panel zeigt die Karte „SSH-Schlüssel hat sich geändert“ mit altem und neuem Fingerabdruck; „Neuen Schlüssel übernehmen“ (Recht hosts.edit, mit Identitätsbestätigung, steht im Audit-Log) übernimmt genau den gemeldeten Fingerabdruck.

Abgelehnte Zugangsdaten und unerreichbare Geräte

Werden die SSH-Zugangsdaten abgelehnt, merkt sich der Collector das pro Gerät und versucht 15 → 30 → 60 Minuten keinen weiteren Login — vorher liefen mehrere Fehlversuche pro Check und Intervall, was Geräte als Angriff werten (Kontosperre, Blockliste). Betroffene Checks stehen solange auf Unknown mit Klartext (Nutzer, Ziel, Ende der Pause); geänderte Zugangsdaten, ein Sofort-Check oder bei Collector-Checks der Knopf „Anmeldung jetzt erneut versuchen“ im Status-Panel heben die Pause sofort auf. Ist das Gerät per SSH gar nicht erreichbar (Verbindung abgelehnt/Timeout), ist der Check Critical, nicht Unknown (ab v1.9.437).

ssh_cpu, ssh_mem, ssh_disk — CPU, RAM, Festplatte (SSH)

Standard-Befehle für Linux-Geräte ohne Agent. Schwellwerte 80 / 95 % (CPU, RAM) bzw. 80 / 90 % (Festplatte). ssh_disk hat das Feld Mountpoint (mount, Vorgabe /).

Nicht für ESXi

ESXi lässt nur Konten mit der Rolle „Admin" in die Shell — ein Read-only-Monitoring-Konto hätte hier also Admin-Rechte gebraucht. Für ESXi gilt api_script (siehe Abschnitt „Script (API)" oben): dieselben Kennzahlen über die vSphere-API, mit einem Read-only-Konto.

ssh_process, ssh_service — Prozess, Dienst (SSH)

Prüft, ob ein Prozessname (process) läuft bzw. ein systemd-Dienstname (service) aktiv ist. Urteilen selbst. Fehlt am Gerät ein brauchbares pgrep (ESXi, BusyBox), meldet ssh_process UNKNOWN mit Klartext statt „läuft nicht“.

ssh_custom, ssh_command — Eigenes Kommando, Kommando mit Auswertung (SSH) (ssh_command nicht mehr im Katalog)

Ein eigenes Kommando (command) über SSH ausführen. Ausgewertet wird nur die Standardausgabe — wer eine Fehlerausgabe prüfen will, leitet sie mit 2>&1 um; bei leerer Ausgabe steht die Fehlerausgabe in der UNKNOWN-Meldung. Die Ausgabe ist auf 1 MiB, die Meldung auf 8192 Zeichen begrenzt. Beide lesen denselben Auswerte-Vertrag (unten: Auswertung bei Kommando- und Script-Checks).

ssh_script — Script (SSH)

Ein Script aus der Script-Bibliothek über SSH ausführen — zentral verwaltet, mit einstellbaren Werten. Ausgewertet wird nach dem am Script deklarierten Ausgabe-Format, genau wie am Agent; Python-Scripts laufen mit dem Python-Interpreter, Shell-Scripts fallen auf sh zurück, wenn das Gerät kein bash hat (ESXi, Appliances).

Agent-Checks

Voraussetzung: Agent installiert und Host Agent-verwaltet. Die reichen Typen (Festplatten, Dienste, Prozess, Eventlog, Container) haben eigene, geführte Editoren mit Vorschlägen aus dem Inventar des Hosts.

agent_cpu, agent_memory — CPU, RAM

Auslastung in %, Schwellwerte 80 / 95 (Vorgabe).

Die CPU-Auslastung ist der Durchschnitt über das ganze Prüfintervall (Differenz der CPU-Zähler zwischen zwei Läufen, unter Windows aus den Roh-Leistungsindikatoren), keine Momentaufnahme. Der erste Lauf nach einem Agent-Start liefert deshalb noch keinen Wert. Wer vor v1.9.452 Grenzen gesetzt hat: die Werte liegen seitdem spürbar niedriger, die Grenzen lohnen einen Blick.

agent_disk — Festplatten

Alle Partitionen automatisch überwachen; Schwellen als Prozent oder als freier Platz in GB, pro Laufwerk abweichende Schwellen, Laufwerke ausschließen. Ein einzelnes unlesbares Volume zieht den Check nicht auf UNKNOWN — der Status kommt aus den lesbaren Laufwerken, das unlesbare steht in der Meldung. Intervall 5 min.

agent_service — Dienst

Dienstname (service, systemd-Unit oder Windows-Dienst). OK wenn aktiv, sonst CRITICAL.

agent_services_auto — Dienste (automatisch)

Alle Dienste mit Starttyp „Automatisch" — jeder, der nicht läuft, ist CRITICAL. Ausnahmen (auch mit Wildcards) matchen Name und Anzeigename.

agent_process — Prozess

Läuft ein Prozess (Mindest-/Höchstzahl)?

agent_network, agent_disk_io, agent_temperature — Netzwerk-Durchsatz, Datenträger-Last, Temperatur

Diese drei misst der Agent nicht eigens: Vesana bildet sie aus der System-Übersicht, die der Agent ohnehin alle 30 s für den Telemetrie-Tab sendet. Im Tab und im Check steht deshalb dieselbe Zahl, und sie laufen mit jedem Agent ohne Update. Am schnellsten legt man sie im Telemetrie-Tab mit überwachen an — vorbelegt auf genau die Schnittstelle, die Platte oder den Sensor der Zeile.

Typ Feld Wert
Netzwerk-Durchsatz Schnittstelle (interface, leer = alle echten zusammen), Richtung (direction: stärkere · Empfangen · Gesendet · beide zusammen) Mbit/s; Empfangen und Gesendet als weitere Werte im Verlauf
Datenträger-Last Datenträger (device, leer = alle), Messgröße (metric: Auslastung in % oder Lesen + Schreiben in MB/s) % bzw. MB/s; Warnung ab 90 % (Vorgabe)
Temperatur Sensor (sensor, leer = der heißeste; Platten heißen „disk <Name>“) °C

Ohne eigene Grenzen urteilt bei der Temperatur das Maximum, das der Sensor selbst meldet (ab 85 % davon WARNING, am Maximum CRITICAL); gesetzte Schwellwerte verschärfen nur. Virtuelle Schnittstellen (Docker-Brücken, veth, libvirt) zählen in der Summe „alle“ nicht mit — ihr Verkehr steckt schon in der echten Karte. Das Intervall gilt: ein 60-s-Check nimmt jede zweite Übersicht, ein Statuswechsel geht sofort durch. Direkt nach einem Agent-Start fehlt der erste Wert (Raten brauchen zwei Messungen).

agent_eventlog — Eventlog

Windows-Eventlog bzw. Linux-Journal (journald) filtern und zählen — Protokoll, Level, Zeitfenster (Vorgabe 30 min), Event-IDs (nur Windows), Quellen bzw. systemd-Units, dazu Ausschlüsse nach Event-ID und Quelle und ein Muster für den Meldungstext. Ein Ausschluss entfernt nur das betroffene Ereignis. Der Messwert ist die Anzahl Einträge im Fenster; Schwellwerte 1 / 5 (Vorgabe), Intervall 5 min. Treffer-Beispiele stehen in der Zeitzone der Instanz.

agent_containers — Container (Docker)

Alle Docker-Container automatisch überwachen (Status, Health, CPU/RAM/Netz) über den Docker-Socket, nur unter Linux; Docker-Socket (abweichend) (socket) nur für rootless Docker. Intervall 2 min. Der Messwert ist die Anzahl Problem-Container. Details: Host-Detail → Docker.

Einstellung Wirkung
Stufe je Problemart unhealthy · gestoppt trotz Restart-Policy · Crashloop · Pflicht-Container gestoppt/fehlt — je aus, WARNING oder CRITICAL (Vorgabe CRITICAL)
Crashloop-Empfindlichkeit Neustarts im Zeitfenster (Vorgabe 3 in 15 min)
Einmal-Container ignorieren ein mit Exit-Code 0 beendeter Container ist kein Problem
Alle müssen laufen jeder nicht laufende Container zählt, auch ohne Restart-Policy
Auf neuere Images prüfen der Agent fragt höchstens alle 6 h die Registry, ob es für den Tag ein neueres Image gibt (nur Anzeige, Vorgabe an)
Ausnahmen einzelne Container (auch nur für eine Problemart), ganze Compose-Projekte, oder das Docker-Label vesana.ignore=true am Container
Schwellwert Warning/Critical Grenzen auf die Anzahl Problem-Container

Ohne Schwellwerte entscheidet die schlimmste Stufe der gefundenen Probleme. Ist ein Schwellwert gesetzt, entscheidet die Anzahl; die Stufen legen dann nur fest, was mitzählt (Stufe aus zählt nicht). Frühere Werte „Warn ab“/„Crit ab“ hat das Update in die Schwellwert-Felder übernommen.

agent_custom — Eigenes Kommando

Ein Kommando (command) auf der Maschine ausführen. OK-Muster (ok_pattern, Vorgabe .) — trifft es auf die Ausgabe zu, ist der Check OK; CRITICAL-Muster (crit_pattern) hat Vorrang.

agent_script — Script

Ein Script aus der Script-Bibliothek ausführen. Alternativ ein lokaler Pfad auf der Maschine oder ein Inline-Script direkt am Check — beide mit Interpreter und Ausgabe-Format am Check. Intervall 5 min (Vorgabe).

Nagios-Plugin

plugin_local — Plugin (Nagios)

Ein Nagios-kompatibles Plugin über den Aktiven Collector ausführen. Kommt über die Script-Bibliothek (Interpreter „plugin_local"); Details: Nagios-Migration.

Auswertung bei Kommando- und Script-Checks

ssh_custom, ssh_command, ssh_script, api_script, agent_custom, agent_script und plugin_local urteilen selbst und liefern einen Messwert. Bei den SSH- und API-Typen stellst du die Auswertung in Klartext ein — Regex-Kenntnisse braucht es dafür nicht:

Wann ist dieser Check in Ordnung?

Auswahl Bedeutung
Das Script entscheidet über seinen Exit-Code: 0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN. Der übliche Weg.
Anhand der Ausgabe Liest sich als Satz: Die Ausgabe muss / darf nicht · genau das sein / das enthalten · active. Trifft die Erwartung nicht zu (bzw. das Fehler-Muster zu), meldet der Check CRITICAL. Das daraus erzeugte Muster wird offen angezeigt.
Eigenes Muster für Kenner: ein Regex (match_regex) plus „Wenn das Muster zutrifft: ist der Check OK / CRITICAL" (fail_if_match). Ein vorhandenes Muster, das sich nicht als Klartext-Regel ausdrücken lässt, bleibt hier unverändert stehen.

Welche Zahl aus der Ausgabe ist der Messwert? — Die erste Zahl in der Ausgabe (Vorgabe), Die Zahl am Anfang der Ausgabe, Die Zahl nach einem bestimmten Text oder ein eigenes Muster mit Klammer-Gruppe (extract_value); dazu Einheit des Werts (value_unit). Findet der Check keine Zahl, bleibt er gültig — er hat dann nur keinen Wert, und die Schwellwert-Felder sind mit Grund gesperrt.

Was dabei gilt:

  • Entscheidet die Ausgabe den Status, sagt die Meldung warum: 0 · Muster "^0$" trifft zu statt einer nackten 0. Mehrzeilige Ausgaben werden dafür auf eine Zeile eingedampft.
  • Leere Ausgabe bleibt UNKNOWN — ohne Ausgabe lässt sich kein Ergebnis begründen.
  • Scripts aus der Bibliothek werden über SSH und am Agent nach dem am Script deklarierten Ausgabe-Format (Nagios, Text, JSON) ausgewertet; bei Nagios ist der Messwert die erste Perfdata-Metrik.
  • Ein Script kann neben dem Messwert mehrere Serien (Nagios-Perfdata oder JSON series) und ein freies details-Objekt liefern — die Serien erscheinen einzeln wählbar im Verlaufs-Graph, die Details beim Klick auf den Check. Details: Monitoring-Scripts.

Zwölf mitgelieferte Checks konnten nie rot werden

Bis v1.9.358 las der Collector die Auswerte-Regel bei SSH-Script-Checks nicht; Kommandos, die auf || echo 0 enden, meldeten immer OK — betroffen waren u. a. „Nginx service running", „Postgres service running", „WAN reachability (ICMP)" und „DNS recursion test". Seit dem Update greifen die Regeln. Nach dem Update lohnt ein Blick in die Fehlerübersicht: was jetzt rot ist, war vorher schon kaputt. Felder ohne Wirkung wurden dabei entfernt oder umbenannt („Mount-Point" bei Festplatte (SSH) maß still /; „Prozessname"/„Service-Name" bei den SSH-Checks; die Ablauf-Schwellen beim SSL-Zertifikat) — gespeicherte Werte wirken automatisch weiter.

Schwellwerte

Numerische Checks werten sich in der Regel nicht selbst aus — der Server vergleicht den ankommenden Wert gegen Warning/Critical und setzt den Status.

  • Richtung: hoch = schlecht (Vorgabe) oder niedrig = schlecht — z. B. bei freiem Speicherplatz, USV-Akkuladung und -Restlaufzeit oder Laufzeit seit dem letzten Start. Sie lässt sich am Profil und am einzelnen Check eines Geräts umstellen. Die Uptime-Checks der Profile aus der Vesana-Bibliothek tragen niedrig = schlecht: eine Grenze in Stunden meldet einen unerwarteten Neustart. Vom Geräte-Scan übernommene USV-Checks für Akkuladung und Restlaufzeit alarmieren, wenn der Wert fällt.
  • Nur Zahlen: nan/inf werden beim Speichern abgelehnt.
  • Leer heißt geerbt. Am Host-Check zeigt das Feld nur einen eigenen Wert für dieses Gerät; der Profilwert steht als Platzhalter daneben. Was du leer lässt, zieht mit, wenn das Profil aktualisiert wird. Nur was du wirklich änderst, wird für das Gerät festgehalten — das gilt für Schwellwerte wie für alle anderen Felder.
  • Wirkt beim nächsten Ergebnis, spätestens nach fünf Minuten (Server-Cache) — Agent oder Collector müssen dafür nichts neu laden. Der Server prüft jedes eingehende Ergebnis gegen die aktuell gültigen Grenzen, allerdings nur eskalierend: ein harter Fehler (Port zu, HTTP 500) wird durch einen harmlosen Zahlwert nie herabgestuft.
  • Bei Script-Checks greifen die Grenzen zusätzlich zum Urteil des Scripts und können es nur verschärfen. Grenzwerte gehören an den Check, nicht ins Script — ein number-Wert am Script ist für Zeitfenster, Mindestanzahlen und Ports gedacht (Einstellbare Werte).
  • Bestätigungen: ein erster Fehlschlag geht zunächst in PROBING — der Worker wiederholt die Bestätigung so oft wie unter „Erweitert" eingestellt (Vorgabe 1× / 10 s), bevor er den Fehler als bestätigt behandelt. Details: State-Modell.

„Jetzt prüfen" & Intervalle

„Jetzt prüfen" löst einen einzelnen Check sofort aus, unabhängig vom Intervall — praktisch beim Testen einer neuen Konfiguration. Den Knopf gibt es nur bei Checks, die der Active-Checker ausführt (check_mode='active'): er misst synchron und zeigt das Ergebnis sofort; langlaufende Checks wie der Speedtest melden „läuft“ und tragen das Ergebnis nach. Es braucht das Recht „Checks neu einplanen" (Operator und Admin haben es, Viewer nicht). Checks, deren Status aus der Check-Logik kommt (Interface-/Port-Status), behalten ihn dabei; ein harter Fehler (z. B. HTTP 500) bleibt auch mit Antwortzeit-Schwellwerten stehen.

Agent- und Collector-Checks führt der Server nie selbst aus — einen Agent-Check gibt es auf dem Server gar nicht, ein Ziel im Kundennetz erreicht er nicht. Ein frisch angelegter Check bekommt stattdessen einen Auftrag an Agent bzw. Collector (Abholung binnen rund 60 s) und steht bis zum ersten echten Ergebnis auf PENDING („Wartet auf Daten", blau) — kein Fehler, nur „noch keine Daten da".

Das Intervall lässt sich zwischen 10 Sekunden und 7 Tagen wählen; der Check-Typ ist nach dem Anlegen unveränderlich.

Gemeinsame Felder (alle Check-Typen)

Feld Bedeutung
Intervall (s) wie oft (10 s ≤ x ≤ 7 Tage)
Bestätigungen · Bestätigungs-Intervall (s) Anzahl und Abstand der Bestätigungs-Versuche im PROBING-Zustand („Erweitert")
Schwellwert Warning / Critical numerische Grenzen — nur bedienbar, wo sie wirken
Wert-Typ nur am Profil-Check: gauge / counter / status / info / duration — bestimmt, wie der Verlauf die Werte darstellt; alarmiert wird unabhängig davon
Darstellung im Verlauf Automatisch (Vorgabe), Kurve, Statusband oder Beides — reine Anzeige, am Profil-Check mit Überschreibung am Gerät; eine Uptime als Kurve zeigt einen Neustart als Sprung auf null
Info-Modus am Check eines Geräts: reine Statistik — der Check misst und zeichnet auf, alarmiert nie und zählt nicht als Problem
Als Reachability-Hint verwenden schlägt dieser Check fehl, gilt das Gerät als nicht erreichbar; Folge-Alarme werden unterdrückt (normalerweise übernimmt das der Ping)

Welcher Check-Typ für welches Problem

Problem Empfehlung
Ist das Gerät erreichbar? ping
Ist die Webseite oben? http
Läuft Apache? agent_service (mit Agent) oder ssh_service (ohne)
CPU-Last? agent_cpu
Disk läuft voll? agent_disk
Ereignisse im journald/Eventlog? agent_eventlog
Switch-Port-Status? Geräteprofil mit Portkarte (snmp_table)
USV-Akkuladung oder Restlaufzeit? snmp/snmp_oid mit OID aus der UPS-MIB (Geräte-Scan schlägt sie vor), Richtung niedrig = schlecht
VPN-Tunnel überwacht? snmp_row_watch (über passendes Geräteprofil)
Ein einzelner Wert aus einer REST-API? http_json mit value_path
Proxmox VE / Proxmox Backup Server? api_script über das Geräteprofil
Backup gestern erfolgreich? agent_script / ssh_script mit einem Script aus der Bibliothek
Eigene Logik? agent_custom / ssh_custom
ESXi-Host überwachen (ohne Shell-Zugriff)? api_script mit einem vSphere-API-Script (Read-only-Konto)
Wie voll ist eine Leitung / ein Port gerade? snmp_bandwidth
Fehler oder verworfene Pakete auf einem Port? snmp_bandwidth mit Messgröße Fehler/Verwerfungen
Ein anderer Zähler (Pakete, Anfragen) je Sekunde? snmp_counter
Bandbreite der Internetleitung? internet_line (Speedtest) oder snmp_bandwidth mit Bezugsbandbreite (Last am Router)

Anschluss