OpenTelemetry est le résultat d’une fusion entre deux projets antérieurs, OpenTracing et OpenCensus. Ces deux projets ont été créés pour résoudre le même problème : l’absence de norme pour coder les instruments et envoyer les données de télémétrie à un back-end d’observabilité. Cependant, aucun des deux projets n’a permis, seul, de résoudre le problème. Les deux projets ont donc fusionné pour former OpenTelemetry, afin de combiner leurs points forts et de fournir une norme véritablement unique.

Surtout, OpenTelemetry est indépendant des fournisseurs et des outils, ce qui signifie qu’il peut être utilisé avec une grande variété de back-ends d’observabilité, y compris des outils open source tels que Jaeger et Prometheus, ainsi que des produits commerciaux. OTel est un projet Cloud Native Computing Foundation (CNCF) conçu pour fonctionner comme une solution robuste, portable et facile à utiliser avec de nombreux langages. Pour ce faire, OTel fournit un ensemble unique d’API, de bibliothèques, d’agents et de services de collecte pour capturer les traces et les mesures distribuées à partir de votre application. OpenTelemetry fournit une véritable observabilité.

L’observabilité est un terme qui a fait l’objet d’une attention considérable dans le monde de l’ingénierie logicielle et de l’administration système, au point de perdre une partie de sa signification. Aujourd’hui, de nombreuses personnes, y compris dans l’IT, utilisent ce terme de manière vague pour indiquer tout type de visibilité du système. Mais qu’est-ce que l’observabilité exactement et en quoi diffère-t-elle de la surveillance traditionnelle ?

L’observabilité diffère de la surveillance

La surveillance consiste à regarder et vérifier activement l’état du système, généralement à l’aide de seuils et d’alertes prédéfinis. Bien que cette approche puisse attirer votre attention sur les systèmes affectés en cas de problème, la surveillance ne vous fournit généralement pas d’informations sur la raison du problème ou sur la meilleure façon de le résoudre.

L’observabilité est une approche plus complète. Elle vise à comprendre ce qui se passe au sein d’un système en analysant ses sorties externes. L’observabilité vous permet de poser n’importe quelle question sur ce qui s’est passé, à tout moment, sans avoir défini ce que vous vouliez savoir à l’avance. En résumé, la surveillance peut vous indiquer quand un problème existe, alors que l’observabilité vous aide à comprendre pourquoi ce problème s’est produit.

Traces, mesures et journaux

Il existe trois piliers essentiels à l’observabilité :

• Traces
  Une trace représente le parcours d’une demande dans un système et peut fournir une image détaillée des interactions entre les services. Les traces OpenTelemetry sont organisées en spans qui contiennent des attributs et des événements, décrivant et contextualisant le travail effectué via divers processus et services.
• Mesures
  Les mesures sont des représentations chiffrées de données, capturées dans un intervalle de temps. Elles permettent de surveiller en continu les performances et le comportement du système. Dans OpenTelemetry, l’API Metrics peut être utilisée pour enregistrer, définir et ajouter des mesures système, offrant ainsi ultérieurement des outils de filtrage et d’analyse globale.
• Journaux
  Les journaux sont des enregistrements textuels générés par les systèmes et les applications. Ils fournissent un compte rendu chronologique des événements et jouent parfois un rôle essentiel pour déboguer le système et comprendre son comportement.

Bien que ces trois éléments aient longtemps été considérés comme les facteurs les plus essentiels de l’observabilité, l’échelle et la complexité croissantes des systèmes distribués modernes ont fait évoluer ce modèle traditionnel. Les professionnels ont compris que ces trois piliers ne sont pas isolés, mais fondamentalement interconnectés, et doivent être utilisés en coordination les uns avec les autres.

OpenTelemetry joue un rôle crucial dans l’observabilité des systèmes distribués basés sur des microservices. L’accent mis sur la portabilité, la disponibilité des implémentations et les kits de développement logiciel (SDK) pour la plupart des langages, et en particulier sur ses modèles d’exportation et de collecte, en fait un outil clé pour collecter et distribuer des données appropriées au système.

Avec OpenTelemetry, les équipes peuvent collecter efficacement les traces et les données de mesures clés, nécessaires pour analyser le comportement du système. Cet alignement sur les pratiques d’observabilité permet une compréhension plus approfondie des performances du système, améliorant ainsi la capacité à diagnostiquer et à résoudre les problèmes.

Qu’est-ce que le traçage dans OpenTelemetry ?

