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", blaue Markierung) — das ist der Normalzustand zwischen Anlage und erstem Ergebnis, kein Fehler. Erst wenn ein Check, der schon mindestens einmal ein Ergebnis hatte, danach für längere Zeit stumm bleibt, wird er zu NO_DATA. Details zum Unterschied: Status- und State-Modell.

Wenn du also einen Check gerade erst angelegt hast: kurz das reguläre Intervall abwarten, bevor du hier weiterliest.

Schritt 1 — Welcher Monitoring-Modus?¶

Auf der Host-Detail-Seite zeigt die Kopfzeile die SourceChips — pro Monitoring-Quelle (Agent / Collector / Active-Checker) ein Chip mit Online/Offline-Status und Uptime-Popover. 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 SourceChip?"}
    B -->|Agent| C["agent.log auf der Zielmaschine prüfen"]
    B -->|Collector / passiv| D["Ist der Collector online?"]
    B -->|Active-Checker| E["Ist der Aktive Collector online?"]
    C --> C1["401/403 → Token · 404 → Server-URL · 0 Checks → keine Zuweisung"]
    D --> D1["Offline → Collector-Seite prüfen"]
    E --> E1["Offline → Python-Fallback läuft, aber langsamer"]

Agent-Host¶

Zeigt der SourceChip „Agent" als offline, oder ist er online, aber der Check bleibt trotzdem stumm — dann ist agent.log auf der Zielmaschine die erste Anlaufstelle, nicht die Vesana-UI.

agent.log finden und lesen¶

Plattform	Pfad
Linux	neben der Config, also `/etc/vesana-agent/agent.log`
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  checks=5

Der Agent schreibt typische Ursachen als klaren Fehlertext statt sie stumm zu verschlucken:

Log-Inhalt	Bedeutung	Fix
`401 Unauthorized`	Token falsch, widerrufen oder wurde neu erzeugt	Neues Token auf der Maschine eintragen, Service neu starten
`403 Forbidden`	Token gehört zu einem anderen Host	Token für diesen Host neu erzeugen
`404`	Server-URL falsch (Pfad/Domain stimmt nicht)	Server-URL in der Config prüfen
„0 Checks"	Host hat noch keine Services zugewiesen	Auf der Host-Seite Checks hinzufügen
`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	Echtes Zertifikat oder Cert in den System-Trust-Store
`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. Wenn agent.log gar keine Einträge zum betroffenen Check zeigt, ist der Check auf Agent-Seite vermutlich nicht konfiguriert (siehe „0 Checks" oder Config-Poll unten).

Hostname-Korrelation¶

Der Server ordnet eingehende Ergebnisse über die Kombination (Tenant, Hostname) zu — nicht über eine interne ID, die der Agent kennen müsste. Wurde der Host in Vesana umbenannt (der interne Hostname-Slug, nicht nur der Anzeigename) nachdem der Agent schon lief, zeigt der Agent unter Umständen weiter den alten Hostnamen — die Zuordnung greift dann nicht mehr sauber. Prüfen: Läuft agent.log fehlerfrei durch, aber der Host bleibt trotzdem NO_DATA? Dann Hostname in der Config gegen den aktuellen internen Namen des Hosts abgleichen.

Ist der Agent überhaupt online?¶

Der Agent schickt alle ~20 Sekunden einen Heartbeat — das ist die Grundlage für den Online-Status im SourceChip. Die eigentliche Check-Konfiguration (neue/geänderte Checks) holt er separat, im Regelfall alle ~5 Minuten. Schwellwert-Änderungen wirken davon unabhängig sofort (der Server wendet sie serverseitig auf jedes eingehende Ergebnis an); andere Config-Änderungen (Eventlog-Filter, Service-Ausschlüsse, neue Checks) brauchen den nächsten Poll.

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 überhaupt sinnvolle Werte liefert.

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. Ein Windows-Dienst kann sich nicht über einen eigenen Kindprozess neu starten; der wird beim Beenden des Dienstes mitgetötet.

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 (sie gehört dem Aufgabenplaner und überlebt das Ende des Agenten) und — falls die nicht zustande kommt — der Wiederherstellung des Windows-Dienstmanagers, die bei jedem Dienststart nachgezogen wird, also auch für alte Installationen gilt.
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 — Windows war nicht betroffen. Ursache war eine tote Verbindung, die minutenlang festgehalten wurde. Ab v1.9.448 wird sie beim ersten Zeitüberschritt ersetzt; der Ausfall ist auf Sekunden begrenzt.

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

Nach einem Ausfall stehen Checks mit langem Intervall noch auf No Data¶

War der Server oder das Netz eine Weile weg, blieben Checks mit langem Intervall (Stunden, Tage) danach bis zu ihrem nächsten Takt ohne Daten, obwohl der Agent längst wieder sendete. Ab v1.9.446 laufen nach der Rückkehr eines Hosts alle seine Checks sofort; „Jetzt erheben" am Host misst ebenfalls den ganzen Host — für Agent-, Collector- und Active-Checker-Hosts.

Token neu erzeugt?¶

Wurde auf der Host-Seite ein neues Agent-Token erzeugt (z. B. weil das alte verloren ging), aber die Zielmaschine läuft noch mit dem alten Token in der Config — dann meldet der Server konsequent 401. Das alte Token ist ab dem Moment der Neu-Erzeugung ungültig, nicht erst irgendwann später. Fix: neues Token in die Config eintragen, Service neu starten.

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

Collector-Host (passiv)¶

Zeigt der SourceChip „Collector" als offline, ist das meist der ganze Grund — alle Checks, die über diesen Collector laufen, bleiben dann stumm, nicht nur einer.

Collector aktuell online? Ein Collector gilt nur online, wenn er kürzlich (praktisch: innerhalb weniger Minuten) einen Heartbeat geschickt hat. Auf der Collector-VM: journalctl -u vesana-collector --since '5 minutes ago'.
Host diesem Collector zugewiesen? Ein Host ohne collector_id kann keine passiven Checks bekommen.
Config-Refresh abgewartet? Der Collector holt seine Check-Liste alle ~60 Sekunden — kürzer als beim Agent, aber nicht sofort.
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.

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 normalerweise über den Aktiven Collector — einen Dienst direkt auf der Vesana-Maschine. Ist der Aktive Collector offline (kein Heartbeat innerhalb der letzten ~2 Minuten), springt der Worker automatisch auf einen langsameren Python-Fallback um — Checks laufen weiter, aber mit höherer Latenz und weniger Funktionsumfang (z. B. keine SNMP-Walks). Ein Host bleibt in diesem Fall also eher verzögert als komplett NO_DATA.

Bleibt trotzdem alles stumm, prüfe zuerst, ob der Aktive Collector überhaupt eingerichtet ist (Admin → System → Aktiver Collector). 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
Reachability-Hint des Hosts alarmiert	Host-Karte zeigt „nicht erreichbar", Kind-Checks unterdrückt	Reachability-Hint prüfen
Elternteil hängt (Dependency)	Host-Header zeigt „hängt an: …" mit Warnfarbe	Dependencies & Inhibition
Check ist Info-Modus	Teal „Info"-Badge — 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.