Vous avez dit event-driven ?

L'arrivée de Docker, de Kubernetes et plus généralement de ce que l'on nomme le cloud natif a bousculé nos habitudes : de la manière dont nous écrivons notre code, dont nous le déployons, mais aussi de la manière dont nous l'observons ! Peu d'entre nous se préoccupaient de l'Application Performance Monitoring (APM) avant 2014, et je suis sûr que beaucoup ignorent encore ce qu'est une trace distribuée. Pourtant, avec nos applications dynamiques découpées en microservices et hébergées dans le cloud, il est de plus en plus difficile de faire l'impasse sur ce genre d'outils. Et le continuous profiler est justement l'un de ces précieux outils.

N'importe qui ayant travaillé dans l'informatique depuis plus de cinq ans vous le dira : on n'a pas attendu Google et son livre sur les SRE [1] pour « monitorer » nos systèmes. Au passage, excusez-moi pour l'affreux barbarisme alors que j'aurais pu utiliser le mot surveiller tout simplement, mais alerte de « divulgâchage » : il y en aura malheureusement bien d'autres dans cet article, parce que soit je ne trouve pas la traduction française satisfaisante, soit la traduction française n'a pas exactement le même sens. Alors pourquoi depuis cinq ans ne parle-t-on plus que d'observabilité et non plus de monitoring ?

Après avoir survolé ce qu'était une trace distribuée dans l'article sur les 3 piliers de l'observabilité, et donné une description des différents éléments qui la composaient, nous allons entrer un peu plus dans les détails de l'instrumentation proprement dite. Car si collecter des traces pour mieux comprendre une application en microservices change totalement la donne, pour autant, cela demande un peu de travail. Et c'est justement ce qui explique la montée en puissance d'OpenTelementry aujourd'hui. Vous allez découvrir pourquoi.