CephCXI · Manager RecoveryManager Recovery
Verifying manager state
What you'll learn
- Read manager state from stat, dump, and module ls
- Detect a module failure inside a healthy manager
- Treat standby count as a capacity number
- Choose the manager signals worth watching continuously
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 mgr stat reporting available means a manager registered with the
monitors — nothing more — and a manager whose dashboard, prometheus, and
orchestrator modules all failed on load reports exactly the same thing.
The three views
ceph mgr stat
{"epoch":214,"available":true,"active_name":"ceph-a.qkjvzt","num_standby":2}
ceph mgr dump | python3 -c '
import sys,json
d = json.load(sys.stdin)
print("active: ", d["active_name"])
print("active_change:", d["active_change"])
print("available: ", d["available"])
print("standbys: ", [s["name"] for s in d["standbys"]])
print("services: ", d.get("services"))'
ceph mgr module ls --format json | python3 -c '
import sys,json
d = json.load(sys.stdin)
print("enabled: ", ",".join(sorted(d["enabled_modules"])))
for m in d.get("disabled_modules", []):
if not m.get("can_run") or m.get("error_string"):
print("BLOCKED %-16s %s" % (m["name"], m.get("error_string") or "cannot run"))'
| View | Answers |
|---|---|
ceph mgr stat | is there an active manager, and how many spares |
ceph mgr dump | who, since when, at what address, offering what services |
ceph mgr module ls | which modules are enabled, blocked, or broken |
ceph mgr services | the URLs the modules actually published |
A healthy manager with a broken module
CRASH_ID=2026-08-18T02:11:04.128Z_9f2c
ceph health detail | grep -A4 -E 'MGR_MODULE_ERROR|MGR_MODULE_DEPENDENCY|RECENT_MGR_MODULE_CRASH'
ceph crash ls | tail -5
ceph crash info ${CRASH_ID}
ceph log last 100 debug cephadm | tail -20
| Signal | Meaning |
|---|---|
MGR_MODULE_ERROR | a module raised and is not serving |
MGR_MODULE_DEPENDENCY | a module cannot run — usually a missing Python package |
RECENT_MGR_MODULE_CRASH | a module raised at runtime and was recorded |
Empty ceph mgr services | modules that should publish a URL did not start |
Standby count is a capacity number
ceph orch ls mgr
ceph mgr stat --format json | python3 -c '
import sys,json
d = json.load(sys.stdin)
if not d["available"]:
print("CRITICAL: no active manager")
elif d["num_standby"] == 0:
print("WARNING: single manager, next failure is a full outage")
else:
print("ok: active plus %d standby" % d["num_standby"])'
A cluster with one manager and no standby raises no health warning on its
own. If nobody watches num_standby, nobody finds out until the outage.
What to watch continuously
| Signal | Source | Why it matters |
|---|---|---|
available false | ceph mgr stat | no manager at all |
num_standby zero | ceph mgr stat | the next failure is total |
active_change moving | ceph mgr dump | flapping starves periodic work |
Non-empty error_string | ceph mgr module ls | a dead module in a live manager |
RECENT_MGR_MODULE_CRASH | ceph health detail | a module raised while serving |
| Manager RSS growth | host metrics | prometheus scales with OSD count |
Quiz
Knowledge check · 4 questions
Q1. Why does a failed manager module leave the manager reporting available?
Q2. A cluster running exactly one manager with no standby raises a health warning.
Q3. Investigate a dashboard that is unreachable while the cluster is healthy.
The Ceph dashboard has been unreachable since a manager failover last night. `ceph -s` is HEALTH_OK and `ceph mgr stat` reports available true with two standbys.
Q4. Why is a moving `active_change` timestamp worth alerting on?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Check ceph mgr module ls alongside ceph mgr stat; the first says
whether anything is serving and the second only says whether a daemon
registered. Alert explicitly on num_standby reaching zero, because Ceph
raises no health warning for a single manager and the deficiency is
discovered by the outage otherwise.
Cross-course references
- Kubernetes: a Running pod with a crashed sidecar reports Ready if the probe never covers the sidecar
- Linux: a supervisor that restarts threads silently converts failures into missing work