Storage metrics

Host storage charts are the whole machine's disk picture: pressure, combined throughput and latency, and the root filesystem — how the disk is behaving. What is consuming it (hosting, backups, Docker, logs) is a different question, answered by Storage usage. Individual disks have their own group — Block devices. Extra mounts (not /) live under Filesystems.

Overview tile

Hosting storage used is the used percent of the filesystem marked with the hosting role, or the root filesystem if none is. For root it is derived.rootFilesystemUsedPercent. For a non-root hosting mount it is computed from that mount's available bytes and its inventory total.

This tile is about capacity, not speed. A disk can be 20% full and still saturated — that shows up as I/O PSI and latency, not on this tile.

I/O pressure (PSI)

PSI for storage — share of this sample's wall clock that tasks spent waiting on disk, not how full the disk is or how many bytes moved.

Series	Wire name	What it is
Some	`host.storage.ioPressureSomePercent`	At least one task waited on I/O
Full	`host.storage.ioPressureFullPercent`	Every non-idle task waited on I/O — the host stalled on disk

Utilization and throughput can look modest while PSI is high: many small waits, a saturated queue, or a single slow device holding everyone. Full leaving zero is the serious case — pair it with disk latency, then open Block devices to see which disk.

The chart hides when /proc/pressure/io is missing.

Disk throughput

Series	Wire name	What it is
Read	`host.storage.diskReadBytesPerSecond`	Bytes read per second across the host
Write	`host.storage.diskWriteBytesPerSecond`	Bytes written per second across the host

This is a host-wide sum, not “the SSD's rated sequential speed.” A high write line during a backup is expected. A high line that stays high with rising latency and PSI is saturation.

Per-disk bytes are on Block devices.

Disk latency

host.storage.diskLatencyMs — average host-wide I/O service time in milliseconds, reads and writes combined. The per-direction split is on each drive's own latency chart.

Latency is usually the better saturation signal than bytes/s. An SSD that was at 0.2 ms and is now at 5–20 ms is hurting even if throughput has not grown. Spinning disks and busy RAID rebuilds sit higher by nature — compare a host to its own baseline, not to a generic number. There is no host-level "busiest disk" rollup any more: per-disk utilization is on Block devices, and every tier watches at least two.

Root filesystem available

host.storage.rootFilesystemAvailableBytes — free space on / that new files can use. A steadily falling line is the disk filling up. A sudden drop is often a log explosion, a container image pull, or a misplaced write.

Non-root mounts are not on this chart — see Filesystems.

Root filesystem used

derived.rootFilesystemUsedPercent — used percent of /, computed on the control plane from available bytes and the known size. Area chart, 0–100%.

Plan growth before this reaches the high 80s — some filesystems (and some databases) degrade badly before they hit 100%. Inodes can run out while this percent still looks fine; use the next chart.

Root filesystem free inodes

host.storage.rootFilesystemFreeInodes — remaining inode (file-slot) count on /.

Each file, directory, and symlink consumes an inode. A host that creates millions of small files (mail, caches, container layers, CI artifacts) can hit zero inodes with gigabytes of space still free. “No space left on device” then means inodes, not bytes. A falling free-inode line with a flat used-% line is that pattern.

Storage usage — what is consuming the disk: hosting, backups, Docker, logs
Block devices — per-disk charts
Filesystems — extra mounts
Pressure Stall Information

On this page