Guide de mise à niveau pour Logstash 2.2

Salut les Logstashers !

Dans cet article, nous allons évoquer les éléments à prendre en considération lors d'une mise à niveau vers Logstash 2.2.0. Il nous importe particulièrement de savoir comment éviter les situations où un comportement nouveau (et un comportement anormal, qui sera bientôt résolu, du plugin "output elasticsearch") peut entraîner l'utilisation de plus de "file handles" que souhaité. J'aborderai également quelques nouvelles options de tuning avec la version 2.2.0. Afin d'aider les utilisateurs à faire leur mise à niveau vers la version 2.2.0, nous avons également préparé une nouvelle rubrique de documentation, disponible ici.

La bonne nouvelle, c'est que Logstash 2.2 apporte de nettes améliorations en termes de performances ! La moins bonne nouvelle, c'est que l'une des modifications que nous avons faites au niveau des paramètres par défaut dans Logstash pourrait entraîner des problèmes avec certaines configurations. Des utilisateurs nous ont signalé, par exemple, que Logstash utiliserait bien plus de "file handles" qu'auparavant.

Voyons ces modifications de plus près.

Worker Units

Il existe deux types de workers dans Logstash 2.2, les pipeline workers (anciennement appelés filter workers) et les output workers. Dans les versions précédentes de Logstash, les filtres et les sorties étaient exécutés dans leurs propres threads. Avec la version 2.2, nous avons uniformisé notre modèle de threading, plaçant les threads de workers « filter » et « output » dans un type de thread « pipeline » worker. Ceci nous a permis de réaliser de bien meilleures performances. Le concept d'output worker reste le même, mais il effectue un mapping vers un pool d'objets « output » disponibles plutôt que directement vers un thread. Ces objets sont récupérés par un pipeline worker pendant l'exécution, utilisés puis restitués.

Vous vous apercevrez qu'il est nécessaire de donner au paramètre -w une valeur plus haute qu'auparavant, et aussi que Logstash peut nécessiter davantage de threads au total. Cependant, c'est voulu ! Vous découvrirez que vous aurez plus de threads, effectuant moins de travail. Il est vrai qu'un bon nombre d'entre eux seront oisifs en attente d'E/S, mais il n'en demeure pas moins qu'ils travailleront bien plus efficacement, et avec moins de changements de contexte. Il suffit pour régler le paramètre -w de continuer à l'augmenter, quitte à atteindre un multiple du nombre de cœurs au sein de votre système (rappelez-vous que ces threads sont souvent oisifs) jusqu'à ce que vous constatiez une baisse de débit. Par défaut, -w est paramétré pour correspondre au nombre de cœurs dans votre système.

Batching Events

Nous proposons également un nouveau paramètre de taille de batch -b que vous pouvez régler de la même façon. Veuillez lire notre article précédent qui explique ces options de façon plus détaillée. Cette taille de batch est désormais également la taille de flush par défaut pour l'output Elasticsearch. L'option flush_size ne sert maintenant qu'à modifier la taille de flush maximale, et ne change plus sa taille minimale.

Pipeline et Outputs

Lors de nos tests de performance, nous avons remarqué que le fait d'augmenter le nombre d'output workers afin d'assurer un alignement sur les pipeline workers permettait d'améliorer les performances. Cependant, un comportement importun, qui était jusqu'alors demeuré caché, se manifeste pour notre output Elasticsearch. Si vous utilisez plusieurs output workers Elasticsearch, ils ne partageront pas le même pool de connexion. Cela signifie que si vous avez 5 instances de Elasticsearch et 5 workers, vous pourrez obtenir jusqu'à 5 x 5 = 25 connexions ! Si vous avez 40 nœuds Elasticsearch, cet effet est encore amplifié !

Nous sommes bien conscients du fait que la situation actuelle n'est pas idéale pour tous. La solution n'est pas de modifier le comportement du cœur Logstash, mais de forcer la sortie Elastisearch à gérer les connexions de manière responsable dans le nouveau modèle de pipeline. Nous préparons une nouvelle version dans la série 2.2 pour résoudre ce problème. Nous travaillons actuellement à une correction qui ne nécessitera qu'une mise à niveau de plugin. Cependant, jusqu'à ce qu'elle soit disponible, vous devrez travailler avec un nombre relativement faible d'output workers ES. La solution de contournement avec la version 2.2 consiste simplement à paramétrer un nombre de worker délibérément bas - essayez avec seulement un ou deux workers.

Feedback

J'espère avoir clarifié certains aspects de notre nouvelle architecture de pipeline et de la mise à niveau vers la version 2.2. N'hésitez pas à nous transmettre vos impressions ! Vous pouvez à tout moment nous contacter via Twitter (@elastic), sur notre forum, ou signaler tous problèmes sur la page des problèmes GitHub page.