Journalisation OpenTelemetry : introduction

La journalisation OTel offre aux équipes informatiques une structure de mappage unifiée et non ambiguë pour convertir les données de journalisation provenant de différentes sources, systèmes et formats en un modèle unique et indépendant du langage, tout en préservant les significations sémantiques originales.

Avec un modèle de données structurées indépendant du fournisseur, les outils d’observabilité peuvent plus facilement et de manière fiable analyser les journaux, joindre des métadonnées et corréler les journaux avec des métriques et des traces pour une visibilité profonde de bout en bout.

La journalisation OTel permet aux entreprises de basculer et de mélanger les backends d’observabilité sans réinstrumenter toute l’architecture informatique, ce qui explique pourquoi il est devenu la norme des secteurs pour l’instrumentation dans les systèmescloud natifs. Ces capacités aident les équipes informatiques et les ingénieurs de fiabilité des sites (SRE) à éviter les lacunes en matière d'observabilité et les problèmes de fragmentation des données qui surviennent lorsque chaque fournisseur, pile et appareil a son propre schéma de journalisation et ses propres protocoles de transmission.

La journalisation OTel facilite également la corrélation automatique des signaux croisés, ce qui améliore considérablement le débogage et réduit l’enfermement propriétaire de l’observabilité.

Les journaux OpenTelemetry sont un composant essentiel d’OpenTelemetry. OpenTelemetry est un cadre d’observabilité open source qui inclut une collection de kits de développement logiciel (SDK), des interfaces de programmation d’applications (API) indépendantes des fournisseurs et d’autres outils pour l’instrumentation des applications, systèmes et appareils.

Les codes d'instrumentation variaient considérablement et aucun fournisseur commercial n'offrait un outil capable de collecter des données à partir de chaque application et service d'un réseau. Cette lacune fonctionnelle a rendu difficile (et souvent impossible) pour les équipes de collecter des données provenant 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.

Si, par exemple, une équipe de développement souhaitait changer d’outils back-end, elle devrait réinstrumenter complètement son code et configurer de nouveaux agents (composants logiciels qui exécutent des tâches de construction et de libération automatisées) pour envoyer les données de télémétrie aux nouveaux serveurs. Les approches fragmentées ont créé des silos de données et de la confusion, rendant difficile la résolution efficace des problèmes de performance.

OpenTelemetry a représenté une avancée significative dans le domaine des outils d’observabilité, car il a standardisé la manière dont les données de télémétrie sont recueillies, analysées et transmises aux plateformes back-end. Ceci a fourni une solution open source — basée sur des normes communautaires — pour collecter des données sur le comportement et la sécurité des systèmes, aidant les équipes à rationaliser la surveillance et l’observabilité dans les écosystèmes distribués.

La journalisation OpenTelemetry repose sur plusieurs composants coopératifs qui créent, structurent, transportent et fournissent des enregistrements dans le cadre d'un pipeline d'observabilité unifié. Elles incluent :

Un enregistrement est une structure de données centrale qui représente un événement unique dans OpenTelemetry. Elle suit un modèle de données standard qui définit des champs et des sémantiques, de sorte que les journaux issus de différents langages et systèmes peuvent être interprétés de manière cohérente par les backends.

Les enregistrements de journal apparaissent comme des lignes structurées dans un tableau Excel décrivant un événement et répondant à des questions de base, telles que « que s’est-il passé », « quand cela s’est-il produit », « quelle est son importance » et « d’où cela vient-il ».

Le modèle de données de journalisation est le modèle commun que suit chaque enregistrement, quels que soient les langages et les systèmes. Il définit les champs de premier niveau qui existent et leur signification.

Un modèle de données journal typique exige que les enregistrements incluent :

• Un horodatage et un horodatage observé (quand l'événement s'est produit et quand il a été vu)

• Nombres de sévérité et texte de sévérité (également appelé niveau logarithmique), qui décrivent le niveau de gravité d’un événement

• Le corps (le message principal du journal, souvent une courte chaîne de caractères ou un objet JSON)

