OpenTelemetry et Prometheus en 2026 : l’interopérabilité qui devient enfin simple

Pendant longtemps, faire cohabiter OpenTelemetry et Prometheus dans la même stack d’observabilité relevait du bricolage : exporters à double emploi, noms de métriques qui ne correspondaient pas, labels à retraiter à la main. Une enquête publiée en 2026 par le projet OpenTelemetry, menée auprès de 81 utilisateurs actifs des deux écosystèmes, montre que cette friction a nettement reculé depuis 2024. Si tu hésites encore entre migrer intégralement vers OTel ou garder ton stack Prometheus historique comme évoqué dans notre tour d’horizon Grafana 13 / Prometheus 3 / OpenTelemetry, voici ce que dit ce retour terrain — et comment configurer l’interopérabilité concrètement sur ton cluster.

Ce que révèle l’enquête 2026

Le constat principal : la coexistence des deux écosystèmes est devenue nettement plus simple, et la tendance de fond n’est pas la migration totale vers l’un ou l’autre, mais la cohabitation assumée.

• Facilité d’usage perçue : la note moyenne passe de 3,1 à 3,6 sur 5 entre 2024 et 2026 ; la part des répondants trouvant l’intégration difficile chute de 29 % à 10 %, et plus personne ne la juge « très difficile » (contre 7 % en 2024)
• Instrumentation infra : 72 % utilisent encore des exporters Prometheus classiques, 57 % des receivers OTel — et près de la moitié des répondants font tourner les deux en parallèle plutôt que de migrer intégralement
• Instrumentation applicative : les SDK OTel sont en tête avec 65 % d’adoption, devant les SDK Prometheus natifs (52 %) ; 41 % des répondants utilisent exclusivement l’instrumentation OTel
• Traitement des données : 53 % passent par l’OpenTelemetry Collector open source, 54 % gardent des règles de relabeling Prometheus ; 65 % déclarent maintenir une stack « vanilla » sans surcouche propriétaire

Les points de friction qui restent, d’après les retours de la communauté : l’unification des modèles de données entre les deux mondes, la gestion des attributs de ressource (resource attributes), et les frictions de nommage entre conventions Prometheus et sémantique OTel.

Comment ça marche concrètement : Prometheus comme backend OTLP

Depuis Prometheus 3.x, le serveur peut recevoir directement des métriques au format OTLP, sans passer par un collector intermédiaire pour le stockage final. La documentation officielle Prometheus décrit la configuration minimale :

# Démarrer Prometheus avec le receiver OTLP activé
# (désactivé par défaut pour des raisons de sécurité)
prometheus --web.enable-otlp-receiver

# Côté application ou collector, pointer vers l'endpoint Prometheus
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://localhost:9090/api/v1/otlp

Le chemin /v1/metrics est ajouté automatiquement à l’URL — pas besoin de le préciser toi-même dans la variable d’environnement.

UTF-8 et noms de métriques

Depuis la version 3.x, Prometheus supporte l’UTF-8 dans les noms de métriques et de labels, ce qui règle une bonne partie des frictions de nommage évoquées dans l’enquête. Tu peux choisir entre quatre stratégies de traduction (translation_strategy), dont NoTranslation et NoUTF8EscapingWithSuffixes qui préservent les caractères UTF-8 des métriques OTel sans les réencoder — utile si tes métriques utilisent des points ou des caractères non-ASCII issus des conventions sémantiques OTel.

Attributs de ressource : à promouvoir en labels

Par défaut, les attributs de ressource OTel (service.name, service.instance.id, k8s.namespace.name…) ne sont pas automatiquement exposés comme labels Prometheus interrogeables en PromQL. La documentation recommande de les promouvoir explicitement — sans ça, tu perds une bonne partie de la valeur du contexte OTel une fois les métriques stockées côté Prometheus.

Temporalité delta : encore expérimental

OpenTelemetry gère nativement la temporalité delta pour certaines métriques, alors que Prometheus attend du cumulatif. Un processeur delta-to-cumulative existe côté collector, mais reste marqué comme expérimental et nécessite d’activer le feature flag otlp-deltatocumulative — à tester en environnement de non-prod avant de t’y fier en production. Le détail des transformations appliquées à l’export OTLP vers Prometheus est documenté sur la page de compatibilité officielle OpenTelemetry.

Faut-il migrer entièrement vers OTel, ou garder Prometheus ?

Le message de l’enquête est clair : la cohabitation n’est plus une solution de transition bancale, c’est devenu un choix d’architecture assumé par une majorité de répondants. Concrètement :

• Si ton parc applicatif est déjà majoritairement instrumenté en Prometheus (exporters, client libraries), le receiver OTLP de Prometheus 3.x te permet d’absorber progressivement les nouvelles applications instrumentées en OTel sans tout réécrire
• Si tu démarres un nouveau projet ou migres un service, l’instrumentation OTel-native (SDK OTel) te donne la portabilité vers d’autres backends si tu changes un jour de stack d’observabilité
• Dans tous les cas, prévois du temps pour la promotion des attributs de ressource en labels — c’est le point qui casse le plus souvent les dashboards PromQL existants après une migration partielle

Si tu utilises déjà l’instrumentation zero-code via eBPF (OBI) pour tes applications non instrumentées manuellement, cette interopérabilité Prometheus/OTLP s’applique de la même façon en aval — le format de sortie reste OTLP, quelle que soit la méthode de collecte utilisée en amont.

FAQ

Le receiver OTLP de Prometheus remplace-t-il l’OpenTelemetry Collector ?

Non. Le receiver OTLP permet à Prometheus de recevoir directement des métriques au format OTLP en fin de chaîne, mais l’OpenTelemetry Collector reste utile pour le traitement intermédiaire (filtrage, enrichissement, routage vers plusieurs backends) — d’ailleurs 53 % des répondants de l’enquête continuent à s’en servir même avec un backend Prometheus.

Dois-je réinstrumenter toutes mes applications pour profiter de cette interopérabilité ?

Non, c’est justement le point de l’enquête : près de la moitié des organisations font tourner exporters Prometheus classiques et receivers OTel en parallèle, sans migration forcée.

Le support OTLP de Prometheus est-il activé par défaut ?

Non, il faut explicitement démarrer Prometheus avec le flag --web.enable-otlp-receiver — désactivé par défaut pour limiter la surface d’exposition du endpoint.

En bref

L’interopérabilité OTel/Prometheus est passée d’un point de friction reconnu à un fonctionnement quasi transparent pour la majorité des équipes qui l’utilisent en 2026 — la cohabitation des deux écosystèmes, plutôt que le tout-ou-rien, est en train de devenir la norme. Si ta stack actuelle jongle encore entre exporters Prometheus et efforts d’instrumentation OTel séparés, active le receiver OTLP sur un environnement de test cette semaine et vérifie la promotion de tes attributs de ressource en labels avant de généraliser.