System health¶
Moved
There's no longer a separate "System health" page with a tab banner and its own sidebar LED. The instance's live health now shows directly on the admin overview (/admin) — as the landing page of the admin area, not a sub-page.
Where to look today¶
| Before | Today |
|---|---|
| System tab with stream backlog, insert rate, DB free, AI provider, worker pool | Admin → Overview — tiles for core services, processing pipeline, storage & database, backup & DR, license, updates, collection, server system, background work |
| Sidebar LED (green/yellow/red) | Traffic light directly in each overview tile |
| Pipeline sparklines | Pipeline traffic light under Admin → System → Resources → Performance |
The top of the overview shows the overall state ("All healthy", "Attention needed", "Problem detected"). If it is not green, every reason is listed in plain text below it, with a "view" link to where you fix it — e.g. a core service off, pipeline backlog, discarded results, an old backup, an expiring licence, an overloaded server, an Active Collector offline or overloaded, stalled background work, or a certificate about to expire.
Details on the overview: Administration → Overview = instance health. Details on the pipeline traffic light and sizing profiles: Resources → Performance.
What to do on a problem¶
| Symptom | Possible cause | Action |
|---|---|---|
| Pipeline traffic light yellow/red, delay rising | Too few workers for the current check mix | Pick a larger sizing profile, see Resources → Performance |
| Storage tile warns (disk usage ≥ 85%) | Retention too long, compression not taking effect | Check Resources → Storage, lower retention or "Clean up now" |
| Backup tile shows no recent successful run | Schedule disabled, backup failing | Check Backup & Disaster Recovery |
| Core-services tile shows a service as "off" (worker: "no consumers") | Container crashed or never started | Check the logs of the affected service's container |
| "Attention needed" because of discarded results (dead letters) | The worker definitively could not store results | Find the cause in the diagnostics log, then clear them under Resources → Performance |
| Background-work tile: no leader or a task is stalled | Redis unreachable, an API process hangs, a watcher crashes repeatedly | Read the diagnose log, category maintenance (hintergrund_stillstand, leiter_verloren, hintergrund_aufgabe_abgestuerzt); check Redis and the API container; emergency switch see Scaling |
Self-monitoring: the "Vesana Server" host¶
The setup wizard offers to monitor the Vesana server itself ("Monitor this Vesana server itself (recommended)", on by default). You then get the host "Vesana Server" in the first tenant with these checks, run by the server itself:
| Check | Checks |
|---|---|
| HTTP Health API | Does the API respond? |
| HTTP Health Receiver | Does the receiver respond? |
| PostgreSQL | Is the database reachable? |
| Redis | Is Redis reachable? |
| Disk Space | Usage of the server disk (WARNING from 80 %, CRITICAL from 90 %) |
| TLS Certificate | Remaining lifetime of the instance certificate (see TLS) |
These checks run through the normal alert rules. They only query these fixed targets; this check type cannot be used to query other addresses in the server's internal network.