Comment OpenTelemetry change la façon dont nous traçons et concevons des applications

L’observabilité est essentielle lors de l’exécution d’applications cloud natives, où les fonctionnalités de l’application émergent de l’interaction entre un grand nombre de microservices exécutés dans plusieurs emplacements. La nature faiblement couplée des applications de microservices signifie potentiellement que chaque microservice rend compte de ses activités à sa manière. Sans un outil qui compile et corrèle ces données de télémétrie, il est extrêmement difficile, voire impossible, de suivre le traitement d’une demande du début à la fin, ce qui est crucial pour le dépannage.

Lors de la recherche d’un outil d’observabilité multifonctionnel, l’ équipe derrière le projet NGINX Modern Apps Reference Architecture (MARA) a choisi OpenTelemetry . Notre équipe OSS ayant choisi ce projet émergent, nous souhaitons aller plus loin. Lors de GlueCon 2022 , j'ai rencontré Granville Schmidt, architecte au bureau du CTO de F5, pour discuter des raisons pour lesquelles nous sommes enthousiasmés par l'état actuel et les offres futures d'OpenTelemetry. Vous pouvez regarder notre conversation ci-dessous et, dans ce blog, en savoir plus sur les raisons pour lesquelles OpenTelemetry est un atout précieux pour le paysage des application cloud natives.

OpenTelemetry optimise l'observabilité 2.0

Annoncé pour la première fois lors de la KubeCon 2019 à Barcelone, OpenTelemetry a attiré un ensemble de contributeurs enthousiastes. Il s’agit du deuxième projet le plus populaire de la Cloud Native Computing Foundation (CNCF) en termes de nombre de contributions et, au cours des six derniers mois, le taux de contribution a été plus élevé que jamais. Ce grand nombre de contributeurs montre qu'OpenTelemetry a mûri et commence à franchir le fossé entre les premiers utilisateurs (qui sont prêts à avoir une longueur d'avance) et les pragmatiques (qui désirent des produits matures).

OpenTelemetry se concentre sur les données, en particulier les données et le flux de données (télémétrie) nécessaires pour mieux comprendre, dépanner et améliorer nos applications. Les données ne sont utiles que si elles peuvent être agrégées, analysées et visualisées à grande échelle. Bien qu’OpenTelemetry ne fournisse pas d’indications sur la manière de visualiser les données, il nous permet d’arrêter de nous soucier des données que nous pouvons obtenir et de nous concentrer plutôt sur ce que nous pouvons faire avec les données.

OpenTelemetry permet également une corrélation naturelle entre ces sources de données, plutôt que de s'attendre à ce que nous tentions nous-mêmes cette corrélation. La capacité d'OpenTelemetry à corréler les événements entre les applications nous conduit vers Observability 2.0 – une nouvelle référence pour mesurer l'activité des application dans le cloud. Les données sont déjà corrélées pour nous, ce qui change la façon dont nous regardons notre espace application . Nous ne nous limitons plus à savoir si l’application est en cours d’exécution ou non ; nous pouvons désormais comprendre le chemin emprunté par chaque requête dans nos applications.

Deux projets open source notables ont précédé OpenTelemetry : OpenTracing (OT) et OpenCensus (OC) . Ces deux entreprises ont relevé le défi de normaliser le format des données de trace afin que nous puissions obtenir les informations nécessaires et comprendre leur impact sur nos applications modernes. Bien que chaque projet présente des similitudes, ils étaient en concurrence pour les ressources et les entreprises devaient souvent n’en choisir qu’un seul. En mars 2019, les deux projets ont annoncé leur fusion au sein d'OpenTelemetry dans le but d'unifier la manière dont les données de trace sont générées et formatées. Le projet OpenTelemetry définit davantage de normes pour l'acquisition d'autres classes de données d'observabilité ( métriques et journaux ) via les mêmes canaux de télémétrie que les traces, conduisant à plus d'intégration et de clarté.

Ensuite, examinons deux aspects fonctionnels intéressants d’OpenTelemetry : le traçage distribué et intelligence applicative .

Pourquoi le traçage distribué est nécessaire dans les architectures d'applications modernes

Bien que le traçage distribué existe depuis des années, de nombreux changements au cours de la dernière décennie ont accru sa nécessité. En utilisant le framework Cynefin , nous pouvons mettre en évidence certains des changements et des défis auxquels nous sommes désormais confrontés dans les applications modernes :

