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…

Le chapitre 4 qui traite de l’unification des formats s’inscrit en fait dans la continuité du chapitre 3 car il figure toujours dans le « shipping stage ». Il est bien brouillon ce chapitre, malgré une finalité des plus intéressante, car il mélange joyeusement des questions de format logique et physique, de moyens de sérialisation et de bus de transport déjà évoqué au chapitre précédent. Alors qu’une articulation logique existe, l’auteur échoue à la mettre en évidence. Le chapitre 5 qui aborde la présentation est plutôt bien fait, avec un point bonus sur la durée de rétention des informations en fonction de leur nature !

On passe à l’enrichissement des informations au chapitre 6, un sujet là encore intéressant et rarement abordé. Le texte est à nouveau un peu frustrant : on y passe rapidement des considérations très haut niveau à du code bas niveau en Python. C’est hélas assez récurrent dans l’ouvrage et chagrinera ceux qui ont plus une fibre conception. Cette première partie se referme sur l’impact du multi-tenancy sur l’architecture. Malgré une approche où l’auteure attaque l’impact que cela a au niveau de chaque stade du pipeline, le propos reste un peu brouillon.

La seconde partie va être consacrée à la transposition de cette architecture sur différents cas d’utilisation. Elle couvre 3 chapitres sur 80 pages qui sont autant de types d’organisations différentes. J’ai trouvé l’approche vraiment intéressante. Le chapitre 8 aborde le cas de la startup résolument basée sur le cloud, et à différents stades de croissance. Ce sont bien sûr des solutions SaaS qui sont mises en œuvre, sir une infrastructure AWS. Le propos n’est pas évident à suivre car il nécessite une certaine familiarité avec certaines technologies, je pense particulièrement à Kubernetes.

Le second cas d’usage est aux antipodes : il s’agit d’une entreprise qui n’est pas dans le domaine informatique (mais qui va aussi grandir). Nous la verrons passer d’une infrastructure basée sur des outils bureautique, vers du cloud Azure pour terminer vers une architecture ressemblant d’avantage à ce que l’on a vu au début de l’ouvrage. Ne ratons pas au passage la mention de SolarWind et du petit texte explicatif dont nous gratifie l’auteure. C’est à une entreprise « bien établie » avec des systèmes assez âgés qu’est consacré le dernier chapitre de cette seconde partie. Le chapitre mérite sans doute que l’on y revienne, car les architectures qui nous sont présentées sont particulièrement complexes, mais aussi intéressantes !

La 3ème partie est dédiée à des pratiques et techniques pour adresser des sujets particuliers au sein du pipeline. Ce sont en quelque sorte des coups de zoom auxquels se livrent ces 8 chapitres. Ils couvrent environ 200 pages. Le chapitre 11 qui ouvre cette dernière partie est pour moi hors sujet : il traite de l’optimisation des expressions régulières pour permettre le scaling. Le sujet est certes connexe au pipeline, mais trouverait logiquement sa place dans un ouvrage sur les expressions régulières (cela existe). Le chapitre 12 nous propose d’implémenter un logger en suivant l’architecture de Log4J ! J’avoue avoir eu du mal à me passionner pour suivre le propos accompagnant le code en Python : on est vraiment le nez dans le code.

Il faut attendre ce chapitre 13 pour voir comment traiter du log ne passant pas par des fichiers (adieu, surface d’attaque), plus précisément en utilisant des datagrammes UDP. Le chapitre fait le boulot quoique certaines parties ne soient pas si facile à appréhender. Au chapitre 14, il sera question du problème des cardinalité et des stratégies pour l’adresser : il s’agit d’un problème auquel les bases de données de type time-series sont particulièrement sensibles. Un bon chapitre.

L’auteure a de toute évidence une bonne expérience des problèmes légaux associés aux logs : ce chapitre 15 explore la question de la garantie d’intégrité de ces derniers. Plusieurs options (non-exclusives) sont développées, et ce sont assurément des techniques qui méritent d’être d’avantage connues. Plus près encore des considérations légales, le chapitre 16 aborde le redacting / rewritting des logs pour adresser les considérations de type RGPD. Ce sont des concepts connus au sein du petit monde du log, mais assez peu en dehors, hélas.

Au chapitre 17, nous allons voir la gestion des politiques de rétention / agrégation des données télémétriques en fonction de leur nature. C’est un chapitre peu technique qui prolonge le propos du chapitre 5. C’est intéressant sans être grandiose. Le livre se referme sur un chapitre 18 purement consacré aux questions juridiques : comment aborder un audit et comment collaborer avec les juristes ! C’est assurément original et même précieux.

L’ouvrage est imposant. Bien plus que nécessaire, en fait. Le propos zigzag beaucoup, ce qui amène de nombreuses répétitions. L’angle ops n’est pas des plus confortables pour des personnes venant du développement, c’est bien dommage car la conceptualisation du pipeline d’observabilité est une découverte pour moi et me fait repenser ce que je sais déjà sur le log. Le traitement du sujet est moins bon que ce qu’il aurait dû être, le livre hérite d’un « 4 » là où il aurait pu (et dû) être noté 7 !

Référence complète : Software Telemetry – Jamie Riedesel – Manning 2021 – ISBN: 978 1 61729 814 1

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.