Que sont les indicateurs OpenTelemetry ?

À l’instar des journaux et des traces OpenTelemetry, les indicateurs OTel fournissent des signaux de télémétrie standardisés reposant sur un modèle de données commun et indépendant des langages, ainsi que sur un protocole de transmission commun, plus précisément, le protocole OpenTelemetry (OTLP). Ils permettent ainsi d’ingérer des données provenant de différentes sources, de différents systèmes et formats, puis de les transmettre à des plateformes d’observabilité back-end. 

Les indicateurs OTel s’appuient sur l’instrumentation OpenTelemetry pour recueillir des données de séries chronologiques telles que l’utilisation du processeur et de la mémoire, le débit, les taux d’erreur, le nombre de requêtes et les temps de réponse, pendant l’exécution des applications et des composants d’infrastructure. Une fois que les développeurs ont instrumenté le code afin d’enregistrer les indicateurs nécessaires, OTel permet d’agréger ces indicateurs et de les exporter vers n’importe quel outil d’observabilité back-end (voire tous) à des fins de stockage, d’interrogation et de visualisation, sans avoir à modifier l’instrumentation.

Les indicateurs sont généralement les premiers signaux de télémétrie à révéler un problème au sein d’un système. Dans le cadre OTel, ils sont intégrés aux journaux (des enregistrements immuables d’événements système distincts) et aux traces (le parcours de bout en bout d’une requête de données) reposant sur les mêmes concepts et métadonnées.

Grâce à cette dynamique, les développeurs et les ingénieurs en fiabilité des sites (SRE) peuvent utiliser les indicateurs comme un système d’alerte précoce de haut niveau. Ils peuvent suivre l’intégralité du parcours d’une défaillance (notamment les indicateurs de chaque service avec lequel le composant défaillant a interagi) dans une vue cohérente, puis basculer rapidement vers les traces et les journaux afin d’effectuer une analyse des causes profondes.

Dans la pratique, cela signifie que les équipes informatiques peuvent passer du constat « ce point de terminaison est lent » à l’identification « ces requêtes et dépendances précises sont à l’origine du problème » en seulement quelques clics.

En outre, les protocoles de standardisation d’OTel facilitent la corrélation automatisée des signaux entre différents fournisseurs de solutions d’observabilité. Les entreprises peuvent ainsi changer d’outil d’observabilité lorsqu’elles le souhaitent ou utiliser plusieurs outils simultanément.

Les indicateurs OpenTelemetry constituent un composant fondamental d’OpenTelemetry. OpenTelemetry est un cadre d’observabilité open source comprenant un ensemble de kits de développement logiciel (SDK), d’interfaces de programmation d’application (API) indépendantes des fournisseurs et d’autres outils destinés à l’instrumentation des applications, des systèmes et des appareils.

Auparavant, le code d’instrumentation variait considérablement, et aucun fournisseur commercial ne proposait à lui seul un outil capable de recueillir des données provenant de l’ensemble des applications et services d’un réseau. Cette lacune fonctionnelle compliquait (et rendait souvent impossible) la collecte par les équipes de données issues de différents langages de programmation, formats et environnements d’exécution.

Les approches traditionnelles de l'observabilité ont également fait de la modification de l'infrastructure et des composants du backend un processus long et laborieux.

Imaginons qu’une équipe de développement souhaite changer d’outils back-end. Elle devrait réinstrumenter entièrement son code et configurer de nouveaux agents (des composants logiciels exécutant des tâches automatisées de compilation et de publication) afin d’envoyer les données de télémétrie aux nouveaux serveurs. Ces approches fragmentées créaient des silos de données et de la confusion, ce qui compliquait la résolution efficace des problèmes de performances.

OpenTelemetry a représenté une avancée majeure dans le domaine des outils d’observabilité, car il a standardisé la manière dont les données de télémétrie sont collectées, analysées et transmises aux plateformes back-end. Il a fourni une solution open source, reposant sur des normes élaborées par la communauté, permettant de recueillir des données sur le comportement et la sécurité des systèmes. Les équipes peuvent ainsi rationaliser la surveillance et l’observabilité au sein des écosystèmes distribués.

