Tu veux « voir » ce qui se passe dans tes apps. Pas juste empiler des dashboards, des logs, et au final… ne rien comprendre quand ça casse à 2 h du matin.
OpenTelemetry, c’est justement l’idée inverse : instrumenter une fois, récupérer des signaux propres, corrélés, actionnables. Et arrêter le bruit.
Dans cet article (version pratique, sans blabla), on fait un setup simple en 60 minutes pour obtenir des traces vraiment utiles. Je publie ce genre de guides sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com) quand je tombe sur un sujet qui mérite un mode d’emploi clair.
Ce qu’on vise en 60 minutes
Avant d’installer quoi que ce soit, on définit la sortie attendue. Sinon tu vas collecter « tout »… et donc rien.
Objectif minimal :
- une trace par requête HTTP
- des spans pertinents (DB, appels externes, jobs)
- propagation du trace id entre services
- sampling pour ne pas exploser les coûts
- export vers un backend (tempo, jaeger, otel collector, etc.)
règle d’or : si tu ne sais pas quelle question tu veux pouvoir répondre, tu n’as pas besoin d’observabilité. Tu as besoin de clarté.
Les 3 signaux OpenTelemetry (mais on commence par un seul)
OpenTelemetry gère :
- Traces : le chemin d’une requête, service par service
- Metrics : agrégats, séries temporelles
- Logs : événements
Ici on se concentre sur les traces. Parce que c’est ce qui fait gagner le plus de temps quand tu débogues un système distribué.
Étape 1 : choisir une architecture simple
Pour éviter le piège « je connecte le SDK direct à mon APM », pars sur ce pattern :
- application(s) avec SDK OpenTelemetry
- OpenTelemetry Collector au milieu
- backend d’observabilité au bout
Le collector te sert de tampon, de routeur, et surtout de filtre. C’est lui qui t’aide à réduire le bruit.
Étape 2 : installer un collector en 5 minutes (docker)
Un docker-compose.yml minimaliste, collector en réception OTLP :
yaml services: otel-collector: image: otel/opentelemetry-collector-contrib:latest command: ["--config=/etc/otelcol/config.yaml"] volumes: - ./otelcol-config.yaml:/etc/otelcol/config.yaml ports: - "4317:4317" # OTLP gRPC - "4318:4318" # OTLP HTTP
Et un otelcol-config.yaml simple qui reçoit et log ce qu’il reçoit (pour vérifier que ça marche) :
yaml receivers: otlp: protocols: grpc: http:
exporters: logging: verbosity: detailed
service: pipelines: traces: receivers: [otlp] exporters: [logging]
Là, tu as déjà un « drain » pour valider l’instrumentation. Pas sexy, mais ultra utile au début.
Étape 3 : instrumenter une app (exemple Node.js express)
Installe :
bash npm i @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node
@opentelemetry/exporter-trace-otlp-http
Crée tracing.js :
js const { NodeSDK } = require("@opentelemetry/sdk-node"); const { getNodeAutoInstrumentations } = require("@opentelemetry/auto-instrumentations-node"); const { OTLPTraceExporter } = require("@opentelemetry/exporter-trace-otlp-http");
const sdk = new NodeSDK({ traceExporter: new OTLPTraceExporter({ url: "http://localhost:4318/v1/traces", }), instrumentations: [getNodeAutoInstrumentations()], });
sdk.start();
Puis démarre ton serveur avec :
bash node -r ./tracing.js index.js
À ce stade, tu dois voir des traces défiler côté collector (exporter logging). Si tu ne vois rien : c’est souvent un problème d’endpoint OTLP ou un serveur qui démarre avant le SDK.
Étape 4 : rendre les traces « utiles » (le vrai sujet)
Auto instrumentation, c’est bien. Mais ça génère vite trop de spans.
Donc on impose 4 règles simples.
1) nommer clairement le service
Dans OTel, un service qui s’appelle unknown_service c’est l’enfer. Ajoute une ressource service.name.
Node : via env vars :
bash export OTEL_SERVICE_NAME=api-checkout
2) ajouter 2 ou 3 attributs qui comptent
Exemples utiles :
enduser.id(si tu as un user authentifié)http.route(route express)deployment.environment(prod, staging)
Ne mets pas d’email, pas de numéro de téléphone, pas de payload complet.
3) créer 1 span manuel sur une zone critique
Par exemple un appel externe, un calcul, une requête lente. Un span manuel bien placé vaut 200 spans automatiques.
4) sampling, sinon tu vas souffrir
En dev : 100 % OK.
En prod : commence petit. 1 % à 10 % selon le trafic.
Par env var (selon SDK) :
bash export OTEL_TRACES_SAMPLER=parentbased_traceidratio export OTEL_TRACES_SAMPLER_ARG=0.05
Étape 5 : filtrer le bruit côté collector (simple et puissant)
Tu peux ignorer certaines routes (healthcheck, metrics, etc.) au collector.
Exemple avec un processor filter (selon version contrib) : logique : drop si route = /health.
C’est exactement le genre d’endroit où tu gagnes en « signal » sans toucher au code.
Étape 6 : brancher un vrai backend (tempo ou jaeger)
Quand tu es prêt, remplace l’exporter logging par un exporter vers Jaeger, Tempo, Honeycomb, Datadog, New Relic, etc.
Le point n’est pas l’outil. Le point c’est : OTLP partout.
Checklist rapide pour savoir si tu es « bon »
Tu es bien parti si :
- tu peux prendre un
trace idd’une requête et retrouver tout le chemin - tu vois clairement les latences DB vs appels externes
- tu as moins de 30 spans « inutiles » par requête standard
- tu peux activer ou réduire le sampling sans redéployer
Conclusion (et petit rappel utile)
OpenTelemetry n’est pas compliqué. Ce qui le devient, c’est quand on collecte trop vite, trop large, trop tôt.
Commence par les traces, pose 2 ou 3 spans manuels, mets du sampling, et filtre au collector. Ensuite seulement tu ajoutes metrics et logs.
Si tu veux d’autres guides du même style (Linux, admin, growth, IA, observabilité pragmatique), j’en publie régulièrement sur Le Blog Tech Pro de Samyn-Antoy ABASSE : https://monblog-sa-abasse.blogspot.com
Questions fréquemment posées
Qu'est-ce qu'OpenTelemetry et pourquoi est-il important pour l'observabilité des applications ?
OpenTelemetry est une solution qui permet d'instrumenter une fois vos applications pour récupérer des signaux propres, corrélés et actionnables, notamment des traces, métriques et logs. Cela évite d'empiler des dashboards et logs sans comprendre ce qui se passe réellement quand un problème survient, notamment en production.
Quels sont les objectifs clés à viser lors de la mise en place d'OpenTelemetry en 60 minutes ?
Les objectifs minimaux incluent : obtenir une trace par requête HTTP, générer des spans pertinents (base de données, appels externes, jobs), assurer la propagation du trace ID entre services, appliquer un sampling pour maîtriser les coûts, et exporter les données vers un backend comme Tempo, Jaeger ou OpenTelemetry Collector.
Quels sont les trois signaux gérés par OpenTelemetry et sur lequel se concentrer en priorité ?
OpenTelemetry gère trois signaux principaux : 1) Traces – le chemin d'une requête service par service ; 2) Metrics – agrégats et séries temporelles ; 3) Logs – événements. Pour gagner du temps dans le débogage de systèmes distribués, il est conseillé de commencer par les traces.
Quelle architecture simple est recommandée pour éviter les erreurs lors de l'installation d'OpenTelemetry ?
Il est conseillé d'adopter une architecture avec vos applications instrumentées via le SDK OpenTelemetry, un OpenTelemetry Collector au milieu servant de tampon, routeur et filtre pour réduire le bruit, puis un backend d'observabilité final (Tempo, Jaeger, etc.). Cela évite de connecter directement le SDK à un APM.
Comment installer rapidement un OpenTelemetry Collector avec Docker ?
Vous pouvez utiliser un fichier docker-compose minimaliste qui lance le collector avec l'image 'otel/opentelemetry-collector-contrib:latest', expose les ports OTLP gRPC (4317) et HTTP (4318), et monte un fichier de configuration 'otelcol-config.yaml' simple recevant les traces via OTLP et exportant vers un logger pour vérifier que tout fonctionne.
Comment rendre les traces générées par OpenTelemetry vraiment utiles et éviter le bruit ?
Il faut appliquer quelques règles simples : nommer clairement le service avec la ressource 'service.name' (éviter 'unknown_service'), ajouter 2 ou 3 attributs pertinents comme 'enduser.id' ou 'http.route', contrôler la quantité de spans générés en désactivant ceux inutiles, et configurer correctement le sampling afin de ne pas surcharger ni perdre l'information essentielle.
0 Commentaires