Was tun, wenn Amazon Bedrock AgentCore 2026 keine Trace-Daten anzeigt?

Wenn Amazon Bedrock AgentCore keine Trace-Daten anzeigt, prüfen Sie zuerst AWS-Konto, Region und Suchzeitraum, danach CloudWatch Transaction Search, die Telemetrie der betroffenen Ressource, das konfigurierte Ziel und die erforderlichen Berechtigungen. Läuft der Agent nicht in einer von AgentCore Runtime verwalteten Umgebung, müssen Sie zusätzlich die OpenTelemetry-Instrumentierung der Anwendung kontrollieren.

Dieser Leitfaden richtet sich an Sie, wenn ein Aufruf Ihrer AgentCore Runtime fehlschlägt, aber keine verwertbaren Traces vorliegen. Er hilft auch Plattformteams, die CloudWatch-Protokolle und -Traces einrichten, und technischen Verantwortlichen, die einen reproduzierbaren Diagnoseablauf für den Produktivbetrieb benötigen.

Amazon Bedrock AgentCore: Trace-Daten 2026 systematisch prüfen

„In CloudWatch ist nichts zu sehen“ beschreibt mehrere verschiedene Situationen. Ein Agent kann aufgerufen worden sein, obwohl kein Anwendungsprotokoll erscheint. Protokolle können vorhanden sein, während Spans fehlen. Eine Runtime kann außerdem einen Fehler zurückgeben, ohne dass Sie am richtigen Ort oder im passenden Zeitraum nach einem Trace suchen. Behandeln Sie diese Fälle nicht als einen einzigen CloudWatch-Ausfall.

Gehen Sie zunächst die Symptome getrennt durch:

• Kein erfolgreicher Aufruf: Prüfen Sie, ob der Request die Runtime überhaupt erreicht hat und welche Fehlermeldung die aufrufende Anwendung erhält. Nutzen Sie die AgentCore-Dokumentation zur Runtime-Fehlerdiagnose, um Runtime-Probleme von fehlender Sichtbarkeit zu unterscheiden.
• Aufruf erfolgt, aber keine Protokolle: Kontrollieren Sie, ob für die betreffende Ressource Protokollierung aktiviert ist, wohin sie schreibt und ob das Ziel erreichbar ist.
• Protokolle vorhanden, aber keine Trace-Daten: Prüfen Sie Spans und Transaction Search unabhängig von der Protokollsuche. Protokolle und Traces sind unterschiedliche Telemetriedaten.
• Metriken vorhanden, aber keine Spans: Eine sichtbare Metrik belegt nicht, dass Traces exportiert werden. Kontrollieren Sie die spanbezogene Konfiguration und den Suchpfad.

Bevor Sie Einstellungen ändern, verifizieren Sie den Kontext: das verwendete AWS-Konto, die Region, den Namen und die Version der aufgerufenen Runtime sowie den tatsächlichen Zeitpunkt des Requests. Ein Aufruf in einer Entwicklungsumgebung sagt nicht aus, ob die gleichnamige Ressource in einem anderen Konto oder einer anderen Region dieselben Einstellungen hat. Begrenzen Sie die Suche zunächst auf einen Zeitraum, der den bekannten Aufruf sicher einschließt, und testen Sie anschließend mit einem einzelnen, kontrollierten Request.

Die AgentCore-Übersicht zu verfügbaren Telemetriedaten unterscheidet unter anderem Metriken, Protokolle und Traces. Für Ihre Diagnose bedeutet das: Jede Datenart braucht einen eigenen Sichtbarkeitstest. Wenn Sie nur nach Protokollereignissen suchen, können Sie daraus nicht ableiten, ob Spans erzeugt oder für die Suche bereitgestellt wurden.

Wenn Traces fehlen, prüfen Sie Transaction Search und den Suchpfad

