Beobachtbarkeit – Übersicht

Die Beobachtbarkeit von KI-Agenten in der Gemini Enterprise Agent Platform bietet umfassende Einblicke in die Leistung, das Verhalten und den Zustand Ihrer bereitgestellten KI-Agenten und MCP-Server (Model Context Protocol). Durch das Monitoring wichtiger Messwerte, das Tracing von Ausführungspfaden und die Beobachtung Ihres Multi-Agenten-Systems als Ganzes können Sie Probleme diagnostizieren, den Ressourcenverbrauch optimieren und die Zuverlässigkeit Ihrer Agenten verbessern.

In diesem Dokument finden Sie eine Übersicht über die Beobachtbarkeitstools, die in der Gemini Enterprise Agent Platform verfügbar sind, einschließlich systemweiter Topologie, Monitoring einzelner KI-Agenten und MCP-Servermesswerte.

Telemetrie einrichten

Damit diese Dashboards, Topologien und Traces zur Beobachtbarkeit mit Daten gefüllt werden, müssen Ihre KI-Agenten so konfiguriert sein, dass sie Telemetriedaten im OpenTelemetry-Format an Speichersysteme in Google Cloud Observability senden.

Achten Sie darauf, dass Ihre KI-Agenten- und MCP-Serverumgebungen richtig konfiguriert sind, um diese Daten auszugeben. Integrierte Google Cloud -Komponenten geben automatisch Telemetriedaten im OpenTelemetry-Format aus. Model Armor gibt beispielsweise standardisierte Telemetriedaten aus, sodass Sie Richtlinienverletzungen in Echtzeit direkt in Ihren Trace-Daten sichtbar machen und überwachen können, ohne dass eine benutzerdefinierte Instrumentierung erforderlich ist.

Anleitungen und Anforderungen zur Einrichtung der Agent-Telemetrie finden Sie in den folgenden Ressourcen:

Beobachtbarkeitssignale

Die Gemini Enterprise Agent Platform bietet Beobachtbarkeit durch Messwerte, Traces und Logs.

Wenn Sie einen bestimmten KI-Agenten aus der Registry auswählen, finden Sie auf dem Tab Beobachtbarkeit eine Reihe von Dashboards, mit denen Sie den Betriebszustand, die Leistung und die Infrastrukturnutzung überwachen können. Über die linke Navigation auf dem Tab Beobachtbarkeit können Sie zwischen den folgenden Ansichten wechseln:

  • Übersicht: Hier wird die allgemeine Nutzung im ausgewählten Zeitraum erfasst, einschließlich der Gesamtzahl der Sitzungen, der durchschnittlichen Anzahl von Turns pro Sitzung und der Gesamtzahl der Agentenaufrufe. In Zeitreihendiagrammen werden die Tokennutzung (Eingabe im Vergleich zur Ausgabe), das gesamte Agent-Traffic-Volumen, Latenzperzentile (p50, p95, p99) und Fehlerraten angezeigt.
  • Bewertung: Zeigt Onlinemonitore für die kontinuierliche Qualitätsbewertung an. Dazu gehören Zeitreihen-Widgets, mit denen die durchschnittliche Antwortqualität, Sicherheitsmesswerte, Halluzinationsraten und die Qualität der Toolnutzung erfasst werden.
  • Modelle: Schlägt die Leistung nach dem zugrunde liegenden Foundation Model auf. Sie können die P95-Latenz, die Gesamtzahl der Aufrufe, die Fehlerraten, die Ratenkontingentfehler und die Tokennutzung für bestimmte Modelle isoliert überwachen.
  • Tools: Überwacht die externen Tools und Dienste, die mit dem Agenten verbunden sind. In dieser Ansicht werden die P95-Latenz, die Anzahl der Aufrufe und die Fehlerraten pro Tool sowie die Häufigkeit von Interaktionen, bei denen kein Tool aufgerufen wurde, aufgeführt.
  • Nutzung: Bietet Messwerte auf Infrastrukturebene für die Laufzeitumgebung des KI-Agenten, einschließlich Container-CPU-Zuweisung, Container-Arbeitsspeicherzuweisung und Tokennutzung.
  • Logs: Zeigt einen filterbaren Stream von Rohlogs des KI-Agenten an, einschließlich Schweregrad, Zeitstempeln und Ausführungszusammenfassungen für eine detaillierte Fehlerbehebung. Weitere Informationen finden Sie unter Agent-Logs ansehen.