Les indicateurs OpenTelemetry reposent sur un ensemble de composants associés qui définissent collectivement la manière dont les indicateurs sont produits, décrits et transmis aux plateformes d’observabilité back-end. Ces composants comprennent les éléments suivants :

Les instruments sont les outils utilisés par le code pour enregistrer les valeurs des indicateurs. Ils enregistrent les valeurs de deux manières : de façon synchrone (directement dans le chemin d’exécution, pendant que le code s’exécute) ou asynchrone (chaque fois que le SDK demande au code de lui fournir des valeurs).

Puisqu’ils s’exécutent directement dans le cadre de l’opération, les instruments synchrones peuvent capturer le contexte de trace actuel ainsi que les attributs associés à l’événement. Les indicateurs qu’ils recueillent sont donc plus faciles à corréler avec les journaux et les traces.

Les instruments asynchrones sont actualisés par des fonctions de rappel basées sur un mécanisme d’extraction, que le SDK appelle selon un intervalle de collecte prédéfini. Ces instruments sont utiles pour enregistrer des valeurs échantillonnées périodiquement plutôt qu’à chaque requête utilisateur (comme l’utilisation du processeur ou de la mémoire). 

L’instrumentation OTel se situe entre la logique applicative et le pipeline d’indicateurs. Elle transforme des événements tels que « requête HTTP terminée » en mesures structurées que le SDK peut agréger et exporter. Chaque type d’instrument de mesure est optimisé pour un modèle de mesure précis et associé à une stratégie d’agrégation décrivant la manière dont le SDK doit combiner les différentes mesures pour produire les indicateurs exportés.

Les types d’instruments les plus courants sont les suivants :

• Les compteurs (Counters) sont des instruments synchrones qui enregistrent des incréments augmentant au fil du temps (comme le nombre total de requêtes ou le nombre total d’octets envoyés depuis le démarrage du processus). Les compteurs sont également monotones : chaque fois qu’ils enregistrent une nouvelle mesure, ils l’ajoutent à la valeur existante au lieu de la remplacer.

• Les compteurs bidirectionnels (UpDown Counters) sont des instruments synchrones qui enregistrent des valeurs pouvant augmenter ou diminuer au fil du temps (comme le nombre d’utilisateurs actifs ou la taille d’une file d’attente). Contrairement aux compteurs standard, les compteurs bidirectionnels ne sont pas monotones. Ils peuvent donc ajuster les totaux à la hausse ou à la baisse en remplaçant les valeurs existantes.

• Les compteurs asynchrones (Asynchronous Counters) et les compteurs bidirectionnels asynchrones (Asynchronous UpDown Counters) sont similaires à leurs équivalents synchrones, mais ils enregistrent les valeurs une fois par exportation, au lieu de les recueillir pendant l’exécution du code.

• Les jauges (Gauges) sont des instruments synchrones qui enregistrent des valeurs pouvant augmenter ou diminuer librement à chaque envoi de données. Elles représentent l’état d’une valeur au moment où celle-ci est collectée dans le code. Outre les jauges synchrones, la collecte d’indicateurs nécessite des jauges observables, qui sont des instruments asynchrones récupérant les valeurs actuelles chaque fois que la plateforme back-end d’indicateurs collecte des données.
  
  Les jauges capturent des instantanés de valeurs, de la même manière qu’un appareil photo capture des instantanés de son sujet. Comme les jauges ne sont pas cumulatives, elles sont généralement utilisées pour des valeurs non additives qu’il ne serait pas pertinent d’additionner (telles que l’utilisation de la mémoire ou la température).  

