CephLIV · ceph status and health detailceph status and health detail
Monitor status at a glance
What you'll learn
- Read mon stat and mon dump output
- Interpret monmap epochs and addresses
- Detect monitor configuration changes
- Verify monitor addressing after a change
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 monmap is how every client and daemon finds the monitors, and it is distributed rather than read from configuration. Understanding that is what explains why a monitor address change is a monmap operation rather than an edit.
mon stat
ceph mon state7: 5 mons at {ceph-mon-01=[v2:10.20.0.10:3300/0,v1:10.20.0.10:6789/0],...},
election epoch 412, leader 0 ceph-mon-01, quorum 0,1,2,3,4 ceph-mon-01,...| Element | Meaning |
|---|---|
e7 | monmap epoch — increments when the monitor set changes |
5 mons at {...} | the monitors and their addresses |
election epoch | increments on every election |
leader | the current leader |
quorum | ranks and names in quorum |
Two epochs, and they mean different things: the monmap epoch changes when monitors are added or removed, the election epoch on every election.
mon dump
ceph mon dump
ceph mon dump --format json | jq '.mons[] | {rank, name, public_addrs}'{"rank": 0, "name": "ceph-mon-01",
"public_addrs": {"addrvec": [
{"type": "v2", "addr": "10.20.0.10:3300"},
{"type": "v1", "addr": "10.20.0.10:6789"}]}}Each monitor advertises both v2 and v1 addresses where msgr2 is enabled, which is what allows older clients to connect during a migration.
Why addresses are in the monmap
The monmap is distributed to every client and daemon, and they use it to find the monitors. A monitor’s address is therefore not a configuration setting that can be edited — it is state the cluster holds and distributes.
# adding a monitor updates the monmap
ceph orch daemon add mon ceph-mon-06:10.20.0.16
ceph mon stat # epoch has incremented
# removing likewise
ceph mon rm ceph-mon-06Changing an existing monitor’s address requires removing and re-adding it, because the monmap entry is keyed to the monitor’s identity.
Detecting changes
ceph mon stat | grep -oE '^e[0-9]+'An unexpected monmap epoch change means monitors were added or removed. Recording the expected epoch and alerting on deviation catches unplanned changes.
Quiz
Knowledge check · 4 questions
Q1. A monitor host is renumbered. How is the monitor's address updated?
Q2. A client that has connected before survives the removal of the only monitor address in its configuration.
Q3. Detect an unplanned monitor change.
Monitoring alerts that the monmap epoch has changed from 7 to 8. No monitor maintenance was scheduled and the cluster reports HEALTH_OK with five monitors in quorum.
Q4. What is the difference between the monmap epoch and the election epoch?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Record the expected monmap epoch and alert on deviation; monitor additions and removals do not produce a health check and are otherwise invisible. List several monitor addresses in client configuration so a cold-start client is not dependent on one monitor still existing.
Cross-course references
- Kubernetes: etcd member list changes are similarly consequential and similarly quiet
- Linux: cluster membership changes warrant alerting in any distributed system