Présentation de l'observabilité

L'observabilité des agents dans Gemini Enterprise Agent Platform offre une visibilité complète sur les performances, le comportement et l'état de vos agents déployés et de vos serveurs MCP (Model Context Protocol). En surveillant les métriques clés, en traçant les chemins d'exécution et en observant votre système multi-agent dans son ensemble, vous pouvez diagnostiquer les problèmes, optimiser la consommation de ressources et améliorer la fiabilité de vos agents.

Ce document présente les outils d'observabilité disponibles dans Gemini Enterprise Agent Platform, y compris la topologie à l'échelle du système, la surveillance des agents individuels et les métriques du serveur MCP.

Configuration de la télémétrie

Pour remplir ces tableaux de bord, topologies et traces d'observabilité, vos agents doivent être configurés pour envoyer des données de télémétrie au format OpenTelemetry aux systèmes de stockage de Google Cloud Observability.

Assurez-vous que vos environnements d'agent et de serveur MCP sont correctement configurés pour émettre ces données. Les composants Google Cloud intégrés émettent automatiquement des données de télémétrie au format OpenTelemetry. Par exemple, Model Armor émet de manière native des données de télémétrie standardisées, ce qui vous permet d'exposer et de surveiller facilement les interceptions de règles en temps réel directement dans vos données de trace, sans nécessiter d'instrumentation personnalisée.

Pour obtenir des instructions et des exigences de configuration de la télémétrie de l'agent, consultez les ressources suivantes :

Signaux d'observabilité

Gemini Enterprise Agent Platform fournit une observabilité via des métriques, des traces et des journaux.

Lorsque vous sélectionnez un agent spécifique dans le registre, l'onglet Observabilité fournit une suite de tableaux de bord ciblés pour surveiller son état opérationnel, ses performances et l'utilisation de l'infrastructure. Utilisez le menu de navigation de gauche dans l'onglet Observabilité pour basculer entre les vues suivantes :

  • Aperçu : suit l'utilisation globale sur la période sélectionnée, y compris le nombre total de sessions, le nombre moyen de tours par session et le nombre total d'appels de l'agent. Les graphiques de séries temporelles affichent l'utilisation des jetons (entrée par rapport à la sortie), le volume de trafic global de l'agent, les centiles de latence (p50, p95, p99) et les taux d'erreur.
  • Évaluation : affiche les moniteurs en ligne pour une évaluation continue de la qualité. Cela inclut des widgets de séries temporelles qui suivent la qualité moyenne des réponses, les métriques de sécurité, les taux d'hallucination et la qualité d'utilisation des outils.
  • Modèles : ventile les performances par modèle de fondation sous-jacent. Vous pouvez surveiller la latence p95, le nombre total d'appels, les taux d'erreur, les échecs de quota et l'utilisation des jetons isolés par des modèles spécifiques.
  • Outils : surveille les outils et services externes connectés à l'agent. Cette vue détaille la latence p95, le nombre d'appels et les taux d'erreur par outil, ainsi que la fréquence des interactions au cours desquelles aucun outil n'a été appelé.
  • Utilisation : fournit des métriques au niveau de l'infrastructure pour l'environnement d'exécution de l'agent, y compris l'allocation de processeur du conteneur, l'allocation de mémoire du conteneur et l'utilisation des jetons.
  • Journaux : affiche un flux filtrable de journaux d'agent bruts, y compris la gravité, les codes temporels et les synthèses d'exécution pour une présentation détaillée du dépannage. Pour en savoir plus, consultez Afficher les journaux de l'agent.

En plus des tableaux de bord de l'onglet Observabilité, vous pouvez utiliser l'onglet Traces de l'agent pour inspecter l'exécution étape par étape de sessions spécifiques, y compris les graphes orientés acycliques des segments et des entrées/sorties. Pour en savoir plus, consultez Afficher les traces de l'agent. Vous pouvez également utiliser l'onglet Topologie pour afficher les dépendances entrantes et sortantes spécifiques à cet agent.

Pour les serveurs MCP, vous pouvez surveiller le nombre de requêtes et la durée des requêtes p95 pour suivre l'utilisation et la réactivité.

Auditer les actions des agents