Zusätzlich zu den Dashboards auf dem Tab Beobachtbarkeit können Sie auf dem Tab Traces des KI-Agenten die schrittweise Ausführung bestimmter Sitzungen prüfen, einschließlich gerichteter azyklischer Graphen von Spans und Ein-/Ausgaben. Weitere Informationen finden Sie unter Agent-Traces ansehen. Sie können auch den Tab Topologie verwenden, um die spezifischen eingehenden und ausgehenden Abhängigkeiten für diesen einzelnen Agenten aufzurufen.

Bei MCP-Servern können Sie die Anzahl der Anfragen und die p95-Anfragedauer überwachen, um die Auslastung und Reaktionsfähigkeit zu verfolgen.

KI-Agentenaktionen prüfen

Zur Unterstützung von Sicherheits- und Compliance-Audits in Unternehmen verwendet die Gemini Enterprise Agent Platform Logging mit doppelter Attribution, um Agentenaktivitäten in Cloud Logging aufzuzeichnen. Wenn ein Agent eine Aktion ausführt oder ein Tool im Namen einer Person aufruft (vom Nutzer delegierte Berechtigung), werden in den Audit- und Ausführungslogs sowohl die SPIFFE-basierte Agentenidentität (principal://... in Audit-Logs oder spiffe://... in Ausführungslogs) als auch die Identität des initiierenden menschlichen Nutzers aufgezeichnet. Wenn ein KI-Agent autonom in eigener Verantwortung handelt, werden die Aktionen in den Logs direkt der eindeutigen Identität des KI-Agenten zugeordnet.

Auditoren und Sicherheitsadministratoren können vom Agent initiierte Ereignisse in Cloud Logging isolieren und prüfen, indem sie in Logabfragen nach dem Flag is_agentic=true filtern. Wenn Sie is_agentic=true mit der Agentenidentität oder dem Nutzer-Principal kombinieren, können Sie End-to-End-Ausführungspfade verfolgen und die Durchsetzung von Richtlinien für alle Agenteninteraktionen überprüfen.

Not-Aus und Erwartungen an die Richtlinienweitergabe

Wenn Sie auf einen Sicherheitsvorfall oder ein ungewöhnliches Verhalten eines KI-Agenten reagieren, bietet die Agent Platform zwei sich ergänzende Ebenen, um die Aktivitäten des KI-Agenten zu stoppen:

  • Sofortige Beendigung der Laufzeit oder Umleitung des Traffics: Wenn Sie einen bereitgestellten KI-Agenten in Agent Runtime (runtimes.delete oder reasoningEngines.delete) löschen, werden die Containerinstanzen sofort beendet, aktive Sitzungen und Streamingaufrufe gestoppt und die SPIFFE-Agentenidentität nach Abschluss des Löschvorgangs dauerhaft ungültig gemacht. Alternativ können Sie 100 % des Root-Traffics mit trafficSplitManual an eine bekannte, funktionierende Überarbeitung weiterleiten oder vorhandene Überarbeitungen durch Aktualisieren von spec.deployment_spec.agent_gateway_config archivieren.
  • Richtlinienbasierter Zugriffswiderruf: Wenn Sie eine DENY-Regel zu Unified Access Policies (UAPs) hinzufügen, die vom Agent Gateway (iamEnforcementMode: "ENFORCE") erzwungen werden, oder eine IAM-Ablehnungsrichtlinie (Identity and Access Management) oder einen Rollenwiderruf anwenden, werden ausgehende Tool- und API-Aufrufe blockiert, während der Laufzeitcontainer für forensische Analysen beibehalten wird. UAPs und Aktualisierungen von IAM-Richtlinien sind jedoch letztendlich konsistent: Direkte Richtlinienänderungen werden in der Regel innerhalb von 2 Minuten wirksam, es kann jedoch bis zu 7 Minuten oder länger dauern, bis sie global übernommen werden (siehe Übernahme von Zugriffsänderungen). Die Synchronisierung von principalSet- oder Gruppenmitgliedschaftsaktualisierungen kann mehrere Minuten bis Stunden dauern. Richtlinienaktualisierungen werden bei neuen Autorisierungsprüfungen ausgewertet und bereits hergestellte Streamingverbindungen werden nur dann zwangsweise geschlossen, wenn sie neu autorisiert werden.

Wenn Sie während eines aktiven Vorfalls einen sofortigen Kill Switch benötigen, löschen Sie die Agent-Laufzeit oder leiten Sie den Versions-Traffic um, zusätzlich zur Anwendung einer Richtlinien-Ablehnungsregel. Eine detaillierte Anleitung finden Sie unter Not-Aus und Widerruf des Zugriffs.

Latenz bei Telemetrie und Sicherheitsergebnissen

Verschiedene Beobachtbarkeits- und Sicherheitskontrollen werden nach unterschiedlichen Aufnahme- und Bewertungsplänen ausgeführt. Wenn Sie diese Latenzerwartungen kennen, können Sie zwischen Inline-Erzwingung und asynchroner Bedrohungserkennung unterscheiden.

In der folgenden Tabelle sind das Bewertungsmodell und die erwartete Latenz für jedes Telemetrie- und sichere Signal in der Agent Platform zusammengefasst:

Signal oder Steuerung Bewertungs- und Aufnahmemodell Typische Latenz
Cloud-Audit-Logs und Agent Gateway-Anfrageprotokolle (cloudaudit.googleapis.com/*, networkservices.googleapis.com/gateway_requests) Wird synchron generiert, wenn API-Aufrufe und Gateway-Autorisierungsprüfungen ausgewertet werden, und dann in Logging aufgenommen. Nahezu in Echtzeit (normalerweise innerhalb von Sekunden im Log-Explorer suchbar). Bei engen Aktualitätsfiltern in der Befehlszeile wie --freshness=6h können gelegentlich kürzlich indexierte Einträge übersehen werden. Verwenden Sie --freshness=1d, wenn Sie aktuelle Ereignisse prüfen möchten.
Ausführungsprotokolle der Agent Runtime (aiplatform.googleapis.com/reasoning_engine_stdout, reasoning_engine_stderr) Werden asynchron vom Laufzeitcontainer an Logging gestreamt. In der Regel innerhalb von Sekunden nach der Emission sichtbar.
Verteilte Traces in Cloud Trace Wird asynchron exportiert, wenn OpenTelemetry-Spans abgeschlossen sind, vorbehaltlich der konfigurierten samplingRate- und parentBasedSampling-Regeln. In der Regel innerhalb von Sekunden nach Abschluss des Spans suchbar.
Cloud Monitoring-Messwerte Werden regelmäßig aus Agent Runtime, Agent Gateway und Anomalieerkennungs-Pipelines entnommen. Die Stichprobenerhebung erfolgt alle 60 bis 120 Sekunden. Die Daten sind im Metrics Explorer und in Dashboards nach 180 bis 420 Sekunden sichtbar.
Inline-Richtlinienerzwingung (Agent Gateway, Identity-Aware Proxy, Model Armor) Wird synchron im Live-Anfragepfad ausgewertet, bevor ein Toolaufruf, eine MCP-Anfrage oder ein Modell-Prompt abgeschlossen wird. Inline-Abfangen in Echtzeit (keine Verzögerung bei der Nachbearbeitung)
Agent-Anomalieerkennung und Security Command Center-Ergebnisse (AGENT_SESSION_ANOMALY) Die Bewertung erfolgt asynchron und out-of-band über eine mehrschichtige Erkennungspipeline, nachdem Sitzungslogs und Traces aufgenommen wurden. Dadurch entsteht keine zusätzliche Latenz bei den Antworten des Live-Agenten. Die erstmalige Aktivierung des Bereichs dauert etwa 40 Minuten. Anomalie-Messwerte werden alle 120 Sekunden abgerufen (bis zu 420 Sekunden Verzögerung bei der Sichtbarkeit). Außerdem gilt eine zusätzliche Synchronisierungslatenz, bevor bestätigte Ergebnisse im Security Command Center angezeigt werden.

Manipulationssichere Aufbewahrung von Audit-Logs

Cloud-Audit-Logeinträge sind unveränderlich: Nachdem Logging einen Audit-Logeintrag geschrieben hat, können die Nutzlast und die Metadaten nicht mehr geändert werden. Audit-Logs zu Administratoraktivitäten und Systemereignissen werden im Log-Bucket _Required gespeichert, der eine feste Aufbewahrungsdauer von 400 Tagen erzwingt und nicht geändert oder gelöscht werden kann.

Standardmäßig werden Audit-Logs zum Datenzugriff (cloudaudit.googleapis.com/data_access), Logs zu Richtlinienverstößen (cloudaudit.googleapis.com/policy_denied), Anfrage-Logs des Agent-Gateways (networkservices.googleapis.com/gateway_requests) und Ausführungslogs des Agenten mit doppelter Attribution (is_agentic=true) an den Log-Bucket _Default mit einer Aufbewahrungsdauer von 30 Tagen weitergeleitet.

Wenn Sie die manipulationssichere WORM-Aufbewahrung (Write Once, Read Many) für Compliance-Nachweise erzwingen möchten, leiten Sie Ihre Agent-Audit- und Gateway-Logs an einen benutzerdefinierten Logging-Bucket weiter, konfigurieren Sie eine benutzerdefinierte Aufbewahrungsdauer (von 1 bis 3.650 Tagen) und sperren Sie den Bucket dauerhaft. Das Sperren eines Logging-Buckets ist eine unumkehrbare Aktion, die verhindert, dass jemand, einschließlich Project Owner und Organization Administrator, den Bucket löscht, Logeinträge vor Ablauf ihrer Aufbewahrungsdauer löscht oder die Aufbewahrungsdauer verkürzt.

Führen Sie die folgenden Befehle aus, um einen benutzerdefinierten Logging-Bucket für Agent-Audit-Logs mit der Google Cloud CLI zu erstellen und zu sperren:

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

Ersetzen Sie Folgendes:

  • BUCKET_ID: Eine eindeutige Kennung für Ihren Audit-Log-Bucket (z. B. agent-audit-worm-bucket).
  • LOCATION: Der Bucket-Speicherort (z. B. global, us oder eu).
  • RETENTION_DAYS: Die Anzahl der Tage, für die Logeinträge aufbewahrt werden sollen (zwischen 1 und 3650).
  • PROJECT_ID: Ihre Google Cloud Projekt-ID

Wenn Sie verhindern möchten, dass ein gesperrter Log-Bucket entfernt wird, wenn das übergeordnete Projekt gelöscht wird, legen Sie eine Projektsperre für das Projekt fest. Alternativ können Sie Audit-Logs in einen Cloud Storage-Bucket exportieren, der mit einer gesperrten Aufbewahrungsrichtlinie (Bucket-Sperre) konfiguriert ist. Weitere Informationen finden Sie unter Log-Buckets konfigurieren und verwalten.

Audit-Logs in ein SIEM exportieren

Um das Sicherheitsmonitoring, die Korrelation und die langfristige Compliance-Archivierung zu zentralisieren, können Sie Agent-Audit-Logs, Agent Gateway-Autorisierungsentscheidungen und is_agentic=true-Ausführungslogs kontinuierlich nach Google Security Operations (Google SecOps) oder in ein Drittanbieter-SIEM-System (Security Information and Event Management) exportieren.

Sie können eine Logging-Senke auf Projektebene oder eine aggregierte Senke auf Organisations- oder Ordnerebene konfigurieren, um Logs an die folgenden Ziele weiterzuleiten:

  • Google Security Operations: Cloud-Audit-Logs, Agent Gateway-Logs und AGENT_SESSION_ANOMALY-Ergebnisse aus dem Security Command Center können nativ oder über einen Pub/Sub- oder Cloud Storage-Feed in Google SecOps aufgenommen werden, um Agent-Sitzungen zusammen mit Unternehmenssicherheitstelemetrie zu untersuchen. Eine Anleitung zur Einrichtung finden Sie unter Google Cloud -Daten nach Google SecOps exportieren.
  • Pub/Sub (Pub/Sub): Streamen Sie Agent-Audit-Logs in Echtzeit an ein Pub/Sub-Thema, damit sie von SIEM-Plattformen von Drittanbietern (z. B. Splunk, Datadog oder QRadar) über ein Pub/Sub-Abo oder einen Dataflow-Connector aufgenommen werden können. Weitere Informationen finden Sie unter Logs an Pub/Sub weiterleiten.
  • BigQuery oder Observability Analytics: Exportieren Sie Logs in ein BigQuery-Dataset oder verknüpfen Sie einen Log-Bucket mit aktivierter Observability Analytics mit BigQuery, um SQL-Compliance-Abfragen für Agent-Identitäten, Nutzerdelegierungen und Ablehnungen von Gateway-Richtlinien auszuführen.
  • Cloud Storage: Exportieren Sie im Batch verarbeitete JSON-Logdateien in einen Cloud Storage-Bucket mit aktivierter Bucket-Sperre für die langfristige unveränderliche Archivierung.

So erstellen Sie eine Logging-Senke, die Agent-Audit- und Gateway-Logs an ein Pub/Sub-Thema für die SIEM-Aufnahme streamt:

  1. Erstellen Sie die Logsenke mit einem Einschlussfilter, der Cloud-Audit-Logs, Agent Gateway-Anfragelogs, Agent Runtime-Logs und Einträge mit doppelter Attribution (is_agentic=true) erfasst:

    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

    Ersetzen Sie Folgendes:

    • SINK_NAME: Ein Name für Ihre Logsenke (z. B. agent-audit-siem-sink).
    • DESTINATION_PROJECT_ID: Die Projekt-ID, die das Pub/Sub-Zielthema hostet.
    • TOPIC_ID: Die ID des Pub/Sub-Themas, das Ihr SIEM abonniert.
    • PROJECT_ID: Die Projekt-ID, aus der Sie Logs exportieren. Wenn Sie Daten für eine gesamte Organisation exportieren möchten, ersetzen Sie --project=PROJECT_ID durch --organization=ORGANIZATION_ID --include-children.

  2. Rufen Sie die Identität des Dienstkontos für die Senke ab und weisen Sie ihm die Rolle „Pub/Sub-Publisher“ (roles/pubsub.publisher) für das Zielthema zu:

    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"

OpenTelemetry-Konventionen für generative KI

Agent-Traces und Prompt-und-Antwort-Logs basieren stark auf den semantischen OpenTelemetry-Konventionen für generative KI-Systeme, um die Erfassung, Strukturierung und Meldung von Telemetriedaten für generative KI zu standardisieren.

Die Einhaltung dieser Konventionen ist für das Agent-Tracing von entscheidender Bedeutung, da sie ein universelles, herstellerunabhängiges Format für die Beschreibung komplexer, mehrstufiger Agent-Workflows wie Toolausführungen, Abrufschritte und Tokenverbrauch festlegt. Diese Standardisierung ermöglicht eine nahtlose Interoperabilität zwischen verschiedenen Beobachtbarkeits-Back-Ends und Analysetools, sowohl innerhalb als auch außerhalb von Google Cloud.

Nächste Schritte