Résolution du statut rouge du cluster : un guide de dépannage Elasticsearch étape par étape

Un statut rouge du cluster Elasticsearch signifie qu'au moins un shard primaire n'est pas alloué. C'est ce qui compte. Certaines données peuvent être indisponibles, les recherches sur les index affectés peuvent renvoyer des résultats partiels ou échouer, et les écritures sur ces shards ne peuvent pas se dérouler normalement.

Le jaune est différent : les primaires sont alloués, mais un ou plusieurs réplicas ne le sont pas. Le jaune mérite toujours de l'attention car vous avez moins de redondance, mais le rouge est l'incident. Ne commencez pas par supprimer des données ou réacheminer les shards manuellement. Trouvez d'abord quel primaire n'est pas attribué et pourquoi Elasticsearch refuse de l'allouer.

Comprendre la santé du cluster Elasticsearch

Elasticsearch fournit une API de santé du cluster qui offre un instantané de l'état du cluster et de l'allocation des shards. Cette API est votre outil principal pour diagnostiquer les problèmes de santé.

GET _cluster/health

La sortie de cette commande inclura un champ status, qui peut être green, yellow ou red. Elle fournit également des informations sur le nombre de shards actifs et non attribués.

• Vert : Tous les shards primaires et réplicas sont alloués et fonctionnent correctement.
• Jaune : Tous les shards primaires sont alloués, mais certains shards réplicas ne sont pas attribués.
• Rouge : Un ou plusieurs shards primaires ne sont pas attribués, entraînant une indisponibilité des données pour ces shards.

Utilisez un appel de santé plus détaillé lorsque vous êtes en incident :

GET _cluster/health?level=indices

Ensuite, listez les shards non attribués :

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index

Causes courantes et étapes de dépannage pour le statut rouge/jaune

Lorsque votre cluster n'est pas vert, il est temps d'enquêter. Voici les raisons les plus courantes des shards non attribués et comment y remédier :

1. Espace disque insuffisant

Elasticsearch dispose de mécanismes de protection pour éviter la corruption des données due à des disques pleins. Si un nœud manque d'espace disque, il empêchera l'allocation de nouveaux shards ou la récupération des shards existants.

Diagnostic :

• Vérifiez l'utilisation du disque sur chaque nœud.
• Utilisez l'API d'explication de l'allocation du cluster pour comprendre pourquoi les shards ne sont pas attribués.

GET _cluster/allocation/explain

Cette API fournira des explications détaillées, pointant souvent vers les seuils de disque.

Résolution :

• Libérez de l'espace disque : Supprimez les anciens index, déplacez les données vers un autre niveau ou ajoutez de la capacité. Forcer la fusion des index actifs n'est pas une solution rapide pour libérer de l'espace disque et peut ajouter une lourde charge d'E/S pendant un incident.
• Ajoutez plus d'espace disque : Augmentez la capacité de stockage de vos nœuds.
• Configurez les seuils de disque : Ajustez cluster.routing.allocation.disk.watermark.low, high et flood_stage uniquement lorsque les valeurs actuelles sont incorrectes pour votre environnement. Augmenter les seuils peut faire gagner du temps, mais peut aussi masquer un véritable problème de capacité.

2. Un nœud a quitté le cluster (éviction de nœud)

Les nœuds peuvent quitter un cluster en raison de problèmes réseau, de plantages ou d'une suppression intentionnelle. Si un nœud contenant des shards (en particulier des shards primaires) quitte, ces shards deviennent non attribués.

Diagnostic :

• Vérifiez les journaux du cluster pour les nœuds qui ont récemment quitté.
• Surveillez la connectivité réseau entre les nœuds.
• Assurez-vous que tous les nœuds sont découvrables les uns par les autres. Vérifiez discovery.seed_hosts, la connectivité de transport et les journaux du cluster. Ne réintroduisez pas cluster.initial_master_nodes dans un cluster existant formé comme correctif générique.

Résolution :

• Redémarrez le nœud : Si le nœud a planté ou est devenu non réactif, essayez de le redémarrer.
• Résolvez les problèmes réseau : Résolvez tout problème de connectivité réseau entre les nœuds.
• Réajoutez le nœud : Si le nœud a été intentionnellement supprimé, assurez-vous qu'il est correctement configuré avant de rejoindre le cluster.

3. Filtrage et sensibilisation de l'allocation des shards

Des règles d'allocation de shards mal configurées peuvent empêcher l'attribution des shards aux nœuds disponibles.

Diagnostic :

• Examinez vos paramètres cluster.routing.allocation.*, en particulier les filtres cluster.routing.allocation.include, exclude et require.
• Vérifiez cluster.routing.allocation.awareness.attributes si vous utilisez la sensibilisation aux zones ou aux racks.

Résolution :

• Ajustez les filtres d'allocation : Modifiez les filtres pour permettre l'allocation des shards aux nœuds appropriés.
• Corrigez les attributs de sensibilisation : Assurez-vous que les nœuds sont correctement étiquetés avec les attributs de sensibilisation s'ils sont utilisés, et que vos règles d'allocation les respectent.

4. Espace disque insuffisant pour l'allocation (après la création de l'index)

Même si un disque n'est pas plein, Elasticsearch peut empêcher l'allocation des shards s'il prédit que le disque dépassera les seuils élevés après l'allocation. Cela est lié aux seuils de disque mais affecte spécifiquement les nouvelles allocations.

Diagnostic :

