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
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
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 . Évalué à 1 (+2/-3).
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) . Évalué à 5 (+3/-0). 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 . Évalué à 4 (+2/-0).
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 . Évalué à 3 (+1/-0).
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) . Évalué à 3 (+1/-0).
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) . Évalué à 6 (+4/-0).
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) . Évalué à 3 (+1/-0).
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 :)
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 . Évalué à 4 (+3/-0).
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 . Évalué à 4 (+2/-0).
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 🦦 . Évalué à 2 (+1/-1).
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 . Évalué à 2 (+4/-2).
ELK c'est super classique, il y a des tutos partout donc c'est facile à mettre en place.
# nosql ?
Posté par steph1978 . Évalué à 4 (+2/-0).
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) . Évalué à 3 (+1/-0).
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 . Évalué à 2 (+1/-0).
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 :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) . Évalué à 3 (+1/-0).
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 . Évalué à 4 (+2/-0).
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) . Évalué à 3 (+1/-0).
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 🦦 . Évalué à 4 (+2/-0).
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) . Évalué à 3 (+2/-0).
Je garde ça sous le coude, merci pour ton travail !
Un gentil du net
[^] # Re: intéressant
Posté par David Delassus (site web personnel) . Évalué à 3 (+1/-0).
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
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.