Le cadre Cynefin illustre comment nous pouvons changer nos pratiques à mesure que nous passons du simple au complexe. Le défi est que notre mouvement emprunte deux chemins distincts, chacun avec ses propres caractéristiques, et essayer de prendre un raccourci direct du simple au complexe crée souvent du désordre et des progrès incomplets.

Identifions les éléments qui créent les chemins dans notre application moderne et notre parcours cloud natif. Dans notre premier chemin (l’axe Y dans le diagramme Cynefin), nous avons des applications modernes qui sont généralement des architectures de microservices, où chaque application effectue un travail spécifique. Dans le deuxième chemin (axe X), notre environnement complexe est éphémère, car les instances de microservices montent et descendent en réponse à la demande et sont déplacées vers différents hôtes en réponse aux problèmes de réseau.

Nous devons également prendre en compte l’émergence et la croissance massive d’environnements cloud comme Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP). L’un des avantages de ces nuages est leur réponse élastique : ils augmentent ou réduisent les ressources pour correspondre au niveau de demande actuel. Avec l’impact supplémentaire de l’orchestration des conteneurs (le plus souvent à l’aide de Kubernetes), nous commençons à observer un comportement chaotique à mesure que le nombre et l’emplacement des ressources changent au fil du temps. (Même cette vue relativement restreinte est chaotique, et des éléments comme les fonctions sans serveur peuvent la rendre encore plus chaotique.)

Dans une architecture moderne, avec de nombreuses parties distinctes produisant la télémétrie dont nous avons besoin pour surveiller et maintenir nos applications, la charge de données est massive et compliquée. Les problèmes peuvent ne pas se répéter de manière fiable ou être faciles à détecter, car nous ne contrôlons pas entièrement l’infrastructure et les voies de communication. Nous avons besoin d’une technologie qui nous permette de suivre toutes les activités et les éléments connexes, afin que nous puissions comprendre et analyser nos environnements changeants.

C'est là qu'intervient OpenTelemetry.

L'avenir du traçage distribué avec OpenTelemetry

Le traçage distribué provoque de grands changements dans le secteur, notamment autour de la manière dont les requêtes génèrent une vue interne des performances via des métriques. Grâce au traçage distribué, nous pouvons suivre de nouvelles mesures de nombreux types, mais le plus souvent celles liées au nombre de requêtes par unité de temps, au nombre d'erreurs par unité de temps et au temps qu'une requête globale prend sur cette unité de temps.

Les métriques existent depuis un certain temps : elles sont faciles à gérer et à stocker, s’agrègent facilement et se prêtent à l’analyse mathématique. Dans OpenTelemetry, toutes les applications qui génèrent des métriques peuvent les envoyer à un point de collecte commun via une couche de télémétrie (transfert), ce qui permet d'aligner les données des services faiblement couplés qui les génèrent. Cela inclut l’alignement avec l’infrastructure sous-jacente. En bref, avec OpenTelemetry, il devient plus facile d’acquérir et d’envoyer des métriques.

