Greboca  

Suport technique et veille technologique

Suport technique et veille technologique

Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.

C’est alors la barrière de la prise en main qui fait peur, et pourtant...

Les logiciels libres

L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.

Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.

Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.

Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.

LinuxFr.org : les journaux  -  FlowG sort en version v0.29.0

 -  23 mars - 

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

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 :

capture d'écran de la configuration d'un forwarder syslog

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 !

Commentaires : voir le flux Atom ouvrir dans le navigateur

par David Delassus

LinuxFr.org : les journaux

LinuxFr.org : Journaux

IA : Imitation Artificielle

 -  28 mars - 

Bonjour Nal',Tout le monde cause de l'IA. L'IA par ci, l'IA par là. L'IA dans les journaux qui trouvent qu'il y a trop d'IA.Ça commence à (...)


Un super Logic Analyzer DIY pour pas cher

 -  26 mars - 

Wouah, le titre cryptique. Un peu de Wikipedia pour éclaircir (j’espère que c'est mieux que ChatGPT):L’analyseur logique est un outil de mesure (...)


Mise a jour de la traduction française du Wiki de Scribus

 -  24 mars - 

Je viens de commencer à mettre à jour la traduction française du Wiki du logiciel de Publication Assistée par Ordinateur (PAO) Scribus (équivalent (...)


Après photorec

 -  14 mars - 

Sommaire Fichiers perdus Et maintenant ? Retirer les fichiers de programmation Compter les fichiers par type Compter les fichiers dont le noms a (...)


ClockWork PicoCalc

 -  13 mars - 

Puisqu'on parle de calculatrices, de bidouillages, d'Open Source et d' Open Hardware, je crois bien que je vais craquer … (...)