• Les histogrammes sont des instruments synchrones qui enregistrent le nombre de mesures comprises dans différentes plages de valeurs, plutôt que de suivre un nombre unique (comme un total ou une valeur actuelle). Ils répartissent les valeurs dans des « compartiments », ce qui permet aux équipes informatiques de calculer des centiles et de comprendre la distribution d’indicateurs tels que la durée des requêtes, la latence et la taille des charges utiles.

OTel définit un modèle de données d’indicateurs et de séries chronologiques standardisé, qui transforme les différents événements de mesure en séries numériques temporelles claires et interrogeables, que les équipes informatiques peuvent stocker et analyser dans des plateformes d’observabilité.

OpenTelemetry décrit les indicateurs à l’aide de trois modèles associés : le modèle d’événement (Event model, mesures brutes provenant des instruments), le modèle de flux OTLP (OTLP stream model, qui définit la manière dont ces mesures sont regroupées et transmises) et le modèle de séries chronologiques (time series model, qui définit la manière dont les plateformes back-end les stockent).

Dans la pratique, le code de l’application enregistre les événements à l’aide du modèle d’événement, le SDK ou le collecteur les transforme en flux OTLP, puis la plateforme back-end les stocke sous forme de séries chronologiques, comme l’évolution du « nombre de requêtes par seconde pour le service X avec le statut 200 ».

Les conventions sémantiques, également appelées conventions de nommage, définissent des noms, des unités et des clés d’attribut standardisés pour les indicateurs courants, afin que les différents services et bibliothèques produisent des données de télémétrie cohérentes. Par exemple, ces conventions prescrivent des noms tels que « http.server.duration » pour désigner la latence des requêtes d’un serveur HTTP et recommandent d’utiliser des unités telles que les secondes ou les millisecondes pour exprimer une durée.

L’utilisation des conventions sémantiques d’OTel permet aux équipes d’intégrer les indicateurs à des tableaux de bord et à des systèmes d’alerte préconfigurés qui reposent sur un schéma spécifique, ce qui réduit le temps consacré aux tâches de configuration personnalisée. Elle facilite également la collaboration entre les équipes, puisque tout le monde utilise le même « langage des indicateurs » dans l’ensemble des microservices.

En outre, les fonctionnalités de propagation de contexte peuvent relier les indicateurs aux traces associées (à l’aide d’exemplaires) ainsi qu’aux journaux, en transmettant un contexte commun, comme des identifiants de trace ou de segment, au-delà des limites des différents services.

Par exemple, un propagateur OTel peut extraire le contexte entrant depuis un gestionnaire de requêtes, démarrer un segment de trace à partir de celui-ci, puis utiliser ce même contexte pour enregistrer les indicateurs de latence et rédiger les entrées de journal. Ainsi, le point de mesure et la ligne de journal sont tous deux associés à la trace en cours.

Lorsque le code de l’application effectue un appel vers un service en aval, le propagateur injecte le même contexte dans la requête sortante. Le code du service destinataire l’extrait, démarre son propre segment enfant et utilise ce contexte pour ses propres indicateurs et journaux. Toutes les données issues des deux services restent ainsi associées à la même trace de bout en bout.

Les attributs, également appelés libellés, balises ou dimensions, sont des paires clé-valeur associées à des mesures individuelles ou à des points de données agrégés. Avec le nom de l’indicateur, le type d’agrégation et l’unité, ils définissent entièrement ou partiellement une série chronologique. Sans attributs, toutes les mesures associées à un indicateur seraient regroupées dans une seule série indifférenciée.

L’ajout d’attributs (tels que le nom du service, le point de terminaison, le code d’état HTTP, la région ou l’identifiant du locataire) transforme de simples indicateurs en flux d’indicateurs multidimensionnels et spécialisés, que les équipes peuvent analyser sous différents angles dans les outils d’observabilité. Les équipes peuvent ainsi obtenir des vues très détaillées, filtrées ou regroupées selon la dimension de leur choix.

