Metrics
What is sampled, how often, how long it is kept, and the one configuration mistake that makes every number wrong.
Metrics are collected every 15 seconds through the driver, so a remote server is sampled identically to the control plane's own.
What is collected
| Group | Fields |
|---|---|
| Host | OS name and version, kernel, architecture, hostname, uptime, public IP, virtualisation type |
| CPU | Model, physical and logical cores, total %, per-core %, load 1/5/15, steal % |
| Memory | Total, used, free, available, buffers and cache, swap used and total |
| Disk | Per-filesystem total/used/free and inode usage, plus docker system df broken out into images, containers, volumes, and build cache |
| Network | Per-interface rx/tx bytes and computed rates |
| Docker | Containers running, stopped, and unhealthy; per-container CPU %, memory against limit, network I/O, restart count, health status, and OOM-kill events |
| Platform | Database size, active connections, queue depth and failed-job count per queue |
Steal % deserves the callout
On the cheap instances this platform targets, a slow application is often a noisy neighbour rather than your code. Nothing else on the dashboard tells you that.
Retention
| Resolution | Lives in | Kept for |
|---|---|---|
| 15-second samples | Redis only, with a 60-second TTL | Until the next sample |
| One row per minute | PostgreSQL | METRICS_MINUTE_RETENTION_DAYS (7 days) |
| Rolled up hourly | PostgreSQL | METRICS_RETENTION_DAYS (90 days) |
With a BRIN index on the timestamp this stays a few megabytes for a year. The same retention governs per-application container metrics.
Query either resolution with ?resolution=MINUTE or ?resolution=HOUR on the metrics routes.
Live delivery
GET /servers/:id/live is a Server-Sent Events stream. One-way, survives proxies,
reconnects for free, and carries the session cookie like any other route. The same mechanism
serves live build logs and live container logs.
GET /servers/:id/sample takes one sample on demand.
Host metrics inside a container
The mistake that makes every number wrong
When the API runs in a container, it must be given the host's kernel interfaces. Without them every figure describes the container's own cgroup — and the dashboard looks entirely correct while reporting the wrong machine.
Bind mount the host's /proc, /sys, and /, and point these at them:
HOST_PROC_PATH=/host/proc
HOST_SYS_PATH=/host/sys
HOST_ROOT_PATH=/host/rootThe platform's own compose file does this. The dashboard shows a banner when it detects the mounts are missing, and the API logs a warning at boot.
The same three variables exist on the agent, for the same reason.
Per-application metrics
GET /applications/:id/metrics is per-application container history; GET /applications/:id/containers is the live container list. Both read through the driver for the
server the application is on.