Comprendre les métriques clés d’un cluster Ceph (CephFS & MDS) pour l’exploitation

Thu, 19 Mar 2026 12:02:31 +0100

Introduction

Dans un environnement Kubernetes, Ceph est souvent utilisé comme backend de stockage (RBD ou CephFS). Pourtant, lorsqu’un incident survient côté applications (latence, timeouts, pods bloqués), le stockage est fréquemment suspect… sans être correctement analysé.

L’objectif de cet article est simple :

identifier les bonnes métriques Ceph
comprendre leur signification opérationnelle
savoir expliquer les impacts côté applications Kubernetes

On s’appuie ici sur les bonnes pratiques issues du monitoring Prometheus et notamment les Golden Signals (latence, erreurs, saturation, trafic) :contentReference[oaicite:0]{index=0}.

—

1. Vue d’ensemble : raisonner en “Golden Signals”

Ceph n’est pas un simple stockage : c’est un système distribué.

Les 4 signaux à surveiller :

Signal	Ce que ça veut dire dans Ceph	Impact Kubernetes
Erreurs	cluster en état dégradé	pods bloqués / crash
Latence	IO lentes	API lentes / timeouts
Saturation	disque plein	scheduling impossible
Trafic	charge IO	contention

—

2. Santé globale du cluster (LE KPI numéro 1)

Metric clé :

ceph_health_status

Interprétation :

1 = OK
!= 1 = problème critique :contentReference[oaicite:1]{index=1}

Graph recommandé :

Single stat + historique

`1`	`ceph_health_status`

Pourquoi c’est pertinent :

C’est l’indicateur synthétique du cluster
Corrélé directement à l’expérience utilisateur

Impact Kubernetes :

HEALTH_WARN → dégradations progressives
HEALTH_ERR → volumes indisponibles → pods KO

—

3. Saturation : capacité disque (le piège classique)

Metrics :

ceph_cluster_total_bytes
ceph_cluster_total_used_bytes :contentReference[oaicite:2]{index=2}

Graph recommandé :

`1`	`100 * ceph_cluster_total_used_bytes / ceph_cluster_total_bytes`

(type: ligne avec projection)

Ajout critique : prédiction

`1`	`predict_linear(ceph_cluster_total_used_bytes[1d], 5243600)`

Pourquoi c’est pertinent :

Anticipation (pas juste observation)
Détection des effets “runaway” (logs, snapshots, etc.)

Impact Kubernetes :

PVC provisioning FAIL
Pods Pending
CrashLoopBackOff si write impossible

—

4. Latence OSD : le vrai signal applicatif

Metrics :

ceph_osd_commit_latency_ms
ceph_osd_apply_latency_ms :contentReference[oaicite:3]{index=3}

Graph recommandé :

heatmap ou percentiles (P95/P99)

`1`	`avg(ceph_osd_commit_latency_ms)`

Pourquoi c’est critique :

reflète la vitesse réelle du stockage
directement corrélé aux performances applicatives

Lecture :

stable + basse → OK
spikes → contention ou disque lent

Impact Kubernetes :

DB lentes (Postgres, MySQL)
APIs timeout
queues qui explosent

—

5. Trafic : IOPS et throughput

Metrics :

ceph_osd_op_r / ceph_osd_op_w
ceph_osd_op_r_out_bytes / ceph_osd_op_w_out_bytes :contentReference[oaicite:4]{index=4}

Graph recommandé :

`1`	`rate(ceph_osd_op_r[5m])`

`1`	`rate(ceph_osd_op_w[5m])`

Pourquoi c’est pertinent :

Permet de comprendre qui consomme
Détecte les spikes applicatifs

Pattern classique :

trafic ↑ + latence ↑ = saturation
trafic stable + latence ↑ = problème infra

—

6. OSD & résilience (impact invisible mais critique)

Metrics :

ceph_osd_up
ceph_osd_recovery_ops :contentReference[oaicite:5]{index=5}

Graph recommandé :

