Analyse des journaux Elasticsearch courants pour un dépannage efficace
Elasticsearch est un moteur de recherche et d'analyse distribué puissant, mais sa complexité fait qu'en cas de problème, le diagnostic de la cause première peut être difficile. L'outil le plus important pour un dépannage efficace est le fichier journal d'Elasticsearch. Ces journaux servent de journal opérationnel du système, enregistrant tout, des séquences de démarrage réussies et de la maintenance de routine du cluster aux pannes critiques comme les déclenchements de disjoncteurs de mémoire ou les échecs d'allocation de shards.
Maîtriser l'art de lire et d'interpréter ces journaux est essentiel pour maintenir un cluster sain et performant. Ce guide fournit une approche complète pour comprendre la structure des journaux Elasticsearch, identifier les messages critiques et utiliser l'analyse des journaux pour localiser et résoudre rapidement les problèmes opérationnels courants, y compris les problèmes de santé du cluster, les contraintes de ressources et les goulots d'étranglement de performance.
1. Comprendre la structure des journaux Elasticsearch
Elasticsearch utilise le framework Apache Log4j 2 pour la journalisation. Par défaut, les journaux sont écrits dans des fichiers, souvent au format JSON pour un meilleur traitement par machine, bien que le texte brut soit également courant selon la configuration.
Emplacement par défaut des journaux
Les fichiers journaux principaux se trouvent généralement aux emplacements suivants, en fonction de votre méthode d'installation (par exemple, package RPM/DEB, Docker ou fichier ZIP) :
| Type d'installation | Chemin typique du journal |
|---|---|
| RPM/DEB (Linux) | /var/log/elasticsearch/ |
| Docker | Sortie standard du conteneur (stdout/stderr) |
| ZIP/Tarball | $ES_HOME/logs/ |
Anatomie d'une entrée de journal
Chaque entrée de journal, en particulier au format JSON, contient plusieurs champs clés essentiels pour le contexte :
@timestamp: Moment où l'événement s'est produit.level: Sévérité de l'événement (par exemple,INFO,WARN,ERROR).component: Classe ou service Elasticsearch spécifique qui a généré le message (par exemple,o.e.c.c.ClusterService,o.e.n.Node). Cela aide à réduire le sous-système responsable.cluster.uuid: Identifie le cluster auquel appartient le journal.node.name: Identifie le nœud qui a généré le journal.message: Description de l'événement.
{
"@timestamp": "2024-01-15T10:30:00.123Z",
"level": "WARN",
"component": "o.e.c.r.a.DiskThresholdMonitor",
"cluster.uuid": "abcde12345",
"node.name": "es-node-01",
"message": "high disk watermark [90%] exceeded on [es-node-01]"
}
2. Prioriser le dépannage avec les niveaux de journalisation
L'interprétation du champ level est le moyen le plus rapide de prioriser les problèmes. Vous devez généralement filtrer les journaux pour vous concentrer d'abord sur les messages WARN et ERROR.
| Niveau | Description | Priorité d'action |
|---|---|---|
| ERROR | Pannes critiques entraînant une interruption de service ou une perte de données (par exemple, arrêt du nœud, panne majeure de shard). | Immédiate |
| WARN | Problèmes potentiels ou états nécessitant une surveillance (par exemple, paramètres dépréciés, faible espace disque, disjoncteur approchant des limites). | Élevée |
| INFO | Messages opérationnels généraux (par exemple, démarrage du nœud, création d'index, allocation de shard terminée). | Faible/Surveillance |
| DEBUG/TRACE | Journalisation très verbeuse utilisée uniquement lors d'un diagnostic approfondi ou du développement. | N/A (Sauf débogage actif) |
Meilleure pratique : Évitez d'exécuter un cluster de production avec une journalisation définie sur
DEBUGouTRACE, car cela peut rapidement consommer de l'espace disque et introduire une surcharge de performance.
3. Dépannage des scénarios courants via les journaux
Les journaux Elasticsearch fournissent des indicateurs directs pour divers types de pannes. Voici les modèles de journaux critiques à surveiller dans différents scénarios.
3.1. Problèmes de démarrage et de santé du cluster
Si un nœud ne parvient pas à rejoindre le cluster ou si le cluster reste rouge/jaune, recherchez les journaux générés pendant la séquence de démarrage.
A. Échecs des vérifications de démarrage (Bootstrap Checks)
Elasticsearch effectue des vérifications de démarrage obligatoires au démarrage (par exemple, s'assurer de la mémoire adéquate, des descripteurs de fichiers et de la mémoire virtuelle). Si celles-ci échouent, le nœud s'arrête immédiatement.
Modèle de journal : Recherchez les messages bootstrap checks failed.
[2024-01-15T10:00:00,123][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] bootstrap checks failed
[2024-01-15T10:00:00,124][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
B. Échecs de liaison réseau et de découverte
Problèmes où les nœuds ne peuvent pas se lier aux ports requis ou ne peuvent pas trouver d'autres membres du cluster.
Modèle de journal : Recherchez BindException ou Discovery failure.
3.2. Gestion des ressources (Mémoire et JVM)
Les problèmes liés à la mémoire se manifestent souvent par des baisses de performance intermittentes ou une instabilité du nœud. Les journaux sont cruciaux pour suivre la santé de la JVM.
A. Exceptions de disjoncteur (Circuit Breaker)
Le disjoncteur empêche l'épuisement des ressources en arrêtant les opérations qui dépassent les limites de mémoire configurées. Lorsqu'il est déclenché, les opérations échouent rapidement, mais le nœud reste stable.
Modèle de journal : Recherchez CircuitBreakerException ou Data too large.
[2024-01-15T11:45:20,500][WARN][o.e.c.c.CircuitBreakerService] [es-node-02] \nCircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [123456789b], which is larger than the limit of [100.0/500mb]
B. Problèmes de ramasse-miettes (Garbage Collection - GC) de la JVM
Bien que les journaux GC détaillés soient souvent séparés, le journal principal d'Elasticsearch signale parfois une activité GC élevée ou de longues pauses GC (événements d'arrêt du monde).
Modèle de journal : Recherchez les références GC, surtout si des messages WARN ou ERROR concernant de longues pauses apparaissent.
3.3. Échecs d'indexation et de shard
Les échecs d'indexation ou les données corrompues déclenchent souvent des événements d'échec de shard.
A. Allocation et échec de shard
Lorsqu'un shard ne parvient pas à s'allouer, ou qu'un nœud détecte un problème de corruption avec une copie de shard locale, cela est consigné.
Modèle de journal : Recherchez shard failed ou failed to recovery.
[2024-01-15T12:05:10,999][ERROR][o.e.i.e.Engine] [es-node-03] [my_index][2] fatal error in engine loop
java.io.IOException: Corrupt index files, checksum mismatch
B. Seuils d'eau (Watermarks) de disque
Elasticsearch surveille l'espace disque et empêche les écritures lorsque certains seuils sont atteints, ce qui peut entraîner des échecs d'indexation.
Modèle de journal : Recherchez les avertissements DiskThresholdMonitor, indiquant généralement une utilisation de 85 % (low) ou 90 % (high).
4. Optimisation des performances avec les journaux lents (Slow Logs)
Pour l'analyse des performances, en particulier les requêtes ou les opérations d'indexation lentes, les journaux principaux du cluster sont souvent insuffisants. Elasticsearch utilise des Journaux Lents spécialisés.
Les journaux lents suivent les opérations qui dépassent les seuils de temps prédéfinis. Ils doivent être configurés explicitement, soit statiquement dans elasticsearch.yml, soit dynamiquement via l'API de paramètres d'index.
Configuration des seuils dynamiques des journaux lents
Vous pouvez définir différents seuils pour les phases d'indexation et de recherche. L'exemple suivant définit un seuil WARN de 1 seconde pour les requêtes de recherche sur un index spécifique.
PUT /my_index/_settings
{
"index.search.slowlog.threshold.query.warn": "1s",
"index.search.slowlog.threshold.query.info": "500ms",
"index.indexing.slowlog.threshold.index.warn": "1s"
}
Interprétation des entrées de journaux lents
Les journaux lents fournissent des informations détaillées sur l'exécution de la requête, y compris l'index/shard spécifique, le temps passé et le contenu de la requête elle-même. Cela permet aux utilisateurs d'identifier les requêtes inefficaces ou les agrégations complexes.
Métriques clés à surveiller :
took: Temps total pris par l'opération.source: Texte intégral de la requête ou de l'opération d'indexation.id: L'identifiant du contexte de recherche.
5. Meilleures pratiques pour l'analyse des journaux
Un dépannage efficace repose sur plus que la simple connaissance de l'endroit où chercher ; il nécessite une approche systématique.
A. Centralisez vos journaux
Dans un environnement distribué, parcourir manuellement les journaux sur des dizaines de nœuds est impraticable. Utilisez des outils de journalisation centralisée tels que Logstash, Filebeat ou des services de journalisation spécialisés pour agréger les journaux dans un seul index Elasticsearch (souvent appelé le 'cluster de journalisation'). Cela vous permet de rechercher, filtrer et corréler les événements sur tous les nœuds simultanément.
B. Corrélatez les événements entre les nœuds
Recherchez les événements connexes en utilisant les champs @timestamp et cluster.uuid. Un shard qui échoue sur node-A peut être enregistré comme une ERROR sur ce nœud, mais le gestionnaire de cluster s'exécutant sur node-B enregistrera une INFO ou une WARN concernant la tentative ultérieure de réallocation du shard.
C. Surveillez les schémas répétitifs
Si vous voyez le même message d'avertissement ou d'erreur se répéter rapidement (une 'tempête de journaux'), cela indique souvent une boucle d'échec continue et gourmande en ressources, telle qu'un processus essayant de se lier de manière répétée à un port indisponible ou un déclenchement continu du disjoncteur en raison d'une surcharge soutenue. Ces schémas nécessitent une enquête immédiate.
D. N'ignorez pas les messages WARN
Les avertissements servent souvent d'indicateurs précoces de futures pannes catastrophiques. Par exemple, les messages WARN répétés concernant des paramètres dépréciés ou une faible utilisation de la mémoire doivent être traités de manière proactive avant qu'ils ne dégénèrent en pannes de niveau ERROR.
Conclusion
Les journaux Elasticsearch sont une ressource inestimable, fournissant le contexte essentiel requis pour aller au-delà des correctifs symptomatiques et diagnostiquer la cause première de l'instabilité du cluster ou des performances médiocres. En comprenant la structure standard des journaux, en priorisant les messages en fonction de la sévérité et en exploitant spécifiquement les journaux lents pour l'optimisation des performances, les administrateurs peuvent réduire considérablement les temps d'arrêt et maintenir une santé robuste du cluster.