Pour faciliter les audits de sécurité et de conformité de l'entreprise, Gemini Enterprise Agent Platform utilise la journalisation à double attribution pour enregistrer l'activité des agents dans Cloud Logging. Lorsqu'un agent effectue une action ou appelle un outil au nom d'une personne (autorité déléguée par l'utilisateur), les journaux d'audit et d'exécution enregistrent à la fois l'identité de l'agent basée sur SPIFFE (principal://... dans les journaux d'audit ou spiffe://... dans les journaux d'exécution) et l'identité de l'utilisateur humain à l'origine de l'action. Lorsqu'un agent agit de manière autonome sous sa propre autorité, les journaux attribuent l'action directement à l'identité unique de l'agent.

Les auditeurs et les administrateurs de sécurité peuvent isoler et examiner les événements initiés par l'agent dans Cloud Logging en filtrant l'indicateur is_agentic=true dans les requêtes de journaux. En combinant is_agentic=true avec l'identité de l'agent ou le compte principal de l'utilisateur, vous pouvez tracer les chemins d'exécution de bout en bout et vérifier l'application des règles pour toutes les interactions de l'agent.

Arrêt d'urgence et attentes concernant la propagation des règles

Lorsqu'il répond à un incident de sécurité ou à un comportement anormal d'un agent, Agent Platform fournit deux couches complémentaires pour arrêter l'activité de l'agent :

  • Arrêt immédiat de l'environnement d'exécution ou redirection du trafic : la suppression d'un agent déployé sur Agent Runtime (runtimes.delete ou reasoningEngines.delete) arrête immédiatement ses instances de conteneur, interrompt les sessions actives et les appels de streaming, et invalide définitivement son identité d'agent SPIFFE une fois l'opération de suppression terminée. Vous pouvez également rediriger 100 % du trafic racine vers une révision dont le bon fonctionnement est avéré à l'aide de trafficSplitManual ou archiver les révisions préexistantes en mettant à jour spec.deployment_spec.agent_gateway_config.
  • Révocation de l'accès basée sur des règles : l'ajout d'une règle DENY aux règles d'accès unifiées (UAP) appliquées par Agent Gateway (iamEnforcementMode: "ENFORCE"), ou l'application d'une stratégie de refus ou d'une révocation de rôle Identity and Access Management (IAM) bloque les appels d'outils et d'API sortants tout en préservant le conteneur d'exécution pour l'analyse d'investigation. Toutefois, les règles d'accès utilisateur et les mises à jour des stratégies IAM sont cohérentes à terme : les modifications directes des stratégies prennent généralement effet en moins de deux minutes, mais leur propagation globale peut prendre jusqu'à sept minutes ou plus (voir Propagation des modifications d'accès), et la synchronisation des mises à jour de l'appartenance à un groupe ou à principalSet peut prendre de quelques minutes à plusieurs heures. Les mises à jour des règles sont évaluées lors de nouvelles vérifications d'autorisation et ne ferment pas de force les connexions de streaming déjà établies, sauf si elles sont réautorisées.

Pour un kill switch immédiat lors d'un incident actif, supprimez l'environnement d'exécution de l'agent ou redirigez le trafic de sa révision en plus d'appliquer une règle de refus de stratégie. Pour obtenir des instructions détaillées, consultez Arrêt d'urgence et révocation des accès.

Latence de la télémétrie et des résultats de sécurité

Différents contrôles d'observabilité et de sécurité fonctionnent selon différents calendriers d'ingestion et d'évaluation. Comprendre ces attentes en matière de latence aide les intervenants en cas d'incident à distinguer l'application intégrée de la détection asynchrone des menaces.

Le tableau suivant récapitule le modèle d'évaluation et la latence attendue pour chaque signal de télémétrie et de sécurité dans Agent Platform :

Signal ou contrôle Modèle d'évaluation et d'ingestion Latence typique
Journaux de requêtes Cloud Audit Logs et Agent Gateway (cloudaudit.googleapis.com/*, networkservices.googleapis.com/gateway_requests) Générés de manière synchrone lorsque les appels d'API et les vérifications d'autorisation de la passerelle sont évalués, puis ingérés dans Logging. En temps quasi réel (généralement consultable dans l'explorateur de journaux en quelques secondes). Les filtres de fraîcheur de la CLI étroits tels que --freshness=6h peuvent parfois omettre des entrées récemment indexées. Utilisez --freshness=1d pour vérifier les événements récents.
Journaux d'exécution d'Agent Runtime (aiplatform.googleapis.com/reasoning_engine_stdout, reasoning_engine_stderr) Diffusés de manière asynchrone depuis le conteneur d'exécution vers Logging. Généralement visible quelques secondes après l'émission.
Traces distribuées dans Cloud Trace Exportées de manière asynchrone à mesure que les segments OpenTelemetry se terminent, sous réserve des règles samplingRate et parentBasedSampling configurées. Généralement consultable quelques secondes après la fin de l'intervalle.
Métriques Cloud Monitoring Échantillonnage périodique à partir d'Agent Runtime, d'Agent Gateway et des pipelines de détection d'anomalies. Échantillonnage toutes les 60 à 120 secondes, avec un délai de visibilité de 180 à 420 secondes dans l'Explorateur de métriques et les tableaux de bord.
Application des règles intégrée (Agent Gateway, Identity-Aware Proxy, Model Armor) Évalué de manière synchrone sur le chemin de la requête en direct avant qu'un appel d'outil, une requête MCP ou un prompt de modèle ne se termine. Interception intégrée en temps réel (aucun délai de post-traitement).
Détection des anomalies d'agents et résultats de Security Command Center (Security Command Center) (AGENT_SESSION_ANOMALY) Évalué de manière asynchrone hors bande via un pipeline de détection multicouche après l'ingestion des journaux et des traces de session, sans ajouter de latence aux réponses des agents en direct. L'activation initiale du champ d'application prend environ 40 minutes. Les métriques d'anomalie sont échantillonnées toutes les 120 secondes (avec un délai de visibilité pouvant atteindre 420 secondes), et une latence de synchronisation supplémentaire s'applique avant que les résultats confirmés n'apparaissent dans Security Command Center.

Conservation inviolable des journaux d'audit

Les entrées Cloud Audit Logs sont immuables par conception : une fois que Logging écrit une entrée de journal d'audit, sa charge utile et ses métadonnées ne peuvent pas être modifiées. Les journaux d'audit des activités d'administration et des événements système sont stockés dans le bucket de journaux _Required, qui applique une durée de conservation fixe de 400 jours et ne peut pas être modifié ni supprimé.

Par défaut, les journaux d'audit des accès aux données (cloudaudit.googleapis.com/data_access), les journaux des refus de règles (cloudaudit.googleapis.com/policy_denied), les journaux des requêtes Agent Gateway (networkservices.googleapis.com/gateway_requests) et les journaux d'exécution de l'agent à double attribution (is_agentic=true) sont acheminés vers le bucket de journaux _Default avec une période de conservation de 30 jours.

Pour appliquer une conservation inviolable de type WORM (Write Once, Read Many) pour les preuves de conformité, acheminez les journaux d'audit et de passerelle de votre agent vers un bucket Logging personnalisé, configurez une durée de conservation personnalisée (de 1 à 3 650 jours) et verrouillez définitivement le bucket. Le verrouillage d'un bucket Logging est une action irréversible qui empêche quiconque, y compris les Propriétaires du projet et les Administrateurs de l'organisation, de supprimer le bucket, de supprimer des entrées de journal avant l'expiration de leur période de conservation ou de réduire la période de conservation.

Pour créer et verrouiller un bucket Logging personnalisé pour les journaux d'audit de l'agent à l'aide de la Google Cloud CLI, exécutez les commandes suivantes :

gcloud logging buckets create BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --locked \
    --project=PROJECT_ID

Remplacez les éléments suivants :

  • BUCKET_ID : identifiant unique de votre bucket de journaux d'audit (par exemple, agent-audit-worm-bucket).
  • LOCATION : emplacement du bucket (par exemple, global, us ou eu).
  • RETENTION_DAYS : nombre de jours de conservation des entrées de journal (entre 1 et 3650).
  • PROJECT_ID : ID de votre projet Google Cloud .

Pour empêcher la suppression d'un bucket de journaux verrouillé si son projet parent est supprimé, placez un privilège de projet sur le projet. Vous pouvez également exporter les journaux d'audit vers un bucket Cloud Storage configuré avec une règle de conservation verrouillée (verrou de bucket). Pour en savoir plus, consultez Configurer et gérer des buckets de journaux.

Exporter les journaux d'audit vers un SIEM

Pour centraliser la surveillance de la sécurité, la corrélation et l'archivage de conformité à long terme, vous pouvez exporter en continu les journaux d'audit des agents, les décisions d'autorisation d'Agent Gateway et les journaux d'exécution is_agentic=true vers Google Security Operations (Google SecOps) ou un système de gestion des informations et des événements de sécurité (SIEM) tiers.

Vous pouvez configurer un récepteur de journaux au niveau du projet, ou un récepteur agrégé au niveau de l'organisation ou du dossier, pour acheminer les journaux vers les destinations suivantes :

  • Google Security Operations : ingérez les journaux d'audit Cloud, les journaux Agent Gateway et les résultats AGENT_SESSION_ANOMALY de Security Command Center dans Google SecOps de manière native ou via un flux Pub/Sub ou Cloud Storage pour examiner les sessions d'agent en même temps que la télémétrie de sécurité de l'entreprise. Pour obtenir des instructions de configuration, consultez Exporter des données Google Cloud vers Google SecOps.
  • Pub/Sub (Pub/Sub) : diffusez les journaux d'audit de l'agent en temps réel vers un sujet Pub/Sub pour qu'ils soient ingérés par des plates-formes SIEM tierces (telles que Splunk, Datadog ou QRadar) à l'aide d'un abonnement Pub/Sub ou d'un connecteur Dataflow. Pour en savoir plus, consultez Acheminer des journaux vers Pub/Sub.
  • BigQuery ou Analyse de l'observabilité : exportez les journaux vers un ensemble de données BigQuery ou associez un bucket de journaux compatible avec l'Analyse de l'observabilité à BigQuery pour exécuter des requêtes de conformité SQL sur les identités des agents, les délégations d'utilisateurs et les refus de règles de passerelle.
  • Cloud Storage : exportez des fichiers journaux JSON par lot vers un bucket Cloud Storage avec le verrou de bucket activé pour l'archivage immuable à long terme.

Pour créer un récepteur de journaux Logging qui diffuse les journaux d'audit et de passerelle de l'agent vers un sujet Pub/Sub pour l'ingestion SIEM, procédez comme suit :

  1. Créez le récepteur de journaux avec un filtre "Inclure" qui capture les journaux Cloud Audit Logs, les journaux de requêtes Agent Gateway, les journaux Agent Runtime et les entrées de double attribution (is_agentic=true) :

    gcloud logging sinks create SINK_NAME \
    pubsub.googleapis.com/projects/DESTINATION_PROJECT_ID/topics/TOPIC_ID \
    --log-filter='logName:("cloudaudit.googleapis.com" OR "networkservices.googleapis.com%2Fgateway_requests" OR "aiplatform.googleapis.com%2Freasoning_engine") OR jsonPayload.is_agentic=true OR labels.is_agentic="true"' \
    --project=PROJECT_ID

    Remplacez les éléments suivants :

    • SINK_NAME : nom de votre récepteur de journaux (par exemple, agent-audit-siem-sink).
    • DESTINATION_PROJECT_ID : ID du projet hébergeant le sujet Pub/Sub de destination.
    • TOPIC_ID : ID du sujet Pub/Sub auquel votre SIEM s'abonne.
    • PROJECT_ID : ID du projet à partir duquel vous exportez les journaux. Pour exporter des données à l'échelle d'une organisation, remplacez --project=PROJECT_ID par --organization=ORGANIZATION_ID --include-children.

  2. Récupérez l'identité du compte de service de l'éditeur du récepteur et attribuez-lui le rôle d'Diffuseur Pub/Sub (roles/pubsub.publisher) sur le sujet de destination :

    WRITER_IDENTITY=$(gcloud logging sinks describe SINK_NAME \
    --project=PROJECT_ID \
    --format='value(writerIdentity)')

gcloud pubsub topics add-iam-policy-binding TOPIC_ID \
    --project=DESTINATION_PROJECT_ID \
    --member="${WRITER_IDENTITY}" \
    --role="roles/pubsub.publisher"

Conventions d'IA générative OpenTelemetry

Les traces d'agent et les journaux de prompts et de réponses s'appuient fortement sur les conventions sémantiques OpenTelemetry pour les systèmes d'IA générative afin de standardiser la façon dont la télémétrie de l'IA générative est capturée, structurée et signalée.

Le respect de ces conventions est essentiel pour le traçage des agents, car il établit un format universel et indépendant du fournisseur pour décrire les workflows d'agents complexes en plusieurs étapes, tels que les exécutions d'outils, les étapes de récupération et la consommation de jetons. Cette standardisation facilite l'interopérabilité entre les différents backends d'observabilité et outils d'analyse, à la fois dans et en dehors de Google Cloud.

Étapes suivantes