Tout comme les traces sont l’un des trois piliers de l’observabilité, le traçage est une pratique cruciale dans le développement logiciel, généralement utilisée pour établir le profil et analyser le code d’application à l’aide d’outils de débogage spécialisés. Dans le contexte d’OpenTelemetry, le traçage prend une signification plus nuancée, et fait le plus souvent référence au traçage distribué, un concept essentiel dans les architectures complexes d’aujourd’hui.

Traçage distribué

Le traçage distribué désigne l’application des techniques de traçage traditionnelles aux applications modernes basées sur les microservices. Alors qu’avec les applications monolithiques, le diagnostic d’une défaillance peut impliquer le traçage d’une seule trace de pile, les systèmes distribués sont trop complexes pour ce type d’approche. Lorsqu’une application se compose potentiellement de milliers de services exécutés sur de nombreux hôtes, les traces individuelles sont insuffisantes. Le traçage distribué résout ce problème en créant des profils de demandes à mesure qu’elles franchissent différentes limites de service, générant ainsi des données de haute qualité à analyser. Cette méthode offre différents avantages, tels que :

• La détection des anomalies 
• La modélisation des charges de travail 
• Un diagnostic permanent des problèmes

Des traces et des spans

Dans OpenTelemetry, une trace est un ensemble de spans liés, constitués d’opérations nommées et chronométrées représentant une unité de travail dans une demande. Un span peut avoir un parent ou un span racine, qui décrit la latence de bout en bout de l’ensemble de la trace. Les spans enfants représentent des sous-opérations au sein de la trace.

• Span racine
  Span parent ou point de départ de la trace, le span racine représente la latence de l’intégralité de la demande. 
• Span enfant
  Ce sont les sous-opérations spécifiques de la trace.

Les spans regroupent les informations essentielles, notamment le nom de l’opération, l’horodatage de l’entrée et de la sortie et les événements et les attributs survenus au cours du span. Elles contiennent également des liens vers d’autres spans et le statut de l’opération.

Attributs et événements

Compte tenu de la complexité des données des traces des systèmes distribués, l’accès au contexte et à d’autres détails pertinents peut être déterminant dans l’analyse des données. Dans OpenTelemetry, ces balises sont les attributs et événements :

• Attributs
  Ces paires clé-valeur (appelées « balises » dans OpenTracing) peuvent être ajoutées à un span pour faciliter l’analyse des données de trace.
• Événements
  Ce sont des chaînes horodatées avec un ensemble facultatif d’attributs, qui fournissent une description plus détaillée, pour une analyse plus approfondie.

Traceurs et propagateurs

Dans OpenTelemetry, les spans sont créés par un objet appelé « traceur ». Ce dernier suit le span actif et autorise la mise en place de nouveaux spans. Il existe des objets nommés « propagateurs ». Leur rôle est d’assurer le transfert du contexte d’un processus à l’autre, ce qui est vital pour le traçage dans les systèmes distribués. Le traceur envoie les spans terminés à l’exportateur du SDK d’OTel, qui envoie les spans à un système back-end pour une analyse détaillée.

Bien que le traçage fournisse des informations détaillées sur les demandes et les opérations individuelles, il s’intègre également avec le contexte plus large de l’observabilité au sein d’OpenTelemetry, y compris avec les mesures. En connectant les données de trace aux mesures pertinentes, les entreprises peuvent comprendre le comportement et les performances de leur système.

Dans le contexte d’OpenTelemetry, l’API Metrics est conçue pour traiter et récapituler en continu les mesures brutes. Les entreprises bénéficient ainsi d’une meilleure visibilité sur les mesures opérationnelles essentielles, notamment sur l’utilisation de la mémoire par les processus, les taux d’erreur et bien plus. Les mesures peuvent être envoyées à divers instruments pour agrégation et enregistrement. L’API OpenTelemetry Metrics classe les instruments de mesure en fonction de leur signification sémantique au lieu d’utiliser le type final de valeur qu’ils exportent.

Instruments de mesure dans OpenTelemetry

L’API Metrics fournit six instruments de mesure distincts, chacun remplissant une fonction spécifique. Ces instruments sont créés et définis par l’intermédiaire d’appels à une API Meter, le point d’entrée de l’utilisateur dans le SDK. Les instruments de mesure sont synchrones ou asynchrones.

Les instruments synchrones

Les instruments synchrones sont appelés via une demande et sont associés à un contexte distribué. Les instruments synchrones comprennent :

• Counter
  L’instrument Counter accepte les valeurs positives avec la fonction Add(). Il est idéal pour compter les données telles que les octets reçus et les demandes traitées, et pour mesurer l’incidence des erreurs. Il est particulièrement adapté aux mesures de volume et de débit.
