OpenTelemetry a atteint la maturité de production — Les équipes découvrent désormais ce que l'observabilité coûte réellement

La spécification de la traçabilité d'OpenTelemetry est devenue stable en 2021. Celle des métriques a suivi en 2023. Début 2025, OTel est le second projet CNCF le plus actif en nombre de contributeurs, derrière Kubernetes. Tous les principaux backends d’observabilité — Datadog, New Relic, Honeycomb, Grafana, Dynatrace et AWS CloudWatch — acceptent désormais nativement les données OTel. L’enquête CNCF 2024 a révélé que 44 % des organisations utilisent OTel en production, contre 27 % l’année précédente. Il s’agit d’une réelle vélocité d’adoption, et non d’un bruit statistique.

Ce que ces chiffres masquent, c’est la réalité opérationnelle à laquelle les équipes sont confrontées lorsqu’elles activent OTel dans un environnement de production sérieux : le volume de données est énorme, et le coût de stockage, d’interrogation et d’alertage augmente plus vite que le système lui-même.

Le problème de la cardinalité en termes concrets

La cardinalité, dans le contexte de l’observabilité, désigne le nombre de séries temporelles uniques que votre système de métriques doit suivre. Un seul point d’entrée HTTP instrumenté avec OTel peut émettre une span pour chaque requête comportant des attributs comme http.method, http.status_code, http.route, http.target, ainsi qu’une balise personnalisée user_id ajoutée par le développeur. Dès que vous incluez user_id dans une métrique (pas seulement dans une trace), votre cardinalité explose : au lieu de quelques séries temporelles pour ce point d’entrée, vous avez désormais une série temporelle par utilisateur l’ayant jamais sollicité.