Une bonne conception des attributs permet également de trouver un équilibre entre le niveau de détail et la cardinalité des indicateurs (le nombre de valeurs uniques qu’un attribut peut prendre). Les équipes peuvent ainsi éviter une explosion du nombre de libellés tout en continuant à effectuer des requêtes utiles.

Une mesure est une valeur individuelle, enregistrée au niveau d’un événement par un instrument à un instant précis et souvent accompagnée d’attributs. Par exemple, lorsqu’une requête HTTP se termine, il est possible d’enregistrer une latence de 120 millisecondes avec des attributs tels que route="/login" et status_code=200, qui représentent respectivement la route et le code d’état.

Chaque enregistrement individuel constitue une mesure distincte décrivant ce qui s’est produit au cours de cette opération précise.

Les mesures sont brièvement stockées dans le SDK, qui convertit ensuite les mesures brutes en points de données appartenant à des flux d’indicateurs plus vastes. Au lieu d’afficher chaque requête séparément, un point de données agrégé pourrait par exemple indiquer : « Pour la route /login avec le statut 200, entre 10:00:00 et 10:00:10, 500 requêtes ont été enregistrées, pour une durée totale de 25 secondes ». Ce sont ces points de données qui sont ensuite exportés vers les plateformes d’observabilité back-end et stockés dans celles-ci.

L’API d’indicateurs OpenTelemetry désigne l’ensemble des interfaces appelées par le code de l’application afin de produire des indicateurs. Elle est conçue pour être indépendante des fournisseurs et dissocie l’instrumentation de l’implémentation concrète du SDK. Les équipes informatiques peuvent ainsi écrire l’instrumentation une seule fois, à l’aide de l’API standard, puis remplacer les SDK, les exportateurs et les plateformes back-end sans avoir à effectuer d’étapes supplémentaires.

Trois interfaces fondamentales structurent l’API d’indicateurs OTel : les fournisseurs de compteurs (Meter Providers), les compteurs d’indicateurs (Meters) et les instruments de mesure.

Les fournisseurs de compteurs constituent le point d’entrée de l’API et sont chargés de créer les instances de compteurs. Ils déterminent les lecteurs d’indicateurs et les exportateurs à utiliser, les vues et agrégations à appliquer, ainsi que la fréquence de collecte et d’exportation des données. Le fournisseur de compteurs est généralement chargé une seule fois au démarrage de l’application (souvent en tant que fournisseur global). Tous les compteurs et instruments partagent ainsi des définitions de ressources et des pipelines d’exportation cohérents.

Les compteurs d’indicateurs sont les objets utilisés par le code de l’application pour créer des compteurs, des histogrammes et des jauges. Chaque compteur d’indicateurs porte généralement le nom d’une bibliothèque ou d’un service (par exemple bank.payment) afin que les indicateurs provenant de ce code puissent être regroupés et identifiés de manière cohérente.

Les compteurs d’indicateurs ne stockent pas directement les données. Ils servent plutôt de fabriques d’instruments et transmettent les mesures enregistrées au SDK sous-jacent à des fins d’agrégation et d’exportation. Puisqu’ils sont obtenus auprès d’un fournisseur de compteurs, ils fonctionnent toujours selon la configuration, les vues et les exportateurs définis par ce dernier.

Les instruments fournissent ensuite au code les interfaces nécessaires pour enregistrer des mesures accompagnées d’attributs.

Le SDK OpenTelemetry est une implémentation concrète de l’API OpenTelemetry qui transforme les appels d’API en véritables points de données de télémétrie. Il fournit une bibliothèque propre à un langage (tel que Java ou Python) qui collecte, agrège et prépare les données d’indicateurs en vue de leur exportation.

Les SDK gèrent le cycle de vie de l’instrumentation, le stockage en mémoire des mesures, l’exécution des fonctions de rappel associées aux instruments asynchrones, l’application des agrégations et des vues configurées, ainsi que les intervalles de collecte des indicateurs (généralement compris entre 10 et 60 secondes).

