KI-Agenten Observability: Multi-Cloud-Monitoring mit AgentCore und OpenTelemetry

KI-Agenten laufen längst nicht mehr nur in AWS. Unternehmen setzen sie auf eigenen Servern, in Kubernetes-Clustern oder bei anderen Cloud-Anbietern ein. Mit der Verteilung wächst die Aufgabe, ihr Verhalten zu überwachen. Amazon Bedrock AgentCore Observability bietet umfangreiche Tracing- und Analysefunktionen. Allerdings unterstützt es standardmäßig nur Agenten, die direkt auf der AgentCore-Runtime in AWS laufen. Der neue AWS-Blogbeitrag zeigt, wie man die Lücke schließt: Mit der AWS Distro for OpenTelemetry (ADOT) lassen sich auch Agenten außerhalb von AWS an das AgentCore-Dashboard anbinden. Dieser Beitrag analysiert die Lösung, erläutert die technischen Komponenten und liefert praktische Prompts für die Umsetzung.

Überblick

Die vorgestellte Architektur leitet Telemetriedaten von KI-Agenten, die außerhalb von AWS laufen – etwa auf GCP, Azure oder on-premises – an das AgentCore-Observability-Dashboard weiter. Das Herzstück ist die AWS Distro for OpenTelemetry (ADOT), die in den Python-Prozess des Agenten integriert wird. ADOT instrumentiert das Agenten-Framework (im Beispiel Strands Agents) automatisch und exportiert Spans, Metriken und Logs über den OpenTelemetry-Exporter an den CloudWatch-OTLP-Endpoint. Die Authentifizierung übernimmt IAM mit SigV4-Signatur.

Der Datenfluss besteht aus drei Komponenten: ADOT-Auto-Instrumentierung, IAM-Anmeldedaten und Umgebungsvariablen. Die Umgebungsvariablen steuern Routing und Authentifizierung. Ohne sie landen die Telemetriedaten in allgemeinen CloudWatch-Logs, statt im dedizierten Generative-AI-Observability-Dashboard.

Prompt-Analyse

Der Artikel enthält keine klassischen Prompts, sondern technische Konfigurationsschritte und Codebeispiele. Für die praktische Umsetzung werden hier zwei Beispiel-Prompts vorgestellt: einer zur Konfiguration der Observability-Umgebung, einer zur Abfrage von Agenten-Metriken.

Der Prompt

# Prompt 1: Konfiguration der Observability für einen externen KI-Agenten
"Du bist ein DevOps-Experte für AWS-Infrastruktur. Erkläre Schritt für Schritt, wie ich einen KI-Agenten, der mit Strands Agents auf einem GCP-Server läuft, an Amazon Bedrock AgentCore Observability anbinde. Gehe dabei auf die Installation der Pakete 'aws-opentelemetry-distro' und 'strands-agents[otel]' ein, erläutere die notwendigen IAM-Berechtigungen und Umgebungsvariablen (AGENT_OBSERVABILITY_ENABLED, OTEL_PYTHON_DISTRO, OTEL_RESOURCE_ATTRIBUTES, OTEL_EXPORTER_OTLP_LOGS_HEADERS) und zeige, wie man den Agenten mit 'opentelemetry-instrument' startet."

Bestandteile

Rolle/Persona: Der Prompt weist dem Modell die Rolle eines DevOps-Experten zu. Das fokussiert die Antwort auf technische Details und hält den Ton professionell.

Kontext: Der Kontext nennt GCP-Server und Strands Agents. Das verhindert allgemeine Antworten und erzwingt eine an das Szenario angepasste Lösung.

Aufgabe: Die Aufgabe ist explizit: Schritt-für-Schritt-Erklärung der Anbindung. Die Nennung von Paketen, IAM-Berechtigungen und Umgebungsvariablen strukturiert die Antwort und deckt relevante Aspekte ab.

Output-Format: Erwartet wird eine Schritt-für-Schritt-Anleitung, also eine nummerierte, klar getrennte Darstellung mit Befehlen und Erklärungen.

Constraints: Die konkreten Variablen und Pakete schränken den Lösungsraum ein. Das Modell darf keine alternativen Tools vorschlagen, sondern muss sich auf die im AWS-Artikel beschriebene Vorgehensweise konzentrieren.