• UpDownCounter
  Extension de la fonctionnalité Counter, UpDownCounter traite les incréments positifs et négatifs via la fonction Add(). Cela est utile pour surveiller des quantités telles que le nombre de demandes actives, la quantité de mémoire utilisée et la taille de la file d’attente.
• ValueRecorder
  L’instrument ValueRecorder capture les valeurs d’événements distincts à l’aide de la fonction Record(). Il est utilisé pour capturer la latence, la taille de la demande et la longueur de la file d’attente, en mettant l’accent sur la distribution des valeurs.

Les instruments asynchrones

Contrairement aux instruments synchrones, les instruments asynchrones n’ont pas de contexte associé. Ces instruments sont signalés par un rappel et appelés une seule fois par intervalle de collecte. Les instruments synchrones comprennent :

• SumObserver
  L’instrument SumObserver utilise la fonction Observe() pour les sommes monotones asynchrones. Il est plus adapté aux données sur les échecs de cache et le processeur système. 
• UpDownSumObserver
  UpDownSumObserver est un compteur asynchrone et non monotone qui accepte des sommes positives et négatives avec la fonction Observe(). Cet instrument est utilisé pour les mesures qui capturent l’augmentation et la baisse des sommes, telles que la taille du segment de mémoire des processus.
• ValueObserver
  Enfin, ValueObserver offre aux entreprises un contrôle précis sur les mesures non additives à l’aide de la fonction Observe(). Cela est idéal lorsque les mesures concernent une distribution.

La composition des événements de mesure

Les événements de mesure capturés, quel que soit l’instrument utilisé, se composent d’un horodatage, d’une définition de l’instrument (nom, type, description, unité de mesure), d’un ensemble d’étiquettes (clés et valeurs), d’une valeur (nombre entier ou nombre à virgule flottante), des ressources associées au SDK et du contexte distribué (pour les événements synchrones uniquement). La diversité des instruments de mesure disponibles offre suffisamment de flexibilité pour capturer différents types de données, ce qui facilite l’analyse et la surveillance des divers attributs du système.

Qu’il s’agisse de surveiller les taux d’erreur, la latence ou l’utilisation des ressources, les instruments de mesure d’OpenTelemetry offrent aux développeurs diverses options pour obtenir des insights essentiels sur leurs applications.

L’exportateur crée des lots et transporte les données de télémétrie vers un système back-end pour l’analyse et la création d’alertes. Le modèle d’exportation d’OpenTelemetry prend en charge l’intégration de l’instrumentation à trois niveaux différents :

• Intégration au niveau du service
  Cela implique de déclarer une dépendance sur le package OpenTelemetry approprié dans votre code, et de le déployer en conséquence.
• Dépendances de la bibliothèque
  Elles fonctionnent de la même façon que l’intégration au niveau du service, mais concernent spécifiquement les bibliothèques, qui déclarent généralement une dépendance à l’API OpenTelemetry uniquement.
• Dépendances de la plateforme
  Il s’agit de composants logiciels indépendants qui prennent en charge votre service, comme Envoy et Istio. Ils déploient leur copie d’OpenTelemetry et émettent un contexte de trace utile pour votre service.

L’interface de l’exportateur, implémentée par les SDK OpenTelemetry, utilise un modèle de plug-in qui traduit les données de télémétrie au format requis pour un système back-end particulier, avant de transmettre les données. Ce modèle prend également en charge la composition et le chaînage des exportateurs, ce qui facilite le partage des fonctionnalités entre différents protocoles.

L’approche d’OpenTelemetry présente un avantage important : la facilité de changement ou d’ajout de composants d’exportation. Cela le distingue de l’OpenTracing, où la modification du système nécessite de remplacer l’ensemble du composant du traceur.

Bien que le modèle de l’exportateur soit très pratique, certaines contraintes organisationnelles ou techniques peuvent compliquer le redéploiement d’un service pour ajouter un nouvel exportateur. Le collecteur OpenTelemetry est conçu pour servir de « puits » pour les données de télémétrie provenant de plusieurs processus. Il les exporte vers divers systèmes back-end tels que ServiceNow Cloud Observability, Jaeger ou Prometheus. Le collecteur peut être déployé en tant qu’agent en parallèle d’un service ou en tant qu’application distante :

• Agent
  Il est déployé avec votre service, et s’exécute comme un processus ou un side-car distinct. 
• Collecteur distant
  Il est déployé séparément dans un conteneur ou une machine virtuelle, il reçoit des données de télémétrie de chaque agent et les exporte vers des systèmes back-end.

OpenTelemetry comprend les principaux composants suivants :

