Skip to content

Resources

Admin → Maintenance → 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 — sizing profiles (worker/Postgres/Redis), pipeline traffic light

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.

Configuring retention

Configurable per data class — compress after (days) and keep (days, 0 = unlimited):

Data class Label Compress after (default) Keep (default) Compressible
Metrics (check results, detail) Metrics 3 days 90 days yes
Logs from monitored systems Logs 3 days 30 days yes
Diagnostic events (system log) Diagnostics 7 days 90 days yes
Collector heartbeats Heartbeats — 30 days no
Agent heartbeats Heartbeats — 30 days no

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.

What happens behind the scenes

Your input is the wish; a background job enacts it every 6 hours as a real TimescaleDB policy (compression and retention policy). Setting "keep" to 0 removes the retention policy entirely — data then grows unbounded, exactly as configured.

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).

Sizing profiles

Four static profiles — no automatic recommendation, you choose deliberately:

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

"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