Journal FlowG sort en version v0.29.0

Bonjour Nal !

Si c'est la première fois que tu en entends parler, FlowG est un logiciel open-source de traitement de journaux systèmes. La fonctionnalité principale est un éditeur de "pipeline" se basant sur React Flow. Le but est de recevoir des journaux systèmes et de les transformer à l'aide de scripts VRL, catégoriser, et stocker dans des "streams".

J'en ai déjà parlé précédemment ici.

Aujourd'hui, je t'annonces la toute dernière mouture qui introduit un changement majeur qui va améliorer l'interopérabilité.

• https://github.com/link-society/flowg/releases/tag/v0.28.0
• https://github.com/link-society/flowg/releases/tag/v0.29.0

La naissance du concept d'alerte dans FlowG

L'une des idées initiales de FlowG était de pouvoir non seulement catégoriser les journaux en les stockant dans différents "streams", mais aussi de pouvoir notifier des systèmes tiers sous certaines conditions. L'un des premiers cas d'usage était d'envoyer des alertes par SMS, Mail, ou via Teams / Slack.

On avait choisit d'utiliser une webhook Zapier pour implémenter cela. Et donc une alerte au sein de FlowG se présentait comme une webhook, on précisait l'URL et les en-tête HTTP, et ce dernier exécutait une requête POST avec en corps de requête le journal transformé et/ou catégorisé.

C'était simple (KISS), efficace, et cela faisait le travail.

Cependant, cela nécessite d'utiliser un service tiers, ou d'implémenter le-dit service tiers soit même. Pas forcément idéal pour le cas d'usage que l'on a rencontré par la suite.

Un nouveau cas d'usage avec Syslog

Depuis la version v0.11.0, FlowG est également un serveur Syslog, capable de recevoir des journaux systèmes en utilisant le protocol Syslog, soit au format décrit par la RFC 3164, ou au format décrit par la RFC 5424, et ce via UDP, TCP ou même TCP+TLS.

C'est pratique pour agréger les journaux de l'ensemble des conteneurs Docker d'une machine, ou de l'ensemble des Pods d'un cluster Kubernetes. Mais l'infrastructure que l'on gère est grande, et segmentée. Nous avons plusieurs clusters pour les différentes applications que nous devons héberger, et quelques cluster de "gestion" dans lequel tournent certains services que l'on utilise pour (roulement de tambour) gérer les autres clusters.

On a donc la chaîne suivante :

• le daemon Docker utilise un "log driver" syslog pour rediriger la sortie standard des conteneurs vers le serveur syslog de la machine virtuelle
• le serveur syslog de la machine virtuelle redirige les journaux vers un serveur syslog local au cluster (sur une machine virtuelle dédiée)
• ce serveur syslog local au cluster redirige ensuite les journaux vers un serveur syslog dans notre cluster de gestion, on l'appelle le "syslog central"
• ce "syslog central" redirige ensuite les journaux vers un Logstash qui les envoi à Splunk

Si on veut ajouter FlowG dans la chaine, il faut demander à un des serveurs Syslog de dupliquer les journaux pour les envoyer à FlowG. Pas forcément pratique.

FlowG a besoin d'être capable de rediriger les journaux vers un serveur Syslog.

Le nouveau concept de "Forwarder"

Il faut donc généraliser le concept d'alerte. Déjà que le nom était pas top pour ce qui était simplement une webhook HTTP…

Un bien meilleur nom c'est "Forwarder" (redirecteur dans la langue de Molière).

C'est ainsi que la version v0.28.0 renomme les alertes en "Webhook Forwarder". Avec le code qui va bien pour gérer la migration des données automatiquement (vous pouvez donc mettre à jour sans crainte de corrompre votre configuration).

Et la version v0.29.0 introduit donc un nouveau type de "Forwarder", le "Syslog Forwarder", pour envoyer le journal (au format JSON) à un serveur Syslog distant :

Ainsi, FlowG est capable de complètement remplacer les maillons de notre chaîne de serveur Syslog, ce qui simplifie grandement la complexité de notre infrastructure. Et il est beaucoup plus simple d'analyser, transformer, catégoriser et filtrer les journaux avec FlowG qu'avec rsyslog et Logstash 😉

La feuille de route pour la suite

Mais on ne va pas s'arrêter simplement à un "forwarder HTTP" et un "forwarder Syslog".

Comme je l'ai décrit plus haut, nous avons en bout de chaîne une instance Splunk. Et d'autres utilisateurs utilisent Datadog. On a également des RabbitMQ et des Kafka par-ci par-là.

Être capable d'envoyer des données à tout ces services tiers est une fonctionnalité très importante pour garantir une grande interopérabilité.

Au passage, j'aimerais mentionner que l'on travaille aussi sur l'implémentation de la réplication, pour permettre d'installer un cluster FlowG hautement disponible. Le sujet est assez velu, et ça risque de prendre encore pas mal de temps.

Conclusion

Voilà, je pense avoir tout dit concernant les dernières nouveautés. N'hésitez pas à poser vos questions, critiquer la documentation, ouvrir des rapports de bogues, demander de nouvelles fonctionnalités, ou même nous envoyer des "Pull Requests", toutes contributions est la bienvenue !