OpenTelemetry
zero-code vs instrumentation classique, le vrai duel des métriques
Cet article est aussi disponible en anglais
L'introduction (le "pain point" ou contexte)
On a tous connu ça : une app qui rame en production, un client qui s'impatiente, et nous, devant un écran, à fouiller dans des montagnes de logs illisibles.
Mettre en place une bonne observabilité est souvent perçu comme la corvée ultime. Mais avec OpenTelemetry (OTel), la donne change. On se retrouve face à un choix concret : opter pour l'efficacité du "zero-code" (auto-instrumentation) ou mettre les mains dans le code avec une approche classique (manuelle) pour extraire la vraie valeur métier.
Pourquoi est-ce devenu indispensable et jusqu'où peut-on aller ? Décryptage.
L'auto-instrumentation (zero-code) : la couverture du premier jour
Le grand avantage du zero-code, c'est la promesse d'obtenir une observabilité fonctionnelle sans toucher à la moindre ligne de votre logique métier.
🐍 Exemple concret sur Python (le plus mature)
Python utilise un système d'agent basé sur du monkey patching : au démarrage, cet agent modifie dynamiquement les bibliothèques que vous utilisez. C'est une méthode redoutablement efficace.
Voici les étapes d'installation :
# 1. Installation (une seule fois)
pip install opentelemetry-distro opentelemetry-exporter-otlp
# 2. Installation automatique des instrumentations pour vos libs (Flask, FastAPI, requests, psycopg2, redis, kafka, etc.)
opentelemetry-bootstrap -a install
# 3. Lancement de votre app avec l'agent (zero-code pur)
export OTEL_SERVICE_NAME=mon-app-python
export OTEL_TRACES_EXPORTER=otlp
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=http://ton-collector:4317 # ou votre backend (Tempo, Jaeger, Signoz, etc.)
opentelemetry-instrument python app.py
# ou pour Flask :
opentelemetry-instrument flask run
Et voilà ! L’application app.py tournera sans aucun changement de code.
Ce que vous récupérez out-of-the-box :
- Traces distribuées (Spans HTTP serveur et client, bases de données, queues, propagation automatique du contexte).
- Métriques techniques (Nombre de requêtes HTTP, latence, erreurs, metrics système/runtime).
- Logs enrichis par les identifiants de corrélation (
trace_idouspan_id).
Les limites : L'approche excelle sur la couche technique, mais s'arrête aux portes de votre logique métier. Vous n’aurez aucun span pour une fonction complexe calculate_price(). De plus, il est impossible d'y attacher des variables cruciales comme user_tier sans utiliser des hooks avancés ou repasser à une approche manuelle.
Exemple concret sur Rust (l'approche moderne 🦀)
Rust est un langage compilé, ce qui rend le monkey patching dynamique beaucoup moins naturel. Mais l’écosystème évolue rapidement.
L'approche zero-code réelle (OpenTelemetry eBPF - OBI) :
C’est un agent eBPF qui tourne au niveau du noyau Linux. Il instrumente vos appels sans toucher le binaire Rust, sans recompilation, et sans dépendance additionnelle dans le Cargo.toml.
- Avantages : Très léger, zero downtime, parfait pour tracer les flux HTTP/gRPC entrants et sortants.
- Limites : Moins profond. Pas de spans pour vos fonctions internes, ni d'accès facile aux variables métier.
L'approche « presque zero-code » (Middleware de framework) :
Pour des frameworks comme Actix-web ou Axum, ajouter un middleware ne demande que quelques lignes de configuration au démarrage :
# Cargo.toml
[dependencies]
opentelemetry = { version = "0.28", features = ["trace"] }
opentelemetry_sdk = { version = "0.28", features = ["rt-tokio"] }
opentelemetry-otlp = "0.28"
opentelemetry-instrumentation-actix-web = "0.1"
tracing-opentelemetry = "0.1"
Le classique (manuel) : quand la technique rencontre le "business"
Peut-on obtenir un dashboard affichant le "nombre de commandes validées > 100€" uniquement avec du zero-code ? La réponse est non.
C’est là que l'instrumentation manuelle prend tout son sens. Instancier des métriques (Counter, Histogram, Gauge) directement dans le code permet de lier directement les performances applicatives aux objectifs de l'entreprise.
Commencez toujours par le zero-code pour sécuriser 80% de couverture instantanément. Puis, instrumentez uniquement vos chemins critiques métiers manuellement. L'effort est minime pour un retour sur investissement maximal.
💡 La touche Opsvox : l'observabilité pour anticiper et construire l'avenir
Chez Opsvox, nous mettons systématiquement en place la base technique (métriques système, logs globaux, traces réseau) pour nos clients. Mais on ne s'arrête pas là.
Ce qui différencie le fait de "subir" sa production de celui d'en maîtriser l'évolution, c'est l'intégration de métriques ciblées. En ajoutant cette couche d'instrumentation manuelle, nous ne voyons plus seulement "un pic RAM ou CPU", mais nous identifions instantanément "quelle typologie d'opération" génère cette charge.
Cela nous donne les clés pour anticiper le dimensionnement, assurer une Haute Disponibilité pertinente et planifier un scaling intelligent. C'est l'essence même de notre maîtrise opérationnelle.
Le verdict du terrain
OpenTelemetry unifie enfin la manière dont nous observons nos systèmes. Le zero-code est l'outil parfait pour amorcer le monitoring : il offre des métriques techniques solides, vitales pour les équipes d'infrastructure. Mais pour créer de la véritable valeur et comprendre finement le comportement de vos utilisateurs, l'instrumentation manuelle reste incontournable.
Alliez les deux : commencez par l'auto-instrumentation, puis complétez de façon chirurgicale par du code là où c'est critique. Plus rien ne vous échappera en production.