Cloud Trace est un système de traçage distribué pour Google Cloudqui suit la latence des requêtes et vous aide à résoudre les goulots d'étranglement des performances dans les services et les applications d'IA générative. En collectant les données de latence des services et des applications instrumentéesGoogle Cloud , Trace vous aide à comprendre comment les requêtes sont traitées dans une architecture de microservices et à identifier les journaux pertinents.
Avec Trace, vous pouvez mesurer la latence des requêtes de bout en bout, comparer les tendances de performances au fil du temps et identifier les dépendances en aval qui provoquent des retards. Pour découvrir comment corréler des traces et des journaux, consultez Utiliser conjointement les traces et les journaux pour analyser l'origine des problèmes.
Environnements compatibles
Trace s'exécute sous Linux dans les environnements suivants :
- Compute Engine
- Google Kubernetes Engine (GKE)
- Apigee (version Preview publique)
- Environnement flexible App Engine
- Environnement standard App Engine
- Cloud Run
- Cloud Service Mesh
- Insights sur les requêtes Cloud SQL
- Environnements non-Google Cloud
Composants
Trace est un client de traçage qui collecte des traces et les envoie à votre projet Google Cloud . Vous pouvez ensuite utiliser la consoleGoogle Cloud pour afficher et analyser les données collectées par le client de traçage. Pour en savoir plus sur le modèle de données, consultez Traces et segments.
Client de traçage
Un client de traçage collecte les données de latence et de segment de votre application, puis les exporte vers votre projet Google Cloud . En fonction de votre environnement et de vos exigences, vous pouvez collecter des données de trace automatiquement ou manuellement en instrumentant le code de votre application.
Interface de traçage
Pour afficher et analyser vos données de segment, vous pouvez utiliser les pages Explorateur de traces et Analyse de l'observabilité de la consoleGoogle Cloud :
Explorateur Trace : affiche des informations agrégées sur vos données de trace et vous permet d'examiner des traces individuelles en détail. Les données de latence agrégées sont affichées sur une carte de densité, que vous pouvez explorer avec votre pointeur. Pour limiter les données affichées, vous pouvez ajouter des filtres. Vous pouvez également afficher et explorer des segments et des traces individuels :
- Pour savoir comment afficher les données de trace stockées dans plusieurs projets, consultez Créer et gérer un champ d'application de trace.
- Pour en savoir plus sur le filtrage et l'affichage de vos données de trace, consultez Rechercher et explorer des traces.
Analyse de l'observabilité : fournit une interface de requête SQL. Vos requêtes peuvent joindre vos données de trace et de journal, et vous pouvez afficher les résultats de la requête sous forme de tableau ou de graphique. Vous pouvez utiliser BigQuery pour analyser vos données de trace si vous créez un ensemble de données BigQuery associé. Pour en savoir plus, consultez Interroger et analyser des traces.
Configurations avec traçage automatique
Les configurations suivantes capturent automatiquement les données de trace :
Environnement standard App Engine
Les environnements d'exécution de première génération interceptent et envoient automatiquement des segments de trace à Cloud Trace. Pour en savoir plus, consultez Présentation des anciens services groupés.
Les environnements d'exécution de deuxième génération capturent automatiquement la latence globale des requêtes et ajoutent l'en-tête HTTP
X-Cloud-Trace-Contextaux requêtes. Pour en savoir plus, consultez le calendrier de compatibilité des environnements d'exécution.
Cloud Run Functions et Cloud Run
Pour les requêtes HTTP entrantes et sortantes, les données de latence sont automatiquement envoyées à Trace.
Instrumenter votre application
Instrumentez votre application pour collecter des informations spécifiques qui vous aideront à comprendre ses performances et à résoudre les problèmes. Plusieurs frameworks d'instrumentation Open Source collectent des données de journaux, de métriques et de traces, et peuvent les envoyer à n'importe quel fournisseur, y compris Google Cloud. Pour vos applications d'agent, certains frameworks peuvent collecter vos requêtes et réponses, ou transmettre un contexte permettant de tracer certains appels de serveurs MCP Google Cloud distants.
Pour instrumenter votre application, nous vous recommandons d'utiliser un framework d'instrumentation Open Source neutre du point du vue du fournisseur, tel qu'OpenTelemetry, plutôt que des API spécifiques aux fournisseurs et aux produits ou des bibliothèques clientes. Pour en savoir plus sur ces frameworks, consultez Observabilité pour les développeurs d'applications et Choisir une approche d'instrumentation.
Les exemples d'instrumentation que nous fournissons utilisent OpenTelemetry :
Pour obtenir des exemples utilisant une exportation basée sur un collecteur, consultez les pages suivantes :
Ces exemples envoient des données de métriques et de traces au format OpenTelemetry Protocol (OTLP) à votre projet à l'aide de l'API Telemetry. Les exemples utilisent un exportateur Google Cloud pour les données de journaux.
Pour savoir comment utiliser une exportation directe des données de trace et les envoyer à l'API Telemetry, consultez Migrer de l'exportateur Trace vers le point de terminaison OTLP.
Pour obtenir des exemples montrant comment configurer une application agentique pour collecter des prompts et des réponses, consultez Observabilité pour les développeurs d'agents IA.
- Pour en savoir plus sur les serveurs MCP Google Cloud capables de générer des segments de trace, consultez Examiner les appels MCP à l'aide de Trace.
Bien que vous puissiez utiliser les bibliothèques clientes Cloud Trace pour instrumenter votre application, nous vous recommandons d'utiliser OpenTelemetry. Les bibliothèques OpenTelemetry sont préférables aux bibliothèques clientes Trace, car elles sont plus simples et exportent les données de trace au format OTLP, défini par OpenTelemetry. Pour en savoir plus, consultez Instrumenter pour Trace et Bibliothèques clientes pour Cloud Trace.
Cloud Trace et les applications agentiques
Pour comprendre le comportement de vos applications agentives, configurez-les pour collecter les requêtes et les réponses, ou pour générer des segments lorsqu'elles appellent des serveurs MCP Google Cloud distants. Les prompts et les réponses vous aident à comprendre le raisonnement utilisé par votre application agentive. Les segments qui enregistrent les appels d'outils vous aident à confirmer l'appel d'outils, l'état des appels et les latences des requêtes.
Plusieurs exemples d'instrumentation vous montrent comment configurer une application pour collecter les requêtes et les réponses. Ces exemples s'appuient sur OpenTelemetry. Pour en savoir plus, consultez Comment instrumenter vos applications d'IA générative.
Les serveurs MCP Google Cloud peuvent générer des segments de trace. Pour en savoir plus, consultez Examiner les appels MCP à l'aide de Trace.
API qui ingèrent des données de trace
Vous pouvez envoyer des données de trace à votre projet à l'aide de l'API Telemetry ou de l'API Cloud Trace. Nous recommandons l'API Telemetry pour les raisons suivantes :
L'API est compatible avec l'écosystème Open Source OpenTelemetry, et ses limites sont souvent plus généreuses que celles de l'API Cloud Trace, qui est une API Google Cloud propriétaire.
Vos données de trace sont stockées dans un format généralement cohérent avec les fichiers proto définis par OTLP. Certains champs peuvent être convertis d'un type de données spécifique à OpenTelemetry en un type de données JSON avant d'être stockés. Pour en savoir plus sur le format de stockage, consultez Schéma des données de trace.
Pour l'exportation des données de trace basée sur un collecteur, votre instrumentation ne repose pas sur un exportateur spécifique à Google Cloud.
Certaines fonctionnalités, comme la surveillance des applications, reposent sur des informations qui ne sont disponibles que lorsque vous envoyez des données de trace à l'API Telemetry.
Pour empêcher votre projet Google Cloud de stocker des données de trace, désactivez l'API Cloud Trace. La désactivation de l'API Cloud Trace a les effets suivants :
- Les servicesGoogle Cloud n'envoient pas de données de trace à votre projet.
- Google Cloud répond aux requêtes envoyées à un point de terminaison de l'API Cloud Trace avec un code d'erreur.
- Google Cloud Observability supprime les données de trace envoyées au point de terminaison de l'API Telemetry spécifique aux traces. Ne désactivez pas l'API Telemetry, car elle peut recevoir des données de journaux, de métriques et de traces.
Si vous gérez une organisation et que vous souhaitez empêcher l'utilisation de Cloud Trace, créez une contrainte de règle d'administration.
Compatibilité avec VPC Service Controls
Les servicesGoogle Cloud et vos applications peuvent envoyer des données de trace à votre projet à l'aide de l'API Cloud Trace ou de l'API Telemetry. Les services de visualisation fournis par Cloud Trace utilisent l'API Cloud Trace pour récupérer les données de trace qu'ils affichent :
Cloud Trace est un service compatible avec VPC Service Controls. Le nom du service Trace est
cloudtrace.googleapis.com. Pour en savoir plus sur les limites, consultez Produits compatibles : Cloud Trace.L'API Telemetry est un service compatible avec VPC Service Controls. Le nom du service est
telemetry.googleapis.com. Pour en savoir plus sur les limites, consultez Produits compatibles : API Telemetry.
Pour définir des valeurs par défaut qui spécifient la région Google Cloud où vos données de trace sont stockées et si une clé gérée par le client chiffre les données, utilisez l'API Observability. Vous pouvez également utiliser cette API pour configurer des ensembles de données BigQuery associés, qui vous permettent d'interroger vos données de trace à l'aide des services BigQuery, et pour configurer des champs d'application de trace, qui vous permettent d'agréger les données de trace stockées dans plusieurs projets.
- L'API Observability est un service compatible avec VPC Service Controls. Le nom du service est
observability.googleapis.com. Pour en savoir plus sur les limites, consultez Produits compatibles : API Observability.
Pour en savoir plus, consultez les ressources suivantes :
Cloud Trace et résidence des données
Si vous utilisez Assured Workloads parce que vous avez des exigences de résidence des données ou de niveau d'impact 4 (IL4), n'utilisez pas l'API Cloud Trace pour envoyer des segments de trace.
Pour empêcher votre projet Google Cloud de stocker des données de trace, désactivez l'API Cloud Trace. Ne désactivez pas l'API Telemetry, car elle peut recevoir des données de journaux, de métriques et de traces.
Conservation des traces
| Catégorie | Durée de conservation |
|---|---|
Segments stockés dans le bucket _Trace |
30 jours |
Rôles IAM
Cloud Trace utilise Identity and Access Management (IAM) pour contrôler l'accès aux ressources. Pour obtenir la liste des rôles de l'API Cloud Trace et de l'API Telemetry, consultez Contrôler les accès avec IAM.
Étant donné que l'API Telemetry est une API client, l'envoi de données à l'API Telemetry nécessite de spécifier un projet de quota et d'accorder au compte de service de l'application l'autorisation d'utiliser ce quota. Pour en savoir plus, consultez API Telemetry : authentification.
Tarifs
Pour en savoir plus sur les tarifs de Cloud Trace, consultez la page Tarifs de Google Cloud Observability.
Étapes suivantes
Lisez le Guide de démarrage rapide.
Pour plus d'informations sur les quotas et les limites, consultez la section Quotas et limites.
Consultez nos ressources sur le DevOps et découvrez le programme de recherche DevOps Research and Assessment.