Hub de Connaissances DevOps
Hub de Connaissances DevOps

Dépannage de la santé des clusters Elasticsearch : Un guide étape par étape

Votre cluster Elasticsearch affiche-t-il un statut Jaune ou Rouge ? Ce guide complet et étape par étape vous accompagne à travers le processus de diagnostic critique. Apprenez à utiliser les API Cat essentielles, à interpréter l'explication d'allocation et à appliquer des solutions pratiques pour résoudre les shards primaires et les répliques non attribués. Assurez la sécurité des données et la résilience du cluster en maîtrisant les techniques de dépannage pour les erreurs de connectivité des nœuds, les contraintes d'espace disque et le réacheminement manuel des shards pour une récupération rapide.

36 vues

Dépannage de la Santé du Cluster Elasticsearch : Un Guide Étape par Étape

Elasticsearch est un système distribué robuste, mais comme toute architecture distribuée, il nécessite une surveillance active et une intervention occasionnelle pour maintenir une santé optimale. L'état de santé du cluster est la métrique la plus critique pour déterminer la disponibilité opérationnelle et la sécurité des données de votre déploiement. Lorsque le cluster passe de Vert à Jaune ou, de manière critique, à Rouge, l'intégrité ou la disponibilité des données est menacée.

Ce guide complet fournit des étapes d'expert pour diagnostiquer et résoudre les problèmes courants de santé du cluster Elasticsearch, en se concentrant spécifiquement sur la récupération des états Jaune et Rouge. Nous utiliserons les API Cat pratiques et des vérifications étape par étape pour identifier rapidement la cause profonde et mettre en œuvre les actions correctives.

1. Comprendre l'État de Santé du Cluster Elasticsearch

Avant de dépanner, il est essentiel de comprendre ce que signifie chaque couleur d'état du cluster. L'état de santé est déterminé par l'état d'allocation de vos shards primaires et répliques sur les nœuds du cluster.

Statut Signification Implications
Vert Tous les shards primaires et répliques sont alloués avec succès. Le cluster est entièrement opérationnel et résilient.
Jaune Tous les shards primaires sont alloués, mais un ou plusieurs shards répliques ne sont pas assignés. Les données sont disponibles, mais le cluster manque de résilience complète en cas de défaillance de nœud.
Rouge Au moins un shard primaire n'est pas assigné (et donc indisponible). Perte de données ou inaccessibilité pour l'index contenant le(s) shard(s) défaillant(s). Action critique requise.

2. Diagnostic Initial : Vérification de la Santé du Cluster

La première étape de tout processus de dépannage consiste à confirmer l'état actuel et à recueillir les métriques de base à l'aide de l'API Cluster Health et de l'API Nodes.

Étape 2.1 : Vérifier la Santé du Cluster

Utilisez l'API _cat/health pour obtenir un résumé de haut niveau. Le paramètre ?v fournit une sortie verbeuse, incluant le nombre de nœuds et le nombre total de shards.

GET /_cat/health?v

Exemple de Sortie (État Jaune) :

epoch      timestamp cluster       status node.total node.data shards  pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1678233600 09:00:00  my-cluster    yellow 3          3         10     5    0    0        5 0             -                  50.0%

Si le statut est Jaune ou Rouge, notez la valeur sous unassign.

Étape 2.2 : Vérifier l'État et la Mémoire des Nœuds

Assurez-vous que tous les nœuds attendus sont connectés et fonctionnent correctement. Vérifiez également l'utilisation du tas (heap) (critique pour la performance et la stabilité).

GET /_cat/nodes?v&h=name,node.role,version,heap.percent,disk.total,disk.used,disk.avail

Si un nœud est manquant dans cette liste, vous pourriez avoir un problème de connectivité ou un service arrêté.

3. Résolution de l'État Rouge du Cluster (Défaillance du Shard Primaire)

Un état Rouge signifie que les données sont immédiatement inaccessibles. L'objectif est de remettre le shard primaire en ligne le plus rapidement possible.

Étape 3.1 : Identifier les Shards Primaires Non Assignés

