The per-pool dashboard

Intermediate⏱ ~17 mingrafanaprometheus

What you'll learn

Design a pool-scoped dashboard
Use template variables for pool selection
Show what differs meaningfully between pools
Link from the overview

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

Pools differ in durability policy, device class, workload, and importance. A pool-scoped view is where a question about one workload gets answered without the others obscuring it.

Template variables

Variable: pool
Query:    label_values(ceph_pool_metadata, name)
Type:     query, multi-value optional

# in panel queries
ceph_pool_stored{pool_id=~"$pool_id"}

Since most pool metrics carry pool_id rather than name, a second variable derived from the first is the usual approach:

Variable: pool_id
Query:    query_result(ceph_pool_metadata{name=~"$pool"})
Regex:    /pool_id="([^"]+)"/
Hide:     variable

The panels

Capacity
  Stored          ceph_pool_stored{pool_id=~"$pool_id"}
  Used (raw)      ceph_pool_bytes_used{pool_id=~"$pool_id"}
  Max avail       ceph_pool_max_avail{pool_id=~"$pool_id"}
  Overhead ratio  ceph_pool_bytes_used / ceph_pool_stored

Objects
  Object count    ceph_pool_objects{pool_id=~"$pool_id"}
  Avg object size ceph_pool_stored / ceph_pool_objects

Activity
  Read IOPS       rate(ceph_pool_rd[5m])
  Write IOPS      rate(ceph_pool_wr[5m])
  Read bytes/s    rate(ceph_pool_rd_bytes[5m])
  Write bytes/s   rate(ceph_pool_wr_bytes[5m])

Configuration
  Pool metadata   ceph_pool_metadata — size, min_size, type, crush_rule
  PG count        ceph_pool_metadata / autoscale status

The overhead ratio panel is the one that earns its place: for a replicated pool it should equal size, and for an EC pool it should equal (k+m)/k. A value above that indicates small-object padding.

What differs meaningfully

Property	Why it matters per pool
Overhead ratio	reveals EC padding or unexpected replication
Average object size	drives EC efficiency and metadata load
Read/write mix	determines whether EC or replication suits
Device class	via the CRUSH rule, sets the latency floor
MAX AVAIL trend	per-pool capacity forecasting

Linking from the overview

"links": [{
  "type": "dashboards",
  "title": "Pool detail",
  "tags": ["ceph", "pool"],
  "includeVars": true,
  "keepTime": true
}]

keepTime matters: following a link during an incident should preserve the time window being investigated, not reset to the last hour.

Quiz

Knowledge check · 4 questions

Q1. What should `ceph_pool_bytes_used / ceph_pool_stored` equal for a k=4 m=2 erasure coded pool?

1.0 3.0 6.0 1.5
Q2. A drill-down link that resets the time range costs a responder more than the seconds spent re-selecting the window.

True False
Q3. Investigate unexpected capacity consumption in a pool.

An erasure coded pool with k=4 m=2 is consuming far more raw capacity than the stored figure suggests it should. The per-pool dashboard shows an overhead ratio of 2.9.
Q4. Why do pool metrics need a derived `pool_id` template variable?

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

Production discipline

Include an overhead ratio panel (bytes_used / stored) on every per-pool dashboard — it should equal the durability multiplier exactly, and a higher value surfaces EC padding or an unexpected size at a glance. Set keepTime: true on drill-down links so an incident window survives navigation.

Cross-course references

Kubernetes: namespace-scoped dashboards use the same template variable pattern
Linux: per-filesystem views answer questions aggregate ones cannot