OpenTelemetry OTel Tracing Observability
OpenTelemetry unifie les traces, les métriques et les logs sous un standard ouvert unique, éliminant la dépendance aux agents propriétaires qui augmente les coûts à chaque changement de backend. Nous instrumentons les services écrits en Go, Java, Python, Node.js et .NET avec les SDK OTel, configurons le pipeline Collector pour la suppression des données personnelles et l'échantillonnage en queue, et exportons les signaux vers n'importe quel backend — Prometheus, Tempo, Jaeger ou Datadog — pour les clients américains et européens dans des secteurs réglementés.
OpenTelemetry unifie les traces, les métriques et les logs sous un standard ouvert unique, éliminant la dépendance aux agents propriétaires qui augmente les coûts à chaque changement de backend. Nous instrumentons les services écrits en Go, Java, Python, Node.js et .NET avec les SDK OTel, configurons le pipeline Collector pour la suppression des données personnelles et l'échantillonnage en queue, et exportons les signaux vers n'importe quel backend — Prometheus, Tempo, Jaeger ou Datadog — pour les clients américains et européens dans des secteurs réglementés.
Défis
Les développeurs instrumentent les spans avec des paramètres de requête, des identifiants utilisateurs ou des champs de payload sans réaliser que ces valeurs contiennent des données personnelles réglementées. Une fois dans le backend, les données personnelles sont difficiles à purger et peuvent violer les exigences de traitement des données du RGPD ou de HIPAA.
Instrumenter naïvement chaque appel de fonction ou créer des spans à forte cardinalité (étiquettes par utilisateur ou par identifiant de requête) gonfle la mémoire, le CPU et l'utilisation réseau. Un échantillonnage mal réglé laisse passer 100 % des traces et sature le Collector et le stockage backend.
L'échantillonnage en tête décide au début de la trace s'il faut l'enregistrer, manquant ainsi les chemins d'erreur rares mais importants. L'échantillonnage en queue met en tampon la trace complète avant de décider, ajoutant latence et pression mémoire dans le Collector. Choisir la mauvaise stratégie laisse des traces critiques manquantes ou des coûts de stockage excessifs.
Un en-tête W3C TraceContext manquant ou corrompu casse la trace à la première frontière de service, produisant des spans déconnectés qui ne peuvent pas être corrélés. Les stacks polyglots — passerelle Go, service Java, worker ML Python — nécessitent chacun une configuration de propagation spécifique au langage.
Les agents propriétaires (agent Datadog, New Relic APM) intègrent des API spécifiques à un fournisseur dans le code applicatif. Changer de backend nécessite des modifications au niveau du code, et le binaire de l'agent lui-même peut introduire une complexité de licence, de sécurité et de gestion des dépendances.
Le Collector prend en charge des receivers, processeurs et exporteurs dans des pipelines composables, mais un ordre de processeurs mal configuré (par exemple, mise en lot avant filtrage) provoque des pertes de données ou une utilisation excessive de la mémoire. La diffusion multi-backend et le routage basé sur l'environnement ajoutent une surface de configuration supplémentaire.
Solutions
Nous instrumentons les services avec les SDK OTel officiels et les agents d'auto-instrumentation, émettant des traces, métriques et logs au format OTLP sans API propriétaire dans le code applicatif — les backends sont interchangeables sans modification du code.
Nous concevons des pipelines OTel Collector avec des règles de processeur d'attributs qui suppriment, hachent ou éliminent les champs réglementés avant l'export, garantissant que la télémétrie est conforme au RGPD et aux exigences réglementaires sur tous les backends en aval.
Nous configurons des politiques d'échantillonnage en queue dans le Collector qui enregistrent 100 % des traces d'erreurs et de lenteur tout en réduisant le trafic routinier — capturant chaque anomalie sans exploser les budgets de stockage.
L'auto-instrumentation couvre les frameworks (HTTP, gRPC, base de données, messagerie) sans configuration supplémentaire ; nous ajoutons des spans manuels ciblés pour les chemins de code critiques — flux de paiement, appels d'inférence ML, événements réglementaires — là où le tracing au niveau framework est insuffisant.
Nous configurons la propagation W3C TraceContext et Baggage dans chaque runtime de langage, testons la propagation de bout en bout dans le pipeline CI et validons la continuité des traces entre les frontières de service à l'aide de scénarios de test distribués synthétiques.
Les exporteurs OTLP dans le Collector diffusent les signaux vers un ou plusieurs backends simultanément. Les clients peuvent exécuter Jaeger ou Tempo sur site pour les données réglementées et dupliquer les métriques non sensibles vers Datadog — sans modification de l'instrumentation.
Stack
SDK OpenTelemetry (Go, Java, Python, Node.js, .NET), OTel Collector, OTLP, agents d'auto-instrumentation, instrumentation manuelle de spans, propagation du contexte (W3C TraceContext / Baggage), conventions sémantiques, exporteurs (Prometheus, Grafana Tempo, Jaeger, Datadog, OTLP/gRPC), échantillonnage en queue, processeurs Collector (suppression des données personnelles, filtrage d'attributs, mise en lot), politiques d'échantillonnage.
Conformité
Données personnelles exclues de la télémétrie · export neutre vis-à-vis des fournisseurs · piste d'audit des traces · observabilité de bout en bout NIS2
Études de cas
Refonte et reconstruction Android + iOS pour un opérateur logistique allemand du dernier kilomètre — planification d'itinéraires multi-points, suivi des chauffeurs en temps réel et facturation intégrée, en production dans l'UE.
Plateforme sociale en production — App Store + Google Play, en ligne aux États-Unis et dans l'UE — avec radar géographique, messagerie chiffrée et économie virtuelle.
Plateforme de réservation de courses à trois applications — chauffeur, passager, répartiteur — avec GPS en temps réel, vérification des documents, paiements en espèces et par carte.
Pourquoi YuSMP
Chaque span et métrique est émis via l'API OTel ouverte. Passer de Datadog à Grafana Tempo ou ajouter un second backend est une modification de la configuration du Collector — pas un sprint de refactoring sur des dizaines de services.
Notre conception du pipeline Collector traite la suppression des données personnelles comme une priorité absolue, pas une réflexion après coup. Les champs réglementés sont supprimés ou hachés avant qu'un signal n'atteigne un backend externe, maintenant votre télémétrie conforme au RGPD et aux cadres similaires.
Nous instrumentons les trois types de signaux et configurons des exemplaires reliant les métriques Prometheus aux traces sous-jacentes, afin que les ingénieurs passent directement d'un pic de latence sur un tableau de bord à la trace incriminée sans changement de contexte.
FAQ
OpenTelemetry est un projet CNCF qui définit une API, un SDK et un protocole wire (OTLP) neutres vis-à-vis des fournisseurs pour les traces, les métriques et les logs. Contrairement aux agents propriétaires — Datadog APM, New Relic, Dynatrace — il n'intègre aucun code spécifique à un fournisseur dans votre application. Vous instrumentez une seule fois avec l'API OTel ouverte et routez les signaux vers n'importe quel backend conforme via le Collector. Changer de backend nécessite uniquement une configuration de l'exporteur du Collector, pas de modifications du code applicatif.
Les traces enregistrent le parcours de bout en bout d'une requête unique à travers les services — chaque opération est un span avec timing, attributs et statut. Les métriques sont des agrégations numériques dans le temps (taux de requêtes, taux d'erreurs, percentiles de latence) adaptées aux tableaux de bord et aux alertes. Les logs sont des événements textuels horodatés ou structurés provenant de composants individuels. OTel unifie les trois sous un SDK et un protocole wire, et les exemplaires relient les points de données métriques directement aux traces qui les ont produits.
OTel lui-même ne supprime pas les données personnelles — c'est la responsabilité du pipeline. Nous configurons le processeur d'attributs et le processeur de transformation du Collector OTel pour supprimer, hacher ou masquer les attributs de span et les champs de log susceptibles de contenir des données réglementées (e-mails, identifiants utilisateurs, numéros de carte, numéros de sécurité sociale) avant que les signaux n'atteignent un backend. Cela maintient la télémétrie conforme au RGPD et aux cadres similaires sans nécessiter de modifications de l'instrumentation au niveau applicatif.
L'échantillonnage en tête décide au début d'une trace s'il faut l'enregistrer — rapide et économe en mémoire, mais il élimine les traces d'erreurs rares avec la même probabilité que les traces routinières. L'échantillonnage en queue met en mémoire tampon la trace complète dans le Collector avant de décider, permettant des politiques telles que « toujours conserver les traces avec des erreurs ou une latence supérieure à 1 s ». Nous configurons l'échantillonnage en queue pour les systèmes en production où manquer des traces d'erreurs est plus coûteux que la mémoire et le CPU supplémentaires du Collector.
Le Collector OTel est un agent neutre vis-à-vis des fournisseurs qui reçoit OTLP (ou d'autres formats), traite les signaux — mise en lot, filtrage, transformation des attributs, suppression des données personnelles, échantillonnage en queue — et exporte vers un ou plusieurs backends simultanément. Vous pouvez exporter directement depuis les SDK vers un backend, mais le Collector découple l'instrumentation du choix du backend, centralise la gestion des données sensibles (suppression des données personnelles) et permet la diffusion vers plusieurs backends sans modification de l'application. Nous le recommandons pour tout déploiement en production.
La surcharge dépend du taux d'échantillonnage et de la cardinalité. Avec un échantillonnage en tête à 10 % et des attributs de span bien réglés (sans étiquettes à forte cardinalité comme l'identifiant utilisateur par span), la surcharge CPU est typiquement inférieure à 2 % et l'impact mémoire est minimal. Les agents d'auto-instrumentation ajoutent un coût de chargement des bibliothèques au démarrage. L'échantillonnage en queue dans le Collector ajoute de la mémoire proportionnelle à la fenêtre de tampon. Nous profilons les services instrumentés avant et après le déploiement et ajustons les politiques d'échantillonnage pour maintenir la surcharge dans les SLO convenus.
La migration est progressive. Nous commençons par exécuter le Collector OTel aux côtés de l'agent existant, en routant un flux OTLP dupliqué vers un backend OTel compatible à l'essai pendant que l'agent propriétaire continue en production. Une fois la parité des signaux confirmée — couverture des traces, cardinalité des métriques, fidélité des alertes — nous supprimons l'auto-instrumentation de l'agent propriétaire, ne laissant que les SDK OTel dans l'application. Le Collector peut toujours exporter vers Datadog via son exporteur OTLP si Datadog est conservé comme backend, il n'y a donc pas de bascule brutale.
Réponse sous 1 jour ouvrable. NDA sur demande.
Partagez quelques détails et un consultant senior vous répondra sous un jour ouvrable.