Skip to content

Resources

Admin → System → Resources is the one page for everything the instance consumes in resources and how it's sized. Three sub-tabs (its own tab bar within the page, addressable via ?sub=):

  • Storage — disk usage, database size, retention per data class, cleanup
  • RAM — memory per service, share of server RAM
  • Performance — pipeline traffic light, discarded results, sizing profiles (worker/Postgres/Redis)

Old links to the former separate "Storage" and "Performance" pages redirect automatically to the matching sub-tab of this page.

Storage

Usage overview

At the top of the tab:

  • Usage — how much of the partition is used, in GB and percent. Warning from 85% used.
  • Database total — total size of the Postgres database.
  • Growth per day — after compression and raw (before compression), so you can see how much TimescaleDB compression actually buys you.
  • WAL — size of the write-ahead log.

Data-class table

Every hypertable data class listed individually, with size, "compressed N/M chunks", row count, and oldest data point. A warning appears if compression is configured but visibly not taking effect.

Also an overview of the metric aggregates (5-minute, hourly, and daily values) with their respective retention — the finest resolution (5 minutes) is automatically consolidated after two weeks, hourly values after a bit over a year, daily values stay unbounded.

"Where the space goes"

A Docker usage panel breaks down what's on disk: images, stopped containers, volumes, build cache — including the portion that could be reclaimed immediately.

"Biggest data producers"

A list of which checks wrote the most to the database in the last 24 hours. Useful for spotting an overly chatty or too-frequent check before it blows through your retention budget.

How long Vesana keeps data

Vesana follows one principle: events stay, measurement series get coarser, only raw material is deleted. Every kind of data belongs to exactly one of three classes.

Events — never deleted by default

Something happened at a point in time and someone cared about it. These rows are tiny and cannot be reconstructed.

Data Keep (default)
Status changes of a check unlimited (stored compressed)
Audit log (who changed what) unlimited
Sent notifications unlimited
Delivery journal unlimited
Anomaly events unlimited

Measurement series — condensed instead of deleted

A continuously measured number. Raw data is limited, but the condensed tiers stay — a long-term trend is never lost.

Tier Resolution Keep
Raw data (check results) per measurement 90 days (configurable)
Hourly values 1 hour 395 days
Daily values 1 day unlimited

Raw material — may expire

Full text and raw signals that are only useful while fresh.

Data Compress after (default) Keep (default)
Logs from monitored systems 3 days 30 days
Diagnostic events (system log) 7 days 90 days
Agent heartbeats 3 days 90 days
Collector heartbeats 3 days 90 days

From the logs, the daily tally stays

The full text expires after 30 days, but how many entries there were per day, device, source and level is kept indefinitely. This answers "when did this start" even years later, without keeping the logs themselves any longer.

Outages are kept regardless

When an agent or collector was gone is additionally recorded as an event — indefinitely. The availability bar therefore still shows an outage long after the heartbeats themselves have expired. Periods for which there is no source at all (before this recording was introduced) show as "no verdict" — not as an outage.

Configuring retention

The settings are grouped by the three classes — events, measurement series, raw material — each with one sentence on what the class means.

Three presets fill the fields with one click:

Preset Events Raw metrics Logs
Frugal 2 years 30 days 7 days
Standard unlimited 90 days 30 days
Archive unlimited 365 days 90 days

A preset does not save

Clicking a preset only fills the input fields. Nothing is stored until you press "Save & apply" — so you see every single number and every warning first. This is deliberate: a click that shortens ten retention settings at once would be exactly the button that causes the data loss this feature exists to prevent.

Configurable per kind of data — compress after (days) and keep (days, 0 = unlimited).

Limits: compress between 1 and 60 days; keep between 7 and 3650 days, or 0 for unlimited. The retention period must be longer than the compression period. Saving takes effect immediately and permanently — there's no undo button, purged raw data is gone.

Measurement series, raw material and, among the events, status changes can be compressed. The other events live in ordinary tables; for them only "keep" applies.

What happens behind the scenes

Your input is the wish; a background job enacts it every 6 hours — as a real TimescaleDB policy for compressible data, and as a time-based deletion in the daily cleanup run for events. Setting "keep" to 0 means nothing is deleted at all, exactly as configured.

Only limit events deliberately

For events the default is "unlimited", because they need almost no space and cannot be restored: on a typical instance all event tables together account for less than one percent of the database. Setting a limit here loses that history permanently — the audit log, for instance, would no longer be complete for a later investigation.

