Stack de monitoring EDI : OpenTelemetry + Grafana en pratique

Le monitoring d'un hub EDI 2026 repose sur trois piliers : OpenTelemetry pour l'instrumentation unifiée, un backend ouvert (Prometheus + Grafana stack ou équivalent), et des dashboards alignés sur les méthodes RED et USE.

Pourquoi OpenTelemetry ?

OpenTelemetry (OTel, projet CNCF graduated en 2024) est issu de la fusion d'OpenTracing et OpenCensus. Il fournit un standard d'instrumentation indépendant du backend pour les trois signaux observability (traces, metrics, logs) et un format de protocole d'export universel (OTLP). C'est devenu le standard de fait pour l'observability cloud-native en 2026.

Pour un hub EDI, OTel résout trois problèmes structuraux : (1) éviter le lock-in vendor (Datadog, New Relic, Dynatrace) — l'instrumentation reste portable ; (2) unifier l'export de traces (Jaeger, Tempo), metrics (Prometheus, Mimir) et logs (Loki, Elasticsearch) avec une seule SDK ; (3) obtenir une corrélation native entre les trois signaux (un trace ID lie un log et une métrique au même évènement métier).

Trois signaux à instrumenter

• Traces : une trace par message EDI traité. Span par étape (réception, parsing, validation, transformation, routage, ACK). Attributs sémantiques : edi.message.type, edi.message.id, edi.partner.id, edi.standard, edi.protocol. Permet de répondre instantanément à « pourquoi cette facture a-t-elle pris 4 minutes au lieu de 30s ? ».
• Metrics : agrégats temporels — count par type message, latence p50/p95/p99, success rate, in-flight messages, queue depth. Cardinalité maîtrisée (pas de label par message ID, jamais !). Exposition Prometheus /metrics ou push OTLP toutes les 15-60 secondes.
• Logs : événements discrets, structurés (JSON), avec trace ID pour corrélation. Niveau ERROR uniquement pour ce qui demande action humaine ; WARN pour situations à surveiller ; INFO pour audit ; DEBUG désactivé en prod. Retention configurable par criticité (90 jours opérationnel, 7 ans audit fiscal).

Stack cible 2026

Plusieurs combinaisons valables. Stack ouverte self-hosted :

• Application → OpenTelemetry SDK → OTel Collector (sidecar ou daemon)
• OTel Collector → Prometheus (metrics) → Mimir (long-term, multi-tenant)
• OTel Collector → Jaeger ou Tempo (traces, avec sampling tail-based)
• OTel Collector → Loki (logs structurés)
• Grafana pour visualisation des trois signaux corrélés
• Alertmanager pour routing des alertes vers PagerDuty/OpsGenie/Slack

Stack managée : Grafana Cloud, Datadog, New Relic, Dynatrace, Elastic Observability. L'avantage clé : pas d'ops sur le backend monitoring (rétention, scaling, upgrades). Le coût : facturation à la cardinalité ou au volume ingestion qui peut dépasser le coût compute du hub lui-même si non maîtrisée.

Stack hyperscaler-native : AWS CloudWatch + X-Ray, GCP Cloud Monitoring + Cloud Trace, Azure Monitor + Application Insights. Souvent plus facile pour démarrer mais moins de portabilité (lock-in).

Patterns d'instrumentation EDI

Propagation du trace ID partenaire

Le trace ID natif OTel n'est pas connu du partenaire externe. Pour relier les incidents end-to-end, propager l'identifiant fonctionnel partenaire (RFF+ON pour EDIFACT, BT-1 pour UBL, ISA13 pour X12) dans les attributs de span. Lors d'une réclamation partenaire « ma facture INV12345 n'est pas reçue », cela permet de remonter le trace complet en quelques secondes.

Span pour chaque acquittement

Modéliser l'acquittement (CONTRL, 997, MDN, NRR AS4) comme un span dérivé du span parent du message. Attributs : edi.ack.type, edi.ack.code, edi.ack.timestamp. Une latence anormale d'acquittement (typiquement > 4h) déclenche une alerte par partenaire.

Métriques RED par partenaire

Pour chaque partenaire : Rate (msg/s), Error rate (errors/total), Duration (latence p50/p95/p99). Combiné avec SLO par partenaire (« 99,5 % des messages acquittés en moins de 4h »), on génère un error budget et on alerte en cas d'épuisement.

Sampling tail-based pour traces

Sur un hub à fort débit (millions de messages/jour), tracer 100 % est trop coûteux en stockage. Le sampling head-based (random 1 % par exemple) perd les traces intéressantes (erreurs, latence élevée). Le tail-based sampling (OTel Collector ou Tempo) garde les traces complètes après évaluation : 100 % des erreurs, 100 % de la longue traîne > p95, 1 % du reste. Stockage divisé par 10-20 sans perte d'information utile.

RED + USE pour dashboards SLO

RED (Rate, Errors, Duration) — proposé par Tom Wilkie (Grafana) en 2015 — pour les services orientés requêtes. USE (Utilization, Saturation, Errors) — proposé par Brendan Gregg en 2012 — pour les ressources physiques (CPU, RAM, disque, network). Les deux méthodes sont complémentaires.

Dashboards type pour un hub EDI :

• Dashboard « Business » : messages/jour par type, success rate par partenaire, top erreurs métier, OTIF par partenaire.
• Dashboard « SLO » : error budget restant pour chaque SLO public, burn rate, projection d'épuisement.
• Dashboard « RED » : pour chaque microservice (parser, validator, router), Rate/Errors/Duration aggregées sur 5 min/1 h/24 h.
• Dashboard « USE » : CPU/mémoire/disk IOPS/network par nœud, queue depth Kafka, lag consumer.
• Dashboard « Partner SLA » : vue par partenaire avec latence, taux de succès, derniers incidents, conformité SLA contractuel.

Coût du monitoring

Sur un hub EDI traitant 10 millions de messages/mois :

• Self-hosted (Prometheus/Mimir/Tempo/Loki/Grafana) : typiquement 800-2 500 EUR/mois de compute + stockage (k8s cluster dédié), plus 0,2-0,5 ETP d'ops. Avantage : coût quasi-linéaire avec volume.
• Grafana Cloud : ~1 500-5 000 EUR/mois selon ingestion (volumes de métriques, logs, traces). Coût fixe : free tier pour démarrer.
• Datadog : typiquement 3 000-15 000 EUR/mois selon cardinalité hosts et custom metrics. Risque d'inflation sans gouvernance.

Pour aller plus loin

• Métriques EDI : SLO, error budgets, KPIs.
• Ops EDI augmentée IA — le LLM-assisted root cause analysis s'appuie sur ces signaux.
• OpenTelemetry — Semantic Conventions. opentelemetry.io
• Google SRE Workbook — chapitre 4 « Service Level Objectives ». sre.google
• Wilkie T. — The RED Method: How To Instrument Your Services, Grafana 2018.