Surveillance et alertes Ceph : guide de mise en œuvre pratique

Introduction

La surveillance et les alertes Ceph avec des exemples pratiques devraient aider les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté.

Cet article se concentre sur la surveillance Ceph pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie les alertes Ceph, les métriques Ceph, le tableau de bord Ceph et la réponse aux incidents Ceph à des commandes, des sorties attendues, des signaux de défaillance et des décisions de récupération qui correspondent à la technologie sélectionnée.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire de la version et de l'environnement

Avant de surveiller ou d'alerter sur un cluster Ceph, vous devez savoir exactement ce que vous exécutez. L'inventaire capture la version de Ceph, l'outil de déploiement, le système d'exploitation, la topologie du cluster et les services clés qui doivent être observés. Ces informations sont la base de toute commande ultérieure, car les options, les noms de métriques et les règles d'alerte diffèrent entre les versions de Ceph.

Exécutez ces commandes en lecture seule sur n'importe quel nœud moniteur pour collecter les faits de l'environnement. Les commandes ne modifient pas l'état et sont sûres pour la production.

# Version et build de Ceph
ceph --version
# Sortie attendue : ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy (stable)

# État du cluster (compact)
ceph -s
# Sortie attendue (exemple) :
# cluster:
#   id:     a1b2c3d4-5678-90ab-cdef-1234567890ab
#   health: HEALTH_WARN
#            1 MDSs report slow metadata IOs
#            1 nearfull osd(s)
#   services:
#     mon: 3 daemons, quorum host1,host2,host3 (age 5d)
#     mgr: host1(active, since 2h), standbys: host2, host3
#     osd: 12 osds: 12 up (since 5d), 12 in (since 6d)
#   data:
#     pools:   3 pools, 257 pgs
#     objects: 45.12k objects, 168 GiB
#     usage:   502 GiB used, 3.5 TiB / 4.0 TiB avail
#     pgs:     257 active+clean

# Outil de déploiement (choisir un)
# Pour cephadm :
ceph orch status
# Pour ceph-deploy ou manuel :
ls /etc/ceph/

Prérequis pour ces commandes :

• Accès SSH à un nœud moniteur avec un utilisateur pouvant lire /etc/ceph/ceph.conf et le keyring admin.
• Le paquet CLI ceph installé, version correspondant au cluster.
• Accès réseau au port du moniteur Ceph (par défaut 6789).

Rayon d'impact : Aucun. Toutes les commandes sont en lecture seule.

Vérification : La sortie de ceph -s doit montrer le nombre attendu de moniteurs, OSD et pools. Si un service est manquant ou si la santé n'est pas HEALTH_OK, résolvez cela avant d'ajouter la surveillance, car une base malsaine produira des alertes bruyantes.

Récupération : Si ceph --version échoue avec permission denied, assurez-vous que votre utilisateur peut lire le keyring admin, généralement à /etc/ceph/ceph.client.admin.keyring. Si la commande n'est pas trouvée, installez ceph-common depuis le dépôt de votre distribution.

Enregistrez la version et la topologie dans un document d'opérations partagé. Exemple d'entrée :

Cluster ID : a1b2c3d4-5678-90ab-cdef-1234567890ab
Version Ceph : 17.2.6 (quincy) déployé avec cephadm sur Ubuntu 22.04
Hôtes moniteurs : mon01, mon02, mon03
Hôte manager : mon01
Nombre d'OSD : 12, tous HDD, bluestore
Pools : rbd (répliqué 3x), cephfs_data (erasure 4+2), cephfs_metadata (répliqué)

Chemin de configuration sûr

La surveillance et les alertes nécessitent souvent des modifications de configuration : activer le module Prometheus, ajuster les intervalles de collecte ou ajouter des règles d'alerte. Le chemin de configuration sûr sépare l'observation de l'intervention. Ne modifiez jamais un paramètre sans d'abord capturer l'état actuel et comprendre comment revenir en arrière.

Activation du module Prometheus

Le Ceph Manager (mgr) inclut un module exportateur Prometheus qui sert les métriques sur le port 9283. C'est la méthode recommandée pour exposer les métriques Ceph à Prometheus.

1. Observez les modules du manager actuels :

ceph mgr module ls
# Cherchez "prometheus" dans la liste enabled_modules. Extrait de sortie attendu :
# "enabled_modules": ["balancer", "dashboard", "iostat", "prometheus", "restful"]

