OpenTelemetry (OTel) est un cadre d’observabilité et une boîte à outils qui est un langage partagé, un modèle de données et une unification des comportements de propagation sous-jacents. OTel est également conçu pour gérer les données de télémétrie telles que les traces, les mesures et les journaux, et est une source ouverte, ce qui permet une plus grande flexibilité.
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 d’une norme sur la façon d’utiliser le code et d’envoyer les données de télémétrie à un arrière-plan d’observation. Cependant, aucun des projets n’a été en mesure de résoudre le problème par lui-même, et les deux projets ont donc fusionné pour former OpenTelemetry afin qu’ils puissent combiner leurs forces et offrir réellement une norme unique.
Fondamentalement, OpenTelemetry est indépendant des fournisseurs et des outils, ce qui signifie qu’il peut être utilisé avec une grande variété d’observation dorsale, notamment des outils libres comme Jaeger et Prometheus, ainsi que des offres commerciales. OTel est un projet de Cloud Native Computing Foundation (CNCF), conçu pour fonctionner comme une solution robuste, portative et facile à utiliser dans de nombreuses langues. Il fournit un ensemble unique d’API, de bibliothèques, d’agents et de services de collecte pour capturer les traces et les mesures distribués de votre application. Une véritable observabilité est possible grâce à OpenTelemetry.
« L’observabilité » est un terme qui a attiré une attention importante dans le monde de l’ingénierie logicielle et de l’administration des systèmes, presque au point de perdre une partie de sa signification. Aujourd’hui, même beaucoup de ceux qui travaillent dans les TI utilisent le terme de manière lâche pour indiquer tout type de visibilité du système. Mais qu’est-ce que l’observabilité et en quoi est-elle différente de la surveillance traditionnelle?
La surveillance est le processus de surveillance et de vérification actives de l’état du système, généralement à l’aide de seuils et d’alertes prédéfinis. Même si cette approche peut attirer votre attention sur les systèmes concernés lorsqu’un problème survient, la surveillance ne vous fournit pas souvent des informations sur les raisons pour lesquelles le problème se produit ou sur la meilleure façon de le résoudre.
L’observabilité, en revanche, est une approche plus globale. Il s’agit de la capacité de comprendre ce qui se passe dans un système en analysant ses résultats externes. L’observabilité vous permet de poser n’importe quelle question sur ce qui s’est passé à tout moment, sans que vous ayez prédéfini ce que vous vouliez savoir à l’avance. Essentiellement, la surveillance peut vous indiquer lorsqu’un problème existe, mais l’observabilité vous aide à comprendre pourquoi ce problème est survenu.
Il existe trois piliers qui sont essentiels à l’observabilité :
- Traces
Une trace représente le parcours d’une demande à travers un système et peut fournir une image détaillée des interactions de service. Les traces d’OpenTelemetry sont organisés en étendues qui contiennent des attributs et des événements, décrivant et mettant en contexte le travail effectué sur divers processus et services. - Mesures
Les mesures sont des représentations numériques des données mesurées à des intervalles de temps. Ils permettent de surveiller en continu la performance et le comportement du système. Dans OpenTelemetry, la Metrics API peut être utilisée pour enregistrer, définir et ajouter des mesures de système, offrant, plus tard, des outils de filtrage et d’analyse globale. - Journalisation
Les journaux sont des enregistrements basés sur du texte générés par les systèmes et les applications. Ils fournissent un compte chronologique des événements et peuvent être essentiels au débogage et à la compréhension du comportement du système.
Même si ces trois éléments sont depuis longtemps 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 forcé ce modèle traditionnel à évoluer. Les praticiens ont commencé à reconnaître que les 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 en permettant l’observabilité dans les systèmes distribués basés sur des microservices. Son accent sur la portabilité, la disponibilité des mises en œuvre et des trousses de développement logiciel (SDK) dans la plupart des langues, et en particulier sur les modèles d’exportation et de collecte, en fait un outil clé pour recueillir et distribuer les données appropriées au système.
Avec OpenTelemetry, les équipes peuvent recueillir efficacement les données clés de trace et de mesure nécessaires pour analyser le comportement du système. Cette harmonisation avec les pratiques d’observation permet une compréhension plus approfondie des performances du système qui améliore la capacité de diagnostiquer et de résoudre les problèmes.
Tout comme les traces sont l’un des trois piliers de l’observabilité, le traçage est une pratique cruciale dans le développement de logiciels, généralement utilisée pour établir le profil et analyser le code d’application au moyen d’outils de débogage spécialisés. Dans le contexte de l’OpenTelemetry, le traçage prend une signification plus nuancée, en se référant le plus souvent au traçage distribué, un concept essentiel dans les architectures complexes d’aujourd’hui.
Le traçage distribué représente l’application des techniques de traçage traditionnelles aux applications modernes basées sur les microservices. Contrairement aux applications monolithiques dans lesquelles le diagnostic d’une défaillance peut impliquer le suivi d’une trace unique, les systèmes distribués sont simplement trop complexes pour cette approche, lorsqu’une application est constituée de milliers de services fonctionnant sur de nombreux hôtes, les traces individuelles deviennent insuffisantes. Le traçage distribué résout ce problème en établissant le profil des demandes au fur et à mesure qu’elles traversent différentes limites de service, générant des données de haute qualité pour analyse. Cette méthode offre des capacités telles que :
- Détection des anomalies
- Modélisation de la charge de travail
- Diagnostic des problèmes à l’état d’équilibre
Dans OpenTelemetry, une trace est un ensemble d’étendues liées, qui sont des opérations nommées et chronométrées représentant une unité de travail dans une demande. Une étendue peut avoir un parent, ou elle peut être une étendue de racine, qui décrit la latence de bout en bout de l’ensemble de la trace. L’étendue enfant représente les sous-opérations au sein de la trace.
- Étendue de la racine
Le point parent ou de départ de la trace, représentant la latence totale de la demande. - Étendue de l’enfant
Sous-opérations spécifiques au sein de la trace.
Les étendues recouvre les informations essentielles, notamment le nom de l’opération, les horodatages de début et de fin, les événements et les attributs qui se sont produits pendant l’étendue. Elles contiennent également des liens vers d’autres étendues et l’état de l’opération.
Étant donné la complexité des données de trace des systèmes distribués, l’accès au contexte et à d’autres détails pertinents peut faire une grande différence positive dans l’analyse des données. Dans OpenTelemetry, ces balises sont connues sous le nom d'attributs et d'événements :
- Attributs
Des paires de valeur clé (connues sous le nom de « balises » dans OpenTracing) qui peuvent être ajoutées à un champ d’application pour aider à analyser les données de trace. - Événements
Des chaînes horodatées avec un ensemble facultatif d’attributs fournissant une description plus approfondie, permettant une analyse plus détaillée.
Les étendues de l’OpenTelemetry sont générées par le traceur, un objet qui suit l’étendue active actuelle et permet la création de nouvelles plages. Les objets propagateurs prennent en charge le transfert du contexte entre les limites des processus, un aspect vital du traçage dans les systèmes distribués. Le traceur envoie les données complètes à l’exportateur du SDK d’OTel, responsable de l’envoi des données complètes à un système d’arrière-plan pour une analyse plus approfondie.
Alors que le suivi fournit des informations détaillées sur les demandes et les opérations individuelles, il est également lié au contexte plus large de l’observabilité au sein d’OpenTelemetry, notamment les mesures. En connectant des données de trace à des mesures pertinentes, les organisations peuvent acquérir une compréhension approfondie du comportement et de la performance de leur système.
Dans le contexte de l’OpenTelemetry, la Metrics API est conçue pour traiter et résumer en continu les mesures brutes. Cela donne aux organisations une meilleure visibilité des mesures opérationnelles vitales, notamment l’utilisation de la mémoire des processus, les taux d’erreur, etc. Les mesures peuvent être envoyées à divers instruments pour l’agrégation et l’enregistrement. La Metrics API de l’OpenTelemetry classifient les instruments de mesure en fonction de leur signification sémantique plutôt que du type final de valeur qu’elles exportent.
La Metrics API fournit six instruments de mesure distincts, chacun ayant une fonction spécifique. Ces instruments sont créés et définis au moyen d’appels à une API de compteur (Meter API), le point d’entrée de l’utilisateur vers le SDK. Les instruments de mesure sont synchrones ou asynchrones.
Les instruments synchrones sont invoqués dans une demande et possèdent un contexte distribué associé. Les instruments synchrones comprennent :
- Compteur
Le compteur accepte les valeurs positives grâce à la fonction Add(). Il est idéal pour compter les données telles que les octets reçus, les demandes terminées et la mesure de l’incidence des erreurs, et il est particulièrement adapté pour la mesure des débits. - UpDownCounter
Extension de la fonctionnalité de compteur, UpDownCounter traite les incréments positifs et négatifs grâce à la fonction Add(). Cela est utile pour surveiller les quantités comme les demandes actives, la mémoire en cours d’utilisation et la taille de la file d’attente. - ValueRecorder
L’instrument ValueRecorder capture des valeurs pour les événements discrets à l’aide de la fonction Record(). Cette donnée est utilisée pour saisir la latence, la taille de la demande et la longueur de la file d’attente, en mettant l’accent sur la distribution des valeurs
Contrairement aux instruments synchrones, les instruments asynchrones n’ont pas de contexte associé. Ces instruments sont signalés par un callback (rappel) et ne sont appelés qu’une seule fois par intervalle de collecte. Les instruments synchrones comprennent :
- SumObserver
L’instrument SumObserver utilise la fonction Observe() pour les sommes monotoniques asynchrones et convient le mieux aux données telles que les échecs de cache et l’UC du système. - UpDownSumObserver
UpDownSumObserver est un compteur asynchrone et non monotonique qui accepte les sommes positives et négatives grâce à la fonction Observe(). Cet instrument est utilisé pour les mesures qui captent la hausse et la baisse des sommes, telles que la taille du tas du processus. - ValueObserver
Enfin, ValueObserver donne aux organisations un contrôle précis sur les mesures non additives à l’aide de la fonction Observe(). Ceci est idéal lorsque les mesures se concentrent sur une distribution.
Les événements de mesure captés par n’importe quel instrument comprennent un horodatage, la définition de l’instrument (nom, type, description, unité de mesure), l’ensemble d’étiquettes (clés et valeurs), la valeur (entier ou nombre à virgule flottante), les ressources associées au SDK et le contexte distribué (pour les événements synchrones seulement). La variété des instruments de mesure disponibles offre de la flexibilité pour saisir différents types de données, ce qui facilite l’analyse et le suivi de 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 diverses options aux développeurs pour obtenir des informations critiques sur leurs applications.
L’exportateur est responsable de la mise en lots et du transport des données de télémétrie vers un système dorsal d’analyse et d’alerte. Le modèle d’exportateur d’OpenTelemetry soutient l’intégration de l’instrumentation à trois niveaux différents :
- Intégration au niveau du service
Pour cela, il faut déclarer une dépendance sur le paquet OpenTelemetry pertinent de votre code et de le déployer en conséquence. - Bibliothèques-dépendances
Semblable à l’intégration au niveau des services, mais spécifique aux bibliothèques, qui ne déclarent généralement qu’une dépendance à l’API d’OpenTelemetry. - Dépendances de la plateforme
Ce sont des composants logiciels indépendants qui soutiennent votre service, comme Envoy et Istio. Elles déploient leur copie d’OpenTelemetry et émettent un contexte de trace utile pour votre service.
L’interface de l’exportateur, mise en œuvre par les SDK d’OpenTelemetry, utilise un modèle de plugiciel qui traduit les données de télémétrie au format requis pour un système principal particulier avant de transmettre les données. Ce modèle soutient également la composition et le chaînage des exportateurs, facilitant ainsi la partage des fonctionnalités entre différents protocoles.
Un avantage important de l’approche d’OpenTelemetry est la facilité de commutation ou d’ajout de composants d’exportation. Cela le distingue de l’OpenTracing, où le changement du système nécessite le remplacement de l’ensemble du composant de traceur.
Même si le modèle d’exportateur est très pratique, certaines contraintes organisationnelles ou techniques peuvent empêcher la facilité de redéploiement d’un service pour ajouter un nouvel exportateur. Le collecteur d’OpenTelemetry est conçu pour agir comme un « guichet » pour les données de télémétrie à partir de plusieurs processus, les exporter vers divers systèmes dorsaux tels que l’Observabilité infonuagique de ServiceNow, Jaeger ou Prometheus. Le collecteur peut être déployé en tant qu’agent parallèlement à un service ou en tant qu’application à distance :
- Agent
Déployé avec votre service, fonctionnant comme un processus distinct ou un périphérique. - Collecteur à distance
Déployé séparément dans un conteneur ou une machine virtuelle, recevant les données de télémétrie de chaque agent et les exporter vers des systèmes dorsaux.
OpenTelemetry comprend les principaux composants suivants :
- une spécification pour tous les composants
- un protocole standard qui définit la forme des données télémétriques
- des conventions sémantiques qui définissent un système de dénomination standard pour les types de données télémétriques communs
- des API qui définissent la façon de générer des données télémétriques
- un écosystème de bibliothèque qui met en œuvre l’instrumentation pour les bibliothèques et infrastructures communes
- Les composants d’instrumentation automatiques qui génèrent des données de télémétrie sans nécessiter de changement de code
- Les langues SDK qui mettent en œuvre 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
- Divers autres outils, tels que OpenTelemetry Operator for Kubernetes
Compatible avec une grande variété d’intégrations d’écosystèmes open source, OpenTelemetry est également soutenu par un grand nombre de fournisseurs, dont plusieurs fournissent un soutien commercial pour OpenTelemetry et contribuent directement au projet.
OpenTelemetry est conçu pour être extensible. Voici quelques exemples de la façon dont elle peut être étendue :
- 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
- charger des instruments personnalisés 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 arrière-plan 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
Même si la plupart des utilisateurs n’ont pas besoin d’étendre OpenTelemetry, le projet est conçu pour le rendre possible à presque tous les niveaux.
Avec l’essor de l’informatique en nuage, des architectures de microservices et des exigences commerciales de plus en plus complexes, le besoin d’observer n’a jamais été plus grand.
Afin de rendre un système observable, il doit être instrumenté. C’est-à-dire que le code doit émettre des traces, des mesures et des journaux. Les données instrumentées doivent ensuite être envoyées à une l’observabilité dorsale.
OpenTelemetry fait 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 exclusif.
- Il vous permet d’apprendre un ensemble unique d’API et de conventions
Ces deux éléments combinés permettent aux équipes et aux organisations de bénéficier de la flexibilité dont elles ont besoin dans le monde informatique moderne d’aujourd’hui.
OpenTelemetry n’est pas un retour de l’observabilité comme Jaeger, Prometheus ou des 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 volontairement laissés à d’autres outils.
La nécessité d’une visibilité de bout en bout est plus cruciale que jamais. OpenTelemetry offre une approche normalisée de la collecte de données de télémétrie dans diverses applications et langues de programmation. En offrant des informations détaillées sur le comportement des systèmes, OTel permet aux organisations d’optimiser les performances, de résoudre les problèmes et d’offrir une expérience utilisateur transparente. Mais en ce qui concerne l’observabilité, il y a toujours place à l’amélioration.
L'observabilité infonuagique de ServiceNow, anciennement connue sous le nom de Lightstep, prend en charge OpenTelemetry comme la façon d’obtenir des données de télémétrie (traces, journaux et mesures) lorsque les demandes circulent dans les services et d’autres infrastructures. L’observabilité infonuagique intègre les données d’OpenTelemetry via le Protocole OpenTelemetry natif (OTLP). Les données OTLP peuvent ensuite être exportées vers l’observabilité infonuagique soit par HTTP ou gRPC.
Pour améliorer encore plus l’observabilité et la gouvernance dans les environnements natifs en nuage, ServiceNow a également lancé Connecteurs du graphe de services pour OpenTelemetry (SGC). Tirant parti des données d’OpenTelemetry et de l’arrière-plan de l’observabilité infonuagique de ServiceNow, cette solution révolutionne la façon dont les entreprises obtiennent de la visibilité et des informations sur leurs applications natives en nuage et leur infrastructure Kubernetes. SGC découvre et cartographie automatiquement les dépendances des services, créant une topologie de services précise et à jour. En permettant aux organisations d’évaluer l’impact des changements, de rationaliser la gestion des incidents et de favoriser la collaboration interfonctionnelle, cette solution améliore l’efficacité, réduit les risques et contribue à garantir la meilleure observabilité possible dans les environnements informatiques complexes.
Découvrez les capacités de transformation de Connecteurs du graphe de services pour OpenTelemetry; contactez ServiceNow dès aujourd’hui!