OpenTelemetry peut également aider à résoudre le problème de dérive et de décalage des horodatages, ce qui rend difficile la corrélation des événements. OpenTelemetry attribue à chaque requête un TraceId , mais les données peuvent toujours être affectées par la dérive et le biais, qui apparaissent souvent dans les architectures cloud natives. La dérive et l'asymétrie peuvent résulter de chemins de rapport avec des durées variables ou d'un manque de synchronisation étroite entre les horloges des différents hôtes. En suivant la communication entre les composants pendant le traitement du trafic, le traçage distribué permet à OpenTelemetry de mesurer les portées individuelles (les unités de travail et les éléments constitutifs d'une trace) sans nécessiter une instrumentation approfondie de l'application associée.

La combinaison de ces trois signaux (catégories de télémétrie) nous permet de corriger les problèmes et de ramener nos applications à la qualité de production :

• Mesures – « Y a-t-il un problème ? »
• Traces – « Où est le problème ? »
• Journaux – « Quel est le problème ? »

C'est ici que nous revenons à l'Observabilité 2.0. La possibilité d’obtenir des traces et de voir immédiatement quelles métriques correspondent à quelle trace nous donne beaucoup de puissance. Par exemple, lorsque les mesures indiquent un problème, le traçage distribué vous permet de remonter jusqu'à la demande spécifique à l'origine du problème initial et de suivre la progression à chaque étape de l'exécution de la demande. Étant donné que notre trace est constituée des intervalles dans l’ordre dans lequel ils se produisent, nous pouvons suivre la requête à travers chaque étape de son parcours. Avoir une compréhension de ce qui s’est passé, dans quel ordre – de l’événement initial au problème indiqué et jusqu’au résultat final – nous permet de cibler exactement « où » dans nos applications sur lequel concentrer notre attention.

Aussi simple que cela puisse paraître, l'aspect de traçage distribué d'OpenTelemetry peut nous fournir un excellent aperçu de ce que vivent nos utilisateurs, en étant un proxy pour le succès des requêtes et le moment de l'exécution. En tant qu'utilisateur, je me soucie de ma demande. En tant qu'ingénieur en fiabilité de site (SRE), je me soucie des demandes agrégées . OpenTelemetry me donne les deux, ainsi que la possibilité d'explorer en profondeur les données globales, car il est conçu pour rendre toutes les données nécessaires disponibles dans toutes les applications.

Intelligence applicative avec l'IA et le ML

Ce nouveau flux de données d’OpenTelemetry nous permet également d’être adaptatifs et automatisés dans notre développement et notre réponse opérationnelle. Avec toutes ces données accumulées, nous pouvons rendre notre application plus intelligente. F5 se concentre actuellement sur l’aide à nos clients dans leur parcours de développement et de déploiement de ce que nous appelons des « applications adaptatives ». Les applications adaptatives sont exactement ce que leur nom indique : des applications qui ajustent automatiquement et intelligemment leur comportement en réaction aux changements de leur environnement.

C’est pourquoi vous voyez beaucoup plus intelligence artificielle (IA) et d’apprentissage automatique (ML) dans diverses solutions. Mais ce n’est pas seulement parce qu’il s’agit de termes tendance : l’IA et le ML sont utiles parce que nous disposons désormais de suffisamment de données pour tirer des conclusions précises sur la causalité et concevoir des réponses appropriées.

En rendant les données de télémétrie accessibles et standardisées, OpenTelemetry rend le parcours vers des applications adaptatives beaucoup plus facile. À mesure que différents types de produits commencent à générer des métriques similaires et en utilisant les conventions sémantiques établies au sein d'OpenTelemetry, il devient plus facile de corréler leurs actions pendant le traitement des requêtes et de transmettre ces informations aux algorithmes ML et AI pour permettre aux applications et à l'infrastructure de s'adapter de manière dynamique.

Lorsque vous comprenez la science des données qui se cache derrière tout cela et que vous vous assurez que vos données de télémétrie sont liées à votre IA et à votre ML, c’est là que la nature axée sur les données des applications adaptatives peut évoluer et briller.

Résumé

La codification de la télémétrie est un avantage évident tant pour les utilisateurs d’OpenTelemetry que pour les applications qui l’utilisent comme canal de télémétrie. Les données peuvent être collectées à partir de plusieurs sources et transmises à n’importe quel outil d’agrégation et d’analyse compatible. De plus, OpenTelemetry Collector libère les fournisseurs de la nécessité d'implémenter eux-mêmes les collecteurs. Au lieu de cela, ils peuvent se concentrer sur l’amélioration de leur code pour effectuer des analyses significatives et prendre des mesures intelligentes, et peuvent créer de nouveaux outils pour aider à comprendre ce nouveau monde complexe et chaotique. En fait, OpenTelemetry Collector – soutenu par l’innovation de l’open source – est extrêmement capable de fonctionner avec presque tous les formats existants tout en faisant le pont entre la technologie et l’avenir.

En se concentrant sur les principales classes de données dont nous avons besoin pour comprendre nos applications, OpenTelemetry a permis à nos applications de fournir des informations plus approfondies sur les performances et les problèmes de notre monde application moderne et complexe. En corrélant nos données, en nous alignant sur des conventions sémantiques et standard, OpenTelemetry rend le voyage vers des applications modernes plus accessible. Et à mesure que le projet continue de mûrir et que l’adoption continue de croître, OpenTelemetry est l’approche claire pour notre compréhension plus approfondie et notre capacité à appliquer les techniques d’IA et de ML pour rendre cette complexité compréhensible.

Pour en savoir plus sur la manière dont les ingénieurs OSS de NGINX utilisent OpenTelemetry, essayez l' architecture de référence des applications modernes et l'exemple application (Bank of Sirius).

Articles Similaires

• Trois étapes pour démarrer votre parcours cloud natif avec Kubernetes