The capacity dashboard

Intermediate⏱ ~17 mingrafanaprometheus

What you'll learn

Design a capacity dashboard serving both planning and incidents
Show the binding constraint rather than averages
Present forecasts with their assumptions
Surface reclaimable capacity

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

Capacity is used in two modes: planning, months ahead, and during an incident, minutes ahead. The panels differ and both belong on the same dashboard.

The binding constraint

Fullest OSD        max(ceph_osd_stat_bytes_used / ceph_osd_stat_bytes)
Cluster average    avg(ceph_osd_stat_bytes_used / ceph_osd_stat_bytes)
Spread             max(...) - avg(...)
OSD utilisation    heatmap of ceph_osd_stat_bytes_used / ceph_osd_stat_bytes

The fullest OSD is what determines when the cluster stops accepting writes, and the spread is capacity a rebalance would recover. Both belong above the cluster average, which constrains nothing.

Thresholds:
  Fullest OSD: <0.75 green, <0.85 amber, <0.90 orange, >=0.90 red
  Spread:      <0.10 green, <0.20 amber, >=0.20 red

Per-pool capacity

MAX AVAIL per pool     ceph_pool_max_avail
Stored per pool        ceph_pool_stored
Growth rate per pool   deriv(ceph_pool_stored[7d]) * 86400
Days remaining         ceph_pool_max_avail / clamp_min(deriv(ceph_pool_stored[7d]) * 86400, 1)

MAX AVAIL is the figure that answers “how much more can we store”, and per pool because the pools have different durability policies.

Forecasting

Projected exhaustion   predict_linear(ceph_pool_max_avail[14d], 86400 * 90)
Days to nearfull       (0.85 - max(osd utilisation)) / daily growth rate

A forecast panel should carry its assumptions in the panel description:

Panel description:
  Linear projection over a 14-day window. Excludes planned workload
  onboarding. Recalibrated quarterly; last reviewed 2026-08-18.

Without that, the number is quoted later as though it accounted for everything.

Reclaimable capacity

Snapshot count         count(ceph_rbd_snapshots) — where RBD stats enabled
Spread                 max - avg OSD utilisation, as recoverable by balancing
Pool overhead ratio    ceph_pool_bytes_used / ceph_pool_stored
Incomplete multipart   from RGW metrics where available

During a capacity incident, the question is what can be freed quickly, and these panels answer it faster than running the commands.

The thresholds panel

Nearfull ratio         ceph_osd_map_nearfull_ratio
Backfillfull ratio     from ceph_health_detail or configuration
Full ratio             ceph_osd_map_full_ratio
Current fullest OSD    against those lines

Plotting the fullest OSD against the three ratio lines shows the remaining margin visually, which is more legible than three separate numbers.

Quiz

Knowledge check · 4 questions

Q1. Why should the fullest OSD and the utilisation spread appear above cluster average utilisation?

They are cheaper to compute, since max and the spread evaluate over a single series while the average has to scan every OSD in the fleet The cluster average is unreliable because OSDs report utilisation at different intervals, so the mean is taken across samples of differing ages The fullest OSD determines when writes stop and the spread shows what a rebalance would recover; the average constrains nothing They update on every OSD map change, while the cluster average is recomputed only when the manager refreshes its aggregated view of the fleet
Q2. A projected exhaustion date can be entirely correct about the last fourteen days and still be wrong about next month.

True False
Q3. Build a capacity dashboard for two use cases.

A team needs one dashboard serving both quarterly capacity planning and capacity incidents, where the questions and time horizons are completely different.
Q4. What should a capacity forecast panel description state?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Lead the capacity dashboard with the fullest OSD and the utilisation spread, not the cluster average — the average is the figure everyone quotes and the one that constrains nothing. Put forecast assumptions in the panel description, where they are read alongside the number rather than in a document nobody opens.

Cross-course references

Kubernetes: node pressure per node beats cluster-wide resource averages
Linux: per-filesystem capacity matters where an aggregate figure does not