1. Activez le module s'il est absent :

ceph mgr module enable prometheus
# Sortie attendue : module 'prometheus' is enabled (always on)

1. Vérifiez que le module est actif et que le point de terminaison écoute :

ceph mgr services
# La sortie attendue doit inclure :
# "prometheus": "http://mon01:9283/"

curl -s http://mon01:9283/metrics | head -n 5
# La sortie attendue commence par des lignes de métriques Prometheus, par exemple :
# # HELP ceph_health_status Health status of Cluster, can vary only between 3 states (err:2, warn:1, ok:0)
# # TYPE ceph_health_status gauge
# ceph_health_status 1.0

Prérequis :

• Cluster Ceph exécutant Nautilus (14.x) ou plus récent.
• Le démon manager (mgr) est actif et joignable.
• Le pare-feu autorise l'accès au port 9283 depuis le serveur Prometheus.

Rayon d'impact : Faible. L'activation du module n'affecte pas les opérations du plan de données. Il ajoute un point de terminaison de métriques sur le manager.

Chemin de récupération : Pour revenir en arrière, désactivez le module avec ceph mgr module disable prometheus. Le point de terminaison de métriques disparaît immédiatement.

Configuration du serveur Prometheus

Ajoutez une tâche de collecte à votre fichier de configuration Prometheus (généralement prometheus.yml) :

scrape_configs:
  - job_name: 'ceph-mgr'
    static_configs:
      - targets: ['mon01:9283', 'mon02:9283', 'mon03:9283']
        labels:
          cluster: 'production-ceph'
    metrics_path: /metrics
    scrape_interval: 15s
    scrape_timeout: 10s

Vérification : Après avoir rechargé Prometheus, vérifiez l'état des cibles à http://<prometheus>:9090/targets. Les cibles Ceph doivent afficher UP en vert. Si une cible affiche DOWN, vérifiez la connectivité réseau et que le module Prometheus du manager est actif.

Rayon d'impact : Modifier la configuration de Prometheus n'affecte pas Ceph lui-même, mais une collecte mal configurée peut surcharger le manager si trop de cibles ou des intervalles trop fréquents sont utilisés. Gardez l'intervalle de collecte à 15 s ou plus.

Chemin de récupération : Restaurez le prometheus.yml précédent et redémarrez Prometheus.

Éviter les modifications dangereuses

Ne modifiez jamais les configurations Ceph comme osd_max_backfills, mon_osd_down_out_interval ou les tailles de pool sans plan de retour en arrière. Par exemple, réduire mon_osd_down_out_interval peut entraîner le marquage des OSD comme hors service trop rapidement lors de problèmes réseau transitoires, conduisant à des mouvements de données et à une dégradation des performances.

Si vous devez modifier un tel paramètre, capturez d'abord la valeur actuelle :

ceph config get mon mon_osd_down_out_interval
# Sortie attendue : 300 (secondes)

Ensuite, effectuez la modification et enregistrez la commande pour revenir en arrière :

ceph config set mon mon_osd_down_out_interval 600
# Pour revenir en arrière :
ceph config set mon mon_osd_down_out_interval 300

Vérification : Exécutez ceph config get mon mon_osd_down_out_interval pour confirmer que la nouvelle valeur est appliquée. Ensuite, surveillez ceph -s pour tout rééquilibrage OSD inattendu.

Vérification et diagnostics

Une fois la surveillance en place, vous devez vérifier qu'elle reflète la réalité du cluster. Cette section couvre les commandes de diagnostic et comment interpréter les sorties typiques pour détecter les problèmes tôt.

Vérification de la santé du cluster

La commande de santé principale est ceph health detail. Elle fournit plus d'informations que le résumé de ceph -s.

ceph health detail
# Exemple de sortie attendue :
# HEALTH_WARN 1 MDSs report slow metadata IOs; 1 nearfull osd(s)
# [WRN] MDS_SLOW_METADATA_IO: 1 MDSs report slow metadata IOs
#     mds.cephfs.host1.up:active reported 13 slow metadata IOs in the last 60s
# [WRN] OSD_NEARFULL: 1 nearfull osd(s)
#     osd.5 is near full (85%)

Interprétation :