CloudWatch Transaction Search ist ein eigener Prüfpunkt. Kontrollieren Sie nicht nur, ob AgentCore Telemetrie erzeugen kann, sondern auch, ob Transaction Search für das betreffende Konto und die verwendeten Protokollgruppen eingerichtet ist. AWS beschreibt Aktivierung und Voraussetzungen in der Anleitung zu CloudWatch Transaction Search. Vergleichen Sie die dort beschriebenen Anforderungen mit dem Konto, in dem Sie tatsächlich suchen.

Trennen Sie dabei Kontoeinstellung, Ressourcen- und Zielkonfiguration sowie Abfrage voneinander:

• Kontoeinstellung: Ist Transaction Search im richtigen Konto eingerichtet? Eine Einstellung in einem anderen Konto macht Daten nicht automatisch in der aktuellen Ansicht auffindbar.
• Ressourcen- und Zielkonfiguration: Werden die AgentCore-Daten in die Protokollgruppe oder an das Ziel geleitet, für das die Suche eingerichtet ist?
• Abfrage: Verwenden Sie eine Ansicht, die zu den erwarteten Spans passt, und suchen Sie im richtigen Zeitraum? Die AWS-Anleitung zur Ansicht von Runtime-Spans beschreibt, wo diese Telemetrie eingesehen werden kann.

Ein erfolgreicher Aufruf direkt nach einer Konfigurationsänderung ist kein Beleg dafür, dass ein Trace sofort sichtbar sein muss. Verifizieren Sie, dass die Änderung gespeichert wurde, wiederholen Sie danach den Request und prüfen Sie den dokumentierten Suchpfad. AWS-Beispiele für Wartezeiten sind keine allgemeine Leistungszusage für jedes Konto, jede Region oder jede Betriebsart. Verwenden Sie daher keinen angenommenen festen Zeitraum als Beweis dafür, dass eine Konfiguration funktioniert oder defekt ist.

Hinweis: Ändern Sie nicht mehrere Schalter gleichzeitig. Wenn Sie Transaction Search, das Exportziel und Rollenberechtigungen parallel anpassen, können Sie bei einem anschließenden Erfolg nicht mehr erkennen, welche Änderung entscheidend war.

Ressourcen-Telemetrie und Ziel getrennt kontrollieren

AgentCore Runtime, Memory und Gateway können unterschiedliche Telemetrie- und Zielkonfigurationen haben. Prüfen Sie deshalb die Ressource, die den fraglichen Aufruf tatsächlich verarbeitet hat, statt eine Einstellung pauschal auf alle AgentCore-Komponenten zu übertragen. Die AgentCore-Konfigurationsanleitung für Observability führt durch die Ressourceneinstellungen; die Einführung in AgentCore Observability ordnet die ersten Prüfschritte ein.

Beantworten Sie für jede Ressource und jede Datenart dieselben Fragen:

• Metriken: Ist die erwartete Ressource in der passenden CloudWatch-Ansicht sichtbar? Vergleichen Sie die Anzeige mit der offiziellen Beschreibung der Runtime-Telemetrie.
• Protokolle: Ist ein Ziel für diese Ressource festgelegt? Stimmen Zielname, Konto und Region mit der Protokollansicht überein?
• Spans: Ist die Trace-Ausgabe aktiviert und wird sie an einen Ort geleitet, der über den gewählten Suchweg sichtbar ist?
• Ressourcentyp: Prüfen Sie, ob es sich um Runtime, Memory oder Gateway handelt. Eine Einstellung an einer Komponente belegt nicht, dass eine andere Komponente dieselbe Einstellung verwendet.

Achten Sie besonders auf das Ziel. AWS dokumentiert Änderungen an unterstützten Telemetriezielen in den AgentCore Release Notes. Wenn eine Umgebung nach einer Änderung ein anderes Ziel verwendet, kann eine ältere CloudWatch-Suchroutine weiterhin leer bleiben, obwohl Telemetrie an anderer Stelle ankommt. Prüfen Sie daher die aktuellen Anweisungen und die konfigurierte Destination, nicht nur eine früher gespeicherte Betriebsnotiz.

