TurboPanel Docs
Server metrics

Server metrics

The server Metrics screen is a history of how a host has been doing — CPU, memory, disks, network, and whatever else that machine actually has (GPUs, extra filesystems, ingress, a database proxy). It is statistical and disposable: good for spotting saturation, stalls, and hardware faults. It is not a billing ledger or an audit trail.

What each chart means

This section is the operator glossary. Storage, retention, and the wire contract live in Server metrics architecture and Metrics operations.

How sampling works

A connected Linux daemon posts one sample about every 60 seconds. The first sample after connect is immediate (gauges such as memory available). Rates (CPU busy, disk bytes/s, network) appear about two seconds later, once the daemon has two readings to subtract.

Range on the screenWhat you get
5 minutes / 10 minutesLive mode — 10 second samples for up to 60 minutes, then it falls back to 1 minute
1 hour / 6 hours1 minute refresh
24 hours5 minute refresh
7 / 30 / 90 daysHistorical buckets; no auto-refresh

Live-mode samples are streamed to the chart and never stored: once the lease ends, history for that window is the normal one-minute data. Every chart group is collected on every sample — there is no slower cadence for any group.

Charts are not wall-clock real time below that ~60 second baseline. A gap in the line is a missing sample, not zero usage — amber bands mark those holes. A solid vertical divider is a topology change (a NIC, disk, GPU, or sensor was added, removed, or replaced). The line breaks there on purpose so two different devices never look like one continuous trend.

Metrics are Linux-only. A non-Linux server shows an unsupported-OS state instead of empty charts.

Overview tiles

The five numbers above the charts are the latest values, not a plotted series:

TileWhat it is
CPU utilizationShare of CPU time that was busy (host.cpu.busyPercent). See CPU.
Memory usedUsed RAM as a percent of capacity (derived from used bytes). See Memory.
Hosting storage usedUsed percent of the filesystem marked for hosting, or the root filesystem if none is. See Storage.
Running / blockedTasks on a CPU right now vs tasks waiting on I/O. See Processes.
UptimeTime this server has been connected in the selected range, from connection history — not a metrics-store series. History only; the Servers list is what says whether the host is online right now. See Uptime.

Uptime

The Uptime tile is not a plotted series. It is time this server was connected during the selected range, from the connection-status history. That history is best-effort. Whether the host is online right now is the Servers list (Postgres liveness), never this tile.

A chart is missing

Most groups only appear when that hardware or sidecar exists on the host. A VM with no GPU has no GPU charts, and no Physical signals group at all. A host whose kernel does not export Pressure Stall Information has no PSI charts. CPU detail and Memory detail are reported by every Linux host at every tier — they are not a capability to enable. The one group hidden by license tier rather than by presence is Docker: on an S1 license the console shows a one-line notice in its place, since the Docker breakdown is granted from S2 (see License tiers). Self-hosted servers see every group their hardware supports.

Empty is not the same as zero. A metric the host cannot measure stays blank; a metric that is legitimately zero (no swap configured, no retransmits) plots at 0%.

Pressure Stall Information (PSI)

PSI is the Linux kernel's answer to “are tasks waiting?” It is the most important number on the Metrics screen when CPU busy % looks fine but the machine still feels slow.

Each PSI reading is a percent of that sample's wall clock during which tasks were stalled on the resource — not how busy the resource was, and not a load average. The daemon derives it from the kernel's cumulative stall-time counter (total in /proc/pressure/{cpu,memory,io}), so a 20% Some value means tasks spent a fifth of that minute waiting. TurboPanel does not store the kernel's avg10 / avg60 / avg300 rolling averages.

Busy percent vs pressure

Busy percent is how much of the CPU (or disk) was occupied. Pressure is how often work waited for that resource. A host can be 40% busy and still have high CPU pressure if too many tasks are queued behind too few cores. It can also be 95% busy with almost no pressure if the work is well matched to the hardware.

Linux tracks three resources. TurboPanel collects five percentages from them:

ResourceChartSomeFull
CPUCPU pressure (PSI)host.cpu.pressureSomePercent — at least one task waited for a CPUnot collected — a CPU is never completely stalled the way memory and disk can be (some task is always running if there is work)
MemoryMemory pressure (PSI)host.memory.pressureSomePercent — at least one task waited for RAM (reclaim, compaction, or swap)host.memory.pressureFullPercentevery non-idle task waited — the machine stalled
I/OI/O pressure (PSI)host.storage.ioPressureSomePercent — at least one task waited on storagehost.storage.ioPressureFullPercent — every non-idle task waited on storage

Some answers “is anyone stuck?” Full answers “did the whole machine stop?” A rising Some line is contention. A Full line that leaves zero is a stall — memory thrashing or a disk that cannot keep up.

How to read a PSI chart

Rules of thumb, not product alert thresholds:

What you seeWhat it usually means
Flat near 0%The resource is keeping up
Some in the low single digits, brief spikesNormal under bursty load
Some in double digits for minutesSaturation — tasks are regularly waiting
Some high while busy % is only moderateMismatch: too many threads, a few pegged cores, or a noisy neighbor (check Cores saturated and steal %)
Memory or I/O Full above 0% for more than a blipSevere — the host stalled. Pair memory Full with swap I/O; pair I/O Full with disk latency

PSI needs a kernel that exports /proc/pressure/ (mainstream Linux since 4.20; Debian 13 does). If those files are missing — some older kernels, some containers — the PSI charts hide instead of plotting zero. A missing chart is not the same as 0%.

Catalog

Each heading below uses the same id as the console chart. A later console click can open /docs/metrics/<group>#<chart-id>.

Console chart idDocs
cpu-modesCPU utilization
cpu-pressureCPU pressure (PSI)
cpu-saturated-coresCores saturated
cpu-processesProcesses
cpu-detail-frequencyCPU frequency
cpu-detail-schedulingContext switches & interrupts
cpu-detail-forksProcess forks
cpu-detail-irqIRQ time
memory-breakdownMemory breakdown
memory-percentMemory used
swap-bytesSwap used
swap-percentSwap used %
memory-pressureMemory pressure (PSI)
memory-swap-ioSwap I/O
memory-major-faultsMajor page faults
memory-detail-primaryFree & cached memory
memory-detail-slabSlab memory
memory-detail-dirtyDirty & writeback pages
memory-detail-other-gaugesShared memory
memory-detail-commitCommitted memory
memory-detail-reclaimPage reclaim
memory-detail-compactionCompaction stalls
storage-io-pressureI/O pressure (PSI)
disk-throughputDisk throughput
disk-latencyDisk latency
root-filesystem-bytesRoot filesystem available
root-filesystem-percentRoot filesystem used
root-filesystem-inodesRoot filesystem free inodes
managed-storage-hostingHosting root
managed-storage-backupBackups
managed-storage-dockerDocker data root
managed-storage-logsLogs
managed-storage-enginesManaged databases
managed-storage-connectionsManaged database connections
managed-docker-layersImage layers
managed-docker-containersContainer writable layers
managed-docker-volumesVolumes
managed-docker-build-cacheBuild cache
managed-docker-countsObject counts
network-retransmitTCP retransmit rate
network-softnet-dropsSoftnet drops
kernel-resourcesKernel resource usage
router-backend-requestsBackend requests
router-backend-latencyBackend latency
router-backendsBackends & services
router-connectionsOpen connections
router-configConfig reloads
router-config-ageSince last config reload
router-tls-expirySoonest TLS expiry

Per-device charts (GPU, extra NICs, filesystems, block devices, sensors, ingress, ProxySQL) use the group page, not a per-device heading.

Edit on GitHub

Last updated on

On this page