Host bleibt NO_DATA / grau¶

Ein Check zeigt dauerhaft NO_DATA (orange), oder ein ganzer Host wirkt „grau" — keiner seiner Checks bekommt neue Werte. Dieser Leitfaden führt dich vom Symptom zur Ursache, getrennt nach Monitoring-Modus.

Erster Blick: PENDING oder wirklich NO_DATA?¶

Ein frisch angelegter Check zeigt zunächst PENDING („Wartet auf Daten") — das ist der Normalzustand zwischen Anlage und erstem Ergebnis, kein Fehler, und er kippt auch nicht nach einer Weile von selbst auf No Data. Erst wenn ein Check, der schon mindestens einmal ein Ergebnis hatte, danach zu lange stumm bleibt, wird er zu NO_DATA. Details zum Unterschied: Status- und State-Modell.

Wann „zu lange" ist:

Ein Check, der zuletzt OK war, wird nach rund dem 3-fachen seines Intervalls ohne neues Ergebnis zu No Data. Agent-Checks bekommen dabei mindestens 3 Minuten — ein einzelner langsamer Lauf eines 30-Sekunden-Checks erzeugt also keinen Ausfall.
Ein Check, der schon WARNING, CRITICAL oder UNKNOWN war, bekommt mehr Toleranz: das 10-fache Intervall, mindestens 30 Minuten.
Wird das Intervall eines Checks verkürzt, zählt die Grenze ab der Änderung (seit v1.905.0; vorher konnte ein Check direkt nach der Änderung auf No Data springen).

Schritt 1 — Welcher Monitoring-Modus?¶

Auf der Host-Detail-Seite zeigt die Kopfzeile pro Monitoring-Quelle einen Chip (Agent / Collector / Active-Checker) mit Online/Offline-Status. Das ist die schnellste Antwort auf „wer sollte hier überhaupt Daten liefern". Ein Host kann mehrere Modi gleichzeitig haben (z. B. Agent und ein SNMP-Check über einen Collector).

flowchart TD
    A["Check zeigt NO_DATA"] --> B{"Welcher Modus laut Chip in der Kopfzeile?"}
    B -->|Agent| C["agent.log auf der Zielmaschine prüfen"]
    B -->|Collector / passiv| D["Ist der Collector online?"]
    B -->|Active-Checker| E["Ist ein Aktiver Collector online?"]
    C --> C1["401/403 → Token · 404 → Server-URL"]
    D --> D1["Offline → Collector-VM prüfen"]
    E --> E1["Keiner online → Ersatzweg des Servers, langsamer"]

Agent-Host¶

Zeigt der Chip „Agent" offline, oder ist er online, aber der Check bleibt trotzdem stumm — dann ist agent.log auf der Zielmaschine die erste Anlaufstelle, nicht die Vesana-Oberfläche. Ein Agent gilt nach 3 Minuten ohne Lebenszeichen als offline.

agent.log finden und lesen¶

Die Datei liegt neben der config.yaml (sofern dort kein eigenes log_file gesetzt ist):

Plattform	Pfad
Linux	`/etc/vesana-agent/agent.log` (zusätzlich im Journal: `journalctl -u vesana-agent`)
Windows	`C:\ProgramData\Vesana\Agent\agent.log`

Das Log ist Klartext, lokale Zeit, Level als Wort — kein strukturiertes Format zum Parsen nötig:

2026-07-04 10:15:03  INFO   Ergebnisse gesendet  anzahl=5

Typische Ursachen stehen als klarer Fehlertext im Log:

Log-Inhalt	Bedeutung	Fix
`Server lehnt den Agent ab — Token in config.yaml prüfen` (HTTP 401/403)	Token falsch, deaktiviert oder durch ein neues ersetzt	Aktuelles Token auf der Maschine eintragen, Dienst neu starten
`Server-Endpunkt nicht gefunden — Server-URL in config.yaml prüfen` (HTTP 404)	Server-URL falsch (Pfad/Domain stimmt nicht)	Server-URL in der Config prüfen
`Host (oder Tenant) in Vesana deaktiviert — Agent pausiert`	Host oder Tenant ist in Vesana deaktiviert	Gewollt — reaktivieren, dann arbeitet der Agent von selbst weiter. Siehe Deaktivieren, Löschen, Wiederherstellen
`dial tcp: lookup …: no such host`	DNS-Auflösung schlägt fehl	DNS-Resolver auf der Zielmaschine prüfen
`x509: certificate signed by unknown authority`	TLS-Zertifikat nicht vertrauenswürdig	Gültiges Zertifikat, Zertifikat in den System-Trust-Store oder den Fingerabdruck in `server_cert_sha256` der Config hinterlegen
`connection refused`	Server nicht erreichbar	Server-Erreichbarkeit/Port prüfen

Nicht-OK-Ergebnisse werden zusätzlich mit Klartext-Meldung geloggt — OK-Ergebnisse bleiben bewusst auf Debug-Level, damit das Log nicht flutet.

Die Zuordnung der Ergebnisse hängt am Token, nicht am Hostnamen: Jedes Agent-Token gehört genau einem Host. Ein Umbenennen des Hosts in Vesana ändert an der Zuordnung nichts.

Ist der Agent überhaupt online?¶

Der Agent schickt alle 20 Sekunden ein Lebenszeichen — das ist die Grundlage für den Online-Punkt am Chip „Agent". Änderungen an den Checks dieses Hosts holt er beim nächsten Lebenszeichen ab (aktuelle Agents); Änderungen an Profilen und anderen übergreifenden Einstellungen spätestens mit dem regulären Config-Abruf alle 5 Minuten. Schwellwert-Änderungen wirken unabhängig davon sofort, weil der Server sie auf jedes eingehende Ergebnis anwendet.

Unveränderte OK-Ergebnisse schickt ein Agent gesammelt (höchstens 30 Sekunden verzögert); Statuswechsel und Nicht-OK-Ergebnisse gehen weiterhin im 5-Sekunden-Takt raus.

Direkt nach einer Änderung, statt auf den nächsten Zyklus zu warten:

vesana-agent test

Führt alle vom Server konfigurierten Checks einmal aus, zeigt jedes Ergebnis live und schickt den Batch — bestätigt in einem Schritt, ob die Konfiguration angekommen ist und ob der Check sinnvolle Werte liefert.

Nach einem Ausfall¶

Rückstau: Nach einer Verbindungsunterbrechung schicken Agents zuerst die frischen Ergebnisse und liefern den zwischengespeicherten Rückstau gedrosselt nach (seit v1.901.0). Vorher konnte ein Agent nach einem langen Ausfall bis zu einer halben Stunde lang als „online, aber alle Checks überfällig" erscheinen. Nachgelieferte Ergebnisse erscheinen im Verlauf zu ihrer Messzeit, ändern aber den aktuellen Status nicht.
Kurze Pause: War ein Agent zwischen drei und fünf Minuten still, blieben seine Checks bis v1.904 auf „Agent offline", bis sie das nächste Mal regulär liefen. Seit v1.905.0 lässt ein zurückkehrender Agent alle als offline markierten Checks sofort neu laufen.
Lange Intervalle: Kehrt ein Host zurück, laufen alle seine Checks sofort (seit v1.9.446); „Jetzt erheben" am Host misst ebenfalls den ganzen Host — für Agent-, Collector- und Active-Checker-Hosts.

Windows-Agent meldet sich nach einem Update nicht mehr¶

Bis v1.9.443 blieb der Windows-Dienst nach jedem Selbst-Update gestoppt: der Agent ersetzte sein Programm, beendete sich sauber — und startete nicht wieder.

Sofort-Abhilfe auf der Maschine: Start-Service VesanaAgent (oder sc start VesanaAgent). Das Programm ist in Ordnung, es fehlte nur der Neustart.
Behoben ab v1.9.444, seit v1.9.445 mit zwei unabhängigen Wegen zurück: einer einmaligen Aufgabe im Windows-Aufgabenplaner und — falls die nicht zustande kommt — der Wiederherstellung des Windows-Dienstmanagers, die bei jedem Dienststart nachgezogen wird.
Der Übergang selbst läuft noch mit dem alten Programm: ein Agent unterhalb v1.9.444 bleibt beim Update auf v1.9.444 ein letztes Mal stehen und braucht einmalig ein Start-Service. Danach kommt er von allein zurück.
Protokoll des Neustarts: restart-helper.log neben agent.log.

Linux-Agents gelten nach einem Wechsel der Internet-Adresse als offline¶

Wechselt die öffentliche Adresse des Standorts (nächtliche Zwangstrennung, CGNAT, Mobilfunk), galten Linux-Agents und -Collectors bis v1.9.447 bis zu 15 Minuten als offline, obwohl sie liefen. Ab v1.9.448 ist der Ausfall auf Sekunden begrenzt.

Erkennungsmerkmal: die Lücke beginnt reproduzierbar zur selben Uhrzeit (dem Zeitpunkt der Zwangstrennung) und trifft alle Linux-Agents desselben Standorts gleichzeitig.

Token neu erzeugt?¶

Wurde auf der Host-Seite ein neues Agent-Token erzeugt, läuft die Zielmaschine aber noch mit dem alten — dann lehnt der Server den Agent ab (Log: „Server lehnt den Agent ab"). Das alte Token ist ab dem Moment der Neu-Erzeugung ungültig. Fix: neues Token in die Config eintragen, Dienst neu starten.

Vollständige Installations- und Token-Details: Agent (Linux/Windows).

Collector-Host (passiv)¶

Zeigt der Chip „Collector" offline, ist das meist der ganze Grund — alle Checks, die über diesen Collector laufen, bleiben dann stumm, nicht nur einer. Ein Collector gilt nach 3 Minuten ohne Lebenszeichen als offline; Vesana meldet das als eine Meldung „Collector offline" statt einer pro Host.

Collector aktuell online? Auf der Collector-VM: journalctl -u vesana-collector --since '5 minutes ago'.
Host diesem Collector zugewiesen? Ein Host ohne zugewiesenen Collector bekommt keine passiven Checks.
Config-Abruf abgewartet? Der Collector holt seine Check-Liste alle 60 Sekunden.
SNMP-spezifisch: schlägt nur ein SNMP-Check fehl, während der Collector selbst online ist, teste die Community direkt von der Collector-VM aus (snmpwalk -v 2c -c <community> <ziel-ip> .1.3.6.1.2.1.1.1.0) — scheitert das schon, liegt es an Netzwerk/Community, nicht am Collector.

Nach einem Collector-Ausfall (auch nach einer angehaltenen VM) führt der Collector beim ersten Kontakt alle Checks seiner Geräte sofort aus (seit v1.901.0) — Checks mit langem Intervall bleiben nicht mehr bis zu ihrem nächsten Takt auf „Keine Daten: Collector offline".

Details: Collector, Collector überlastet — was tun.

SSH-Checks stehen auf Unknown: „Zugangsdaten abgelehnt"¶

Lehnt ein Gerät die SSH-Zugangsdaten ab, merkt sich Vesana das pro Ziel (Adresse, Port, Benutzer) und versucht 15 → 30 → 60 Minuten keinen weiteren Login. Alle SSH-Checks dieses Ziels melden solange UNKNOWN mit Klartext (Benutzer, Ziel, Ende der Pause) — ohne dass eine einzige Verbindung aufgebaut wird.

Das ist Absicht: vorher liefen pro Check und Intervall bis zu sechs Fehlversuche. Für das Zielgerät sieht das aus wie ein Angriff — ESXi sperrt das Konto nach fünf Fehlversuchen, andere Geräte setzen die Adresse auf eine Blockliste.

Die Pause endet sofort bei:

geänderten Zugangsdaten am Host oder im Zugangsdaten-Set,
„Jetzt prüfen" bzw. „Jetzt erheben" am Host,
dem ersten erfolgreichen Login.

Bei passiven Checks gibt es kein „Jetzt prüfen" — dort steht im Status-Panel der Knopf „Anmeldung jetzt erneut versuchen"; der Collector prüft dann beim nächsten Config-Abruf alle Checks des Hosts sofort.

Zur Abgrenzung: Ist das Gerät per SSH gar nicht erreichbar (Verbindung abgelehnt, Zeitüberschreitung), ist der Check CRITICAL, nicht UNKNOWN — dann ist es kein Zugangsdaten-Problem.

Active-Checker-Host¶

Aktive Checks laufen über einen Aktiven Collector — standardmäßig einen Dienst direkt auf der Vesana-Maschine; weitere lassen sich hinzufügen. Ein Aktiver Collector ohne Lebenszeichen seit 2 Minuten gibt seine Geräte an die übrigen ab. Lebt keiner mehr, prüft der Ersatzweg des Servers — Checks laufen weiter, aber langsamer; Checks, die die Server-Maschine selbst messen (Internetlinie, lokale Plugins), melden dann „nicht verfügbar". Ein Host bleibt in diesem Fall also eher verzögert als komplett NO_DATA.

Bleibt trotzdem alles stumm, prüfe unter Admin → Agents & Collectors → Active-Checker, ob ein Aktiver Collector eingerichtet und online ist. Details: Aktiver Collector.

Key-Regenerierung beim Aktiven Collector

Den API-Key des Aktiven Collectors neu zu erzeugen, während er läuft, trennt ihn sofort — der alte Key wird beim Erzeugen des neuen ungültig. Nur mit sofortigem Redeploy des neuen Keys auf der Maschine kombinieren.

Übergreifende Ursachen (alle Modi)¶

Ursache	Anzeichen	Fix
Erreichbarkeits-Check des Hosts alarmiert	Host gilt als „nicht erreichbar", Folge-Alarme unterdrückt	Reachability-Hint prüfen
Elternteil ausgefallen (Abhängigkeit)	Host-Kopf zeigt „hängt an: …"	Dependencies & Inhibition
Check ist im Info-Modus	„Info"-Pille — Status läuft, alarmiert aber nie	Kein Fehler, gewolltes Verhalten
Worker verarbeitet Ergebnisse nicht	Diagnose-Log Kategorie „Ergebnis-Verarbeitung" zeigt Fehler	Diagnose-Log prüfen

Wenn nichts davon greift¶

Erzeuge ein Support-Bundle — es enthält Ingest-Statistiken, den Zustand der Verarbeitungs-Pipeline und die letzten Diagnose-Ereignisse in einem Rutsch.