OpenTelemetry : unifier métriques, traces et logs pour l’observabilité

Version audio :

Table des matières :

1. L’observabilité moderne : arrêter de confondre monitoring et divination
2. OpenTelemetry : un standard CNCF, pas un énième agent « magique »
3. Les trois signaux unifiés : métriques, traces et logs… et la colle (le contexte)
4. Déployer OpenTelemetry proprement : Collector, pipelines, sampling et maîtrise des coûts
5. Cas d’usage e-commerce et sécurité : du panier qui rame à la tentative de fraude
6. Gouvernance & opérationnel : SLO, qualité de télémétrie, RGPD et MCO/MCS
7. Mise en route réaliste : le plan en 10 jours (pas en 10 slides)

L’observabilité moderne : arrêter de confondre monitoring et divination

Vous pouvez monitorer un système sans jamais comprendre pourquoi il casse. C’est même la norme historique : un graphe CPU, une alerte « HTTP 500 > 1% », et une cérémonie vaudou autour d’un redémarrage. Ça marche… jusqu’au jour où votre architecture passe de « un monolithe PHP sur un VPS » à « une constellation de services, files, caches, CDN, WAF, workers et un PSP externe qui a décidé de faire la sieste ». À ce moment-là, « regarder des courbes » devient une discipline artistique, pas une pratique d’ingénierie.

L’observabilité (observability) se distingue justement du monitoring classique par sa capacité à répondre à des questions non prévues à l’avance. Là où le monitoring excelle sur les known unknowns (« est-ce que l’API répond ? »), l’observabilité vous aide sur les unknown unknowns (« pourquoi le checkout est lent seulement pour les clients iOS en 4G, derrière tel ASN, quand le stock est faible ? »). Et non, une énième dashboard Grafana copiée d’un template ne suffit pas : il faut des signaux corrélables et des dimensions (attributs) cohérentes.

Pour éviter la “divination”, il faut distinguer deux niveaux :

• Détection (vite, fiable) : alertes sur des métriques agrégées (latence, erreurs, saturation).
• Diagnostic (précis, actionnable) : traces et logs corrélés, capables d’expliquer la chaîne causale.

Le problème, c’est que beaucoup d’organisations ont des métriques dans un coin (Prometheus), des logs dans un autre (ELK), des traces… nulle part, et un runbook « si ça marche pas, augmenter les pods ». Résultat : MTTR qui grimpe, escalades nocturnes, et coût d’infra qui explose à coups de surprovisionnement « au cas où ». Si vous gérez un e-commerce, l’impact est brutal : latence = conversion qui fond. Avant de refaire le design du bouton « Ajouter au panier », commencez par savoir ce qui se passe réellement.

Un bon test pour savoir si vous êtes “observables” : quand un incident arrive, êtes-vous capables de répondre rapidement (et avec des preuves) à ces questions ?

• Quelle route / quel parcours utilisateur est touché (ex. /checkout, /search) ?
• Est-ce global ou segmenté (pays, réseau, version, feature flag) ?
• Est-ce applicatif, base de données, cache, réseau, ou dépendance externe ?
• Quel changement a précédé l’incident (déploiement, config, feature flag, incident fournisseur) ?

Si la réponse ressemble à « on va ouvrir trois dashboards et espérer », vous êtes encore dans le monitoring “à l’ancienne”.

OpenTelemetry : un standard CNCF, pas un énième agent « magique »

OpenTelemetry (OTel) n’est pas un produit, ni un backend. C’est un ensemble d’API, de SDK et d’outils pour instrumenter, collecter et exporter des données de télémétrie. La définition officielle est limpide :

“OpenTelemetry is a collection of tools, APIs, and SDKs. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.” — OpenTelemetry, documentation officielle : https://opentelemetry.io/

L’intérêt ? Unifier métriques, traces et logs pour l’observabilité, sans vous enfermer dans le format propriétaire du vendor du moment. Vous instrumentez une fois (correctement), vous exportez vers la stack de votre choix (Prometheus/Grafana, Elastic, Datadog, New Relic, Splunk, Tempo/Jaeger, etc.) et vous gardez une porte de sortie. En 2026, avec des contraintes budgétaires et des migrations cloud/hybrides fréquentes, cette neutralité n’a rien d’un « nice to have ».

Deux précisions utiles (et souvent mal comprises) :

• OpenTelemetry ne remplace pas Prometheus/Grafana/Elastic : il standardise la production et le transport de télémétrie (notamment via OTLP), puis laisse la place au backend pour le stockage, la requête, l’UI, l’alerting.
• “Auto-instrumentation” ≠ observabilité prête à l’emploi : ça donne un socle (spans HTTP/DB), mais sans conventions d’attributs, sans sampling maîtrisé, et sans corrélation logs↔traces, vous aurez des données… pas forcément exploitables.

