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}.

—

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

Les 4 signaux à surveiller :

—

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

—

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], 5*24*3600)

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

—

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

—

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

—

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

—

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

—

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

—

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

—

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

Exemples de corrélation :

—

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”

—

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.