Instrumentation des applications avec OpenTelemetry et ServicePilot

Qu’est-ce qu’OpenTelemetry ?

OpenTelemetry est né de la fusion de deux projets majeurs : OpenTracing, orienté traces distribuées et OpenCensus, orienté métriques. La fusion a permis de créer un standard ouvert unique, largement adopté par l’industrie.

OpenTelemetry (OTel) est un projet open source soutenu par la Cloud Native Computing Foundation (CNCF). Il fournit un ensemble d’outils, d’API et de SDK permettant de collecter trois types de signaux essentiels :

• Les métriques sont des mesures chiffrées comme le nombre de requêtes, la latence, le taux d’erreur.
• Les traces représentent le parcours d’une requête à travers les services. Chaque trace est composée d’une succession de spans, chacun correspondant à une opération ou étape précise du traitement. Par exemple, une trace liée à une requête Web peut inclure des spans dédiés à l’authentification, à l’interrogation de la base de données ou encore à la génération de la réponse.
• Les logs sont des événements textuels décrivant ce qui se passe dans l’application avec leurs contextes temporels et informationnels.

L’intégration de l’observabilité dans les applications n’est plus une simple bonne pratique , c’est une condition essentielle pour assurer leur maintenance, leur optimisation et leur amélioration continue. Elle offre aux développeurs les moyens de garantir des applications fiables et performantes, tout en fournissant les informations nécessaires pour prendre des décisions éclairées.

Pourquoi OpenTelemetry est devenu aussi populaire ?

L’objectif d’OpenTelemetry est simple : standardiser l’instrumentation des applications et envoyer les données de télémétrie à un back-end d'observabilité. Le framework se distingue par son approche véritablement indépendante des fournisseurs : il propose des API, des SDK et des outils qui ne dépendent d’aucun écosystème propriétaire. Grâce à cette neutralité, les organisations évitent le risque de verrouillage technologique et conservent la liberté de choisir leur solution d’observabilité en back-end.

Interopérabilité
OTel fonctionne avec tous les principaux outils du marché : ServicePilot, Prometheus, Jaeger, Grafana, etc.

Standardisation
Il n'y a plus besoin d’utiliser un SDK différent propre à chaque outil de monitoring.

Flexibilité
Les applications peuvent être instrumentées automatiquement ou manuellement, selon les besoins.

Écosystème riche
OpenTelemetry propose des implémentations spécifiques de l'API et du SDK pour plusieurs langages de programmation :

• .NET
• C++
• Go
• Java
• JavaScript
• Node.js
• Python
• PHP
• Ruby
• Rust, etc.

OpenTelemetry est de plus en plus embarqué nativement dans les logiciels modernes. Cette évolution s’explique par la nécessité croissante d’offrir une observabilité prête à l’emploi et sans configuration complexe. Les frameworks web, les plateformes serverless, les orchestrateurs de conteneurs ou encore les bases de données commencent à exposer des traces, métriques et logs au format OpenTelemetry dès leur installation. Cela signifie que les équipes n’ont plus besoin d’ajouter manuellement des bibliothèques d’instrumentation : l’observabilité devient un composant standard, intégré dès la conception. Cette tendance va continuer à s’accélérer, faisant d’OpenTelemetry un véritable langage universel de la télémétrie et simplifiant encore davantage l’intégration avec des plateformes comme ServicePilot.

Les composants clés d’OpenTelemetry

L’API définit les interfaces permettant d’instrumenter le code indépendamment du backend utilisé.

Les SDK propres à chaque langage permettent d'utiliser l'API OpenTelemetry afin de générer des données de télémétrie et d'exporter ces données vers un backend. Ces SDK donnent également la possibilité d'intégrer des bibliothèques d'instrumentation pour les frameworks courants.

L'OpenTelemetry Collector est un proxy indépendant des fournisseurs capable de recevoir, de traiter et d'exporter des données de télémétrie. Il prend en charge la réception de données de télémétrie dans plusieurs formats et leur envoi vers un ou plusieurs backends. Il permet également de traiter et de filtrer les données de télémétrie avant leur exportation. L'utilisation d'un Collector améliore l'évolutivité, permet aux services de décharger rapidement leurs données et peut prendre en charge des opérations supplémentaires telles que les tentatives de reconnexion, le traitement par lots ou le chiffrement.

OTLP (OpenTelemetry Protocol) est le protocole natif pour transporter les données de télémétrie. Il supporte tous les signaux (traces, métriques, logs, profiles) dans un format unique, avec deux modes de transport : gRPC ou HTTP/protobuf. OTLP est le format recommandé pour la communication SDK → Collector et Collector → backend.

Comment instrumenter une application ?

Pour qu'un système soit observable, il doit être instrumenté : en d'autres termes, le code des composants du système doit émettre des signaux, tels que des traces, des métriques et des logs. Avec OpenTelemetry, il est possible d'instrumenter le code de deux manières principales :

1. Auto-instrumentation (ou zero-code), solution sans modifier le code pour quelques langages spécifiques
2. Instrumentation manuelle, solution basée sur l'insertion manuelle dans le code via les API et SDK officiels pour la plupart des langages

Les bonnes pratiques préconisent de combiner les deux, en commençant par l’auto-instrumentation pour obtenir immédiatement les spans des appels HTTP, des requêtes SQL, des appels gRPC sans modifier le code. Puis en ajoutant l’instrumentation manuelle sur les opérations métier critiques (paiement, création de commande, authentification, etc.) afin d'obtenir des spans manuels avec des attributs métier pertinents pour le diagnostic.

