AgentCore Observability wird Multi-Cloud: Was ADOT wirklich tut

Wenn Sie heute Strands-, LangGraph- oder CrewAI-Agents in der Produktion betreiben, ist die Wahrscheinlichkeit groß, dass diese nicht alle an einem Ort laufen. Manche laufen in EKS, manche in Lambda, manche in einem GCP-Projekt Ihres Data-Teams, und ein peinlicher Pilotbetrieb läuft noch immer auf einer VM unter dem Schreibtisch von jemandem. AWS hat gerade das Verkabelungsdiagramm veröffentlicht, um Telemetrie aus all diesen Quellen in ein einziges Dashboard zu ziehen – und es lohnt sich, das genau zu lesen, bevor man sich dazu bekennt.

Das Problem

Amazon Bedrock AgentCore Observability bietet, wie Amazon Web Services (AWS) es beschreibt, natives Tracing, Monitoring und Analytics für Agents – doch die native Unterstützung deckt nur Agents ab, die auf der AgentCore-Runtime innerhalb der AWS Cloud deployt sind. Alles andere – also EKS, ECS, Lambda, On-Prem, GCP und Azure – erfordert manuelle Instrumentierung, um Telemetrie in dasselbe Dashboard zu bekommen. Genau diese Lücke schließt dieser Beitrag.

Das zugrunde liegende Engineering-Problem ist jedem vertraut, der schon einmal versucht hat, Observability über mehrere Clouds hinweg zu zentralisieren. Agent-Frameworks emittieren Spans in unterschiedlichen Formen. Strands, LangGraph und CrewAI haben jeweils eine eigene Vorstellung davon, wie ein „Reasoning Step" oder ein „Tool Call" aussieht. Model-Aufrufe über boto3 fügen noch eine weitere Schicht hinzu. Ohne eine gemeinsame semantische Konvention endet Ihr Dashboard als drei Dashboards im Trenchcoat, und Sie können keine grundlegenden Kosten- oder Sicherheitsfragen über Umgebungen hinweg beantworten.

Die entscheidende Einschränkung liegt auf der Anbieterseite. AgentCore Observability unterstützt Strands, LangGraph und CrewAI als erstklassige Frameworks – aber nur, wenn die Agents auf der AgentCore-Runtime laufen. Das ist eine enge Deployment-Oberfläche. Die meisten Teams, mit denen ich spreche, haben mindestens einen Agent, der außerhalb dieser Box läuft – oft aus Gründen der Latenz, der Datenresidenz oder bestehender Plattforminvestitionen. AWS sagt diesen Teams jetzt: Nutzt den OpenTelemetry-Weg, und wir nehmen die Daten an.

Die Quelle gibt in dieser Anleitung keine Preise pro Request für die CloudWatch OTLP-Endpunkt-Ingestion an – was relevant ist, da Agent-Workloads Dutzende von Spans pro Benutzeranfrage emittieren können. Wir kennen die effektiven Kosten pro Agent-Stunde unter diesem Muster nicht, aber die Obergrenze sind die CloudWatch Logs- und X-Ray-Ingestion-Kosten bei Ihrem Span-Volumen – und diese Zahl muss modelliert werden, bevor Sie das über eine ganze Flotte aktivieren.

Die verfügbaren Optionen

Es gibt im Wesentlichen vier Möglichkeiten, eine Multi-Cloud-Agent-Flotte heute zu instrumentieren, und dieses AWS-Muster ist eine davon.

Option 1: Das hier beschriebene AWS-Muster. Führen Sie aws-opentelemetry-distro (mindestens Version 0.10.0) im gleichen Prozess wie Ihren Agent aus, verwenden Sie opentelemetry-instrument, um Auto-Instrumentierung in die Python-Runtime zu injizieren, und exportieren Sie via SigV4 an den CloudWatch OTLP-Endpunkt. ADOT patcht boto3 für Bedrock-Aufrufe und das Strands-Framework für Agent-Reasoning-Spans automatisch. Sie erhalten das AgentCore-Dashboard, und alles wird über CloudWatch als Ingestion- und Speicherfundament geleitet. Erfordert neun spezifische IAM-Berechtigungen für bedrock, logs, xray und cloudwatch.