• MDS_SLOW_METADATA_IO peut indiquer des performances insuffisantes du pool de métadonnées ou un client de système de fichiers occupé. Enquêtez avec ceph daemon mds.<id> perf dump ou le graphique de performance MDS du tableau de bord.
• OSD_NEARFULL signifie qu'un OSD est au-dessus du seuil nearfull (par défaut 85 %). Action immédiate : ajouter de la capacité ou rééquilibrer. N'attendez pas full (95 %), car les écritures seront bloquées.

Vérification de la surveillance : Après avoir vu OSD_NEARFULL dans la CLI, vérifiez que Prometheus enregistre la métrique ceph_osd_nearfull et qu'une alerte est déclenchée. Par exemple, la règle d'alerte par défaut pour nearfull pourrait être :

- alert: CephOSDNearFull
  expr: ceph_osd_nearfull > 0
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Ceph OSD near full"
    description: "OSD {{ $labels.ceph_osd }} is above 85% capacity."

Analyse des performances

Utilisez ceph osd perf pour identifier les OSD lents.

ceph osd perf
# Sortie attendue (exemple) :
# osd commit_latency(ms) apply_latency(ms)
#   0                  2                  3
#   1                 25                 30
#   2                  3                  4
#   ...

Une latence élevée (dizaines de millisecondes ou plus) sur un seul OSD suggère un disque défaillant, un problème réseau ou un OSD surchargé. Corrélez avec smartctl et iostat sur l'hôte OSD.

Commande de diagnostic pour vérifier la distribution des données :

ceph osd df tree
# La sortie attendue montre l'utilisation par OSD, par exemple :
# ID CLASS WEIGHT  REWEIGHT SIZE    RAW USE DATA    OMAP    META     AVAIL   %USE  VAR  PGS STATUS
#  0   hdd 1.00000  1.00000 500 GiB  120 GiB 118 GiB   2 MiB 1.2 GiB 380 GiB 24.00 0.96  64     up
#  1   hdd 1.00000  1.00000 500 GiB  400 GiB 398 GiB   5 MiB 2.0 GiB 100 GiB 80.00 1.60  64     up

Une variance élevée (VAR > 1,5) indique une distribution inégale des données. Utilisez le module balancer pour la corriger :

ceph balancer status
# Sortie attendue : {"active": true, "last_optimize_duration": "0:00:07.123", "mode": "upmap", "no_optimization_needed": false}
ceph balancer eval
# Sortie attendue : "current cluster score: 0.1523 (lower is better)"

Si le score est élevé (par exemple > 0,5), exécutez ceph balancer optimize plan pour voir les changements qui seraient apportés, puis ceph balancer execute plan pour les appliquer.

Modes de défaillance et récupération

La surveillance doit vous aider à répondre aux défaillances. Cette section décrit les modes de défaillance Ceph courants, comment les détecter et comment récupérer.

Perte de quorum des moniteurs

Symptômes :

• ceph -s se bloque ou signale mon client: couldn't connect to cluster.
• La cible Prometheus pour le moniteur tombe en panne.

Détection :

ceph quorum_status
# Si le quorum est perdu, la commande échoue.
# Si le quorum existe, la sortie inclut une liste des moniteurs et leurs rangs.

Récupération :

1. Vérifiez les processus des moniteurs sur chaque hôte : systemctl status ceph-mon@<hostname>.
2. Redémarrez un moniteur en échec : systemctl restart ceph-mon@<hostname>.
3. Si une majorité de moniteurs sont en panne, vous devrez peut-être démarrer les moniteurs manuellement avec ceph-mon -i <id>.
4. Après la restauration du quorum, vérifiez avec ceph -s et ceph quorum_status.

Prévention : Alertes de moniteur avec Prometheus :

- alert: CephMonDown
  expr: ceph_mon_quorum_count < 2
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "Ceph monitor quorum lost"
    description: "Only {{ $value }} monitors in quorum."

Défaillance d'un OSD

Symptômes :

• ceph -s affiche HEALTH_WARN avec osd.X is down.
• Les applications signalent des erreurs d'E/S ou des délais d'attente.

Détection :

ceph osd tree
# Cherchez les OSD avec le statut 'down' ou 'out'.
# Exemple de sortie montrant osd.3 down :
# ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
# -1       0.09766 root default
# -3       0.04883     host host2
#  3   hdd 0.04883         osd.3    down  1.00000 1.00000

Récupération :

1. Enquêtez sur l'hôte OSD : systemctl status ceph-osd@3.
2. Si le disque a échoué, remplacez-le. Pour cephadm, supprimez l'OSD :

