Dépannage : Vérification et interprétation de l'état de santé du cluster Elasticsearch

Elasticsearch est un moteur de recherche et d'analyse distribué et robuste, mais sa nature distribuée nécessite une surveillance constante pour garantir l'intégrité des données et une haute disponibilité. La première étape, et la plus cruciale, de l'administration consiste à vérifier l'état de santé du cluster. Un état sain garantit que tous les segments de données primaires et répliqués (shards) sont correctement assignés aux nœuds et opérationnels.

Ce guide propose une approche pratique pour vérifier l'état de santé du cluster à l'aide de l'API essentielle _cat/health. Nous détaillerons comment interpréter les statuts codés par couleur (Vert, Jaune, Rouge) et fournirons des étapes concrètes pour diagnostiquer et résoudre les problèmes courants d'instabilité, aidant ainsi les administrateurs à restaurer rapidement des performances optimales du cluster.

Comprendre l'état de santé d'Elasticsearch

Elasticsearch utilise un système simple de feux de signalisation codés par couleur pour communiquer l'état opérationnel des index et des shards du cluster. Cet état reflète l'état d'assignation des shards primaires et répliqués.

Les trois états de santé principaux

Statut	Signification	Disponibilité des données	Redondance	Action requise
Vert	Tous les shards primaires et répliqués sont assignés et opérationnels.	100 % disponible	Complète	Surveillance uniquement
Jaune	Tous les shards primaires sont assignés, mais un ou plusieurs shards répliqués ne sont pas assignés.	100 % disponible	Compromise	Investigation/Résolution de l'assignation des répliques
Rouge	Un ou plusieurs shards primaires ne sont pas assignés.	Perte/indisponibilité partielle ou totale des données	Gravement compromise	Intervention immédiate

Vérification de l'état de santé du cluster avec `_cat/health`

Les API _cat sont conçues pour des diagnostics rapides et lisibles par l'homme. Le point de terminaison _cat/health est le moyen le plus rapide d'obtenir un aperçu de l'état actuel du cluster.

Commande de base

Vous pouvez exécuter cette commande en utilisant cURL, la console Kibana Dev Tools, ou tout client HTTP.

# Utilisation de cURL (format lisible par l'homme)
curl -X GET "localhost:9200/_cat/health?v&pretty"

Interprétation de la sortie de `_cat/health`

Une requête réussie renvoie un tableau avec les métriques clés :

Colonne	Description
`epoch`	Le moment (timestamp Unix) où la requête a été exécutée.
`timestamp`	L'heure au format HH:MM:SS.
`cluster`	Le nom du cluster.
`status`	L'indicateur de couleur crucial (Vert, Jaune ou Rouge).
`node.total`	Nombre total de nœuds actuellement connectés au cluster.
`node.data`	Nombre de nœuds de données dans le cluster.
`shards`	Nombre total de shards (primaires + répliqués) qui devraient être actifs.
`pri`	Nombre total de shards primaires.
`relo`	Nombre de shards actuellement en cours de relocalisation entre les nœuds.
`init`	Nombre de shards en cours d'initialisation.
`unassign`	Nombre de shards actuellement non assignés.

Exemple d'un cluster sain (Vert) :

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign
1678886400 10:30:00  my-cluster-dev green         3         3     30  15    0    0        0

Diagnostic de l'état : Jaune

Lorsqu'un cluster signale un état Jaune, cela signifie que bien que toutes vos données soient techniquement disponibles (tous les shards primaires sont assignés), le niveau de redondance défini n'est pas atteint. Un ou plusieurs shards répliqués n'ont pas pu être alloués.

Causes courantes de l'état Jaune

Perte de nœud (temporaire) : Un nœud de données hébergeant des shards répliqués s'est déconnecté. Elasticsearch attend que ce nœud revienne ou qu'un nouveau nœud rejoigne avant de tenter une ré-allocation.
Nœuds insuffisants : Si vous avez besoin de 2 répliques (soit 3 copies des données au total) mais que vous n'avez que 2 nœuds de données, la troisième copie ne peut pas être placée, ce qui entraîne un état Jaune permanent jusqu'à ce qu'un autre nœud soit ajouté.
Allocation retardée : Le cluster est configuré pour retarder l'allocation des répliques après un échec de nœud afin d'éviter un rééquilibrage immédiat et coûteux si le nœud revient rapidement.
Contraintes d'espace disque : Les nœuds peuvent manquer d'espace disque pour héberger les shards répliqués.

Étapes concrètes pour l'état Jaune

Vérifier les shards non assignés : Utilisez l'API _cat/shards pour identifier précisément quels shards ne sont pas assignés (u) et pourquoi ils attendent.

bash curl -X GET "localhost:9200/_cat/shards?v"
Utiliser l'API Allocation Explain : Pour un diagnostic détaillé des raisons pour lesquelles un shard spécifique n'est pas assigné, utilisez l'API Allocation Explain. Remplacez index_name et shard_id ci-dessous par les valeurs réelles trouvées via _cat/shards.