Utilisez l'API _cat/shards pour identifier l'index et le shard exacts qui causent le problème. Recherchez spécifiquement les entrées marquées comme UNASSIGNED avec un rôle p (primaire).

GET /_cat/shards?v | grep UNASSIGNED

Exemple de Sortie :

index_logs 0 p UNASSIGNED

Étape 3.2 : Vérifier l'Explication de l'Allocation

C'est l'étape de diagnostic la plus importante. L'API Allocation Explain vous indique pourquoi un shard spécifique (ou tout shard non assigné) ne peut pas être alloué.

GET /_cluster/allocation/explain

Raisons Courantes de l'État Rouge :

  1. Défaillance du Nœud : Le nœud qui hébergeait le shard primaire a planté ou a été retiré du cluster. Si le nœud défaillant avait suffisamment de répliques sur d'autres nœuds, le shard primaire devrait automatiquement promouvoir une réplique. Si toutes les copies (primaire et répliques) se trouvaient sur le nœud défaillant, le shard est perdu à moins que le nœud ne soit récupéré.
  2. Données Corrompues : Les fichiers du shard primaire sur le disque sont devenus corrompus, empêchant le nœud de les initialiser.

Étape 3.3 : Plan d'Action pour l'État Rouge

  • Scénario A : Nœud Hors Ligne (Préféré)
    • Si le nœud qui détenait le shard primaire est simplement hors ligne, restaurez le service du nœud (par exemple, redémarrez Elasticsearch ou corrigez les problèmes réseau). Une fois que le nœud rejoint le cluster, le shard primaire devrait récupérer.
  • Scénario B : Shard Primaire Perdu (Dernier Recours)
    • Si le nœud est perdu définitivement et qu'aucune réplique n'existait, les données sont perdues. Vous devez ignorer manuellement la récupération à l'aide de la commande allocate_empty_primary. Attention : Ceci créera un tout nouveau shard primaire, vide, entraînant une perte de données permanente pour ce segment de l'index.
POST /_cluster/reroute
{
  "commands" : [
    {
      "allocate_empty_primary" : {
        "index" : "[index-name]", 
        "shard" : [shard-id],
        "node" : "[target-node-name]", 
        "accept_data_loss" : true
      }
    }
  ]
}

Meilleure Pratique : Avant de recourir à allocate_empty_primary, vérifiez toujours qu'une snapshot ou une sauvegarde n'existe pas pour l'index.

4. Résolution de l'État Jaune du Cluster (Défaillance du Shard Réplique)

Un état Jaune signifie que le cluster est opérationnel mais vulnérable. L'objectif principal est d'allouer les répliques manquantes.

Étape 4.1 : Utiliser Allocation Explain

Si l'état est Jaune, utilisez l'API _cluster/allocation/explain (Section 3.2) pour comprendre pourquoi la réplique ne peut pas être assignée. L'explication pour les répliques est généralement plus simple.

Raisons Courantes de l'État Jaune :

Code de Raison Explication Correction
NO_AVAILABLE_NODES La taille du cluster est trop petite (par exemple, le nombre de répliques est 2, mais il n'y a que 2 nœuds existants). Ajoutez plus de nœuds de données ou réduisez number_of_replicas.
NOT_ENOUGH_DISK_SPACE Les nœuds ont atteint le seuil du watermark bas ou élevé. Supprimez les anciens index, libérez de l'espace disque ou ajustez les watermarks de disque.
ALLOCATION_DISABLED L'allocation des shards a été explicitement désactivée par les paramètres du cluster. Réactivez le routage via PUT /_cluster/settings.
PRIMARY_NOT_ACTIVE Le shard primaire est toujours en cours d'initialisation ou de récupération. Attendez que le primaire devienne actif (Vert).

Étape 4.2 : Vérifier les Exigences et Contraintes des Nœuds

Assurez-vous que le cluster répond aux exigences de base pour l'allocation des répliques :

  1. Nombre de Nœuds : Pour N répliques, vous avez besoin d'au moins N+1 nœuds de données pour garantir que le primaire et les répliques ne se trouvent jamais sur le même nœud.
  2. Watermarks de Disque : Elasticsearch cesse d'allouer des shards aux nœuds lorsque l'utilisation du disque dépasse le watermark élevé (90% par défaut).
# Vérifier les paramètres d'allocation de disque
GET /_cluster/settings?flat_settings=true&filter_path=*watermark*

# Exemple : Définir le watermark élevé à 95% (Temporairement !)
PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.high": "95%"
  }
}