ceph orch device zap host2 /dev/sdX --force
ceph orch osd rm 3 --force

1. Ajoutez un nouvel OSD si un disque de remplacement est disponible : ceph orch apply osd --all-available-devices (à utiliser avec prudence).
2. Attendez le rééquilibrage et vérifiez que la santé revient à HEALTH_OK.

Prévention : Alerte sur OSD en panne :

- alert: CephOSDDown
  expr: ceph_osd_down > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Ceph OSD down"
    description: "OSD {{ $labels.ceph_osd }} is down."

OSD ou pool plein

Symptômes :

• Les écritures échouent avec -ENOSPC ou pool is full.
• ceph -s affiche HEALTH_ERR avec des OSD full ou nearfull.

Détection :

ceph df
# La sortie attendue inclut l'utilisation par pool :
# POOL            ID  PGS  STORED  OBJECTS  USED  %USED  MAX AVAIL
# rbd             1   64   80 GiB   20.48k  240 GiB  80.00     60 GiB

Si le %USED d'un pool approche 100 %, il est plein.

Récupération :

1. Identifiez et supprimez immédiatement les données inutiles si possible : rados -p <pool> rm <object>.
2. Étendez le cluster en ajoutant des OSD.
3. Augmentez le quota du pool si autorisé : ceph osd pool set-quota <pool> max_bytes <larger_value>.
4. Si le cluster est vraiment plein, vous devrez peut-être définir temporairement ceph osd set full et ceph osd set pause pour empêcher d'autres écritures pendant que vous libérez de l'espace.

Prévention : Définissez des alertes pour l'utilisation du pool :

- alert: CephPoolFull
  expr: (ceph_pool_percent_used > 85)
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Ceph pool above 85% usage"
    description: "Pool {{ $labels.name }} is {{ $value }}% full."

Liste de contrôle des opérations

Utilisez cette liste de contrôle quotidiennement ou hebdomadairement pour vous assurer que la surveillance et les alertes Ceph restent efficaces.

Vérifications quotidiennes :

• Exécutez ceph -s sur un moniteur. Confirmez que la santé est HEALTH_OK ou que tous les avertissements sont connus et suivis.
• Vérifiez les cibles Prometheus à http://prometheus:9090/targets. Toutes les cibles Ceph doivent être UP.
• Passez en revue les alertes actives dans Alertmanager (ou votre système d'alerte). Enquêtez sur toute nouvelle alerte.
• Vérifiez que la connexion au tableau de bord fonctionne et affiche l'état du cluster : https://mon01:8443.

Vérifications hebdomadaires :

• Passez en revue ceph df pour les tendances d'utilisation des pools. Planifiez une extension si un pool dépasse 70 %.
• Vérifiez l'équilibre de capacité des OSD avec ceph osd df tree. Exécutez le balancer si la variance > 1,5.
• Passez en revue les requêtes lentes : ceph daemon osd.0 perf dump | jq '.osd.op_latency' ou ceph osd perf.
• Validez les procédures de sauvegarde et de restauration pour la configuration Ceph et les keyrings.
• Testez la livraison des notifications d'alerte en envoyant une alerte de test depuis Alertmanager.

Vérifications mensuelles :

• Mettez à jour le document d'inventaire de l'environnement si des changements ont eu lieu.
• Passez en revue et élaguez les anciennes règles d'alerte bruyantes ou plus pertinentes.
• Vérifiez la santé des disques sur les hôtes OSD en utilisant smartctl -a /dev/sdX.
• Effectuez un exercice de défaillance : simulez un OSD en panne en arrêtant le service OSD et vérifiez que les alertes se déclenchent et que les étapes de récupération fonctionnent.

Chaque élément de la liste de contrôle doit avoir un propriétaire. Par exemple :

Conclusion

La surveillance et les alertes Ceph avec des exemples pratiques ne sont utiles que si chaque recommandation est versionnée, observable et réversible là où la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure opérationnelle.

Comme prochaine étape, choisissez une vérification à faible risque pour la surveillance Ceph, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et examinez les dépendances telles que Prometheus, le tableau de bord Ceph et les hôtes Linux sous-jacents.

Un flux de travail technique fiable rend la défaillance visible, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. En appliquant les commandes, les extraits de configuration et les règles d'alerte de ce guide, vous pouvez construire un système de surveillance Ceph qui fournit une alerte précoce et permet une récupération rapide.