Option 2: Vanilla OpenTelemetry zu einem neutralen Backend. Verweisen Sie Ihre Agents auf einen selbst gehosteten oder SaaS-OTel-Collector (Grafana Tempo, Honeycomb, Datadog, Signoz) unter Verwendung derselben OTel-Semantic-Conventions für generative KI. Sie verlieren die AgentCore-spezifischen Dashboard-Ansichten, zahlen aber keine CloudWatch-Ingestion für Agents, die bereits außerhalb von AWS leben, und halten Ihr Observability-Backend portabel. Kompromiss: Keine native „Agent Reasoning Chain"-Ansicht, es sei denn, Ihr Anbieter hat eine gebaut.

Option 3: Framework-natives Telemetry. LangGraph hat LangSmith. CrewAI hat sein eigenes Tracing. Strands emittiert OpenTelemetry-konforme Spans über das strands-agents[otel]-Paket gemäß den generativen KI-Semantic-Conventions, einschließlich Reasoning-Steps, Tool-Invocations und Model-Calls mit Token-Nutzung. Am günstigsten pro Framework einzurichten, aber am Ende haben Sie N Dashboards für N Frameworks – was genau das Fragmentierungsproblem ist, das Sie lösen wollten.

Option 4: Nichts zentralisieren, lokal loggen. Noch immer der Standard für eine überraschend große Anzahl von Teams. Für einen Prototyp akzeptabel, in der Produktion nicht vertretbar, sobald Agents Tool-Calls ausführen, die Zahlungen, Nutzerdaten oder Drittanbieter-APIs berühren.

Die eigentliche Entscheidung fällt zwischen dem AWS-Muster und Vanilla OTel. Wenn Ihr Gravitationszentrum bereits AWS ist und Sie die AgentCore-spezifischen Ansichten in das Agent-Reasoning wollen, ist das der kürzere Weg. Wenn Ihr Gravitationszentrum GCP oder Azure ist und Sie nur für Bedrock-Modellzugriff auf AWS zurückgreifen, ist es eine seltsame Entscheidung, CloudWatch als Observability-Backend zu bezahlen – eine, die explizit begründet werden sollte. Die Quelle gibt nicht preis, ob das AgentCore-Dashboard jemals Telemetrie von Nicht-CloudWatch-Backends akzeptieren wird – was relevant ist, da diese Antwort bestimmt, ob dies eine Brücke oder ein Trichter ist.

Was Engineering-Teams tatsächlich tun sollten

Meine Einschätzung: Wenn Sie bereits Bedrock-Modelle für Inference nutzen, ist die Übernahme dieses Musters für Ihre Nicht-AWS-Agents kurzfristig ein vernünftiger Schritt – aber behandeln Sie die Credentials-Thematik als die entscheidende Frage, nicht die SigV4-Verkabelung.

Die Anleitung verwendet AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY als Umgebungsvariablen, was für eine Laptop-Demo in Ordnung und für eine Produktionsflotte, die über GCP-Nodes und On-Prem-Hosts läuft, inakzeptabel ist. Der Beitrag selbst empfiehlt IAM Roles Anywhere für die Produktion, was On-Prem-Workloads ermöglicht, temporäre Credentials über X.509-Zertifikate zu erhalten. Das ist die richtige Entscheidung, und sie sollte Ihr Setup von Tag eins sein, nicht eine Migration nach neunzig Tagen. Eine PKI aufzubauen, um diese Zertifikate auszustellen, ist echte Arbeit – und wenn Sie keine haben, ist das das eigentliche Projekt, nicht die ADOT-Installation.

Die Installation selbst ist ein Einzeiler: pip install "aws-opentelemetry-distro>=0.10.0" boto3 "strands-agents[otel]". Fügen Sie die neun IAM-Berechtigungen hinzu, führen Sie einmalig aws xray update-trace-segment-destination --destination CloudWatchLogs --region us-east-1 aus, um Transaction Search zu aktivieren, überprüfen Sie mit dem get-destination-Aufruf (erwartet: {"Destination": "CloudWatchLogs", "Status": "ACTIVE"}), und Sie sind verbunden.