Clean up now

A "Clean up now" button appears as soon as a visible backlog exists (compression or retention lagging). The result is reported in plain text, e.g. "12 chunk(s) compressed, 4 removed by retention".

Deadband & heartbeat (background mechanics)

So that unchanging readings don't create a new row on every poll, the worker only writes on: the first data point, a status change, a value change beyond a small tolerance threshold, or when the heartbeat interval (default 10 minutes) is exceeded. This meaningfully cuts storage needs without losing the trend. This fine-tuning is deliberately not a UI field — it's an internal safeguard, not a retention lever.

RAM

Shows how much memory Vesana consumes in total and per service — the values come from container statistics, adjusted for Linux page cache (which otherwise misleadingly reads as "used" memory).

  • Vesana total (all services) — sum across all containers, plus "of X GB server RAM (Y%)"
  • Distribution per service — as bars per service: database, API, receiver, worker, worker-scheduler, Redis, web server, updater, Ollama (if active), agent gateway (if active)

The view refreshes automatically every 30 seconds. Without a running updater container (e.g. a fully manually managed install), a warning appears instead of live numbers — the values are collected server-side via the updater, not via the API itself.

Use this view before scaling up: if a single service (usually the database) takes the lion's share, that tells you more than raw total server utilization.

Performance

Pipeline traffic light

At the top of the tab is a traffic light (green/yellow/red) showing how far processing is lagging behind — derived from the age of the oldest still-unprocessed message in the processing stream. It's the quick answer to "do I need to scale up right now?": green means the pipeline processes in real time; yellow/red means messages are backing up — a reason to pick a larger sizing profile or investigate the cause (DB bottleneck, too few workers).

Discarded results

If the worker definitively could not store a result, it ends up here as a discarded result (dead letter) — it is lost and is not retried. As long as such entries exist, the admin overview shows "Attention needed" and names this reason. Once the cause is fixed (usually it is in the diagnostics log), remove them with Clear (super admins only); the action is recorded in the diagnostics log.

Sizing profiles

Four static profiles — no automatic recommendation, you choose deliberately (super admins only):

Profile Workers WORKER_CONCURRENCY Postgres shared_buffers effective_cache_size work_mem maintenance_work_mem max_connections DB pool Redis maxmemory
Small 1 4 256 MB 512 MB 8 MB 128 MB 100 5 (+10 overflow) 256 MB
Medium 2 4 512 MB 1 GB 16 MB 256 MB 150 10 (+20 overflow) 512 MB
Large 3 8 1 GB 2 GB 32 MB 512 MB 200 15 (+30 overflow) 1 GB
XL 5 8 2 GB 4 GB 64 MB 1 GB 300 20 (+40 overflow) 2 GB

On a fresh installation the installer derives the Postgres memory values from the server's RAM; the setup wizard never lowers them. "Apply" on this page, by contrast, sets exactly the values of the chosen profile.

"Apply" writes the matching values into .env and performs a container restart (docker compose up -d) — Postgres has a brief downtime (seconds, not minutes), other containers are recreated without data loss.

Sizing confirmation with real runtime numbers

After "Apply", Vesana doesn't rely on plain expectation — it checks back with the running system: how many worker containers are actually running, and did Postgres really pick up shared_buffers (SHOW shared_buffers). The frontend polls for up to 120 seconds until profile, worker count, and shared_buffers all match the chosen target, and then reports success with the actual measured numbers — not just "setting saved".

This matters because a plain settings-success doesn't tell you whether the container restart actually landed. If the confirmation fails (e.g. Postgres takes longer than 120s to restart), check the container logs — the setting itself is still saved and takes effect on the next manual restart.

Which profile, when?

As rough orientation — the actually right profile depends on your check mix (lots of SNMP walks need more workers, lots of agent checks need more DB write throughput):

  • Small — single site, small office, a few hundred services
  • Medium — multiple sites or mid-size business
  • Large — larger IT service provider with many customers
  • XL — datacenter/enterprise scale (more than 32 GB RAM on the server recommended)

Watch the pipeline traffic light and the RAM distribution before scaling up — together they show you whether the bottleneck sits with the workers, with Postgres, or with overall server RAM.

Manual tuning beyond the profiles

The four profiles cover most cases. For edge cases, manual tuning of the .env variables remains possible (see Self-hosting overview) — e.g. if you specifically want to raise only WORKER_REPLICAS without touching the Postgres values. After a manual change: docker compose up -d for the new values to take effect.

Next