# Prompt 2: Abfrage und Interpretation von Observability-Daten
"Du bist ein KI-Operations-Analyst. Ich habe die Observability für meinen Agenten 'gcp-hosted-agent' eingerichtet und im CloudWatch-Dashboard sehe ich mehrere Traces. Beschreibe, welche Spans typischerweise in einem erfolgreichen Agenten-Trace erscheinen (z. B. 'invoke_agent', 'chat', 'execute_event_loop_cycle', 'chat.us.anthropic.claude-haiku') und wie man anhand von Latenz- und Token-Metriken Verhaltensmuster des Agenten erkennt. Fasse zusammen, welche Kennzahlen auf Halluzinationen oder ineffiziente Tool-Aufrufe hindeuten können."

Bestandteile

Rolle/Persona: Die Rolle des KI-Operations-Analysten betont die Fähigkeit, Telemetriedaten zu interpretieren und geschäftliche Relevanz abzuleiten.

Kontext: Der Nutzer bezieht sich auf konkrete Spans aus dem AWS-Artikel, wodurch die Antwort auf reale Beobachtungen eingehen muss.

Aufgabe: Zwei Teilaufgaben: Beschreibung typischer Spans und Ableitung von Verhaltensmustern aus Metriken. Der Prompt verlangt eine analytische, keine rein beschreibende Antwort.

Output-Format: Die Antwort soll zusammenfassen – das heißt eine textuelle Erklärung mit Beispielen, nicht nur eine Auflistung.

Constraints: Der Fokus liegt ausschließlich auf den genannten Spans und Metriken. Zudem wird eine Verbindung zu Qualitätsproblemen wie Halluzinationen hergestellt, was die Antwort in Richtung Verantwortung von KI-Systemen lenkt.

Häufig gestellte Fragen

Welche Umgebungsvariablen sind für die Anbindung eines externen Agenten an AgentCore Observability essenziell?

Nötig sind AGENT_OBSERVABILITY_ENABLED=true, OTEL_PYTHON_DISTRO=aws_distro, OTEL_PYTHON_CONFIGURATOR=aws_configurator, OTEL_RESOURCE_ATTRIBUTES (mit aws.log.group.names) und OTEL_EXPORTER_OTLP_LOGS_HEADERS (mit x-aws-metric-namespace=bedrock-agentcore). Diese steuern Routing und Authentifizierung.

Welche IAM-Berechtigungen werden benötigt?

Der IAM-Benutzer braucht Berechtigungen für bedrock:InvokeModel, logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents, xray:PutTraceSegments, xray:PutTelemetryRecords, xray:GetSamplingRules, xray:GetSamplingTargets und cloudwatch:PutMetricData.

Warum funktioniert die Observability nicht ohne ADOT in Nicht-AWS-Umgebungen?

AgentCore Observability unterstützt nativ nur Agenten, die auf der AgentCore-Runtime laufen. Für externe Umgebungen fehlen die automatische Instrumentierung und die SigV4-Signierung. ADOT übernimmt diese Aufgaben und exportiert Telemetrie über den CloudWatch-OTLP-Endpoint.

Kann man auch andere Agenten-Frameworks wie LangGraph oder CrewAI anbinden?

Ja, der AWS-Artikel sagt ausdrücklich, dass das ADOT-basierte Muster auch für andere OpenTelemetry-kompatible Frameworks gilt. Man muss nur sicherstellen, dass das Framework OTel-Spans emittiert.

Wie lange dauert es, bis Telemetriedaten im Dashboard sichtbar sind?

In der Regel erscheinen die Daten innerhalb von zwei bis drei Minuten nach der Ausführung des Agenten. Das ist die übliche Latenz für Verarbeitung und Indexierung in CloudWatch.

Ist die Verwendung von IAM-Zugriffsschlüsseln für Produktionsumgebungen empfehlenswert?

Der Artikel rät für Produktion zu IAM Roles Anywhere, das temporäre Anmeldeinformationen über X.509-Zertifikate ausstellt. Langlebige Zugriffsschlüssel sollten nur in Entwicklungsumgebungen verwendet werden.

Quelle

Basiert auf diesem Artikel.