Côté équipes, OpenTelemetry colle particulièrement bien à un fonctionnement DevOps mature : vous créez de la télémétrie au plus près du code et de l’infra, vous automatisez la collecte, puis vous exploitez ça dans vos boucles d’amélioration (SLO, post-mortems, capacity planning). Si votre organisation est encore en train de débattre de qui « possède » la prod, commencez par remettre les pendules à l’heure côté pratiques (voir l’article interne DevOps : Méthodes et outils essentiels pour les équipes informatiques : https://www.les-vikings.fr/article/devops-methodes-et-outils-essentiels-pour-les-equipes-informatiques/).

Les trois signaux unifiés : métriques, traces et logs… et la colle (le contexte)

Avant d’entrer dans le détail, gardez cette règle simple : les métriques détectent, les traces expliquent la chaîne, les logs prouvent et documentent. Et la colle, c’est le contexte (trace/span + attributs cohérents).

Un résumé “terrain” :

Signal	Sert à	Granularité	Forces	Pièges fréquents
Métriques	Alerter, suivre des tendances, piloter des SLO	Agrégée	Peu coûteux à interroger, parfait pour l’alerte	Cardinalité, mauvais percentiles, dimensions instables
Traces	Comprendre la latence, le chemin d’exécution, les dépendances	Par requête	Causalité, visibilité inter-services, dépendances externes	Volume, sampling mal choisi, propagation incomplète
Logs	Détail d’un événement, stacktrace, contexte métier	Événement	Explication précise, audit, forensic applicatif	Non structuré, bruit, absence de trace_id, PII

Métriques : le thermomètre (et pas l’autopsie)

Les métriques (counters, gauges, histograms) vous donnent une vue agrégée : taux d’erreur, latence p95/p99, saturation, débit. En prod, c’est indispensable pour alerter vite et suivre une tendance. Le piège classique, surtout en e-commerce, c’est la cardinalité : ajouter user_id, email ou cart_id en label de métrique parce que « ça aidera »… et découvrir ensuite que votre TSDB brûle. On garde les métriques pour les dimensions stables (service, route, méthode, statut, région, version), et on réserve l’ultra-détail aux traces et logs.

Une approche pragmatique qui marche bien pour démarrer (et qui se lit facilement en incident) : les métriques RED par service/route :

• Rate : combien de requêtes (ou de jobs) ?
• Errors : combien d’échecs (HTTP 5xx, exceptions, échecs métier) ?
• Duration : quelle latence (histogrammes) ?

Checklist anti-cardinalité (à appliquer en revue de télémétrie) :

• Les labels/attributs sont-ils bornés (petit nombre de valeurs possibles) ?
• Les routes sont-elles normalisées (/product/{id}) au lieu d’exploser (/product/123, /product/124) ?
• Les codes d’erreurs métiers sont-ils regroupés intelligemment (catégories) plutôt qu’un message libre ?
• Les percentiles sont-ils calculés sur des histogrammes (et non des moyennes “trompeuses”) ?

Et si vous êtes déjà sur Prometheus : regardez aussi la notion d’exemplars (quand supportés par votre stack), qui permet de relier un point de métrique à un trace_id — un bon raccourci entre “thermomètre” et “film”.

Traces distribuées : le film complet, pas une photo floue

Les traces décrivent un parcours de requête au travers de plusieurs composants, via des spans (ex. HTTP GET /checkout, DB SELECT, CALL PSP /authorize). Une trace apporte le chaînage causal : où et quand la latence apparaît, qui appelle quoi, et quelle dépendance externe est en train de vous saboter. C’est aussi l’arme anti « blame game » : on voit noir sur blanc si le problème vient du service A, du cache, de la base, d’un appel réseau, ou d’un fournisseur.

Deux points qui font souvent la différence entre “on a des traces” et “on comprend vraiment” :

• Propagation de contexte partout : HTTP oui, mais aussi files (Kafka/RabbitMQ), tâches asynchrones, cron, workers. Sans propagation, vous cassez la chaîne et vous retombez sur du debug local.
• Attributs utiles et stables : service.name, service.version, deployment.environment, http.route, db.system, error.type, et quelques attributs métier non sensibles (ex. payment.method, feature_flag.*, cart.value_bucket).

Enfin, la plupart des équipes découvrent tardivement que les traces ne sont pas gratuites : le sampling fait partie du design, pas de l’optimisation de fin de projet. (On y revient plus bas.)

Logs corrélés : la preuve textuelle (et l’anti “grep dans le noir”)

Les logs restent utiles pour le détail (erreur métier, stacktrace, message précis), à condition d’être structurés (JSON), et surtout corrélés. La corrélation repose sur la propagation de contexte : un trace_id et un span_id injectés dans les logs, pour pouvoir pivoter d’un log vers une trace, puis vers des métriques. Le standard côté propagation HTTP est le W3C Trace Context :

“This specification defines standard HTTP headers and a value format to propagate context information that enables distributed tracing scenarios.” — W3C Trace Context : https://www.w3.org/TR/trace-context/

Quelques pratiques simples qui évitent le “grep dans le noir” :

• Un champ severity/level normalisé (et pas 12 variantes).
• Des événements métiers explicites (ex. payment_authorization_failed) plutôt qu’un message ambigu.
• Un identifiant de requête stable (ici le trace_id) présent à tous les niveaux.
• Des garde-fous RGPD : pas de PII en clair dans les logs “par défaut”, pas de payload complet de carte/paiement, pas d’adresses email en attribut de trace.

Si vous n’avez pas cette « colle », vous avez juste trois silos de données qui se regardent de loin, comme des services dans une orga qui ne se parle pas.

Déployer OpenTelemetry proprement : Collector, pipelines, sampling et maîtrise des coûts

La pièce maîtresse en prod, c’est souvent OpenTelemetry Collector : un agent/gateway vendor-agnostic qui reçoit OTLP (gRPC/HTTP), applique des processeurs (batch, memory limiter, filtering, tail sampling…) et exporte vers un ou plusieurs backends. Le Collector se déploie typiquement : (1) en DaemonSet sur Kubernetes pour capter localement, (2) en Gateway central pour mutualiser les exports et appliquer des politiques, ou (3) en sidecar quand vous adorez la complexité (personne n’adore vraiment).

Un pipeline réaliste doit traiter trois enjeux : fiabilité, coût, valeur.

• Fiabilité : backpressure, files/queues, retries, compression, timeouts, haute dispo (au moins 2 réplicas côté gateway), et chiffrement en transit (mTLS).
• Coût : réduire le volume (sampling, filtrage), limiter la cardinalité, maîtriser la rétention (surtout logs et traces).
• Valeur : enrichir la télémétrie (resource attributes service.name, deployment.environment, service.version) et normaliser les attributs via les semantic conventions OTel (référence officielle : https://opentelemetry.io/docs/specs/semconv/).

Un point opérationnel souvent sous-estimé : dimensionner et protéger le Collector, parce qu’en incident majeur… tout le monde loggue plus, tout le monde trace plus, et c’est précisément à ce moment que votre pipeline d’observabilité peut tomber si vous l’avez traité comme un “petit agent”.

Exemple minimaliste (mais pas naïf) de Collector en mode gateway, avec OTLP entrant, batch + tail sampling, et export OTLP :

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  memory_limiter:
    check_interval: 2s
    limit_percentage: 80
    spike_limit_percentage: 25
  batch:
    timeout: 5s
    send_batch_size: 2048
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: errors
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: slow
        type: latency
        latency:
          threshold_ms: 500
      - name: baseline
        type: probabilistic
        probabilistic:
          sampling_percentage: 5

exporters:
  otlphttp:
    compression: gzip

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, tail_sampling, batch]
      exporters: [otlphttp]

Deux rappels sur le sampling (pour éviter les mauvaises surprises) :

• Head sampling (décision au début) : simple et peu coûteux, mais peut rater des erreurs rares.
• Tail sampling (décision après coup) : plus “intelligent” (on garde les erreurs et les lenteurs), mais demande buffer/mémoire et une infra de collecte plus robuste.

Le sarcasme du jour : si vous ne faites pas de sampling sur un site à fort trafic, vous allez « découvrir » la facture de stockage comme on découvre une fuite d’eau… en regardant le plafond s’effondrer.

Astuce de pilotage budgétaire (sans vendre du rêve) : faites une estimation avant le déploiement global.

• Requêtes/s : 500 rps sur /checkout en période de pic
• Traces à 1 trace/requête, moyenne 15 spans/trace
• Sans sampling : 500 × 15 = 7 500 spans/s
• Avec tail sampling 5% + 100% des erreurs : vous retombez rapidement à un volume gérable tout en gardant les cas “intéressants”

Ce n’est pas “parfait”, mais c’est une base saine pour faire de l’observabilité sans transformer votre budget en brasier.

Cas d’usage e-commerce et sécurité : du panier qui rame à la tentative de fraude

Prenons un cas classique : p95 du checkout qui passe de 450 ms à 2,3 s entre 11h58 et 12h07 (période promo, évidemment). Les métriques vous diront « latence en hausse » et « erreurs 502 en hausse ». Les traces, elles, vous montreront où : par exemple une augmentation du temps sur le span POST /psp/authorize, couplée à une cascade de retries côté service payment. Et les logs corrélés (avec trace_id) expliqueront pourquoi : timeout contacting PSP + circuit breaker open + un fallback mal géré qui déclenche un recalcul de panier.

Le “bonus” quand vous avez des traces distribuées correctes : vous pouvez isoler des scénarios que les courbes seules ne révèlent pas. Exemple réaliste côté e-commerce :

• le span “PSP authorize” est stable en médiane, mais
• les timeouts explosent uniquement quand payment.method=card et feature_flag.checkout_v2=true
• et uniquement depuis une zone réseau donnée (attribut réseau, ou région de POP/CDN si vous l’avez)

Sans corrélation, vous partez sur “la prod est lente”. Avec corrélation, vous avez une hypothèse testable (et souvent un rollback ciblé).

Avec OpenTelemetry, vous pouvez mettre des attributs métier raisonnables (sans PII) : cart.value_bucket, payment.method, shipping.country, feature_flag.checkout_v2. Ça permet de segmenter : « le problème concerne 80% des paiements carte, mais seulement sur la nouvelle version checkout_v2 ». Là, on n’est plus dans l’intuition : on a une preuve et un périmètre. Et si votre infra est bancale, commencez par régler le socle (voir VPS Linux : guide de déploiement, durcissement et maintenance proactive : https://www.les-vikings.fr/article/vps-linux-guide-de-deploiement-durcissement-et-maintenance-proactive/).

Côté cybersécurité, l’observabilité n’est pas un SIEM, mais elle peut accélérer la détection et l’investigation : pics d’erreurs 401/403, changements de patterns de latence sur /login, hausse d’échecs de MFA, ou comportements suspects sur le parcours « reset password ». En combinant traces (qui montrent les appels) et logs (qui portent les événements), vous gagnez en forensic applicatif.

Concrètement, ce que vous pouvez repérer plus vite avec une instrumentation propre :

• une augmentation de 403 sur des routes d’admin (tentatives d’accès),
• un taux anormal de password_reset_requested (énumération d’emails),
• une hausse de latence avant la réponse (ex. WAF/CDN) vs dans l’app (ex. DB),
• des patterns d’appels “impossibles” dans le parcours (ex. POST /checkout sans GET /cart préalable, selon votre logique métier).

Pour une approche plus pipeline-friendly, le lien avec DevSecOps est direct (voir DevSecOps-as-a-service : intégrer la sécurité au pipeline CI/CD : https://www.les-vikings.fr/article/devsecops-as-a-service-integrer-la-securite-au-pipeline-ci-cd/ et, quand ça sent le roussi, la page Urgence cybersécurité : https://www.les-vikings.fr/groupe-vikings-technologies-tous-nos-domaines-intervention/cybersecurite-entreprise-e-commerce-web-mail/urgence-cybersecurite/).

Gouvernance & opérationnel : SLO, qualité de télémétrie, RGPD et MCO/MCS

Instrumenter, c’est bien. Instrumenter bien, c’est rare. Sans gouvernance, vous aurez des spans incohérents (/product/:id vs /product/123), des attributs divergents (env=prod vs environment=production), et des logs « error happened » (merci pour l’info). La règle : définir des conventions internes basées sur les semantic conventions OpenTelemetry, standardiser service.name, service.version, deployment.environment, et imposer des revues de télémétrie comme vous imposez des revues de code.

Une pratique simple mais efficace : traiter la télémétrie comme un contrat.

• Une PR qui ajoute une route critique ajoute aussi : métriques RED, spans clés, et logs structurés sur les erreurs.
• Une PR qui ajoute un attribut doit préciser : son type, son domaine de valeurs, et s’il contient un risque de données personnelles.
• Un service doit publier un “minimum viable telemetry” (à défaut d’être parfait).

L’exploitation sérieuse passe ensuite par des SLO (Service Level Objectives) et des SLI (indicateurs). Typiquement : disponibilité de /checkout (taux de succès), latence p95, taux d’erreurs de paiement, fraîcheur des stocks. Les métriques pilotent l’alerte, les traces pilotent l’enquête, et les logs documentent l’événement. C’est exactement le genre de discipline qui s’inscrit dans un cadre MCO/MCS : durcir, maintenir, surveiller, corriger avant l’incendie (voir la page MCO/MCS – Maintien en Conditions Opérationnelles / Maintien en Conditions de Sécurité : https://www.les-vikings.fr/groupe-vikings-technologies-tous-nos-domaines-intervention/entreprise-maintenance-preventive-wordpress-prestashop-magento-tma-e-commerce/mco-mcs-maintien-en-conditions-operationnelles-maintien-en-conditions-de-securite/).

Dernier point, et non des moindres : RGPD / privacy. OpenTelemetry facilite la corrélation, donc il facilite aussi… les erreurs de conformité si vous logguez n’importe quoi. Évitez la PII dans les attributs (emails, noms, adresses), anonymisez/hashez si besoin, et appliquez des politiques de rétention adaptées (les traces « debug » n’ont pas vocation à vivre 18 mois). Sur les environnements sensibles, chiffrez en transit (mTLS OTLP), segmentez les exports, et traitez l’observabilité comme une brique critique de votre surface d’attaque — au même titre que l’hébergement (voir Hébergement informatique sécurisé : meilleures pratiques pour les professionnels : https://www.les-vikings.fr/article/hebergement-informatique-securise-meilleures-pratiques-pour-les-professionnels/).

Pour cadrer “proprement” côté France/UE, un point d’attention concret : où partent vos données d’observabilité (logs et traces peuvent contenir des éléments sensibles, même sans PII explicite). Si vous externalisez le backend hors UE, documentez-le, et adaptez vos mesures (contrats, chiffrement, contrôle d’accès, rétention). En complément, le Guide de la sécurité des données personnelles de la CNIL est une référence utile pour poser des bases de sécurité (journalisation, contrôle d’accès, etc.) : https://www.cnil.fr/fr/guide-de-la-securite-des-donnees-personnelles

Mise en route réaliste : le plan en 10 jours (pas en 10 slides)

Jour 1–2 : choisissez un périmètre qui fait mal (checkout, recherche, authentification) et un backend cible (même temporaire). L’objectif n’est pas de « tout tracer », mais de prouver la valeur sur un flux critique. Si vous n’avez aucun service catalogue, commencez par un point d’entrée HTTP et une base de données : c’est déjà suffisant pour sortir des traces utiles.

À livrer à la fin du jour 2 :

• une liste de parcours “critiques business” (ex. GET /search, POST /checkout)
• 2–3 questions d’incident que vous voulez résoudre (ex. “où part la latence ?”, “quelle dépendance explose ?”)
• une convention minimale d’attributs (même si elle évolue ensuite)

Jour 3–6 : instrumentez proprement un service (SDK OTel), ajoutez propagation W3C, et mettez un Collector. Travaillez vos attributs : http.route plutôt que http.target, db.system, net.peer.name, error.type. Ajoutez des métriques RED (Rate, Errors, Duration) par route et service. Puis corrélez les logs (logger JSON + injection du trace_id). À ce stade, vous avez déjà gagné : la prochaine panne ne sera plus un escape game.

Petit “test de qualité” en fin de jour 6 : sur une requête de bout en bout, pouvez-vous pivoter en moins de 2 minutes :

• alerte (métrique) → trace lente/erreur → logs associés au trace_id → dépendance fautive

Si non, ce n’est pas grave : ça indique juste que la colle (propagation, attributs, logs structurés) est encore incomplète.

Jour 7–10 : mettez des garde-fous. Tail sampling sur erreurs/latences, filtrage de logs bruyants, conventions d’attributs, et surtout un premier SLO. Ensuite seulement, industrialisez (déploiements, GitOps, durcissement réseau). Et si vous voulez éviter que l’observabilité finisse comme un projet « PoC éternel », rattachez-la à des engagements opérationnels et à une vraie démarche de maintenance (la TMA – Tierce Maintenance Applicative est un cadre naturel quand vous devez faire évoluer instrumentation, pipelines et backends dans la durée : https://www.les-vikings.fr/groupe-vikings-technologies-tous-nos-domaines-intervention/entreprise-maintenance-preventive-wordpress-prestashop-magento-tma-e-commerce/tma-tierce-maintenance-applicative/).

Unifier métriques, traces et logs pour l’observabilité avec OpenTelemetry, ce n’est pas « ajouter des outils ». C’est accepter une idée radicale : en production, les opinions ne valent rien face à une trace corrélée, un histogramme et un log structuré. Oui, c’est moins glamour qu’un redesign. Mais c’est nettement plus rentable quand votre site rame un vendredi à 18h.