Monitoring a dedicated cluster

Intermediate⏱ ~17 mincephprometheus

What you'll learn

Define monitoring for an independent storage cluster
Identify the signals specific to a dedicated deployment
Integrate storage alerts with consumer teams
Report cluster health to its consumers

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

A dedicated cluster serves consumers who do not administer it. Monitoring must serve both the storage team and the teams depending on it.

What differs from hyper-converged

Aspect	Dedicated
Attribution	storage problems are unambiguously storage
Contention	absent; latency changes have storage causes
Consumer visibility	consumers need a view they do not administer
Boundary	the storage network is the interface
Incident ownership	clear

The attribution clarity is the practical benefit: a latency change on a dedicated cluster is a storage event, where on a hyper-converged one it could be a noisy VM.

The signals that matter

Storage team:
  everything — health, capacity, performance, durability, recovery

Consumers:
  is the storage available?
  is it meeting its latency commitment?
  is there planned work coming?
  how much capacity do I have left?

# a consumer-facing view
ceph_health_status
histogram_quantile(0.99, sum(rate(ceph_osd_op_w_latency_bucket[5m])) by (le))
ceph_pool_max_avail * on(pool_id) group_left(name) ceph_pool_metadata
ceph_pg_total - ceph_pg_active

Four series answer every question a consumer has, and none requires them to understand PGs or OSDs.

Signals specific to a dedicated deployment

Signal	Why
Storage network utilisation	the interface to consumers
Per-consumer pool metrics	attribution and capacity
Client connection counts	detects a consumer misbehaving
Per-pool latency	different consumers, different commitments

# per-pool operation rate, for attribution
sum by (name) (
  rate(ceph_pool_rd[5m]) + rate(ceph_pool_wr[5m])
) * on(pool_id) group_left(name) ceph_pool_metadata

Attributing load to a consumer is what makes a capacity or performance conversation specific rather than general.

Integrating with consumer teams

Practice	Effect
A consumer-facing dashboard per pool	self-service answers
Alerts routed to the consumer for their pool’s capacity	they act on their own growth
Planned work announced through the consumer’s channel	no surprises
A stated latency commitment with monitoring against it	expectations are measurable

- alert: TenantPoolCapacity
  expr: |
    (ceph_pool_stored / (ceph_pool_stored + ceph_pool_max_avail)) > 0.80
  labels:
    severity: ticket
    team: '{{ $labels.name }}'

Reporting to consumers

Monthly storage report — pool: pve-vms
  Availability:      100% (no periods below min_size)
  p99 write latency: 4.2 ms (commitment: under 10 ms)
  Capacity used:     58 TB of 92 TB available
  Growth:            1.1 TB/week → 31 weeks remaining
  Planned work:      firmware update, 2026-09-14, no impact expected

Quiz

Knowledge check · 4 questions

Q1. Why give consumers a four-metric view rather than the full Ceph dashboard?

They need availability, latency, capacity, and planned work; a full dashboard adds a hundred things they cannot act on and they end up asking the storage team The full dashboard is expensive to render for many concurrent viewers, and consumers open it far more often than the storage team, which slows it down for everyone Security requires it, since the full dashboard exposes daemon names and host addresses consumers have no authorisation to see The metrics differ per consumer, so a shared dashboard needs a template variable that each team would have to set correctly
Q2. Cluster-level capacity metrics are sufficient for capacity conversations on a shared cluster.

True False
Q3. Set up monitoring for a shared dedicated cluster.

A dedicated Ceph cluster serves three Proxmox clusters owned by different teams. All monitoring is currently storage-team-facing and every capacity question comes to the storage team.
Q4. Which four questions does a consumer of a dedicated cluster actually need answered?

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

Production discipline

Build a four-metric consumer-facing view per pool — availability, latency against commitment, remaining capacity, and planned work — rather than granting access to the full dashboard. Route per-pool capacity alerts to the owning team so growth becomes their concern rather than an unbounded demand on the storage team.

Cross-course references

Kubernetes: platform teams expose focused SLO views rather than full cluster dashboards
Linux: any shared service benefits from per-consumer attribution