
Observabilité moderne avec OpenTelemetry et Grafana
J’ai longtemps utilisé la stack ELK et Prometheus + Grafana séparément. Puis j’ai découvert OpenTelemetry. Voici pourquoi j’ai migré et comment j’ai intégré le tout avec Grafana.
OpenTelemetry, c’est quoi ?
OpenTelemetry (OTel) est un standard ouvert pour collecter et exporter des traces, métriques et logs (les trois piliers de l’observabilité). Un seul agent, un seul format, direction votre backend préféré.
Avant OTel, chaque service devait être instrumenté pour chaque backend :
Service A → Prometheus (métriques) + Jaeger (traces) + ELK (logs) |
Avec OTel :
Service A → OTel SDK → Collector → Grafana (métriques) + Tempo (traces) + Loki (logs) |
Architecture type
Instrumenter une app Node.js
npm install @opentelemetry/api @opentelemetry/sdk-node \ |
const { NodeSDK } = require('@opentelemetry/sdk-node'); |
C’est tout. Les traces HTTP, les requêtes DB, les calls externes sont automatiquement capturés.
OTel Collector
Le collector est le cœur du pipeline. Il reçoit, transforme et achemine les données.
receivers: |
Grafana : tout en un
Avec Grafana, plus besoin de changer de dashboard :
- Prometheus pour les métriques (CPU, RAM, latence)
- Tempo pour les traces distribuées
- Loki pour les logs
Et la killer feature : Tempo peut retrouver les traces à partir des logs Loki, grâce aux trace IDs automatiquement injectés par OTel.
Ce que ça change au quotidien
- Debug : une requête lente identifiée en 2 clics au lieu de 30 min
- Alerting : une métrique + une trace = un contexte complet
- Coût : OTel est open source, pas de licence par nœud
La stack OTel + Grafana est devenue mon réflexe pour tout nouveau projet. Le surcoût d’installation est vite rentabilisé quand vous passez de 2h à 5 min pour identifier un goulot d’étranglement.