Note de lecture : Logging in Action, par Phil Wilkins

Note : 6 ; Comprendre le “log shipping” avec fluentd !

Avec 300 pages, l’ouvrage est légèrement au-dessus de la moyenne, il compte 11 chapitres répartis en 4 parties, ce qui est un découpage également raisonnable. La première partie « From zero to hello world » ne cache pas son caractère introductif et nous propose 2 chapitres sur une soixantaine de pages. S’il est déjà bien focalisé sur Fluentd, le premier chapitre d’une trentaine de pages couvre bien les problématiques du « log shipping » en corrélation sur ce qu’est un élément de log. Il ne manque pas non plus d’évoquer son concurrent de toujours, Logstash. C’est une bonne introduction, fort prometteuse. Le second chapitre nous fait découvrir à haute altitude les éléments structurants de Fluentd. Cela permet de mieux le conceptualiser en tant que « ESB pour les logs ». Mais le gros du chapitre est consacré au déploiement et aux nombreuses options possibles. C’est certes intéressant, mais je trouve le propos assez déséquilibré dans ce chapitre.

La seconde partie « Fluentd in depth » explicite bien le titre sa finalité. Il couvre une centaine de pages avec 4 chapitres. Le chapitre 3 nous permet de rentrer dans l’action en mettant en œuvre pour capturer les évènements de log à la source, mais en l’occurrence uniquement sous forme de fichiers. C’est dommage, car Fluentd permet aussi de capturer d’autres sources, mais ce sera en partie traité plus tard. Le second volet traite du parsing permettant d’imposer une structure au log dès leur capture. Au final une bonne couverture du sujet, même si elle est limitée aux fichiers. C’est fort logiquement à l’ouput qu’est consacré le chapitre 4. On y découvre des possibilités que l’on ne soupçonnait pas : buffering (pour grouper les évènements à des fins d’optimisation), compression, etc. Contrairement au chapitre 3, l’auteur nous met en perspectives la mise en œuvre sur plusieurs destinations, de quoi nous donner envie !

Les choses se compliquent au chapitre 5 où il est question de routage. C’est le côté ESB de Fluentd. Il faut un peu s’accrocher pour bien saisir les notions de copie d’évènements et surtout de réécriture des tags, car l’outils utilise essentiellement ceux-ci pour le routage, ce qui fait un peu bricolage de mon point de vue. On termine en beauté avec la notion de pipeline qui donne toute sa dimension à Fluentd, mais il faut s’accrocher un peu. Cette seconde partie se referme sur un chapitre 6 consacré au filtrage et à l’enrichissement des évènements. Là encore, on découvre la puissance insoupçonnée du log shipping. Si les filtres nous permettent de déclencher des actions spécifiques sur certains logs, l’enrichissement nous ouvre les portes sur l’ajout d’informations de contexte ou la « rédaction » de logs qui permet d’éliminer de ceux-ci les données à caractère personnel ! Bref, là encore de belles perspectives.

Continuer à lire « Note de lecture : Logging in Action, par Phil Wilkins »

Note de lecture : Software Telemetry, par Jamie Riedesel

Note : 4 ; Une très belle conceptualisation, mais un texte qui s’éparpille et manque souvent de hauteur

J’ai renommé la section dans laquelle figure cette note de lecture d’après ce livre. Cela devrait en dire long sur celui-ci. Car celui-ci aborde et conceptualise de manière original un sujet : celui de l’architecture du pipeline d’observabilité. Pourtant il n’est pas écrit par un architecte, mais par une ops. Cela est très visible dans la manière dont les sujets sont abordés et cela coûte au texte pas mal de points.

Le texte justement, parlons-en. Il est franchement volumineux avec ses 500 pages découpés en 3 parties, pour un total de 18 chapitres. La première partie aborde le volet architecture que j’évoquais. Cela occupe 170 pages sur 7 chapitres, auquel il faut rajouter le chapitre d’introduction. Il ne faut assurément pas rater ce dernier : les grandes lignes de l’architecture du pipeline d’observabilité y sont décrites, ainsi que les usages de l’observabilité (métriques et logs) par différents acteurs : développeurs, ops, exploitant, sécurité, service légaux…

Le chapitre 2 qui ouvre réellement cette première partie rentre en profondeur sur « l’emitting stage ». On voit déjà ici l’angle ops du texte qui évoque bien SNMP ou systemd, tandis que des briques logicielles permettant l’émission de logs ou de métriques sont passées assez légèrement. Ainsi Log4J est succinctement évoqué, mais pas JMX… Le propos n’est pas inintéressant, mais il aurait peu être nettement meilleur et plus efficace. Fort logiquement, le chapitre 3 va couvrir le shipping, mais également le stockage, ce qui est peut-être trop. J’ai apprécié l’analyse de plusieurs architectures de shipping intégrant même des bus orientés queues (tel que Kafka), mais curieusement les superstars telles que fluend ou Logstash n’y ont guère de place. Il faudra vous diriger vers l’excellent et mal nommé « Logging in Action » si vous êtes frustrés…

Continuer à lire « Note de lecture : Software Telemetry, par Jamie Riedesel »