• L'API _cluster/allocation/explain est inestimable ici.
• Vérifiez l'espace libre disponible par rapport à la taille attendue des shards.

Résolution :

• Similaire au problème général d'espace disque : libérez de l'espace, ajoutez plus de stockage ou ajustez les seuils avec prudence.

5. Taille des shards et capacité des nœuds

Des shards très volumineux ou un grand nombre de shards peuvent solliciter les ressources du nœud (CPU, mémoire) et affecter l'allocation. De plus, si un nœud a atteint sa limite de shards (cluster.routing.allocation.total_shards_per_node), les nouveaux shards ne lui seront pas attribués.

Diagnostic :

• Vérifiez les tailles des shards (GET _cat/shards?v).
• Surveillez l'utilisation des ressources du nœud (CPU, mémoire).
• Examinez le paramètre cluster.routing.allocation.total_shards_per_node.

Résolution :

• Réduisez la pression des shards : Pour les futurs index, ajustez le rollover et le nombre de shards afin que les shards se situent dans une plage de taille gérable. Pour les index existants, utilisez la réindexation, la réduction ou la division uniquement après que le cluster soit suffisamment stable pour gérer le travail.
• Augmentez la capacité des nœuds : Ajoutez des nœuds plus puissants ou des nœuds avec plus de mémoire/CPU.
• Ajustez la limite de shards : Si nécessaire et si vous disposez de ressources suffisantes, augmentez cluster.routing.allocation.total_shards_per_node.

6. Problèmes de nœud maître

Un nœud maître instable peut entraîner des problèmes d'allocation des shards. Si le maître est indisponible ou incapable d'effectuer ses tâches, les shards peuvent devenir non attribués.

Diagnostic :

• Vérifiez les journaux du cluster pour les erreurs ou avertissements liés au maître.
• Assurez-vous d'avoir un nombre impair de nœuds éligibles au maître (généralement 3 ou 5) pour éviter les scénarios de split-brain.
• Vérifiez que les nœuds éligibles au maître peuvent élire un maître.

Résolution :

• Stabilisez le maître : Assurez-vous que les nœuds éligibles au maître sont sains, disposent de ressources suffisantes et sont bien connectés.
• Vérifiez l'historique d'amorçage : cluster.initial_master_nodes est destiné uniquement à la première formation du cluster. Après l'amorçage, supprimez-le des configurations de nœud et résolvez l'instabilité du maître via les journaux, la mise en réseau du transport et la configuration de vote.

Dépannage avancé avec _cluster/allocation/explain

L'API _cluster/allocation/explain est votre outil le plus puissant pour comprendre pourquoi un shard spécifique n'est pas attribué.

Exemple :

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

Cela renverra une sortie JSON détaillée expliquant pourquoi le shard primaire 0 de my-index ne peut pas être alloué. Recherchez des champs comme deciders qui listent les raisons de la non-attribution (par exemple, DISK_THRESHOLD, NODE_LEFT, NO_VALID_SHARD_COPY).

Résolution du statut jaune du cluster

Un statut jaune signifie que les shards primaires sont alloués, mais pas les réplicas. Cela impacte principalement la redondance des données et la tolérance aux pannes.

Causes courantes :

• Nœuds insuffisants : Vous n'avez pas assez de nœuds pour accueillir le nombre requis de réplicas pour vos index.
• Filtrage de l'allocation des shards : Similaire au statut rouge, les filtres peuvent empêcher l'allocation des réplicas.
• Contraintes d'espace disque : Les nœuds peuvent avoir suffisamment d'espace pour les shards primaires mais pas assez pour les réplicas, surtout si les seuils de disque sont actifs.

Résolution :

• Ajoutez plus de nœuds : Augmentez le nombre de nœuds dans votre cluster.
• Ajustez le nombre de réplicas : Réduisez le nombre de réplicas par index (index.number_of_replicas) si la tolérance aux pannes n'est pas critique pour tous les index.
• Vérifiez les paramètres d'allocation : Assurez-vous que les shards réplicas sont autorisés à être alloués aux nœuds disponibles.

Meilleures pratiques pour maintenir la santé du cluster

• Surveillez l'utilisation du disque : Surveillez de manière proactive l'espace disque sur tous les nœuds et configurez des alertes.
• Dimensionnez correctement votre cluster : Assurez-vous d'avoir suffisamment de nœuds et de ressources pour votre volume de données et votre charge de requêtes.
• Gestion des shards : Maintenez les tailles de shards dans les plages recommandées et évitez le sur-sharding.
• Examinez régulièrement la santé du cluster : Utilisez GET _cluster/health et GET _cluster/allocation/explain dans le cadre de votre surveillance de routine.
• Testez les modifications : Avant d'apporter des modifications importantes aux paramètres d'allocation ou aux seuils de disque, testez-les dans un environnement de staging.

Une fois que vous connaissez le décideur d'allocation, le chemin est généralement clair. Le seuil de disque signifie la capacité. NODE_LEFT signifie récupérer ou remplacer le nœud manquant. NO_VALID_SHARD_COPY signifie que vous pourriez avoir besoin d'une restauration à partir d'un snapshot ou d'une décision délibérée de perte de données en utilisant les procédures de récupération non sécurisées documentées d'Elasticsearch. Ce dernier cas doit être traité lentement, en vérifiant d'abord les sauvegardes, car la commande qui sort le cluster du rouge peut également confirmer la perte permanente des dernières données du primaire manquant.