URL: https://linuxfr.org/users/linkdd/journaux/flowg-une-solution-low-code-de-traitement-de-journaux-systemes Title: FlowG - Une solution "Low Code" de traitement de journaux (systèmes) Authors: David Delassus Date: 2024年08月23日T01:39:01+02:00 License: CC By-SA Tags: nocode, lowcode, flowg, logiciel_libre, autopromotion et foss Score: 19 Bonjour Nal! Aujourd'hui, je te présente un projet sur lequel j'ai travaillé ces derniers jours. Pour bien le comprendre, il faut d'abord que je te parle un peu du contexte dans lequel il est né. ## Pour les impatients - https://github.com/link-society/flowg - https://hub.docker.com/r/linksociety/flowg ## Le besoin A mon travail actuel, nous avons plusieurs sources de "log" très hétérogènes. Toutes ces sources envoient leurs logs à syslog, qui ensuite les remonte dans un [OpenObserve](https://openobserve.ai) local à l'environnement, ainsi qu'à un [Splunk](https://splunk.com) central qui agrège les logs de tout les environnements. Nous nous servons du OpenObserve pour debugger et analyser les problèmes du quotidien, et nous utilisons le Splunk pour extraire des métriques/indicateurs plus globaux. Quand je dis "nous utilisons OpenObserve", c'est une exagération. Jusqu'à il y a quelques mois, nous avions uniquement le Splunk. Et nos clients (utilisateurs de l'environnement) n'ont pas accès a ce Splunk. Il fallait donc leur fournir une solution locale à leurs environnements dédiés, avec uniquement les données de leurs environnements. On a donc décidé d'essayer OpenObserve, car on a un préjudice totalement subjectif contre ELK (ElasticSearch, Logstash, Kibana), et on a pas le budget pour une autre solution similaire à Splunk pour chaque environnement (nous en avons une centaine, et d'ici la fin d'année, nous en aurons une vingtaine de plus). Quel préjudice ? Le fameux "j'aime pas c'est nul" sans aucun argument bien sûr ! Fast Forward quelques mois plus tard, jusqu'à la semaine dernière. Nous voulons configurer OpenObserve pour traiter nos logs afin de les enrichir, catégoriser, et les diriger vers les bonnes destinations. En effet, si je veux voir les logs d'accès du Reverse Proxy, je ne veux pas voir ceux du Prometheus. Et je veux que ce soit simple, j'ai pas envie d'écrire une requête SQL (ou tout autre DSL) pour ça. Bref, je veux ce que Logstash fait. Il nous semblait qu'OpenObserve proposait cela, [mais non](https://github.com/openobserve/openobserve/issues/4245). ## FlowG rejoint le tchat ![capture d'écran de flowg](https://github.com/link-society/flowg/raw/main/docs/screenshots/pipelines.png) https://github.com/link-society/flowg Libre et Open Source, ce logiciel est distribué sous licence MIT. Il se repose sur [BadgerDB](https://dgraph.io/docs/badger/), une base de donnée clé/valeur très performante qui est notamment derrière la base de donnée graphe [DGraph](https://dgraph.io). Dans FlowG, on a 3 grands concepts : - **un "stream":** c'est là que les "logs" seront stockés, c'est cela que l'on va interroger et visualiser - **un "transformer":** il s'agit d'un script [VRL](https://vector.dev/docs/reference/vrl/) permettant de transformer un log record, on s'en sert pour parser des messages (format syslog, format apache, format nginx, format logfmt, ...), ajouter des champs au log record, en supprimer d'autres, etc... - **une "pipeline":** c'est le point d'entrée des logs, écrite de manière "No Code" grâce à [React Flow](https://reactflow.dev/), elle permet d'orchestrer comment transformer et rediriger les logs vers les bons "streams", un exemple est visible dans la capture d'écran ci-dessus ![capture d'écran de flowg](https://i.ibb.co/PD6gfqn/Screenshot-2024年08月23日-012824.png) La configuration est donc extrêmement rapide à établir, et tout de même très flexible. La solution entière reste légère avec un binaire de 40Mo contenant l'interpréteur VRL, l'interface web (les fichiers statiques sont "embed" dans le binaire), l'API (sa documentation et son schéma OpenAPI sont aussi "embed" dans le binaire). Grâce a BadgerDB, qui supporte la compression de la base complète avec l'algorithme [ZSTD](https://fr.wikipedia.org/wiki/Zstandard), et qui supporte les transactions ACID, il fut relativement simple d'arriver à une preuve de concept rapidement. En effet, le projet a mis 4 jours seulement pour être développé. Ci jeune, et plein de potentiel à mon avis (totalement biaisé, on se l'accorde). Pour arriver à une solution digne de ce nom qu'on hésitera pas à mettre en production, il reste cependant encore pas mal de chemin 🙂 ## Conclusion On commence à peine les benchmarks, le logiciel n'a même pas de suite de test pour le moment. Tout cela viendra avec le temps. J'en fais la démo ce Vendredi au travail, on verra si le projet est accepté ou non 🤞 Tout les retours, positifs ou négatifs, sont les bienvenus, cela nous aidera à améliorer le projet. Oulà, 1h37, il est déjà si tard ! Je te laisse dormir, Nal.

AltStyle によって変換されたページ (->オリジナル) /