bash curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" -H 'Content-Type: application/json' -d' { "index": "index_name", "shard": 0, "primary": false } '

Examinez spécifiquement les champs unassigned_info et decisions pour des raisons telles que CLUSTER_REBALANCE_ALLOCATION_DELAY ou NO_VALID_TARGET_NODE.
Vérifier le nombre et la configuration des nœuds : Assurez-vous que le nombre de nœuds de données est égal ou supérieur au nombre requis de répliques plus un (N répliques + 1 primaire).

Conseil : Si le cluster est Jaune en raison d'une maintenance à court terme connue sur un nœud, vous pouvez souvent l'ignorer temporairement, mais soyez conscient que vous fonctionnez sans redondance.

Diagnostic de l'état : Rouge

Un état Rouge est critique et signifie qu'un ou plusieurs shards primaires ne sont pas assignés. Cela signifie que les données stockées dans ce shard sont complètement indisponibles pour l'indexation ou la recherche.

Causes courantes de l'état Rouge

Panne massive de nœuds : Un nœud primaire est tombé en panne, et aucun autre nœud n'a pu prendre le rôle de primaire avec succès car les données étaient corrompues ou totalement indisponibles sur le cluster restant.
Corruption/panne de disque : Le périphérique de stockage contenant le shard primaire est tombé en panne, et aucune réplique n'existe pour être promue.
Problèmes de configuration d'index : Mauvaise configuration ou suppression incorrecte des fichiers d'index au niveau du système de fichiers.

Intervention immédiate pour l'état Rouge

Sauvegardez toujours votre cluster (via des snapshots) avant de tenter des actions de récupération manuelles lorsque le cluster est Rouge.

Vérifiez immédiatement les journaux : Examinez les journaux du nœud maître et du/des nœud(s) hébergeant le shard primaire défaillant pour identifier l'exception exacte ou la raison du crash (souvent liée à une panne de disque ou à des erreurs de mémoire insuffisante).
Identifiez l'index défaillant : Utilisez _cat/shards pour trouver l'index associé au shard primaire non assigné (p).

```bash

Recherchez les lignes où l'état est 'UNASSIGNED' et le type est 'p'

curl -X GET "localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason"
```
Tenter de forcer le reroutage (dangereux - à utiliser en dernier recours) : Si vous êtes certain que les données existent sur l'un des nœuds (par exemple, un nœud est revenu mais le routage ne s'est pas corrigé), vous pouvez essayer un reroutage manuel. Ceci est souvent utilisé lorsqu'un shard primaire est définitivement perdu et que vous décidez de supprimer les données perdues et de forcer un nouveau primaire vide sur un nœud sain.

```bash

ATTENTION : Cette commande peut entraîner une perte de données si elle est utilisée incorrectement.

Elle assigne un shard primaire vide à un nœud, marquant l'index comme sain.

curl -X POST "localhost:9200/_cluster/reroute?pretty" -H 'Content-Type: application/json' -d'
{
"commands" : [
{
"allocate_empty_primary" : {
"index" : "failed_index_name",
"shard" : 0,
"node" : "target_node_name",
"accept_data_loss" : true
}
}
]
}
'
```
Restaurer à partir d'un snapshot : Si le shard primaire défaillant ne peut pas être récupéré, la seule façon sûre de restaurer l'intégrité des données est de restaurer l'index affecté à partir du snapshot réussi le plus récent.

Diagnostic avancé : Paramètres du cluster

Parfois, l'état du cluster est Rouge ou Jaune en raison d'actions administratives ou de protections opérationnelles préconfigurées.

Vérification de l'allocation de routage du cluster

L'API _cluster/settings vous permet de vérifier si l'allocation automatique des shards a été explicitement désactivée, ce qui empêcherait le cluster de se réparer.

# Récupérer les paramètres actuels du cluster
curl -X GET "localhost:9200/_cluster/settings?include_defaults=true&pretty"

Recherchez spécifiquement le paramètre suivant :

{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation": {
          "enable": "none" 
        }
      }
    }
  }
}

Si cluster.routing.allocation.enable est défini sur none (ou primaries), Elasticsearch n'allouera pas les shards, bloquant le cluster dans son état actuel (probablement Jaune ou Rouge).

Réactivation de l'allocation

Pour restaurer l'allocation normale des shards, mettez à jour le paramètre sur all :

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}
'

Conclusion

Interpréter l'état de santé du cluster Elasticsearch est la compétence fondamentale de tout administrateur. L'API _cat/health fournit un aperçu immédiat de l'intégrité opérationnelle de vos données. Bien qu'un état Vert soit l'objectif, comprendre que Jaune signifie une redondance réduite et Rouge des données indisponibles permet un dépannage précis et immédiat à l'aide d'outils secondaires comme _cat/shards et l'API Allocation Explain. Une surveillance régulière et des snapshots proactifs restent les meilleures défenses contre une défaillance critique du cluster.