Journal FlowG - Une solution "Low Code" de traitement de journaux (systèmes)

Posté par David Delassus (site web personnel) le 23 août 2024 à 01:39. Licence CC By‑SA.

Étiquettes :

août

2024

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

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 local à l'environnement, ainsi qu'à un Splunk 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.

FlowG rejoint le tchat

capture d'écran de flowg

https://github.com/link-society/flowg

Libre et Open Source, ce logiciel est distribué sous licence MIT. Il se repose sur BadgerDB, une base de donnée clé/valeur très performante qui est notamment derrière la base de donnée graphe DGraph.

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 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, 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

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, 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.

# saoultion légère ?

Posté par Denis Dordoigne le 23 août 2024 à 08:57. Évalué à 1.

solution entière reste légère avec un binaire de 40Mo

Je ne suis pas très au fait de ce qui se fait en dev ces 15 dernières années, mais intuitivement j'ai l'impression que 40 Mo n'est pas léger. J'ai regardé dans tout le PATH de mon PC et je n'ai aucun binaire qui atteint une telle taille, pourtant ces certains sont des serveurs avec bien plus de fonctionnalités. Est-ce React Flow qui produit un si gros binaire ?

Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
- [^] # Re: saoultion légère ?
  
  Posté par David Delassus (site web personnel) le 23 août 2024 à 09:22. Évalué à 5. Dernière modification le 23 août 2024 à 09:23.
  
  Un binaire qui embarque les fichiers statiques, ainsi que l'interpréteur VRL.
  
  Dans ton PATH, tes binaires sont compilés dynamiquement, et n'embarquent pas de code JS, CSS, d'images, de fonts, …
  
  Comparons ce qui est comparable. Ici l'empreinte totale de FlowG sur le disque après installation, c'est 40Mo.
  
  https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
- [^] # Re: saoultion légère ?
  
  Posté par steph1978 le 23 août 2024 à 19:58. Évalué à 4.
  
  Ce que tu stockes sur disque est peu important, en particulier si ça reste en autour de quelques 10aine de MB.
  
  Ce qui est important, c'est le besoin en RAM, CPU, Stockage des data, bande passante.
  
  Ainsi si il faut ajouter 10MB au binaire pour embarquer un moteur de stockage qui permet d'économiser des GB parce qu'il organise mieux les données, j'hésite pas.
- [^] # Re: saoultion légère ?
  
  Posté par freem le 09 septembre 2024 à 15:18. Évalué à 3.
  
  Les binaires go ou haskell ont cette tendance. Par exemple, j'ai un programme nommé pree (go) qui pèse 2.2Megs, alternative à pstree qui lui ne pèse que 36K.
  pandoc (haskell) lui pèse 165Megs.
  
  Go est plutôt pas mal utilisé pour ce type d'outillage, donc j'aurai tendance a supposer une relation :)
  - [^] # Re: saoultion légère ?
    
    Posté par David Delassus (site web personnel) le 09 septembre 2024 à 16:47. Évalué à 3.
    
    pstree est-il compilé statiquement ? Et possède-t-il le gros runtime de Go ? :)
    
    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# préjudice ?!

Posté par BAud (site web personnel) le 23 août 2024 à 09:58. Évalué à 6.

préjudice à comparer avec prejudice sans préjuger de tes compétences à lire l'anglais :p
- [^] # Re: préjudice ?!
  
  Posté par David Delassus (site web personnel) le 23 août 2024 à 10:04. Évalué à 3.
  
  Effectivement, pour le travail je communique principalement en Anglais (notre équipe est composés de personnes de plusieurs pays d'Europe différents, l'Anglais est le dénominateur commun). J'en oubli souvent mon Français.
  
  J'ai fait des efforts ici pour essayer de traduire au mieux, mais j'ai du mal :)
  
  on a un opinion défavorable de ELK pour aucune raison valable si ce n'est qu'on aime pas.
  
  C'est le sentiment que je voulais partager ^{^}
  
  https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# avis defavorable sur ELK

Posté par guitou le 23 août 2024 à 18:31. Évalué à 4.

Hello

Je partage, et si besoin de donner ne serait-ce qu'une raison, perso, pour avoir eu l'occasion de me pencher dessus il y a qq annees, j'ai vite dechante: c'est super lourdingue, en termes de memoire notamment, et comme il s'agissait en plus de le faire tourner dans une VM, c'etait pas la joie…
Pour la circonstance, j'avais a l'epoque garde le L pour me faire une pile InfluxDB, LogStash, Graphana qui faisait plutot bien le job sans me mettre le serveur sur les rotules.

++
Gi)
- [^] # Re: avis defavorable sur ELK
  
  Posté par steph1978 le 23 août 2024 à 20:03. Évalué à 4.
  
  InfluxDB, LogStash, Graphana
  
  Je trouve ces choix judicieux.
  
  Stocker des logs dans ELS, c'est hyper luxueux. Il y a des produits plus économes comme Loki.
  
  En même temps, je lis que - et je connais - des gens stockent leurs logs dans Spl€€€k alors pourquoi pas dans ELS.
  - [^] # Re: avis defavorable sur ELK
    
    Posté par barmic 🦦 le 24 août 2024 à 00:11. Évalué à 2.
    
    Logstash est vraiment le pire des 3 de mon expérience, il est le plus lent et de loin. C'est pour ça qu'il est remplacé aussi souvent que possible par les "beats" même en restant dans une suite elastic.
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: avis defavorable sur ELK
    
    Posté par henri_my le 25 août 2024 à 18:08. Évalué à 2.
    
    ELK c'est super classique, il y a des tutos partout donc c'est facile à mettre en place.
