CephLIV · ceph status and health detailceph status and health detail
Reading ceph -s line by line
What you'll learn
- Interpret every section of ceph -s output
- Identify what each field is telling you
- Spot the values that warrant attention
- Use it as the entry point to a diagnosis
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
ceph -s is the first command in every investigation and the one whose
output is most often skimmed. Reading it properly frequently answers the
question without a second command.
The output
ceph -s cluster:
id: 8f3a2b1c-4d5e-6f70-8192-a3b4c5d6e7f8
health: HEALTH_WARN
1 osds down
Degraded data redundancy: 41213/18442104 objects degraded (0.223%)
services:
mon: 5 daemons, quorum ceph-mon-01,ceph-mon-02,ceph-mon-03,ceph-mon-04,ceph-mon-05 (age 3w)
mgr: ceph-mon-01(active, since 3w), standbys: ceph-mon-02
mds: 1/1 daemons up, 1 standby
osd: 120 osds: 119 up (since 14m), 120 in (since 3w)
rgw: 4 daemons active (4 hosts, 1 zones)
data:
volumes: 1/1 healthy
pools: 9 pools, 4353 pgs
objects: 18.44M objects, 62 TiB
usage: 187 TiB used, 776 TiB / 963 TiB avail
pgs: 4251 active+clean
102 active+recovering+degraded
io:
client: 142 MiB/s rd, 88 MiB/s wr, 4.21k op/s rd, 1.84k op/s wr
recovery: 412 MiB/s, 103 objects/sThe fields that matter
mon: ... (age 3w) — how long quorum has been stable. A short age
means a recent election, which is worth explaining.
osd: 120 osds: 119 up (since 14m), 120 in (since 3w) — two counts
and two ages. 119 up and 120 in means one OSD is down but not out, so
no data has moved yet. The since 14m dates the failure.
mgr: ... (active, since 3w) — a recently-restarted manager explains
missing metrics.
pgs: — the state breakdown. Anything other than active+clean is
the thing to investigate, and the counts give the scale.
usage: — used, available, and total. The gap between available and
total accounts for replication.
io: client — current client load, useful for judging whether an
observation correlates with load.
io: recovery — the rate. Compare it across two samples to establish
whether recovery is progressing.
Using it as an entry point
| Observation | Next command |
|---|---|
| health not OK | ceph health detail |
| osd up < in | ceph osd tree | grep down |
| PGs not active+clean | ceph pg dump_stuck |
| quorum age short | ceph -w | grep election |
| recovery rate zero with degraded PGs | ceph pg dump_stuck unclean |
| usage high | ceph osd df | sort -k17 -rn |
Quiz
Knowledge check · 4 questions
Q1. `ceph -s` reports `osd: 120 osds: 119 up (since 14m), 120 in (since 3w)`. What does this tell you?
Q2. A `ceph -s` that omits the data and io sections points at the manager rather than at the cluster.
Q3. Extract a diagnosis from a single status output.
`ceph -s` shows HEALTH_WARN, mon quorum age of 40 seconds, mgr active since 40 seconds, 120 osds all up and in, and all PGs active+clean.
Q4. Why can `ceph -s` hang entirely?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Read the OSD up and in counts with their ages rather than skimming
them; four facts about a failure come from that one line. Treat a ceph -s that hangs as a quorum diagnosis and one missing the data sections as
a manager diagnosis, rather than as an unresponsive command.
Cross-course references
- Kubernetes:
kubectl get nodeswith ages carries the same density of information - Linux: reading a status summary carefully before running further commands is general practice