Manager modules — which to enable and which to leave off

Intermediate⏱ ~15 minceph

What you'll learn

List the commonly used manager modules and their purpose
Enable and disable modules safely
Recognise the cost each module imposes
Choose a module set appropriate to a cluster

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

Modules are the manager’s entire feature surface. Some are effectively mandatory, some are valuable, and some cost collection time for data nobody reads — which matters on large clusters where manager collection time is already a constraint.

The module set

NAME=acme
ceph mgr module ls
ceph mgr module enable ${NAME}
ceph mgr module disable ${NAME}

Module	Provides	Recommendation
`cephadm`	orchestration	required for cephadm clusters
`prometheus`	metrics endpoint	enable; the basis of monitoring
`dashboard`	web UI	enable on most clusters
`balancer`	PG distribution	enable, in `upmap` mode
`pg_autoscaler`	pg_num management	enable, usually in `warn` mode first
`devicehealth`	SMART collection and history	enable
`alerts`	simple email alerting	only without external alerting
`telemetry`	anonymised upstream reporting	opt-in; useful to the project
`restful`	legacy REST API	superseded by dashboard API
`influx`, `zabbix`	metric exporters	only if that stack is in use
`insights`	health history summary	small, occasionally useful
`rgw`	RGW management in dashboard	enable if RGW is used

The ones that change cluster behaviour

Most modules only observe. Three act:

balancer moves PGs to even out distribution.

ceph balancer status
ceph balancer mode upmap
ceph balancer on

pg_autoscaler changes pg_num on pools.

# POOL is the pool to change, from `ceph osd pool ls`; substitute your own:
POOL=rbd

ceph osd pool set "$POOL" pg_autoscale_mode warn
ceph osd pool autoscale-status

cephadm deploys and removes daemons.

Start the autoscaler in warn mode on an existing cluster

pg_autoscale_mode on will change pg_num automatically, and on a cluster whose pools were sized by hand the first adjustment can be large — potentially moving a lot of data at a time nobody chose.

warn mode computes the recommendation and raises a health message without acting:

ceph osd pool set rbd-vms pg_autoscale_mode warn
ceph osd pool autoscale-status

Read the recommendation, decide whether you agree, and apply it in a window. Switching to on afterwards is reasonable once the pools are close to target and the cluster is stable.

The dashboard

ceph mgr module enable dashboard
ceph dashboard create-self-signed-cert
ceph dashboard ac-user-create admin -i /tmp/password administrator
ceph mgr services

The dashboard is genuinely useful for browsing state and for people who do not live in a terminal. It is also an authenticated web service on a storage cluster, so it deserves the same treatment as any other: a real certificate, restricted network exposure, and accounts with appropriate roles rather than a shared administrator login.

Why disabling unused modules is a real optimisation on large clusters

Each enabled module registers for events and periodically collects state. On a small cluster the cost is invisible. On a cluster with hundreds of OSDs and tens of thousands of PGs, several modules each walking that state add measurable time to every collection cycle.

The effect compounds with the Prometheus endpoint: the metrics response includes contributions from modules, so a slow module makes scrapes slow, which produces dashboard gaps that look like cluster problems.

The practical test is to measure. Time a ceph status and a curl of the Prometheus endpoint before and after disabling a module you do not use. On clusters where this matters, the difference is obvious; where it is not obvious, leave the module alone rather than optimising blind.

A sensible default set

For a typical cephadm cluster serving RBD:

cephadm, prometheus, dashboard, balancer, devicehealth, pg_autoscaler

Add rgw if object storage is in use. Add telemetry if you are willing to contribute anonymised data upstream. Leave the rest off until there is a reason.

Quiz

Knowledge check · 4 questions

Q1. Why should pg_autoscale_mode be set to warn rather than on when first enabled on an established cluster?

Because on mode is not supported on pools created before the autoscaler module existed Because the first automatic adjustment can move a large amount of data at a time nobody chose Because warn mode computes the target pg_num more accurately, having no deadline to act on Because on mode requires the balancer to be turned off first, and it rarely should be
Q2. Disabling unused manager modules can measurably reduce ceph status and Prometheus scrape times on large clusters.

True False
Q3. A team wants to enable the balancer on a cluster with significant manual reweights applied over several years. Advise.

120-OSD cluster, four years old. Roughly 30 OSDs have manual reweight values between 0.7 and 0.95 applied at various times to correct utilisation imbalance. Utilisation currently varies from 58% to 81% across OSDs. The balancer has never been enabled. The team wants to turn it on in upmap mode.
Q4. Name a sensible default module set for a cephadm cluster serving RBD, and justify each entry.

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

Production discipline

Enable the modules you use and leave the rest off — each one adds collection work that shows up as slow ceph status and slow scrapes on large clusters. Start pg_autoscale_mode in warn so the first recommendation is reviewed rather than executed. Reset manual reweights to 1.0 before enabling the balancer, since the two mechanisms fight. And treat the dashboard as the authenticated web service it is: real certificate, restricted exposure, per-person accounts.

Cross-course references

Ceph: Part X lesson on the balancer for upmap in depth.
Ceph: Part XXI (PG Autoscale) for the autoscaler in operation.
Ceph: Part CII (Management Security) for securing the dashboard.