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…
Lire la suite