Publié le 20 octobre 2025 à 22h02. Google Cloud a activé la prise en charge native du protocole OpenTelemetry (OTLP) pour ses services d’observabilité, simplifiant ainsi l’ingestion des données de traçage et réduisant la dépendance vis-à-vis des fournisseurs tiers.
Google Cloud permet désormais aux ingénieurs d’utiliser Google Cloud Observability, et plus précisément Cloud Trace, pour ingérer des données via le protocole OpenTelemetry (OTLP). Cette intégration permet une ingestion quasi instantanée et une plus grande indépendance vis-à-vis des fournisseurs pour les données de traçage.
Google recommande désormais l’utilisation d’OTLP pour l’envoi des données de traçage, en particulier pour les utilisateurs anticipant de gros volumes de données, notamment en association avec le Collecteur OpenTelemetry. L’adoption de ce protocole a nécessité un travail d’ingénierie important, et la prise en charge d’OTLP pour les métriques et les journaux varie selon le produit et la région.
Cette démarche s’inscrit dans une tendance plus large, avec des acteurs majeurs comme Microsoft Azure et Amazon Web Services qui prennent également en charge OTLP sans nécessiter d’outils tiers. Azure propose Azure Monitor OTel, AWS propose AWS Distro for OpenTelemetry et l’ingestion X-Ray OTLP.
Les avantages clés de l’intégration native d’OTLP
Le protocole OTLP est conçu pour transporter les données de télémétrie d’une source à une destination, indépendamment du fournisseur. Selon la documentation Google, la prise en charge d’OTLP pour Google Cloud Observability réduit la nécessité pour les développeurs d’intégrer des exportateurs spécifiques à chaque fournisseur. Cela garantit un pipeline de télémétrie standardisé et interopérable entre les différents systèmes d’observabilité compatibles OTLP.
Google explique que cette approche élimine une étape de conversion, déplaçant la complexité du côté client (le collecteur) vers le backend cloud.
Ce diagramme illustre comment les configurations actuelles et basées sur des collecteurs peuvent utiliser les exportateurs natifs du protocole OpenTelemetry pour communiquer des données de télémétrie. (Source : Google Cloud)
Dans un article de blog publié en septembre, Sujay Salomon et Keith Chen, chefs de produit chez Google Cloud, ont souligné les avantages de l’intégration OTLP pour l’envoi des données de traçage :
- Pipelines de télémétrie indépendants du fournisseur : L’utilisation d’exportateurs OTLP natifs élimine le besoin d’exportateurs spécifiques aux fournisseurs dans les pipelines de télémétrie.
- Intégrité des données de télémétrie : Les données de télémétrie conservent le modèle de données OpenTelemetry pendant la transmission et le stockage, sans transformation vers des formats propriétaires.
- Interopérabilité avec les outils d’observabilité : Possibilité d’envoyer des données de télémétrie à plusieurs backends d’observabilité compatibles OTLP sans exportateurs OTel supplémentaires.
- Réduction de la complexité et de l’utilisation des ressources : Possibilité de déplacer la logique de traitement de la télémétrie vers le backend d’observabilité, réduisant ainsi la surcharge de traitement côté client.
Un nouveau rôle pour le Collecteur OpenTelemetry
Page d’exploration de trace dans Cloud Trace, avec les champs utilisant la sémantique OpenTelemetry mis en surbrillance. (Source : Google Cloud)
L’ajout récent de l’ingestion OTLP native dans Google Cloud Observability modifie fondamentalement le rôle du Collecteur OpenTelemetry. L’élimination de l’étape de conversion simplifie la configuration du collecteur pour l’ingestion des données de traçage du backend Google Cloud Observability.
Le Collecteur OpenTelemetry est utilisé pour filtrer la télémétrie, notamment pour des raisons de sécurité, dans les environnements impliquant plusieurs applications ou microservices. Avant cette annonce, les utilisateurs pouvaient utiliser des agents d’observabilité tels que Fluent Bit ou Vector pour ingérer des données de traçage avec Google Cloud Observability.
Le rôle des agents d’observabilité
Les agents d’observabilité jouent un rôle essentiel dans le fonctionnement de l’observabilité, en gérant le transport des données pour garantir leur précision. Ils assurent la collecte, le traitement et le transport des données, aidant à identifier et à résoudre les problèmes de performances avant qu’ils ne deviennent critiques.
Un agent d’observabilité collecte les données provenant de diverses sources et les envoie à un point final, par exemple pour une visualisation avec Grafana. Il peut être configuré pour collecter des journaux, des traces et des métriques.
Il est possible de ne pas utiliser d’agent d’observabilité si l’application est déjà instrumentée pour envoyer directement les données de télémétrie à la plateforme d’observabilité. Les collecteurs sont utiles pour surveiller les applications qui ne peuvent pas être instrumentées.
Sans collecteur d’observabilité, chaque backend ou chaque utilisateur doit être configuré séparément, ce qui peut être fastidieux. Un collecteur d’observabilité sert de point de terminaison unique pour tous les microservices, simplifiant l’accès et la gestion via une plateforme comme Grafana. Bien que Grafana propose des alternatives sans collecteur OpenTelemetry, ce dernier simplifie considérablement le processus.
Prise en charge d’OTLP pour les journaux et les métriques
L’annonce de Google Cloud concerne actuellement OpenTelemetry pour le traçage. La prise en charge des journaux et des métriques, en particulier des journaux, est encore en cours en raison de défis liés à la mise en œuvre des contrôles d’accès basés sur les rôles (RBAC), de la conformité et des efforts d’ingénierie nécessaires.
Actuellement, Azure et Google Cloud prennent directement en charge l’ingestion de métriques via OTLP. AWS utilise le collecteur AWS Distro for OpenTelemetry (ADOT). AWS et Google Cloud ne disposent pas d’ingestion directe de journaux OTLP largement disponible, tandis que l’ingestion de journaux Azure via OTLP reste limitée.
Cette évolution s’inscrit dans une course continue à l’intégration et à l’amélioration de l’ingestion des données d’observabilité entre les fournisseurs de cloud, comme l’ont souligné Solomon et Chen de Google dans leur blog.
Selon Solomon et Chen, cette décision est “la pierre angulaire de notre stratégie visant à simplifier la gestion de la télémétrie et à favoriser un environnement cloud ouvert. Nous comprenons que dans les environnements cloud complexes d’aujourd’hui, la gestion des données de télémétrie sur des systèmes disparates, des formats de données incohérents et de vastes volumes d’informations peut entraîner des lacunes d’observabilité et une augmentation des frais opérationnels.”
“Nous nous engageons à rationaliser votre pipeline de télémétrie, en commençant par nous concentrer sur l’ingestion OTLP native pour tous les types de télémétrie afin que vous puissiez envoyer de manière transparente vos données à Google Cloud Observability. Cela contribuera à favoriser une véritable neutralité et interopérabilité des fournisseurs, en éliminant le besoin de conversions complexes ou d’agents spécifiques au fournisseur.”
Sur le même sujet