Outre l'instrumentation des applications elles-mêmes, OpenTelemetry fournit des bibliothèques d'instrumentation pour de nombreux composants tiers qui exposent leurs données au format OpenTelemetry. Par exemple, il est possible de collecter des traces de commandes MySQL Enterprise Server, des métriques concernant l'utilisation de Claude Code ou la télémétrie de Workflows Argo. Le Registry OpenTelemetry propose une base de données consultable regroupant des bibliothèques d'instrumentation, des composants de collecte et d'autres projets utiles au sein de l'écosystème OpenTelemetry.

Les Golden Signals et leur exploitation avec OTel & ServicePilot

Dans le domaine de l’observabilité, tous les signaux ne se valent pas. Pour comprendre rapidement l’état d’un système, les équipes SRE et DevOps s’appuient depuis longtemps sur un concept fondamental : les Golden Signals. Popularisés par Google dans le cadre du SRE, ces quatre indicateurs clés permettent de diagnostiquer en quelques secondes la santé d’un service. Grâce à OpenTelemetry et ServicePilot, il devient possible non seulement de collecter ces signaux automatiquement, mais aussi de les analyser, de les corréler et de remonter à la cause racine en un minimum de temps.

Golden Signals : socle indispensable pour comprendre les services

Les Golden Signals sont au nombre de quatre :

• Latence : le temps nécessaire pour traiter une requête
• Trafic : le volume de requêtes reçues par le service
• Erreurs : le taux de requêtes échouées ou incorrectes
• Saturation : le niveau d’utilisation des ressources (CPU, mémoire, threads…)

Ces signaux constituent la base de toute stratégie d’observabilité efficace. Ils permettent de répondre immédiatement à des questions essentielles :

• Le service est-il lent ?
• Le service est-il surchargé ?
• Le service renvoit-il des erreurs ?
• Le service dispose-t'il des ressources nécessaires pour fonctionner de manière optimale ?

Sans ces indicateurs, l’analyse devient plus longue, plus complexe et souvent plus approximative.

Des Golden Signals visibles en 5 secondes dans ServicePilot

Grâce à l’intégration OpenTelemetry + ServicePilot, les Golden Signals sont automatiquement collectés et affichés dans des tableaux de bord prêts à l’emploi. Dès qu’un service commence à envoyer des traces et des métriques, ServicePilot génère une vue synthétique permettant de comprendre l’état du système en moins de cinq secondes :

• Un graphique de latence moyenne et p95
• Un graphique de trafic avec le nombre de requêtes
• Un graphique des erreurs avec le taux d'erreurs
• Un accès facile aux données des infrastructures sous-jascentes

Un tableau regroupe les 3 signaux (latence, trafic, erreurs) par application, service ou URL afin de résumer toutes ces informations dans un seul widget. Cette visibilité immédiate permet de savoir instantanément si un service est en bonne santé ou s’il nécessite une investigation plus poussée.

Drill-down : de la vision globale au détail d’une requête

L’un des grands avantages de ServicePilot est la possibilité de passer du macro au micro en un clic. À partir d’un Golden Signal anormal (par exemple une latence élevée), vous pouvez :

• Cliquer sur le service concerné
• Ouvrir la liste des traces associées
• Identifier les requêtes les plus lentes
• Explorer leur waterfall détaillé

Ce drill-down rapide permet de comprendre non seulement qu’il y a un problème, mais aussi où il se situe : dans un appel externe, une requête SQL, un microservice en aval ou une fonction métier spécifique.

RCA : trouver la cause racine grâce à la corrélation

Identifier un problème est une chose. Comprendre pourquoi il se produit en est une autre. ServicePilot excelle dans la corrélation automatique entre les traces, les logs, les métriques et l'infrastructure sous-jacente.

Exemple concret :

• Une latence anormale est détectée
• Une trace lente peut être ouverte
• Le waterfall montre un appel SQL particulièrement long
• Les logs corrélés affichent une erreur de connexion à la base
• Les métriques d’infrastructure montrent une saturation CPU sur le serveur SQL

En quelques clics, vous avez reconstitué toute la chaîne causale.

Les Golden Signals ne concernent pas uniquement les applications. Ils doivent être mis en perspective avec l’état des conteneurs, les performances du cluster Kubernetes, la santé des bases de données, les ressources réseau ou les services cloud utilisés. ServicePilot permet de visualiser l’ensemble de cette chaîne dans une seule interface, ce qui facilite la Root Cause Analysis et la compréhension globale du système.

OTel + ServicePilot pour une observabilité simplifiée

OpenTelemetry collecte les données brutes. ServicePilot se positionne comme un backend d'observabilité unifié pour exploiter ces données. L’association des deux offre une solution d’observabilité complète.

Intégration native : ServicePilot supporte nativement OTLP, ce qui simplifie la configuration et l'export automatique des données.

Corrélations des signaux : les données sont unifiées et présentées de manière claire pour effectuer la corrélation entre les signaux (Traces distribuées, Métriques, Logs)

Interfaces et fonctionnalités : tableaux de bord, alerting, reporting PDF, cartographies, cockpits de supervision, capacity planning, etc.

Scalabilité : ServicePilot peut ingérer un volume important de données sans configuration complexe.

Gain de temps : cela permet de se concentrer sur l’analyse et la résolution des incidents au lieu de perdre du temps à configurer et maintenir 4 logiciels supplémentaires.

L’instrumentation est un pilier essentiel de l’observabilité moderne. OpenTelemetry offre un standard ouvert, flexible et puissant pour collecter des données. En l’associant à ServicePilot, vous bénéficiez d’une plateforme complète pour visualiser, analyser et optimiser les performances de vos applications.

Que vous soyez développeur, DevOps, ingénieur SRE ou administrateur système, l’intégration OTel + ServicePilot vous permettra d’améliorer la fiabilité et la performance de vos services tout en simplifiant votre quotidien.