nombre d’OSD up/down
recovery rate

`1`	`rate(ceph_osd_recovery_ops[5m])`

Pourquoi c’est critique :

un OSD down déclenche du rebalancing
le cluster devient plus lent pendant la reconstruction

Impact Kubernetes :

latence globale ↑
performance instable
risque accru si autre panne

—

7. CephFS : comprendre les métriques spécifiques

CephFS ajoute une couche critique : le metadata server (MDS).

Metric clé :

ceph_mds_request :contentReference[oaicite:6]{index=6}

Graph recommandé :

requêtes MDS / seconde

`1`	`rate(ceph_mds_request[5m])`

Pourquoi c’est important :

CephFS = metadata + data
saturation MDS = filesystem lent même si OSD OK

—

8. MDS : le cœur de CephFS

Rôle :

gestion des inodes / metadata
coordination accès fichiers

Si le MDS tombe : → plus d’accès au filesystem :contentReference[oaicite:7]{index=7}

—

Metrics critiques :

ceph_mds_metadata
disponibilité MDS
nombre de MDS actifs

`1`	`count(ceph_mds_metadata)`

—

Graph recommandé :

nombre de MDS actifs vs attendu

Cas critique :

MDS manquant

`1`	`count(ceph_mds_metadata == 1) == 0`

:contentReference[oaicite:8]{index=8}

—

Pourquoi c’est critique :

CephFS dépend du MDS pour TOUT
même si les disques sont OK → FS inutilisable

—

Impact Kubernetes :

volumes montés mais bloqués
pods en timeout IO
erreurs NFS-like

—

9. Quorum MON : stabilité du cluster

Metric :

ceph_mon_quorum_status :contentReference[oaicite:9]{index=9}

Graph recommandé :

nombre de MON en quorum

Pourquoi c’est critique :

perte de quorum = cluster non pilotable

Impact Kubernetes :

opérations bloquées
provisioning impossible

—

10. Lecture globale : corréler les métriques

Un bon exploitant ne regarde jamais une métrique seule.

Exemples de corrélation :

Symptôme	Analyse
Latence ↑ + OSD recovery ↑	rebuild en cours
Latence ↑ + trafic stable	disque lent
Saturation ↑ + trafic normal	fuite stockage
MDS OK + IO lentes	OSD problème
MDS KO + OSD OK	CephFS HS

—

11. Traduire pour un client / applicatif

Le rôle d’un responsable plateforme :

Ne pas dire :

“le cluster est en HEALTH_WARN”

Mais dire :

“les écritures sont 3x plus lentes → impact DB”
“le filesystem CephFS est indisponible → pods bloqués”
“on atteindra 100% disque dans 4 jours”

—

Conclusion

Surveiller Ceph efficacement, ce n’est pas multiplier les dashboards.

C’est :

comprendre les métriques structurantes
raisonner en impact applicatif
corréler les signaux

Les métriques essentielles à retenir :

Santé : ceph_health_status
Capacité : ceph_cluster_total_used_bytes
Latence : ceph_osd_commit_latency_ms
Trafic : ceph_osd_op_*
CephFS : ceph_mds_request
Disponibilité : MDS / MON / OSD

Un bon monitoring Ceph n’est pas technique.

C’est un outil de traduction entre stockage et application.

Devops on Atlanticaweb

Comprendre les métriques clés d’un cluster Ceph (CephFS & MDS) pour l’exploitation

Introduction

1. Vue d’ensemble : raisonner en “Golden Signals”

2. Santé globale du cluster (LE KPI numéro 1)

3. Saturation : capacité disque (le piège classique)

4. Latence OSD : le vrai signal applicatif

5. Trafic : IOPS et throughput

6. OSD & résilience (impact invisible mais critique)

7. CephFS : comprendre les métriques spécifiques

8. MDS : le cœur de CephFS

9. Quorum MON : stabilité du cluster

10. Lecture globale : corréler les métriques

11. Traduire pour un client / applicatif

Conclusion