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 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 Hub-Profil „Synology NAS“ 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). 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. Proxmox VE, Sonos) 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, bleibt der Check ehrlich 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 — siehe Proxmox für ein Beispiel.

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. 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. 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
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)

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.

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
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) — nur bei einer EINZELNEN OID, nicht beim Tabellen-Walk
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:

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.

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). Diese drei Felder befüllt nur ein Profil-Import — bestehende Checks ohne Bitmaske verhalten sich unverändert.

snmp_oid — SNMP-Zustand / Einzelwert (OID)

Erzeugt vom SNMP-Sensor-Picker (Discovery-Walk → „Als Check übernehmen"). 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 werden in diesem Modus ignoriert.

Die Zuordnung Zahl → Klartext (value_labels) kommt über den Profil-Import mit.

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) und Zeilen-Indizes überspringen (ignore_indexes). 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_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).

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 oder ein Sofort-Check 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.

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

Ein eigenes Kommando (command) über SSH ausführen. 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).

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_eventlog — Eventlog

Windows-Eventlog bzw. Linux-Journal (journald) filtern und zählen — Protokoll, Level, Zeitfenster, Event-IDs (nur Windows), Quellen bzw. systemd-Units. Der Messwert ist die Anzahl Einträge im Fenster; Schwellwerte 1 / 5 (Vorgabe), Intervall 5 min.

agent_containers — Container (Docker)

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

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: NSCA & Nagios-Migration.

Spezial

nsca_passive

Pakete vom NSCA-Empfänger landen als virtuelle Checks in der Pipeline. Detail: NSCA-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 oder Laufzeit seit dem letzten Start. Bisher nur am Profil einstellbar, lässt sie sich jetzt auch am einzelnen Check eines Geräts umstellen — praktisch, wenn nur dieses eine Gerät die umgekehrte Richtung braucht.
  • 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. Es braucht das Recht „Checks neu einplanen" (Operator und Admin haben es, Viewer nicht — ab v1.9.437). Checks, deren Status aus der Check-Logik kommt (Interface-/Port-Status), behalten ihn dabei; geänderte Schwellwerte wirken sofort.

Was genau passiert, hängt vom Ausführungsort ab:

  • Active-Checker (check_mode='active'): misst synchron und zeigt das Ergebnis sofort.
  • Agent- oder Collector-Check: „Jetzt prüfen" führt NICHT auf dem Server aus, was eigentlich Agent oder Collector ausführen — ein Agent-Check gibt es auf dem Server gar nicht, ein passives Ziel im Kundennetz erreicht der Server ohnehin nicht. Stattdessen geht der Auftrag an den Agent bzw. Collector (Abholung binnen rund 60 s); der Check bleibt so lange auf PENDING („Wartet auf Daten", blau) stehen, bis das ECHTE Ergebnis eintrifft.

Bis das erste Ergebnis eintrifft, zeigt auch ein frisch angelegter Check den Status PENDING — kein Fehler, nur „noch keine Daten da". Das gilt jetzt zuverlässig: ein neuer Agent- oder Collector-Check kippt nicht mehr nach wenigen Sekunden auf ein UNKNOWN, das vom Server selbst stammte, weil der es nicht ausführen konnte.

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
Werttyp gauge / counter / status / info / duration — info heißt reine Statistik, alarmiert nie
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-Batteriespannung? snmp mit OID aus der UPS-MIB
VPN-Tunnel überwacht? snmp_row_watch (über passendes Geräteprofil)
Werte aus einer REST-API (z. B. Proxmox)? http_json mit value_path
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)
Bandbreite der Internetleitung? internet_line

Anschluss