# nosql ?

Posté par steph1978 le 23 août 2024 à 22:47. Évalué à 4.

J'ai pas creusé la doc ou le code mais comme c'est évoqué dans le journal, je pose la question ici.

Qu'est ce qui a dicté le choix de badgerdb plutôt qu'un base de données SQL type Postgres ou SQLite si on cherche de l'embarqué ?

Ma compréhension est que l'outil sert à définir et exécuter un traitement sur une source de logs. Je suppose donc que l'outil ne stocke que des données de "gestion", pas les données en elles-mêmes. Ainsi je ne vois pas le besoin d'un stockage spécialisé.
- [^] # Re: nosql ?
  
  Posté par David Delassus (site web personnel) le 23 août 2024 à 23:43. Évalué à 3.
  
  Sisi, l'outil stocke bien les données.
  
  Mon choix s'est porté sur BadgerDB car c'est une base de données clés/valeurs très solide et distribuée sous forme de librairie Go.
  
  Une base de données SQL implique d'avoir un schéma, ou de s'en servir comme une base de donnée clé/valeur.
  
  Pour ce qui est de la structure de données sous jacente, BadgerDB utilise un LSM Tree ( https://en.wikipedia.org/wiki/Log-structured_merge-tree ) ce qui se prête très bien aux données que je désire stocker.
  
  De plus BadgerDB supporte les transactions ACID (la plupart des base de données SQL aussi cela dit), donc il n'y a aucun inconvénient à l'utiliser.
  
  En utilisant une base de données clés/valeurs, j'ai aussi un meilleur contrôle sur la structure de données pour les indexes.
  
  Je t'invite à lire ce document : https://github.com/link-society/flowg/blob/main/docs/design/storage.md
  Il est peut être incomplet, donc tout retours dessus est bienvenu :)
  
  https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
  - [^] # Re: nosql ?
    
    Posté par Jean Roc Morreale le 27 août 2024 à 09:31. Évalué à 2.
    Je réagis sur "Une base de données SQL implique d'avoir un schéma, ou de s'en servir comme une base de donnée clé/valeur." juste pour le fun. Si je prend l'exemple de flowg entry:<stream name>:<timestamp in milliseconds>:<UUID v4>, un schéma PgSQL ressemblerait à ça :
```
-- création d'une table reprennant l'exemple de la doc flowg
CREATE TABLE flowg (
  timestamp TIMESTAMPTZ,
  pk_uuid uuid DEFAULT gen_random_uuid(),
  data JSONB
);

-- pour convertir dans un format de stockage timescaledb
SELECT create_hypertable('flowg', by_range('timestamp'));

-- pour indexer toutes les clés
CREATE INDEX idx_global ON flowg USING GIN (data);

-- pour indexer une clé particulière
CREATE INDEX idx_partial
  ON flowg ((data->>'some_key'))
  WHERE data ? 'some_key';
```
    c'est qu'une des nombreuses solutions, on peut aussi voir des solutions en base fichier capables de manger et régurgiter des tonnes de séries temporelles :)
- [^] # Re: nosql ?
  
  Posté par David Delassus (site web personnel) le 23 août 2024 à 23:51. Évalué à 3.
  
  Désolé de faire ça en 2 commentaires, j'ai oublié de préciser :
  
  Je veux aussi que l'outil soit le plus simple possible a déployer. C'est à dire une seule image Docker.
  
  Donc dépendre d'une base de données externe comme PostgreSQL c'était exclu.
  
  https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# agencement des blocks

Posté par steph1978 le 23 août 2024 à 22:56. Évalué à 4.

Dans le diagramme données en exemple, je trouve que le positionner le block appname = "docker en dessous de la source prête à confusion.

Le ligne grise est trop fine pour comprendre que l’exécution reprend après le syslog, on (je) a l'impression qu'un nouveau traitement commence.

Je l'aurai plutôt vu en dessous du block appname = "prometheus" ; pour être à droite de la source.

Ne connaissant pas React Flow, je ne sais pas si l'agencement est automatique ou choisi par l'utilisateur. Dans le second cas, c'est d'autant plus facile à corriger ;)
- [^] # Re: agencement des blocks
  
  Posté par David Delassus (site web personnel) le 23 août 2024 à 23:46. Évalué à 3.
  
  Alors, sur un screenshot on le voit pas, mais les lignes sont "animées" ce qui aide à la visualisation :)
  
  Après, c'est surtout que je voulais faire tenir l'ensemble de la pipeline sur la capture d'écran. De toute façon, il y a plein de choses à améliorer sur le design.
  
  React Flow offre la possibilité d'agencer les noeuds automatiquement, mais non, ici c'est bien moi qui ait fait ça ^{^}
  
  https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
  - [^] # Re: agencement des blocks
    
    Posté par barmic 🦦 le 24 août 2024 à 00:10. Évalué à 4.
    
    J'ai pas l'impression qu'on ai fait beaucoup mieux que les diagrammes d'activités UML ces 25 dernières années. Sans en faire des caisses au moins utiliser des flèches et des losanges pour les conditions ça parait pas mal à mon avis.
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# intéressant

Posté par raspbeguy (site web personnel, Mastodon) le 25 août 2024 à 21:41. Évalué à 3.

Je garde ça sous le coude, merci pour ton travail !

Un gentil du net
- [^] # Re: intéressant
  
  Posté par David Delassus (site web personnel) le 25 août 2024 à 22:50. Évalué à 3.
  
  Merci :)
  
  N'hésite pas à faire des retours, toutes critiques est bonne pour améliorer la solution ^{^}
  
  https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.