Alibaba Cloud Logstash repose sur la même architecture et le même modèle d'optimisation que Logstash open source. Un pipeline traite les événements en trois étapes : input, filter et output. Chaque étape s'exécute sur des threads de travail indépendants. Les événements arrivent dans une file d'attente centrale (en mémoire par défaut). Les threads de travail extraient des lots depuis cette file, appliquent les filtres, puis écrivent les données vers la destination de sortie.
Ce guide aborde les problèmes de performances selon un ordre structuré. Ne modifiez pas directement les paramètres du pipeline. La modification simultanée de plusieurs variables complique l'identification de la cause racine. Suivez la liste de vérification ci-dessous dans l'ordre indiqué, effectuez une modification à la fois et mesurez les résultats après chaque changement.
Ordre de dépannage
Suivez cette séquence :
Vérifiez vos sources d'entrée et destinations de sortie
Vérifiez les ressources système (CPU, mémoire heap)
Optimisez les paramètres du pipeline (Pipeline Batch Size, Pipeline Workers)
Vérification des performances d'entrée et de sortie
Le débit de Logstash est limité par le composant le plus lent du pipeline. Si Kafka ou Elasticsearch constitue le goulot d'étranglement, l'ajustement des paramètres Logstash n'apportera aucune amélioration.
Avant d'ajuster quoi que ce soit dans Logstash :
Vérifiez que le retard du consommateur Kafka n'est pas causé par des écritures lentes en aval.
Contrôlez les taux d'indexation Elasticsearch et surveillez les réponses
429. Un code429indique que la file d'attente d'indexation d'Elasticsearch est pleine. Dans ce cas, Logstash réessaie automatiquement, mais le problème sous-jacent se situe au niveau d'Elasticsearch. Vérifiez l'état du cluster et l'allocation des shards avant de modifier les paramètres Logstash.Surveillez la latence d'écriture sur votre destination de sortie.
Configuration de la surveillance
Pour obtenir une visibilité sur les opérations internes de Logstash, configurez au moins l'une des options suivantes :
Politique d'alerte CloudMonitor : suit les métriques au niveau système (CPU, mémoire, E/S disque) pour le cluster Logstash. Consultez la rubrique Configuration d'une politique d'alerte personnalisée.
X-Pack Monitoring : suit les métriques spécifiques à Logstash, notamment le taux de réception des événements, le taux de transfert des événements, l'utilisation du CPU et l'utilisation de la mémoire. Le cluster Alibaba Cloud Elasticsearch associé à votre cluster Logstash doit se trouver dans le même VPC (Virtual Private Cloud). Consultez la rubrique Activation de la fonctionnalité X-Pack Monitoring.
Pour analyser les détails de traitement par pipeline, installez le plugin logstash-output-file_extend. Une fois le pipeline démarré, ce plugin écrit des journaux de débogage qui montrent comment les données métier circulent à travers chaque étape. Consultez la rubrique Utilisation de la fonctionnalité de débogage de configuration du pipeline.
Vérification du CPU et de la mémoire heap
CPU
Une utilisation élevée du CPU ne constitue pas toujours un goulot d'étranglement. Cela dépend si les ressources sont réellement utilisées à plein rendement.
Si l'utilisation du CPU approche les 100 % : les ressources sont utilisées efficacement. Vous pouvez améliorer le débit en ajoutant des nœuds au cluster. Vérifiez également la mémoire heap, car un garbage collection fréquent provoque souvent des pics d'utilisation du CPU.
Si l'utilisation du CPU reste constamment faible : l'augmentation des spécifications du cluster n'améliorera pas le débit. Le goulot d'étranglement se situe probablement en amont (entrée lente) ou en aval (sortie lente).
La mise à niveau des spécifications des nœuds n'améliore le débit que lorsque les ressources sont déjà proches de leur utilisation maximale.
Mémoire heap
Une mémoire heap trop grande ou trop petite pose problème : le garbage collector (GC) Java s'exécute plus fréquemment, ce qui entraîne des pics d'utilisation du CPU.
Configurez la mémoire heap en fonction de votre charge de travail :
La plage typique est de 4 Go à 8 Go. Pour la plupart des charges de travail, rester dans cette plage suffit.
Si vous observez des signes de pression mémoire (CPU élevé avec des pics de GC), doublez la taille actuelle de la heap et testez si les performances s'améliorent.
Définissez la mémoire heap et la mémoire off-heap à la même taille, conformément aux bonnes pratiques de Logstash open source.
Si vous avez besoin de plus de 8 Go, ajoutez des nœuds au cluster Logstash plutôt que d'augmenter continuellement la taille de la heap sur un seul nœud.
Avant de passer en production, exécutez des tests de charge et ajustez la taille de la heap en fonction de votre trafic réel.
Optimisation des paramètres du pipeline
Deux paramètres contrôlent la quantité de travail effectuée simultanément par Logstash. Le nombre total d'événements en cours de traitement à tout moment est calculé comme suit :
inflight count = Pipeline Workers × Pipeline Batch SizeGardez cette formule à l'esprit lorsque vous ajustez l'un ou l'autre paramètre. Un nombre d'événements en cours de traitement plus élevé signifie une consommation de mémoire plus importante.
Pipeline Batch Size
Ce paramètre contrôle le nombre d'événements que chaque thread de travail extrait de la file d'attente par cycle. Un lot plus grand améliore le débit, mais augmente l'utilisation de la mémoire.
Lors de l'écriture vers Elasticsearch, visez une taille de requête bulk d'environ 5 Mo. Ajustez Pipeline Batch Size pour atteindre cet objectif plutôt que de le définir arbitrairement à une valeur élevée.
Pipeline Batch Size correspond directement au paramètre bulk d'Elasticsearch. Des lots plus grands signifient moins de requêtes bulk, mais de plus grande taille.
Pipeline Workers
Ce paramètre contrôle le nombre de threads de travail exécutant les étapes filter et output. La valeur par défaut correspond au nombre de vCPUs sur chaque nœud.
Quand augmenter Pipeline Workers :
Pipelines limités par le CPU (calculs de filtre intensifs, sans E/S réseau) : augmentez Pipeline Workers progressivement tant que le CPU dispose de marge. Une fois le CPU saturé, l'ajout de workers supplémentaires augmente la surcharge de changement de contexte et peut *réduire* le débit.
Pipelines limités par les E/S (appels réseau dans les filtres ou les sorties, tels que l'écriture vers Elasticsearch) : ces pipelines passent du temps à attendre les E/S. Ainsi, davantage de workers peuvent améliorer le débit même si le CPU n'est pas pleinement utilisé.
Augmentez la valeur, mesurez les résultats et recommencez. Modifiez une seule valeur à la fois.
Résolution de l'accumulation de messages Kafka
Si des messages s'accumulent dans les topics Kafka, appliquez les approches suivantes. Mettez-en une en œuvre à la fois et mesurez les résultats avant de les combiner. Pour plus d'informations, consultez la section Conseils et bonnes pratiques dans la documentation de Logstash open source.
Augmentation du nombre de partitions
Pour les topics à fort volume, calculez le nombre minimal de partitions comme suit :
partitions ≥ Logstash nodes × consumer threads per nodeDavantage de partitions permettent un meilleur parallélisme, mais augmentent également la surcharge. Configurez les partitions en fonction de vos besoins métier.
Répartition de la charge avec plusieurs pipelines
Configurez plusieurs pipelines dans le même cluster Logstash pour utiliser le même ID de groupe. Kafka distribue chaque message à un seul consommateur du groupe, ce qui permet de répartir la charge entre les pipelines sur différents nœuds.
Augmentation de Pipeline Workers et Pipeline Batch Size
Pour les charges de travail intensives en Kafka, l'augmentation simultanée des deux paramètres aide souvent. Commencez par Pipeline Batch Size (augmentez jusqu'à atteindre l'objectif de 5 Mo pour les requêtes bulk Elasticsearch), puis augmentez Pipeline Workers. Surveillez à la fois le retard du consommateur Kafka et la latence d'indexation Elasticsearch pendant l'optimisation.