Bei Berechtigungsproblemen sollten Sie die tatsächlich verwendete Runtime-Rolle und die nötigen Zugriffe prüfen. Maßgeblich ist die Dokumentation zu AgentCore-Runtime-Berechtigungen. Trennen Sie Schreibrechte der Laufzeit von Leserechten der Person oder Rolle, mit der Sie CloudWatch untersuchen. Ein Entwickler kann fehlende Leserechte haben, obwohl die Runtime korrekt schreibt. Umgekehrt kann ein Benutzer die Protokollgruppe sehen, obwohl die Runtime nicht hinein exportieren kann.

Entscheidungswerkzeug: Prüfen, abhaken und den nächsten Schritt wählen

Arbeiten Sie die Prüfpunkte in dieser Reihenfolge ab. Ändern Sie jeweils nur die Einstellung, die durch den Befund als mögliche Ursache eingegrenzt wurde.

• [ ] Konto und Region stimmen: Suchen Sie im Konto, das die Runtime betreibt, und in der Region der tatsächlich aufgerufenen Ressource. Wenn nicht, korrigieren Sie zuerst den Suchkontext und wiederholen Sie die Abfrage.
• [ ] Runtime und Zeitraum stimmen: Verifizieren Sie Ressourcennamen beziehungsweise Version sowie den tatsächlichen Aufrufzeitpunkt. Wenn der Request die Runtime nicht erreicht hat, untersuchen Sie den Aufrufpfad statt CloudWatch.
• [ ] Das erwartete Ziel ist konfiguriert: Prüfen Sie, ob die Ressource an das Ziel schreibt, das Sie abfragen. Wenn das Ziel abweicht oder nicht erreichbar ist, korrigieren Sie Ziel oder Suchpfad, bevor Sie weitere Einstellungen ändern.
• [ ] Die benötigte Telemetrieart ist aktiviert: Kontrollieren Sie Protokolle, Metriken und Spans getrennt. Wenn Protokolle erscheinen, aber Spans fehlen, lassen Sie das Protokollziel zunächst unverändert und prüfen Sie spanbezogene Einstellungen sowie Transaction Search.
• [ ] Transaction Search passt zu Konto und Ziel: Wenn Protokolle und Spans grundsätzlich erzeugt werden, die Suche aber leer bleibt, gleichen Sie die Kontoeinstellung und die verwendeten Protokollgruppen mit der AWS-Anleitung ab.
• [ ] Die Rollen haben die richtigen Zugriffe: Prüfen Sie Schreibrechte der Runtime und Leserechte Ihrer Suchidentität getrennt. Bei kontoübergreifender Suche kontrollieren Sie zusätzlich, ob Sie im richtigen Betriebskonto suchen.

So wählen Sie den nächsten Schritt: Sind weder Protokolle noch Spans vorhanden, beginnen Sie bei Aufrufkontext, Ressourcenziel und Schreibrechten. Sind Protokolle vorhanden, aber Traces nicht, untersuchen Sie Spans und Transaction Search. Sind Metriken sichtbar, aber Spans nicht, behandeln Sie beide Datenarten als getrennte Ausgaben. Läuft der Agent außerhalb von AgentCore Runtime, prüfen Sie zuerst die eigene Instrumentierung und den Export der Anwendung.

Selbst betriebene Agents benötigen eigene Anwendungsinstrumentierung

Nicht jeder Agent wird von AgentCore Runtime ausgeführt. Wenn Sie eine Anwendung selbst in einer anderen Laufzeit betreiben, können Sie nicht voraussetzen, dass AgentCore automatisch die Spans Ihres Frameworks oder Ihrer Modellaufrufe erzeugt. In diesem Fall verantwortet Ihre Anwendung Initialisierung, Export und Kontextweitergabe. AgentCore-Einstellungen bleiben für AgentCore-Ressourcen relevant, ersetzen aber keine fehlende Instrumentierung im selbst betriebenen Prozess.

