The cluster overview dashboard

Intermediate⏱ ~17 mingrafanaprometheus

What you'll learn

Design an overview that answers the first questions
Choose panels that support a decision
Order panels by the order questions are asked
Avoid the common overview mistakes

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

The overview is what someone opens when a page arrives. Its job is to answer, in ten seconds, whether this is a capacity problem, a durability problem, a performance problem, or a false alarm.

The questions in order

1. Is the cluster healthy?
2. Is anything unavailable?
3. Is redundancy reduced?
4. Is it running out of space?
5. Is it slow?
6. Is recovery happening?

Panels ordered to match, top-left first.

The panels

Row 1 — status (stat panels, large)
  Health          ceph_health_status                    OK / WARN / ERR
  PGs inactive    ceph_pg_total - ceph_pg_active        0 is green
  PGs degraded    ceph_pg_degraded                      0 is green
  OSDs down       count(ceph_osd_up == 0)               0 is green

Row 2 — capacity
  Fullest OSD     max(ceph_osd_stat_bytes_used / ceph_osd_stat_bytes)
  Cluster used    ceph_cluster_total_used_raw_bytes / ceph_cluster_total_bytes
  MAX AVAIL       ceph_pool_max_avail by pool
  Days remaining  ceph_pool_max_avail / rate of change

Row 3 — performance
  Client IOPS     sum(rate(ceph_osd_op_r[5m]) + rate(ceph_osd_op_w[5m]))
  Client BW       sum(rate(ceph_osd_op_in_bytes[5m]) + rate(ceph_osd_op_out_bytes[5m]))
  Write p99       histogram_quantile(0.99, sum(rate(ceph_osd_op_w_latency_bucket[5m])) by (le))
  Slowest OSDs    topk(5, ceph_osd_apply_latency_ms)

Row 4 — recovery
  Degraded objs   ceph_degraded_objects
  Misplaced objs  ceph_misplaced_objects
  Recovery rate   rate(ceph_degraded_objects[15m])
  Recovering PGs  ceph_pg_recovering + ceph_pg_backfilling

Sixteen panels, four rows, one screen.

Panels that support a decision

Panel	Decision it supports
Fullest OSD versus average	balance or expand
Degraded objects trend	is recovery progressing or stalled
Slowest OSDs	is there an outlier
PGs inactive	is this an availability incident

A panel that does not change what someone does is decoration.

Common mistakes

Mistake	Why
Per-OSD line graphs	unreadable at 500 series
Only averages	conceals the outlier
No thresholds or colouring	requires reading numbers rather than glancing
Everything on one row	no visual grouping by question
Raw counters	rising forever, meaningless
No time range control	cannot correlate with an incident window

# thresholds turn a number into a signal
ceph_health_status:  0 green, 1 amber, 2 red
PGs inactive:        0 green, >0 red
Fullest OSD:         <0.75 green, <0.85 amber, >=0.85 red

Quiz

Knowledge check · 4 questions

Q1. Why should the top row of an overview dashboard use stat panels with thresholds rather than time series?

They render from a single instant vector rather than a range query, so the whole top row is drawn and coloured before the rest of the dashboard has loaded A time series panel shows only the shape of a change across the selected window and cannot display the current value as a number They answer "what is it now" pre-attentively through colour, which is the first question; time series answer "how has it changed", which is the second Stat panels query far fewer samples, so the top row stays responsive even when the dashboard is opened over a long time range
Q2. Per-OSD line graphs are the most informative way to show OSD latency on an overview.

True False
Q3. Redesign an unused overview dashboard.

An overview dashboard has 30 panels organised by metric family — all OSD metrics together, all pool metrics together. Responders say they open it and then go straight to the CLI.
Q4. What sequence should an overview dashboard follow, and why?

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

Production discipline

Order the overview by the sequence questions are asked during an incident — health, availability, durability, capacity, performance, recovery — and put colour-thresholded stat panels in the top row. Remove any panel that does not change what someone does.

Cross-course references

Kubernetes: cluster overview dashboards follow the same question-ordered design
Linux: a well-designed status display answers the first question without reading