Étape 4.3 : Reroute Manuel (Si la Logique d'Allocation Échoue)

Dans de rares cas, si le processus d'allocation standard semble bloqué malgré des ressources suffisantes, vous pouvez forcer manuellement l'allocation de la réplique à un nœud sain spécifique à l'aide de la commande allocate_replica.

POST /_cluster/reroute
{
  "commands" : [
    {
      "allocate_replica" : {
        "index" : "[index-name]", 
        "shard" : [shard-id],
        "node" : "[target-node-name]"
      }
    }
  ]
}

5. Dépannage Avancé et Pièges Courants

Si l'état Rouge ou Jaune persiste, la cause profonde peut se situer en dehors de la logique standard d'allocation des shards.

5.1 Connectivité Réseau et Split-Brain

Dans les systèmes distribués, la partitionnement (split-brain) peut provoquer de graves problèmes. Si les nœuds éligibles au rôle de maître ne peuvent pas communiquer, le cluster pourrait ne pas réussir à élire un maître stable, entraînant des shards non assignés.

  • Action : Vérifiez la connectivité réseau entre tous les nœuds, en particulier entre les nœuds éligibles au rôle de maître.
  • Vérification de Configuration : Assurez-vous que votre liste discovery.seed_hosts est exacte et que le paramètre cluster.initial_master_nodes a été correctement utilisé lors de l'amorçage du cluster.

5.2 Pression Mémoire JVM Élevée

Une utilisation excessive du tas (souvent supérieure à 75 %) entraîne des pauses de Garbage Collection (GC) fréquentes et longues. Pendant ces pauses, un nœud peut paraître insensible, incitant le nœud maître à le déconnecter, ce qui entraîne des shards non assignés.

  • Action : Surveillez l'utilisation du tas (_cat/nodes?h=heap.percent). Si elle est constamment élevée, envisagez d'augmenter la mémoire des nœuds, d'optimiser les processus d'indexation ou d'implémenter la gestion du cycle de vie des index (ILM).

5.3 Filtrage de l'Allocation des Shards

L'application accidentelle de filtres d'allocation (utilisant des attributs de nœud tels que des balises ou des ID) peut empêcher les shards d'être alloués à des nœuds qui seraient autrement éligibles.

# Vérifier les règles d'allocation au niveau de l'index
GET /[index-name]/_settings
# Rechercher : index.routing.allocation.require.*

# Réinitialiser les règles d'allocation de l'index (si nécessaire)
PUT /[index-name]/_settings
{
  "index.routing.allocation.require": null
}

Liste de Contrôle Récapitulative pour une Récupération Rapide

Statut Outil de Diagnostic Principal Étapes d'Action Clés
Jaune GET /_cluster/allocation/explain 1. Vérifier l'espace disque. 2. Vérifier le nombre de nœuds par rapport au nombre de répliques. 3. Rechercher les règles de filtrage d'allocation. 4. Attendre la récupération du primaire.
Rouge GET /_cat/shards?v | grep UNASSIGNED 1. Consulter les journaux sur le nœud qui hébergeait précédemment. 2. Essayer de redémarrer le nœud défaillant. 3. Si le primaire est confirmé perdu et qu'aucune sauvegarde n'existe, utiliser allocate_empty_primary (Risque de perte de données).

En utilisant systématiquement les API _cat et le point de terminaison critique _cluster/allocation/explain, vous pouvez identifier rapidement la cause de la dégradation de la santé du cluster et mettre en œuvre les étapes correctives nécessaires pour restaurer votre cluster à l'état stable Vert.