Prüfen Sie zunächst, ob das OpenTelemetry-SDK gestartet wird und ob die verwendete Instrumentierung den Agent-Aufruf tatsächlich erfasst. Kontrollieren Sie anschließend die Exportkonfiguration: Sind die erforderlichen Umgebungsvariablen in genau dem Prozess gesetzt, der den Agent ausführt? Wird ein passender Exporter initialisiert? Ist das konfigurierte Ziel aus dieser Laufzeit erreichbar? AWS beschreibt Ressourceneinstellungen in der Observability-Konfiguration. Ergänzen Sie diese Prüfung um die Dokumentation des von Ihnen eingesetzten Frameworks und SDKs.

Ein Vergleich desselben Requests unter kontrollierten Bedingungen hilft, die Fehlerquelle einzugrenzen:

1. Erfassen Sie eine lokale Ausführung mit einem bekannten Eingabefall und prüfen Sie, ob die Anwendung Spans erzeugt.
2. Führen Sie denselben Request in der Cloud aus und notieren Sie Konto, Region, Runtime- oder Prozesskennung sowie den Zeitpunkt.
3. Vergleichen Sie nicht nur das Ergebnis des Agents, sondern auch, ob die Instrumentierung dieselben Modell- und Tool-Aufrufe erfasst.
4. Wenn lokal Spans entstehen und in der Cloud nicht, prüfen Sie zuerst Umgebungsvariablen, Exportziel, Netzwerkpfad und Rollenrechte der Cloud-Laufzeit.
5. Wenn in keiner Umgebung Spans entstehen, suchen Sie früher in der Instrumentierungskette, etwa bei der SDK-Initialisierung oder der Framework-Anbindung.

Diese Gegenüberstellung ist für sich allein kein Beweis, dass die Umgebungen identisch sind: Laufzeitkonfiguration und Aufrufpfad können voneinander abweichen. Sie grenzt aber ein, ob Sie zuerst die Anwendung oder den Cloud-Export untersuchen sollten. Dokumentieren Sie genau, an welcher Stelle der Trace-Kette Daten zum ersten Mal fehlen.

Achtung: Trace- und Protokolldaten können Eingaben, Tool-Ergebnisse, Fehlerdetails oder andere Inhalte eines Agent-Aufrufs enthalten. Bevor Sie Payload-Protokollierung aktivieren oder ausweiten, klären Sie gespeicherte Felder, Zugriffsrechte und Aufbewahrungsdauer. Nutzen Sie für die Diagnose möglichst einen bereinigten Testfall und beachten Sie die Datenschutzanforderungen Ihrer Organisation, einschließlich der DSGVO.

Eine reproduzierbare Übergabe verhindert erneute Sucharbeit

Halten Sie einen fehlgeschlagenen Versuch so fest, dass ein anderes Teammitglied ihn nachvollziehen kann. Notieren Sie nicht nur „CloudWatch zeigt nichts“, sondern erfassen Sie, welche Datenart fehlt und an welcher Stelle Sie gesucht haben.

• Zeitpunkt und Zeitzone: Wann wurde der kontrollierte Request ausgelöst?
• Kontext: Welches Konto, welche Region, welcher Ressourcentyp und welche Runtime-Version waren betroffen?
• Symptom: Fehlen Protokolle, Spans oder beides? Sind Metriken sichtbar?
• Suchweg: Welche CloudWatch-Ansicht, welcher Zeitraum und welches Ziel wurden kontrolliert?
• Konfiguration: Welche Telemetrieoptionen und Zielressourcen waren aktiv?
• Berechtigungen: Welche Runtime-Rolle schreibt, und mit welcher Identität suchen Sie?
• Reproduktion: Welcher bereinigte Request wurde verwendet, und unterscheidet sich das Ergebnis lokal?
• Änderungen: Welche einzelne Einstellung wurde zuletzt angepasst, und was änderte sich danach?

Diese Aufzeichnung macht aus einer vagen Beobachtung einen prüfbaren Fehlerfall. Sie hilft zu unterscheiden, ob das Problem bei der Agent-Ausführung, der Instrumentierung, dem Export, den Berechtigungen oder der Abfrage liegt. Speichern Sie darin keine vertraulichen Payloads, wenn ein Zeitstempel, eine Ressourcenzuordnung und eine bereinigte Request-Kennung für die Zuordnung genügen.