• les attributs, qui ajoutent des détails plus précis sur chaque événement (tels que des détails sur l'utilisateur ou sur le protocole HTTP).

• Informations sur les ressources qui identifient le service émetteur et l'environnement de déploiement

• ID de trace et ID de portée qui relient l'événement à une demande spécifique (simplifie la corrélation des données).

La structure imposée par les modèles de données transforme les journaux provenant de différents services et technologies en entités télémétriques riches et interrogeables qui ont la même apparence et le même comportement lorsqu'elles entrent dans le pipeline d'observabilité. Les modèles de données de logs permettent aux équipes informatiques de corréler les logs avec les traces, de les regrouper par service ou par utilisateur, et d'exécuter les mêmes types de requêtes dans tout l'environnement informatique, au lieu d'avoir à gérer un ensemble de formats de logs incompatibles.

Et parce que le modèle de journal est ouvert et piloté par la communauté, l’instrumentation et les pipelines de logs d’OTel sont portables (non liés à un seul produit logiciel en tant que service (SaaS) ou agent propriétaire). Ils fonctionnent sur différents cadres et plateformes, ce qui est particulièrement utile dans les environnements de microservices polyglottes.

Un logger est l'objet qui écrit les enregistrements de journalisation, similaire aux instances de logger dans d'autres cadres des exigences (tels que Java et Python). Lorsqu'une plateforme d'observabilité envoie la commande « enregistrer cette erreur » ou « enregistrer ce message d'information », elle envoie le message à un enregistreur.

Les différentes parties d'une application ou d'un système peuvent nécessiter leurs propres enregistreurs (par exemple, un pour le « paiement » et l'autre pour les « paiements »), mais elles suivent toutes les mêmes règles pour générer des journaux.

Les enregistreurs sont obtenus auprès d'un fournisseur d'enregistreurs, qui est chargé de créer des enregistreurs et de les configurer avec le pipeline, les attributs et les exportateurs appropriés.​ Lorsque le code du logiciel demande un enregistreur, le fournisseur en fournit un qui est déjà configuré de manière appropriée.

Cette conception permet à différentes parties d'un système d'utiliser différents enregistreurs qui partagent néanmoins une configuration commune et sont tous gérés de manière centralisée par le Logger Provider. Cela permet également aux équipes informatiques de passer plus facilement des implémentations et d’ajuster le comportement de journalisation à l’échelle mondiale sans modifier chaque site d’appel.

Le collecteur OTel est un service distinct qui reçoit, traite et exporte des données de télémétrie — y compris les enregistrements de journal — provenant de nombreuses sources. Les applications envoient leurs journaux (ainsi que leurs traces et métriques) au Collecteur, qui peut recevoir des données sous différents formats, les standardiser puis les envoyer à un ou plusieurs backends.

Les collecteurs prennent en charge des pipelines de journalisation dédiés, construits autour de trois sous-composants principaux : les récepteurs, les processeurs et les exportateurs.

Les récepteurs ingèrent des journaux à partir de différentes entrées, telles que les flux du protocole de télémétrie ouverte (OTLP) et les fichiers journaux des récepteurs à queue de fichier. Les processeurs effectuent des opérations telles que le traitement par lots, la modification des attributs, l’enrichissement du contexte (en ajoutant des métadonnées de pod Kubernetes, par exemple), le filtrage et l’échantillonnage sur les enregistrements de journaux. Les exportateurs situés dans le collecteur transmettent ensuite les journaux traités vers une ou plusieurs destinations.

Les exportateurs d'enregistrements sont intégrés à un collecteur OTel ou à un SDK d'application et définissent où et comment les données télémétriques sont transmises aux systèmes dorsaux.

Une fois que le SDK Logs a créé et traité un enregistrement de journal, l'exportateur code le modèle de données de journal dans un protocole ou un format spécifique et envoie l'enregistrement à un « consommateur » en aval. Les consommateurs peuvent être des collecteurs OTel, des solutions d'observabilité ou des magasins open-source, par exemple.

Les exportateurs peuvent être basés sur le push ou sur le pull, et ils peuvent être échangés et combinés pour transmettre simultanément les mêmes enregistrements de journal à différents backends sans modifier le code de l'application. La flexibilité offerte par les exportateurs permet aux entreprises de faire évoluer plus facilement leur architecture d'observabilité en fonction de l'évolution des exigences.

L'API et le SDK Logs fonctionnent comme une prise de courant sur une Power® : l'API est le type de prise de courant et le SDK est la Power® qui transporte l'électricité.

Les API d'OpenTelemetry comprennent un ensemble de fonctions que le code et les bibliothèques de journalisation appellent pour créer des entrées de journal uniformes. En d'autres termes, l'API Logs détermine la « forme » qu'un journal doit prendre pour se « connecter » à OTel. L'API Logs permet de s'assurer que les mêmes appels d'API fonctionneront quel que soit le backend d'observabilité ou le fournisseur que l'équipe informatique choisira par la suite.

Cependant, l'API n'est qu'une interface. Il ne peut pas décider où vont les journaux ni comment ils sont envoyés. C'est là que le SDK OpenTelemetry, ou Logs SDK, entre en jeu.

Le SDK Logs récupère les journaux du point de terminaison de l’API et les utilise pour faire le vrai travail. Il reçoit les enregistrements de log, les enrichit (en ajoutant par exemple le nom du service ou l’environnement), les regroupe et les prépare à être expédiés. Ensuite, il utilise des exportateurs pour envoyer les journaux traités à un collecteur ou à une plateforme de journalisation.

Les appendeurs de journal — également appelés ponts de journal — connectent les bibliothèques de journalisation existantes (telles que Log4j, SLF4J ou des frameworks similaires) au modèle de données de journal OpenTelemetry.

Au lieu que les développeurs de logiciels appellent directement l’API Logs, ils peuvent configurer leur framework de journalisation existant pour utiliser un appendeur qui transforme chaque événement de journal traditionnel en un enregistrement OTel.

Les ponts de logs peuvent également injecter du contexte span et trace dans les enregistrements de log, permettant une corrélation entre logs et traces même lorsque le code de l’application lui-même ignore les détails de traçage.

Les mécanismes de propagation du contexte et de corrélation sont des composants essentiels de la journalisation OpenTelemetry. Lorsqu'une plage de trace est active, un pont de journalisation ou un SDK peut automatiquement associer l'identifiant de trace et l'identifiant de span actuels à chaque enregistrement de journal émis.

La corrélation aide les backends d'observabilité à relier les journaux aux traces distribuées qui représentent la même demande ou le même workflow. Ces connexions permettent aux équipes de naviguer directement d’une entrée de journal problématique vers une trace qui montre le chemin complet de la requête. Il facilite également l'analyse des signaux croisés pour les indicateurs, les traces et les journaux qui partagent des champs de Ressources et de contexte communs.

OTel parle de « types » de journaux de différentes manières : par structure, par source et par protocole d’encodage ou de transmission.

 Les journaux structurés ont un schéma cohérent (les mêmes champs, avec des noms et des types de données stables) ce qui permet aux outils d’observabilité de les analyser et de les interroger de manière fiable. Les journaux peuvent être encodés au format JSON ou dans un autre format, mais ce qui les structure, c’est l’ensemble prévisible des champs de données.

Les journaux semi-structurés contiennent une structure reconnaissable (paires clé-valeur ou blobs de type JSON, par exemple), mais le schéma n’est pas cohérent dans le temps. Ils sont plus lisibles par les machines que le texte libre, mais ils nécessitent une analyse et une normalisation supplémentaires avant que les équipes ne puissent les analyser efficacement.

Les journaux non structurés sont des messages textuels libres sans schéma stable (tels que des instructions d'impression ad hoc ou des journaux de serveur en texte brut). Ils sont faciles à écrire et à lire pour les humains, mais plus difficiles à rechercher, à corréler et à agréger pour les systèmes automatisés sans une analyse supplémentaire considérable. 

Les journaux du système et de l'infrastructure sont produits par les systèmes d'exploitation, les appareils réseau, les services d'infrastructure cloud et d'autres composants de la plateforme, plutôt que par le code de l'application. Ils enregistrent des événements, tels que les erreurs du système d’exploitation, les problèmes réseau et l’état de l’infrastructure, afin d’aider les équipes à comprendre la santé et la performance de l’environnement sous-jacent.

Les journaux d’application first-party proviennent de services et applications internes, généralement via un SDK OTel, une bibliothèque de journalisation, un sidecar (un second conteneur d’application fonctionnant parallèlement au conteneur principal et utilisant les mêmes ressources) ou un agent. Ils décrivent les événements métier, la gestion des requêtes, les actions des utilisateurs et les erreurs internes. Ils peuvent être enrichis d'attributs de ressources et d'une portée d'instrumentation (qui décrit l'origine du journal au sein de l'entité qui l'a généré) afin de fournir une image plus complète du comportement de l'application.

Les journaux tiers sont émis par les services externes, les composants gérés et les produits SaaS dont dépendent de nombreux environnements informatiques d’entreprise (les API et bases de données externes, par exemple). OTel peut ingérer ces logs en même temps que les logs internes afin que les équipes informatiques puissent voir comment les dépendances externes affectent l'écosystème.

Les journaux OTLP sont représentés dans le modèle de données OTLP natif et envoyés via OTLP gRPC ou HTTP. Chaque journal est standardisé pour garantir la neutralité des fournisseurs et une corrélation rapide avec les traces et les indicateurs.

Les journaux basés sur des fichiers sont écrits dans des fichiers (fichiers journaux des applications ou journaux d'accès au serveur Web), et les journaux de style Syslog sont des messages émis à l'aide du protocole Syslog. OTel collecte généralement ces journaux en utilisant des récepteurs qui suivent les fichiers ou écoutent les messages Syslog, puis les convertissent en enregistrements de journaux OTel pour un traitement unifié.

Les journaux HTTP et JSON sont distribués via HTTP au format JSON. OpenTelemetry prend également en charge les formats CSV, Common Log Format (CLF), LTSV et les paires clé-valeur. Ces formats sont analysés par le collecteur dans le modèle de données commun des journaux OTel, de sorte qu'ils peuvent être interrogés et corrélés de la même manière que les journaux OTLP natifs.

Imaginez que les équipes SRE constatent une augmentation des erreurs « échec de paiement » sur les tableaux de bord d’observabilité d’un microservice de paiement. Ils peuvent commencer le processus de dépannage en examinant les journaux OTel, déjà standardisés et incluant des attributs structurés (y compris le montant de la commande, le nombre d’éléments et l’ID de suivi) pour chaque enregistrement de journal « commande placée ».

Les ingénieurs peuvent rapidement vérifier si les défaillances correspondent à un volume élevé de commandes, à une méthode d’expédition spécifique ou à une région particulière, simplement en interrogeant les attributs du journal. Ils peuvent également aligner la fenêtre temporelle entre les journaux, les traces et les indicateurs, car OTel utilise des horodatages et des métadonnées de ressources cohérents pour tous les signaux de télémétrie.

Les ingénieurs confirment que seules les commandes acheminées vers un prestataire de paiement spécifique échouent. Ils suivent une trace vers tous les journaux qui partagent cet attribut fournisseur, où ils trouvent des délais d’attente de session répétés. Grâce à ces éléments, l’équipe informatique peut rapidement acheminer l’incident vers le bon propriétaire et mettre en œuvre une stratégie d’atténuation (par exemple, en cas de basculement vers un autre fournisseur).

La journalisation OTel diffère considérablement de la journalisation traditionnelle en ce qui concerne ses procédures de collecte, de normalisation, de corrélation et de transmission des journaux.  

Les systèmes de journalisation traditionnels concentrent l’agrégation, l’indexation, la recherche et les alertes en fonction de leurs modèles. Ce sont de puissants outils de recherche textuelle et d'analyse historique, mais ils examinent généralement les journaux séparément des autres données de télémétrie.

Les approches traditionnelles de journalisation consistent principalement à enregistrer des messages texte localement, afin que les développeurs puissent déboguer les problèmes dans une seule application ou un seul hôte. Ils supposent que les utilisateurs liront les fichiers, les filtreront et les enverront peut-être ultérieurement à un agrégateur de journaux. Ils utilisent également généralement des formats ad hoc, tels que des lignes de texte brut, des modèles JSON à structure souple ou des modèles spécifiques à un cadre, sans norme interservices.

Et comme chaque équipe de développement peut choisir ses propres champs et dénominations, l'analyse inter-systèmes est un processus lourd.

Les outils de journalisation traditionnels n'intègrent souvent pas de fonctionnalités de corrélation ou de migration, de sorte que la corrélation des données et l'intégration avec les backends d'observabilité requièrent des processus manuels et des étapes supplémentaires. Les équipes informatiques doivent créer des conventions et des règles d'analyse personnalisées pour assembler les événements entre les services, et l'intégration des données de journalisation dans la pile d'observabilité nécessite généralement des expéditeurs ou des adaptateurs de format personnalisés.

La journalisation d’OpenTelemetry fait partie d’un cadre d’observabilité unifiée qui traite les journaux, les indicateurs et les traces comme des signaux interopérables de première classe, régis par des conventions sémantiques communes. Dès le départ, elle conçoit des journaux à corréler et à analyser sur des systèmes distribués, car l’objectif est de comprendre le comportement du système de bout en bout.

Alors que la journalisation traditionnelle est spécifique à la pile et au backend, la journalisation OTel est délibérément indépendante. Il fournit des ponts et des appenders pour que les cadres des exigences existants puissent émettre des données dans le format OTel sans avoir à réécrire chaque appel de journalisation.

Cette portée et cette approche unifiées permettent aux équipes informatiques de créer des workflows holistiques, où elles peuvent naviguer de manière fluide entre les tableaux de bord et les types de données afin de comprendre des défaillances complexes et distribuées.

La journalisation OTel fournit des journaux standardisés et riches en contexte qui s'intègrent étroitement avec les traces et les indicateurs, ce qui rend le dépannage et l'analyse beaucoup plus efficaces que les approches traditionnelles. Ces bénéfices incluent :