• Une spécification pour tous les composants
• Un protocole standard qui définit la forme des données de télémétrie
• Des conventions sémantiques qui définissent un schéma de dénomination standard pour les types de données de télémétrie courants
• Des API qui définissent comment générer les données de télémétrie
• Un écosystème de bibliothèques qui implémente l’instrumentation pour les bibliothèques et les cadres de travail courants.
• Des composants d’instrumentation automatiques qui génèrent des données de télémétrie sans nécessiter de changement de code
• Des SDK de langage qui implémentent la spécification, les API et l’exportation des données de télémétrie
• Le collecteur OpenTelemetry, un proxy qui reçoit, traite et exporte les données de télémétrie
• D’autres outils, tels que l’opérateur OpenTelemetry pour Kubernetes

Compatibilité

Compatible avec une grande variété d’intégrations d’écosystèmes open source, OpenTelemetry est également pris en charge par un grand nombre de fournisseurs, dont beaucoup proposent une assistance commerciale pour OpenTelemetry et contribuent directement au projet.

Extensibilité

OpenTelemetry est conçu pour être extensible. Voici quelques exemples de la façon dont il peut être étendu :

• Ajout d’un récepteur au collecteur OpenTelemetry pour prendre en charge les données de télémétrie à partir d’une source personnalisée
• Chargement d’une instrumentation personnalisée dans un SDK
• Création d’une distribution d’un SDK ou du collecteur, adaptée à un cas d’utilisation spécifique
• Création d’un nouvel exportateur pour un back-end personnalisé qui ne prend pas encore en charge le protocole OpenTelemetry (OTLP)
• Création d’un propagateur personnalisé pour un format de propagation de contexte non standard

Bien que la plupart des utilisateurs n’aient pas besoin d’étendre OpenTelemetry, le projet est conçu pour que ce soit possible à presque tous les niveaux.

Pourquoi OpenTelemetry est-il important ?

Avec l’essor du cloud computing, les architectures de microservices et les exigences métier de plus en plus complexes, le besoin d’observabilité n’a jamais été aussi important.

Pour rendre un système observable, il doit être instrumenté. En d’autres termes, le code doit émettre des traces, des mesures et des journaux. Les données instrumentées doivent ensuite être envoyées à un back-end d’observabilité.

OpenTelemetry permet deux choses importantes :

• Il vous permet de posséder les données que vous générez plutôt que d’être bloqué par un format ou un outil de données propriétaire.
• Il vous permet d’apprendre un ensemble unique d’API et de conventions

Ces deux éléments combinés offrent aux équipes et aux entreprises la flexibilité dont elles ont besoin pour travailler dans l’univers informatique moderne d’aujourd’hui.

OpenTelemetry n’est pas un back-end d’observabilité comme Jaeger, Prometheus ou ceux d’autres fournisseurs commerciaux. OpenTelemetry se concentre sur la génération, la collecte, la gestion et l’exportation des données de télémétrie. Le stockage et la visualisation de ces données sont intentionnellement laissés à d’autres outils.

La visibilité de bout en bout est plus essentielle que jamais. OpenTelemetry propose une méthode uniforme pour collecter des données de télémétrie dans diverses applications et divers langages de programmation. En offrant des informations complètes sur le comportement du système, OTel permet aux entreprises d’optimiser les performances, de résoudre les problèmes et de garantir une expérience utilisateur fluide. Toutefois, en ce qui concerne l’observabilité, il est toujours possible de faire mieux.

ServiceNow Cloud Observability, anciennement connu sous le nom de Lightstep, prend en charge OpenTelemetry pour obtenir des données de télémétrie (traces, journaux et mesures) lorsque les demandes transitent par les services et d’autres infrastructures. Cloud Observability ingère les données OpenTelemetry via le protocole natif OpenTelemetry Protocol (OTLP). Les données OTLP peuvent ensuite être exportées vers Cloud Observability via HTTP ou gRPC.

Pour améliorer davantage l’observabilité et la gouvernance dans les environnements cloud natifs, ServiceNow a également lancé le Connecteur du graphe de service pour OpenTelemetry (SGC). Grâce aux données OpenTelemetry et au back-end ServiceNow Cloud Observability, cette solution transforme la visibilité et les méthodes d’obtention des insights sur les applications cloud natives et les infrastructures Kubernetes des entreprises. SGC découvre et mappe automatiquement les dépendances de service, créant ainsi une topologie de service précise et à jour. En permettant aux entreprises d’évaluer l’impact des changements, de rationaliser la gestion des incidents et de favoriser la collaboration transverse, cette solution améliore l’efficacité, réduit les risques et fournit la meilleure observabilité possible dans les environnements IT complexes.

Découvrez les capacités transformatrices du Connecteur du graphe de service pour OpenTelemetry. Contactez ServiceNow dès aujourd’hui !