Au sein du SDK, les processeurs appliquent l’agrégation et d’autres traitements, notamment le filtrage, la limitation du débit ou la transformation des flux d’indicateurs avant leur transmission.

Les exportateurs convertissent les points de données d’indicateurs traités dans des formats propres aux plateformes back-end, puis les envoient à des systèmes externes ou à des plateformes d’observabilité au moyen de protocoles pris en charge (tels qu’OTLP).

Les équipes peuvent choisir d’enchaîner plusieurs exportateurs au sein du SDK afin de prendre en charge plusieurs plateformes back-end dans les environnements nécessitant une haute disponibilité et une redondance. Dans ce type de configuration, les collecteurs OpenTelemetry jouent le rôle de proxys intelligents capables d’envoyer simultanément des indicateurs à plusieurs plateformes back-end, de relancer les tentatives d’exportation ou d’authentifier les données à grande échelle. 

Les agrégations définissent la manière dont les différentes mesures brutes sont combinées mathématiquement afin de produire des statistiques récapitulatives que les plateformes back-end stockent et interrogent sous forme de points de données de séries chronologiques. L’agrégateur du SDK rassemble les données brutes en un seul point de données par intervalle de collecte pour chaque série chronologique unique.

Les modèles d’agrégation courants comprennent les suivants :

• La somme (Sum), qui additionne toutes les valeurs associées à des quantités cumulatives (comme le nombre d’octets transférés).

• La dernière valeur (LastValue), qui conserve uniquement la mesure la plus récente et ignore les précédentes.

• L’agrégation par histogramme, qui regroupe les valeurs dans des compartiments afin que les équipes puissent calculer des centiles et détecter les données aberrantes.

• L’abandon (Drop), qui supprime toutes les valeurs afin de protéger le système contre les données à forte cardinalité (les données présentant un grand nombre de valeurs uniques).

Les agrégations comprennent également des métadonnées de temporalité, qui indiquent aux plateformes back-end comment interpréter la valeur d’un indicateur au fil du temps. Les deux principaux types sont les suivants :

• Les valeurs cumulatives représentent le total enregistré depuis le démarrage du processus. Ces valeurs ne sont réinitialisées que lorsque le processus redémarre, et les plateformes back-end calculent les taux en déterminant la différence entre les points de données successifs.

• Les valeurs delta représentent les changements intervenus depuis la dernière collecte de données. Les plateformes back-end peuvent additionner directement ces deltas afin de déterminer les taux.

Les SDK appliquent automatiquement l’agrégation appropriée selon le type d’instrument. Ils permettent également aux équipes informatiques de remplacer de simples totaux par des histogrammes détaillés ou d’autres algorithmes, sans modifier l’instrumentation.

Les indicateurs mettent en évidence les tendances et déclenchent des alertes, les traces révèlent le parcours des requêtes et les journaux fournissent un contexte détaillé au niveau des événements. La corrélation des indicateurs avec les traces et les journaux relie les trois principaux signaux d’observabilité (souvent appelés les « piliers de l’observabilité »), afin que les équipes puissent obtenir une vue à plusieurs niveaux du comportement du système.

Les indicateurs peuvent, par exemple, révéler des tendances agrégées telles que « le taux d’erreur a fortement augmenté à 14 h 15 », mais ils ne permettent pas d’identifier les requêtes qui ont échoué ni la raison de leur échec. Les traces éclairent les parcours problématiques de requêtes individuelles entre différents services. Toutefois, sans indicateurs, elles ne permettent pas aux équipes de déterminer si une requête défaillante constitue une anomalie isolée ou un problème systémique. Les journaux fournissent des messages d’erreur et des événements détaillés, mais sans contexte, ils ne représentent qu’un volume de données difficilement exploitable.

La corrélation de ces trois signaux permet aux équipes informatiques de passer en quelques secondes des tendances générales révélées par les indicateurs à la trace concernée, puis aux journaux associés.

