La surveillance est un petit aspect de nos besoins opérationnels; configurer, surveiller et vérifier la configuration d’outils tels que Fluentd et Fluentbit peut être un peu frustrant, en particulier si nous voulons valider une configuration plus avancée qui fait plus que simplement soulever les fichiers journaux et vider le contenu dans une solution telle qu’OpenSearch. Fluentd et Fluentbit nous fournissent des fonctionnalités très puissantes qui peuvent faire une réelle différence sur le plan opérationnel. Par exemple, la possibilité d’identifier des messages de journal spécifiques et de les envoyer à un service de notification plutôt que d’attendre que le prochain cycle d’analyse de journal soit exécuté par un magasin de journaux comme Splunk. Si nous voulons tester la configuration, nous devons lire les événements du journal comme si le système fonctionnait réellement, ce qui signifie des journaux réalistes à la bonne vitesse afin que nous puissions nous assurer que notre configuration empêche les alertes ou les tempêtes de courrier.
Pour ce faire, le moyen le plus simple consiste soit à prendre un journal réel et à copier les événements dans un nouveau fichier journal à la vitesse à laquelle ils se sont produits, soit à créer des événements synthétiques et à les lire à un rythme réaliste. C’est ce que fait le LogGenerator open source (alias LogSimulator). J’ai créé le LogGenerator il y a quelques années, ayant relevé les mêmes défis auparavant et voulant quelque chose qui aiderait à faire la démonstration des configurations Fluentd pour un livre (Logging in Action with Fluentd, Kubernetes, etc.).
Pourquoi ne pas simplement copier le fichier journal pour que le mécanisme de journalisation le lise ? Plusieurs raisons à cela. Par exemple, si votre infrastructure de journalisation peut envoyer les journaux sur le réseau sans créer de contre-pression, les journaux peuvent être générés sans être affectés par les considérations de performances de stockage. Mais il n’y a rien de tangible à copier. Si vous souhaitez simuler dans votre environnement de surveillance des événements de journaux à partir d’une base de données, cela devient encore plus difficile car la base de données stockera les journaux en interne. L’autre raison à cela est que si vous avez des contrôles d’alerte basés sur des seuils dans le temps, vous avez besoin que les journaux soient consommés au bon rythme. Le simple fait de permettre aux journaux d’être ingérés entiers ne va pas exercer correctement ces contrôles basés sur le temps.
Depuis lors, j’ai constaté des besoins similaires pour pomper des événements de test dans d’autres solutions, notamment OCI Queue et d’autres services Oracle Cloud. Le support de service OCI a été mis en œuvre à l’aide d’un cadre d’extensibilité simple. Par conséquent, même si je me suis concentré sur OCI, le même mécanisme pourrait être appliqué aussi facilement au SQS d’AWS, par exemple.
Une bonne pratique pour la gestion des journaux consiste à traiter chaque entrée de journal comme un événement et à considérer la gestion des événements de journal comme une application spécialisée d’analyse de flux. Étant donné que l’approche la plus courante du streaming et de l’analyse de flux de nos jours est basée sur Kafka, nous travaillons sur un adaptateur pour le LogSimulator qui peut envoyer les événements à un point d’API Kafka.
Nous avons construit le LogGenerator pour qu’il puisse être exécuté comme un script, donc le modifier et étendre son comportement est rapide et facile. nous avons commencé par développer en utilisant Groovy sur Java8, et si vous voulez créer un fichier Jar, il se compilera en Java. Plus récemment, en particulier avec les extensions avec lesquelles nous avons travaillé, Java11 et sa capacité à exécuter des classes de fichiers uniques à partir de la source.
Nous avons prévu d’améliorer le LogGenerator afin de pouvoir injecter des événements OpenTelementry dans Fluentbit et d’autres services. Mais nous aimerions connaître d’autres cas d’utilisation voir pour cela.
Pour en savoir plus sur l’utilitaire :