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.
1. Les traces, first class citizen d'OpenTelemetry
OpenTelemetry est un projet relativement récent (2019), car il est en fait la fusion de deux autres projets : OpenCensus (qui est la version open source de Census de Google), et OpenTracing. Inutile d'entrer dans les détails, mon point ici est que ces projets tournaient initialement autour du tracing bien plus qu'autour des métriques ou des logs. Et c'est un peu normal, car comme je l'ai déjà évoqué, le passage en microservices, encore renforcé par la mise en conteneurs, a créé la nécessité d'avoir de nouveaux outils pour comprendre nos applications.
Bien sûr, ce qui est nouveau pour le grand public existait déjà depuis plus d'une décennie chez Google, car en réalité, c'est à Google que l'on doit la version actuelle du tracing distribué. Comme souvent, Google a publié un article de recherche sur leur outil de traces distribuées nommé Dapper [1]. Du coup, la communauté open source s'est saisie des...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première