Devfest Nantes 2023: Observability With Opentelemetry

Cet article est un extrait de la conférence que j’ai donnée lors du DevFest Nantes, en octobre 2023. Cette conférence avait pour objectif d’introduire le projet OpenTelemetry et de montrer comment il a transformé ma manière d’appréhender le monitoring applicatif.

Le cauchemar du “log manquant” en production

On a tous connu ce moment-là : une panne critique casse la production, les alertes se mettent à hurler, et la pression monte. On ouvre les outils de monitoring, et on se rend compte trop tard qu’il manque la seule ligne de log qui aurait permis de comprendre la cause racine.

Instrumenter manuellement un système de 50 microservices après coup, c’est presque impossible. Et ça finit toujours par la même chose : on publie un correctif “à l’aveugle” juste pour ajouter de la télémétrie, et on perd des heures à diagnostiquer ce qui aurait pu être vu dès le départ.

L’observabilité, c’est vos yeux sur le système.

Le vrai enjeu, c’est comprendre l’état interne d’un système complexe à partir de ses signaux externes, sans avoir à connaître à l’avance tous les rouages. Dans les architectures distribuées, le problème n’est plus seulement de surveiller ce qu’on connaît. C’est aussi de repérer les comportements émergents, ceux qu’on n’avait pas prévus et qui finissent par créer la panne.

L’observabilité n’est plus seulement une affaire de logs et de métriques

Pendant des années, on a vécu avec les deux piliers classiques : logs et métriques. C’était simple, et ça a bien servi son temps. Mais cette vision est dépassée.

Les logs traditionnels, même structurés en JSON , ne suffisent plus dans les environnements modernes. Ils manquent souvent de sémantique et de corrélation native. On finit alors à traduire à la main des données entre services, ce qui coûte du temps et de l’attention sans rien apporter au vrai problème métier.

La vraie révolution, c’est la trace distribuée. Elle apporte enfin la colle sémantique qui manque à tout ça :

• Un Span : l’unité de travail atomique, comme une requête SQL ou un appel API . Chaque span porte des attributs standardisés, par exemple http.response.status_code.
• Une Trace : la vue d’ensemble du parcours utilisateur. Elle relie les spans entre eux pour former un graphe orienté, ce qui permet de voir les exécutions parallèles et séquentielles.

Les logs textuels isolés ne peuvent pas faire ça.

OpenTelemetry : le standard de-facto

Après des années de guerre de chapelles entre OpenTracing et OpenCensus, l’industrie a fini par converger vers un seul projet en 2019 : OpenTelemetry (OTel). Sous l’égide de la CNCF , il est aujourd’hui le deuxième projet le plus actif après Kubernetes.

Contrairement à des solutions propriétaires, OTel est un cadre de collecte neutre. Le standard le dit assez clairement :

“OpenTelemetry s’arrête vraiment à cette étape-là [la collecte]… il n’est pas prévu pour le stockage ou la requête.”

Cette neutralité évite le “vendor lock-in”. On peut envoyer les flux vers Jaeger, Prometheus, ou encore vers une solution commerciale comme Datadog, sans toucher au code source.

Le secret est le protocole OTLP (OpenTelemetry Protocol). Basé sur gRPC et ProtoBuf , il remplace les anciens flux UDP instables par une transmission binaire compressée, plus efficace et mieux adaptée au passage à l’échelle.

Semantic Conventions

La vraie puissance d’OTel, c’est dans ses Semantic Conventions. Plutôt que de laisser chaque équipe inventer ses propres champs au hasard, avec des noms comme user_id et uid, OTel impose un vocabulaire partagé.

Standardiser des attributs comme http.request.method ou url.full réduit considérablement le frottement quand on debugge entre équipes. Et ça ne s’arrête pas au simple nommage : la donnée a une signification commune.

Chez des entreprises comme Decathlon, cette logique va encore plus loin. Les conventions sémantiques sont alignées avec les définitions métiers. Des attributs spécifiques comme dkt.store.id ou dkt.cart.id permettent à la télémétrie de parler le même langage que le catalogue de données de l’entreprise.

Pour industrialiser ce niveau de rigueur, l’outil OpenTelemetry Weaver automatise la génération de code et de documentation à partir de fichiers YAML . La gouvernance ne repose plus sur des documents statiques, mais sur un workflow “as code” : proposition, revue, validation, publication.

La “magie” de l’auto-instrumentation

L’adoption de l’observabilité est souvent freinée par le coût de développement. OpenTelemetry règle ce problème avec l’auto-instrumentation. Grâce à des hooks techniques spécifiques à chaque language, on capture la télémétrie sans toucher à la logique métier.

Le gain est immédiat : chaque requête SQL ou appel API externe est tracé automatiquement avec ses métadonnées d’infrastructure, comme le pod Kubernetes ou le cloud provider. On évite ainsi une corvée manuelle qui ne rapporte rien à la valeur métier.

L’avenir

OpenTelemetry continue d’étendre son spectre pour couvrir l’ensemble du cycle de performance :

• Le profiling : désormais considéré comme le 4e signal, il permet d’analyser en continu la consommation CPU, mémoire et réseau via OpenTelemetry eBPF Profiler
• Real User Monitoring (RUM) & Mobile : avec le projet OpenTelemetry Android, OTel sort du backend pour capturer les freezes d’écran et la consommation de batterie.

Conclusion

Replay en vidéo de ce talk

Si vous préférez le format vidéo, le replay est également disponible sur YouTube — même en vitesse 1,5x ^^