Häufige Fragen zu AgentCore CloudWatch und Observability

Warum bleibt die CloudWatch-Suche nach einem erfolgreichen Agent-Aufruf leer?

Ein erfolgreicher Aufruf bestätigt zunächst nur, dass ein Teil des Ausführungspfads funktioniert hat. Er beweist nicht, dass alle Telemetriearten aktiviert sind oder dass Sie am richtigen Ziel suchen. Prüfen Sie Konto, Region und Zeitpunkt, dann Protokolle und Spans getrennt. Wenn die Runtime Daten erzeugt, aber Transaction Search oder die Ressourcenkonfiguration nicht passt, können Trace-Daten in der erwarteten Ansicht weiterhin fehlen.

Wie kontrollieren Sie die Runtime-Konfiguration ohne Änderungen am laufenden System?

Lesen Sie zuerst die tatsächlich verwendete Ressourcenkonfiguration aus und gleichen Sie sie mit den aktuellen AWS-Anweisungen ab. Notieren Sie Telemetrieart, Ziel und ausführende Rolle, bevor Sie Einstellungen ändern. Erzeugen Sie danach einen kontrollierten Request und suchen Sie gezielt nach diesem Zeitraum. So vermeiden Sie, durch gleichzeitige Änderungen an mehreren Ressourcen eine funktionierende Diagnose zu erschweren.

Was ist bei AgentCore Observability für einen selbst betriebenen Agent anders?

Bei einem nicht von AgentCore Runtime verwalteten Prozess kann die Anwendung eine eigene OpenTelemetry-Initialisierung und Framework-Instrumentierung benötigen. Sie müssen nachvollziehen, ob Spans überhaupt erzeugt werden, ob der Exporter läuft und ob die Cloud-Umgebung die nötigen Konfigurationswerte erhält. Erst wenn diese Anwendungsebene funktioniert, sollten Sie CloudWatch-Suchpfad und Berechtigungen als nächste Fehlerquellen eingrenzen.

Prüfen Sie zuerst Berechtigungen oder das Protokollziel?

Beginnen Sie mit dem Ziel, weil ein falscher oder nicht verwendeter Zielpfad auch bei passenden Rechten zu einer leeren Suche führt. Kontrollieren Sie, ob die erwartete Ressource dorthin schreibt und ob Sie genau dieses Ziel durchsuchen. Prüfen Sie danach getrennt die Schreibrechte der Runtime und die Leserechte Ihrer Suchidentität. Bei kontoübergreifendem Betrieb ergänzen Sie die Prüfung um die jeweilige Kontogrenze.

Wenn Ihre aktuelle Diagnose auf einer gemeinsam genutzten AWS-Umgebung mit wechselnden Konten, Rollen und Laufzeitkonfigurationen beruht, dokumentieren Sie diese Abhängigkeiten, bevor Sie die Infrastruktur neu aufsetzen. Uneinheitliche Testbedingungen, schwer reproduzierbare Berechtigungsänderungen und eine unklare Trennung zwischen Produktions- und Diagnosezugriffen erschweren die Fehlersuche. Ein gemieteter Mac von kvmboot kann für zeitlich begrenzte macOS-Entwicklung, lokale Reproduktion oder plattformgebundene Tests sinnvoll sein, ersetzt aber weder AgentCore Runtime noch eine korrekt konfigurierte CloudWatch-Telemetrie. Wenn Ihr Projekt macOS nicht benötigt und dauerhaft hohe Rechenlast hat, ist eine passende Cloud- oder eigene Serverumgebung oft die sachgerechtere Wahl. Benötigen Sie dagegen vorübergehend einen Mac für einen abgegrenzten Test, helfen Ihnen die Informationen im kvmboot-Hilfebereich bei der Einordnung des Angebots; bei konkreten Fragen zu Mietbedingungen oder Einsatzmöglichkeiten können Sie sich über die Kontaktseite von kvmboot an den Anbieter wenden.