Les indicateurs OTel se distinguent fondamentalement des indicateurs traditionnels. Les indicateurs traditionnels désignent généralement des approches de surveillance historiques, axées sur des compteurs simples et prédéfinis mesurant l’utilisation des ressources. Ces indicateurs privilégient les mesures effectuées au niveau de l’hôte ou propres à une application. 

À l’inverse, les indicateurs OpenTelemetry font partie d’un cadre d’observabilité unifié et indépendant des fournisseurs, qui standardise la collecte des traces, des journaux et des indicateurs dans les environnements informatiques distribués. Ils prolongent les indicateurs traditionnels en proposant un modèle de données et une instrumentation plus flexibles, notamment des compteurs bidirectionnels (UpDownCounters) pour les variations à la hausse comme à la baisse, ainsi que des histogrammes prenant en charge les compartiments exponentiels. Ils fournissent également des attributs, des unités et des horodatages explicites afin d’enrichir les indicateurs.

Les indicateurs OTel se distinguent aussi des indicateurs traditionnels par leur conception, leurs méthodes de collecte et leur adéquation aux systèmes modernes.

Les indicateurs traditionnels reposent sur un modèle rigide couvrant l’ensemble de la pile, dans lequel la collecte, le stockage et l’interrogation sont étroitement liés. Ils utilisent souvent uniquement des valeurs cumulatives provenant de compteurs, de jauges, de synthèses et d’histogrammes simples comportant des compartiments explicites, qui doivent être définis manuellement.

Les indicateurs OpenTelemetry utilisent une architecture modulaire à trois couches (une API, un SDK et un protocole) qui dissocie la génération des signaux de leur traitement et de leur exportation. Cette configuration permet aux indicateurs OTel de prendre en charge des fonctionnalités avancées, telles que la temporalité delta, les valeurs entières, les métadonnées de valeurs minimales et maximales dans les histogrammes, ainsi que les histogrammes exponentiels permettant une mise à l’échelle dynamique.

Les approches traditionnelles reposent sur l’extraction de données à partir de points de terminaison d’API exposés, selon un modèle de collecte par interrogation, principalement destiné aux indicateurs pris isolément. Elles utilisent une instrumentation manuelle et offrent une prise en charge limitée des traces et des journaux, ce qui entraîne une fragmentation de la télémétrie et des pipelines d’observabilité.

OpenTelemetry utilise OTLP (un protocole binaire) pour assurer une collecte des données par envoi. Il permet de collecter de manière unifiée les traces, les indicateurs et les journaux au moyen d’une instrumentation automatique ou manuelle. OTel fournit également un collecteur qui facilite la transformation, le regroupement par lots et l’acheminement des données vers les outils back-end, aidant ainsi les équipes informatiques à résoudre les problématiques liées au stockage des applications.

Les données de télémétrie traditionnelles conviennent bien aux architectures monolithiques simples. Elles montrent toutefois leurs limites dans les environnements de microservices, en raison de capacités de traçage insuffisantes, des risques d’enfermement propriétaire et de signaux cloisonnés qui masquent les dépendances et ne permettent pas de détecter les défaillances en cascade.

OpenTelemetry excelle dans les environnements distribués et cloud natifs, car il fournit une télémétrie corrélée et indépendante des fournisseurs, offrant une visibilité de bout en bout sur le parcours des requêtes entre les services, les goulets d’étranglement liés à la latence et les diagnostics de ressources. OTel prend également en charge l’échantillonnage et l’intégration d’outils hybrides, ce qui permet à la télémétrie et à l’instrumentation d’évoluer en même temps que l’environnement informatique. 

Les indicateurs OpenTelemetry fournissent des mesures quantitatives standardisées qui contribuent à améliorer l’observabilité des architectures modernes. Ils offrent des informations détaillées sur les performances des systèmes, permettant aux développeurs et aux ingénieurs de mettre en œuvre des stratégies proactives de résolution des problèmes et d’optimisation.

Autres avantages :