Host stuck NO_DATA / grey¶
A check permanently shows NO_DATA (orange), or an entire host looks "grey" — none of its checks receive new values. This guide walks you from the symptom to the cause, split by monitoring mode.
First look: PENDING or truly NO_DATA?¶
A freshly created check first shows PENDING ("Waiting for data") — that's the normal state between creation and the first result, not a fault, and it does not flip to No Data on its own after a while. Only a check that already had at least one result and then stays silent for too long turns into NO_DATA. Details on the difference: Status and state model.
When "too long" is reached:
- A check whose last result was OK becomes No Data after roughly 3× its interval without a new result. Agent checks get at least 3 minutes — a single slow run of a 30-second check does not produce an outage.
- A check that was already WARNING, CRITICAL or UNKNOWN gets more tolerance: 10× the interval, at least 30 minutes.
- If a check's interval is shortened, the limit counts from the change (since v1.905.0; before that a check could jump to No Data right after the change).
Step 1 — which monitoring mode?¶
On the host detail page, the header shows one chip per monitoring source (Agent / Collector / Active-Checker) with online/offline status. That's the fastest answer to "who should even be delivering data here". A host can have several modes at once (e.g. an Agent and an SNMP check via a Collector).
flowchart TD
A["Check shows NO_DATA"] --> B{"Which mode per the header chip?"}
B -->|Agent| C["Check agent.log on the target machine"]
B -->|Collector / passive| D["Is the collector online?"]
B -->|Active-Checker| E["Is an Active Collector online?"]
C --> C1["401/403 → token · 404 → server URL"]
D --> D1["Offline → check the collector VM"]
E --> E1["None online → server fallback, slower"]
Agent host¶
If the "Agent" chip shows offline, or it is online but the check still stays silent — then agent.log on the target machine is the first place to look, not the Vesana UI. An agent counts as offline after 3 minutes without a sign of life.
Finding and reading agent.log¶
The file sits next to config.yaml (unless a separate log_file is set there):
| Platform | Path |
|---|---|
| Linux | /etc/vesana-agent/agent.log (also in the journal: journalctl -u vesana-agent) |
| Windows | C:\ProgramData\Vesana\Agent\agent.log |
The log is plain text, local time, level as a word — no structured format to parse:
Typical causes appear as a clear error text in the log:
| Log content | Meaning | Fix |
|---|---|---|
Server lehnt den Agent ab — Token in config.yaml prüfen (HTTP 401/403) |
Token wrong, deactivated or replaced by a new one | Enter the current token on the machine, restart the service |
Server-Endpunkt nicht gefunden — Server-URL in config.yaml prüfen (HTTP 404) |
Server URL wrong (path/domain doesn't match) | Check the server URL in the config |
Host (oder Tenant) in Vesana deaktiviert — Agent pausiert |
Host or tenant is deactivated in Vesana | Intended — reactivate it and the agent continues on its own. See Deactivate, delete, restore |
dial tcp: lookup …: no such host |
DNS resolution fails | Check the DNS resolver on the target machine |
x509: certificate signed by unknown authority |
TLS certificate not trusted | Valid certificate, certificate in the system trust store, or the fingerprint in server_cert_sha256 of the config |
connection refused |
Server unreachable | Check server reachability / port |
Non-OK results are additionally logged with a plain-text message — OK results deliberately stay at debug level so the log doesn't flood.
Results are matched by the token, not by the hostname: each agent token belongs to exactly one host. Renaming the host in Vesana does not affect the matching.
Is the agent even online?¶
The agent sends a sign of life every 20 seconds — that's what drives the online dot on the "Agent" chip. Changes to this host's checks are picked up with the next sign of life (current agents); changes to profiles and other cross-host settings at the latest with the regular config fetch every 5 minutes. Threshold changes take effect immediately regardless, because the server applies them to every incoming result.
Unchanged OK results are sent bundled (delayed by at most 30 seconds); status changes and non-OK results still go out on a 5-second cycle.
Right after a change, instead of waiting for the next cycle:
Runs every check the server configured once, shows each result live and sends the batch — confirms in one step whether the config arrived and whether the check returns sensible values.
After an outage¶
- Backlog: after a connection interruption, agents send the fresh results first and deliver the buffered backlog throttled afterwards (since v1.901.0). Before that, an agent could appear as "online, but all checks overdue" for up to half an hour after a long outage. Back-filled results appear in the history at their measurement time but do not change the current status.
- Short pause: if an agent was silent for three to five minutes, up to v1.904 its checks stayed on "Agent offline" until they next ran regularly. Since v1.905.0 a returning agent re-runs all checks that were marked offline right away.
- Long intervals: when a host comes back, all of its checks run immediately (since v1.9.446); "Collect now" on the host also measures the whole host — for agent, collector and Active-Checker hosts.
The Windows agent stops reporting after an update¶
Up to v1.9.443 the Windows service stayed stopped after every self-update: the agent replaced its program, exited cleanly — and never started again.
- Immediate fix on the machine:
Start-Service VesanaAgent(orsc start VesanaAgent). The program is fine; only the restart was missing. - Fixed from v1.9.444, since v1.9.445 with two independent ways back: a one-time task in the Windows Task Scheduler and — if that can't be created — the Windows service manager's recovery actions, which are re-applied on every service start.
- The transition itself still runs on the old program: an agent below v1.9.444 stops one last time when updating to v1.9.444 and needs a one-time
Start-Service. After that it comes back on its own. - Restart log:
restart-helper.lognext toagent.log.
Linux agents count as offline after the public IP changes¶
If the site's public address changes (nightly forced reconnect, CGNAT, mobile), Linux agents and collectors up to v1.9.447 counted as offline for up to 15 minutes although they were running. From v1.9.448 the outage is limited to seconds.
Telltale sign: the gap starts reproducibly at the same time of day (the moment of the forced reconnect) and hits every Linux agent at the same site at once.
Token regenerated?¶
If a new agent token was generated on the host page but the target machine still runs with the old one — the server rejects the agent (log: "Server lehnt den Agent ab"). The old token is invalid the moment the new one is created. Fix: enter the new token into the config, restart the service.
Full install and token details: Agent (Linux/Windows).
Collector host (passive)¶
If the "Collector" chip shows offline, that's usually the whole reason — every check running through that collector stays silent, not just one. A collector counts as offline after 3 minutes without a sign of life; Vesana reports this as one "Collector offline" message rather than one per host.
- Collector online right now? On the collector VM:
journalctl -u vesana-collector --since '5 minutes ago'. - Host assigned to this collector? A host without an assigned collector receives no passive checks.
- Config fetch waited out? The collector fetches its check list every 60 seconds.
- SNMP-specific: if only one SNMP check fails while the collector itself is online, test the community directly from the collector VM (
snmpwalk -v 2c -c <community> <target-ip> .1.3.6.1.2.1.1.1.0) — if that already fails, the cause is network/community, not the collector.
After a collector outage (also after a suspended VM) the collector runs all checks of its devices immediately on first contact (since v1.901.0) — checks with long intervals no longer stay on "No data: collector offline" until their next run.
Details: Collector, Collector overloaded — what to do.
SSH checks sit on Unknown: "credentials rejected"¶
If a device rejects the SSH credentials, Vesana remembers this per target (address, port, user) and attempts no further login for 15 → 30 → 60 minutes. Every SSH check for that target reports UNKNOWN with plain text (user, target, end of the pause) during that time — without a single connection being made.
That's deliberate: previously each check and interval ran up to six failed attempts. To the target device that looks like an attack — ESXi locks the account after five failed attempts, other devices put the address on a block list.
The pause ends immediately on:
- changed credentials on the host or in the credential set,
- "Check now" or "Collect now" on the host,
- the first successful login.
Passive checks have no "Check now" — there, the status panel shows the button "Retry login now"; the collector then runs all checks of the host right away on its next config fetch.
To tell them apart: if the device is not reachable via SSH at all (connection refused, timeout), the check is CRITICAL, not UNKNOWN — then it's not a credentials issue.
Active-Checker host¶
Active checks run via an Active Collector — by default a service directly on the Vesana machine; more can be added. An Active Collector without a sign of life for 2 minutes hands its devices to the others. If none is alive, the server fallback takes over — checks keep running, but slower; checks that measure the server machine itself (internet line, local plugins) then report "not available". So a host in this case is more likely delayed than fully NO_DATA.
If everything still stays silent, check under Admin → Agents & Collectors → Active checker whether an Active Collector is set up and online. Details: Active collector.
Regenerating the Active Collector key
Regenerating the Active Collector's API key while it's running disconnects it immediately — the old key becomes invalid the moment the new one is created. Only combine with an immediate redeploy of the new key on the machine.
Cross-mode causes (all modes)¶
| Cause | Sign | Fix |
|---|---|---|
| The host's reachability check is alerting | Host counts as "unreachable", follow-up alerts suppressed | Check the reachability hint |
| Parent down (dependency) | Host header shows "depends on: …" | Dependencies & inhibition |
| Check is in info mode | "Info" pill — status runs, but never alerts | Not a fault, intended behaviour |
| Worker isn't processing results | Diagnose log category "Result processing" shows errors | Check the diagnose log |
If none of this helps¶
Create a support bundle — it contains ingest statistics, the processing pipeline state and the latest diagnose events in one go.