Bevor Sie das flottenweit ausrollen, erstellen Sie ein Kostenmodell. Instrumentieren Sie einen repräsentativen Agent, lassen Sie ihn eine Woche lang gegen eine realistische Arbeitslast laufen, rufen Sie die CloudWatch-Abrechnung für diese Log-Gruppe ab und multiplizieren Sie. Wenn die Zahl schlecht aussieht, fallen Sie auf Sampling zurück oder wechseln Sie zu Option 2. Eine überprüfbare Prognose: Teams, die dieses Muster ohne eine Sampling-Strategie deployen, werden ihre CloudWatch-Rechnung innerhalb des ersten Abrechnungszyklus nicht linear mit der Anzahl der Agent-Invocations wachsen sehen. Wenn das nicht eintritt, ist entweder Ihr Traffic gering, oder Sie haben die Sampling-Standardwerte zufällig richtig getroffen.

Fallstricke und Sonderfälle

Einige Punkte aus der beschriebenen Einrichtung sind es wert, hervorgehoben zu werden.

Der OTEL_EXPORTER_OTLP_LOGS_HEADERS-Header ist dafür verantwortlich, Logs an die spezifische AgentCore-Log-Gruppe weiterzuleiten, damit CloudWatch sie im generativen KI-Observability-Dashboard indiziert. Wenn Sie das falsch konfigurieren, kommt Ihre Telemetrie an, erscheint aber nicht im Dashboard, für das Sie das alles gebaut haben. Es sieht dann wie ein Ingestion-Fehler aus, ist aber eigentlich ein Routing-Fehler.

Die Auto-Instrumentierung patcht boto3 und das Strands-Framework spezifisch. Wenn Ihr Agent einen benutzerdefinierten HTTP-Client verwendet, um Bedrock anzusprechen, oder einen Fork von Strands nutzt, oder LangGraph so kapselt, dass die ADOT-Auto-Instrumentierung es nicht erkennt, erhalten Sie nur partielle Traces. Die Quelle beschreibt das Patching für Strands explizit und erwähnt LangGraph und CrewAI als unterstützte Frameworks, aber die Anleitung demonstriert nur Strands mit Claude Haiku. Wir kennen die Güte der Auto-Instrumentierung für LangGraph und CrewAI im Vergleich zu Strands nicht – und diese Lücke lohnt sich zu messen, bevor man standardisiert.

Python 3.10 oder höher ist erforderlich. Wenn Ihre Agents aus Kompatibilitätsgründen auf 3.9 festgepinnt sind, ist das ein blockierendes Upgrade.

Schließlich ist ausgehender HTTPS-Zugriff zu AWS-Endpunkten eine Voraussetzung. In regulierten On-Prem-Umgebungen, in denen der Egress-Traffic über einen Proxy geleitet oder eingeschränkt wird, ist vor der Kommunikation von ADOT mit dem CloudWatch OTLP-Endpunkt ein Security-Review zu erwarten. Dieser Review dauert in der Regel länger als die eigentliche Code-Änderung.

Die wichtigsten Erkenntnisse

• AgentCore Observability hat jetzt einen dokumentierten Weg für Agents, die auf EKS, ECS, Lambda, On-Prem, GCP und Azure laufen – via ADOT-Auto-Instrumentierung und SigV4 zum CloudWatch OTLP-Endpunkt.
• Die Installation ist einfach (aws-opentelemetry-distro>=0.10.0, boto3, strands-agents[otel], plus neun IAM-Berechtigungen), aber die Credentials-Thematik ist die eigentliche Arbeit: Verwenden Sie IAM Roles Anywhere mit X.509-Zertifikaten, keine langlebigen Access Keys.
• Aktivieren Sie CloudWatch Transaction Search einmalig pro Account mit dem dokumentierten X-Ray-Befehl, und überprüfen Sie, ob Sie Status: ACTIVE sehen, bevor Sie irgendetwas instrumentieren.
• Modellieren Sie die CloudWatch-Ingestion-Kosten gegen ein realistisches Span-Volumen vor dem Fleet-Rollout. Agent-Workloads emittieren viele Spans pro Anfrage, und die Quelle gibt keine Preise pro Span für diesen Weg an.
• Die Anleitung demonstriert nur Strands mit Claude Haiku. LangGraph und CrewAI sind als unterstützt aufgeführt, aber die Auto-Instrumentierungsgüte über diese Frameworks hinweg ist eine offene Frage, die es in Ihrer eigenen Umgebung zu validieren gilt.