Gestion de la mémoire Elasticsearch et résolution des problèmes

Avec Elastic Cloud, qui propose des solutions telles que Observability, Security et Search, nous avons élargi le nombre d’utilisateurs d’Elastic Cloud au-delà des équipes opérationnelles complètes pour inclure les ingénieurs de données, les équipes de sécurité et les consultants. En tant que représentant du support Elastic, j’ai eu le plaisir d’interagir avec un large éventail d’utilisateurs et de cas d’utilisation.

Avec un public plus large, je reçois de plus en plus de questions concernant la gestion de l’allocation des ressources, en particulier le dépannage de l’état de l’allocation et l’évitement du déclenchement des disjoncteurs. C’est tout à fait compréhensible ! Quand j’ai commencé à utiliser Elasticsearch, je me posais les mêmes questions. C’était ma première expérience dans la gestion de segments Java et de partitions de bases de données temporelles, et dans le scaling de ma propre infrastructure.

Lorsque j’ai rejoint Elastic, j’ai particulièrement apprécié le fait de disposer, en plus de la documentation, d’articles et de tutoriels pour pouvoir être opérationnel rapidement. Mais le premier mois, cela a été difficile d’appliquer mes connaissances théoriques aux erreurs soumises par les utilisateurs via des tickets. Tout comme d’autres membres de l’assistance technique, je suis finalement parvenu à la conclusion qu’un grand nombre des erreurs signalées étaient simplement symptomatiques de problèmes d’allocation et que la même demi-douzaine de liens permettrait aux utilisateurs d’apprendre à gérer correctement leur allocation de ressources.

En tant que représentant de l’assistance technique, je vais aborder les principaux liens théoriques sur la gestion de l’allocation que nous envoyons aux utilisateurs, les symptômes les plus courants que nous observons, et les endroits vers lesquels nous redirigeons les utilisateurs pour mettre à jour leurs configurations afin de résoudre leurs problèmes d’allocation de ressources.

2. En tant que variable d’environnement Elasticsearch dans votre fichier docker-compose :

3. Via notre Elastic Cloud Hosted > Déploiement > Modifier la vue. Remarque : le menu déroulant attribue la mémoire physique, dont environ la moitié sera allouée au heap.

Si vous rencontrez actuellement des problèmes de performances sur votre cluster, ceux-ci s’expliquent probablement par les raisons habituelles :

• Problèmes de configuration : nœuds maîtres sous-dimensionnés, pas de politique ILM
• Induit par le volume : cadence élevée de requêtes/charge, chevauchement de requêtes/écritures coûteuses

Et à : _cluster/health.

Si des partitions signalent une valeur > 0 en dehors de active_shards ou de active_primary_shards, vous avez identifié une cause de problèmes de performances.

Le plus souvent, si ce rapport indique un problème, le nombre de partitions non attribuées sera supérieur à 0. Si ces partitions sont primaires, votre cluster affichera un statut rouge (status:red), et s’il ne s’agit que de réplicas, le statut sera jaune (status:yellow). (C’est pourquoi il est important de configurer des réplicas sur les index : en cas de problème, le cluster peut récupérer et éviter ainsi toute perte de données.) Imaginons un cluster avec un statut jaune (status:yellow) et une seule partition non attribuée. Pour analyser le problème, nous examinerons quelle partition d’index pose problème via la commande « _cat/shards ».

Cela concerne donc nos logs d’index non système, qui possèdent une partition de réplique non attribuée. Voyons ce qui pose problème en exécutant _cluster/allocation/explain. (Info : lorsque vous contactez l’assistance, c’est exactement ce que nous faisons.)

GET _cluster/allocation/explain?pretty&filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*

Ce message d’erreur pointe vers data_hot, qui fait partie d’une gestion du cycle de vie des index (ILM) et indique que notre politique ILM n’est pas compatible avec nos paramètres actuels d’index. Dans ce cas, la cause de cette erreur vient de la configuration d’une politique ILM hot-warm sans nœuds hot-warm désignés. (J’ai dû m’assurer qu’une erreur se produirait, donc je vous propose des exemples d’erreurs. Pour plus d’informations, consultez cette vidéo d’exemple de dépannage pour le déroulement de la résolution.)

Si vous exécutez cette commande alors que vous n’avez aucune partition non attribuée, vous obtiendrez une erreur 400 indiquant l’impossibilité de trouver des partitions non attribuées à expliquer car aucun problème n’est détecté.Si la cause de l’erreur est non logique (par exemple, une erreur réseau temporaire comme Node left cluster during allocation), vous pouvez utiliser la fonction pratique _cluster/reroute d’Elastic.

Cette requête sans personnalisation lance un processus asynchrone en arrière-plan qui tente d’allouer toutes les partitions en état non attribué (state:UNASSIGNED). (Ne faites pas comme moi : n’attendez pas que cela se termine avant de contacter les développeurs, car je pensais que ce serait instantané et que cela escaladerait juste à temps pour qu’ils disent qu’il n’y avait plus de problème.) Pour plus d’informations, consultez cette vidéo de dépannage pour surveiller la qualité de l’allocation.

Pour comprendre ce qui se passe, vérifiez heap.percent, soit en passant par _cat/nodes :

Ou, si vous l’avez déjà activé, accédez à Kibana > Stack Monitoring.

S’il est avéré que vous avez atteint le seuil de déclenchement des disjoncteurs de mémoire, envisagez d’augmenter le segment de manière temporaire afin que vous puissiez souffler et prendre le temps de faire des recherches sur l’origine du problème. Lorsque vous recherchez la cause première d’un problème, parcourez le journal d’audit, le journal des requêtes lentes, les clusterlogs ou le fichier elasticsearch.log pour voir les événements consécutifs qui précèdent. Recherchez :

• les requêtes gourmandes en ressources, plus particulièrement :
  • de nombreuses agrégations de buckets ;
    • Je me suis senti si bête lorsque j’ai découvert que les recherches allouaient temporairement une certaine portion du segment avant d’exécuter la requête selon la taille des recherches ou des dimensions d’un bucket, si bien qu’un paramétrage de 10 000 000 a vraiment donné des sueurs froides à mon équipe opérationnelle.
  • les mappings non optimisés ;
    • la seconde raison pour laquelle je me suis senti bête, c’est quand je pensais qu’un reporting hiérarchique donnerait de meilleurs résultats de recherche que des données lissées (ce n’est pas le cas).
• Volume/rythme des demandes : généralement des requêtes par lots ou asynchrones

Ou vous pouvez le calculer à partir de _nodes/statistiques :

Où :

Des symptômes potentiels sont la fréquence élevée et la durée prolongée des événements du récupérateur de mémoire (gc) dans elasticsearch.log :

Si ces deux symptômes sont présents, vous devriez envisager soit de scaler votre cluster, soit de réduire le nombre de demandes à traiter. Voici ce que vous pouvez faire pour résoudre le problème :

• Augmentation des ressources du segment (heap/nœud ; nombre de nœuds)
• Réduction des partitions (supprimer les données inutiles/anciennes ; utiliser l’ILM pour placer les données dans un stockage chaud/froid afin de pouvoir les compacter ; désactiver les répliques pour les données dont la perte n’est pas critique)

Initialement publié le 27 avril 2021 ; mis à jour le 5 novembre 2024.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.