LLM Observability auf AWS: AgentCore-Span-Ziele prüfen

Die praktische Antwort auf LLM Beobachtbarkeit auf AWS ist nicht „Öffnen Sie das CloudWatch Dashboard“. Überprüfen Sie zunächst, wohin Amazon Bedrock AgentCore Spans liefern soll, durchsuchen Sie dann jedes Ziel, das noch Beweise enthalten kann, überprüfen Sie die Sitzungs und Trace Identität, lehnen Sie veraltete Beobachtungen ab und verknüpfen Sie den Trace mit einem separaten Beleg für das beabsichtigte externe Ergebnis. Diese Reihenfolge ist wichtig, da sich das Ziel von AgentCore ändern kann. In der aktuellen AWS Dokumentation heißt es, dass unterstützte neue Agenten Spans an eine Protokollgruppe pro Agent senden können, während ältere Konfigurationen möglicherweise die gemeinsame Protokollgruppe verwenden aws/spans Gruppe. ADOT Versionen zuvor 0.18.0 Ignorieren Sie die Einstellung für das einheitliche Ziel. Durch Ändern der Einstellung werden alte Bereiche nicht verschoben. Eine Abfrage nur der heutigen Protokollgruppe kann daher zu einer falschen Diagnose „keine Telemetrie“ führen, selbst wenn die fehlenden Beweise genau dort sind, wo sie in der vorherigen Konfiguration platziert wurden. Dieser Leitfaden erstellt eine inhaltsfreie Prüfung für diese Grenze. Es verwendet Ressourcenidentität, Version, Ziel, Zeitstempel, Korrelationskennungen, Ausführungsstatus und eine boolesche Ergebnisbestätigung. Es sind keine Eingabeaufforderungen, Antworten, Toolargumente oder Geheimnisse erforderlich. Suchen Sie die Beweise, bevor Sie sie für vermisst erklären AgentCore BeobachtbarkeitBietet integrierte Metriken für AgentCore Ressourcen und speichert Metriken, Spannen und Protokolle in Amazon CloudWatch. Die wichtige Grenze besteht darin, dass integrierte Metriken nicht mit Anwendungsablaufverfolgungen identisch sind. AWS dokumentiert Standardspannen für Speicherressourcen, während die Details zur Agentenlaufzeit und Gateway Ablaufverfolgung von der Instrumentierung abhängen. Dadurch entstehen drei separate Fragen: 1. Ist der AWS Beobachtungspfad aktiviert? CloudWatch Transaction Search muss aktiviert sein und das Trace Segment Ziel muss CloudWatch Logs sein. 2. Wo sollen die aktuellen Spans landen? Die Antwort hängt von der Einstellung des einheitlichen Ziels, der Regionsunterstützung, dem Alter des Agenten, der Ausführungsrolle und der ADOT Version ab. 3. Wo können historische Spans verbleiben? Jedes vor einem Wechsel verwendete Ziel bleibt Teil des Untersuchungsfensters, da AWS vorhandene Span Daten nicht migriert. DerAgentCore KonfigurationshandbuchGibt eine besonders nützliche Betriebsgrenze an: Eine einheitliche Bereitstellung pro Agent erfordert aws opentelemetry distro =0.18.0 . Frühere Versionen ignorieren die Konfiguration und stellen Spans an die freigegebene Gruppe bereit. Für die gleiche Anleitung ist die Berechtigung zum Installieren der entsprechenden CloudWatch Logs Ressourcenrichtlinie erforderlich. Verwenden Sie diese Fakten, um vor der Abfrage ein erwartetes Ziel zu berechnen: Beobachtung Erwarteter aktueller Suchbereich Fazit des Betreibers Transaktionssuche deaktiviert Noch ist keiner vertrauenswürdig Setup korrigieren; schließen Sie nicht auf die Gesundheit des Agenten Trace Segmente werden nicht an CloudWatch Logs weitergeleitet Noch ist keiner vertrauenswürdig Korrigieren Sie die Zielvoraussetzung Einheitlich angefordert, ADOT unten 0.18.0 Geteilt aws/spans Eine leere Pro Agent Gruppe ist ein Abfragebereichsfehler Einheitliche Aktiv und Rollenrichtlinie zulässig Laufzeitprotokollgruppe pro Agent Überprüfen Sie dort die aktuellen Spannen Das Ziel wurde während des Überprüfungsfensters geändert Aktuelle und frühere Gruppen Durchsuchen Sie beide; Alte Spannweiten bleiben dort, wo sie gelandet sind Bei dieser Tabelle handelt es sich bewusst nicht um eine einzelne „Telemetrie vorhanden“ Prüfung. Ein fehlender Datensatz in der Pro Agent Gruppe kann auf einen Einrichtungsfehler, eine blockierte Zustellung, eine alte ADOT Version oder einen korrekten historischen Datensatz in der gemeinsam genutzten Gruppe hinweisen. Diese Staaten benötigen unterschiedliche Reparaturen. Führen Sie ein Protokoll über den Zielübergang Machen Sie die aktive Einstellung nicht zu Ihrer einzigen Wahrheitsquelle. Speichern Sie einen kleinen Übergangsdatensatz neben dem Runbook: Der Datensatz enthält keinen Eingabeaufforderungs oder Antwortinhalt. Es beantwortet die Frage der Abfrageplanung, die ein Dashboard später nicht rekonstruieren kann: Welche Ziele überschneiden sich mit dem Vorfallfenster? Führen Sie ein migrationsbewusstes AgentCore Audit durch Das für diesen Artikel verwendete Audit bewertet elf festgelegte Fälle. Sein Eingabevertrag ist absichtlich klein: Seine Entscheidungsreihenfolge ist wichtiger als seine Syntax: Das Ausführen des Klassifikators über die Vorrichtung ergab: Die Fälle umfassen deaktivierte Transaktionssuche, das falsche Ablaufverfolgungsziel, alte ADOT Abfragen nur in der Pro Agent Gruppe, weggelassene historische Beweise nach einem Wechsel, unzureichende Zustellungsberechtigung, eine fehlende aktuelle Spanne, veraltete Beweise, unterbrochene Korrelation, eine legitime Genehmigungswartezeit, falsche Vervollständigung und ein gesundes migrationsbewusstes Ergebnis. Dies ist ein Entscheidungstest, kein Beweis für ein Live AWS Konto. Passen Sie die Eingaben an Ihre eigene Konfiguration und Canary Abfragen an. Behalten Sie die Reihenfolge bei: andernfalls ein Generikum telemetry missing Das Urteil kann die viel strafbarere Tatsache verschleiern, dass der Betreiber am falschen Ort gesucht hat. Bewahren Sie Sitzungsidentität, Trace Identität und Aktualität AWS beschreibt die Beobachtbarkeit von AgentCore als Hierarchie: Eine Sitzung enthält Traces und ein Trace enthält Spans. DerTelemetriedokumentationmacht diese Hierarchie explizit. Dies ist nur dann sinnvoll, wenn die Identität den Anforderungspfad überlebt. Für ADOT instrumentierte AgentCore Laufzeitaufrufe dokumentiert das Konfigurationshandbuch zwei Weitergabedetails: schicken X Amzn Bedrock AgentCore Runtime Session Id so erreicht die Sitzungs ID die Downstream Telemetrie; Rufen Sie die Laufzeit mit auf traceId=<traceId wenn eine Trace ID weitergegeben werden muss. Zeichnen Sie auf, ob diese Kennungen vorhanden sind, nicht ihren sensiblen Nutzlastkontext. Ein Span ohne beitrittsfähige Sitzung kann immer noch nachweisen, dass der Code ausgeführt wurde, aber er kann keine Vorfallzeitleiste auf Sitzungsebene unterstützen. Klassifizieren Sie das als correlation broken , nicht gesund. Frische braucht einen ähnlich expliziten Vertrag. Eine letzte Woche gefundene Spur beweist nicht, dass die Lieferung jetzt funktioniert. Definieren: Wählen Sie das maximale Alter aus der erwarteten Trittfrequenz und Vorfalltoleranz des Workflows aus. Fünf Minuten sind für einen Kanarienvogel im Minutentakt angemessen; es ist unzumutbar für eine nächtliche Charge. Bewahren Sie den Schwellenwert mit dem Urteil auf, damit „frisch“ inspizierbar bleibt. Auch das Warten braucht Beweise. Wenn eine Ablaufverfolgung eine begrenzte Genehmigungsabhängigkeit mit einem Eigentümer anzeigt und die Ausführung fortgesetzt werden kann, kehren Sie zurück waiting . Zeigen Sie es nicht als hängengeblieben an, nur weil keine neue Werkzeugspanne angezeigt wurde. Wenn der Genehmigungsdatensatz fehlt, widersprüchlich oder abgelaufen ist, senden Sie ihn zurück uncertain oder gemäß dem Runbook eskalieren. Fordern Sie nach der Ablaufverfolgung eine Ergebnisquittung an Eine vollständige Ablaufverfolgung antwortet: „Ist der instrumentierte Ausführungspfad abgeschlossen?“ Die Antwort lautet nicht unbedingt: „Hat die beabsichtigte Arbeit stattgefunden?“ Der Unterschied ist bei häufigen Fehlern sichtbar: ein Upload Tool kehrt zurück, bevor das Ziel das Objekt festschreibt; Eine Nachrichten API akzeptiert eine Anfrage, aber die Nachricht erreicht nie den beabsichtigten Kanal. Ein Agent schreibt eine lokale Datei, während das erforderliche Artefakt in den Remote Speicher gehört. Der letzte Modellaufruf ist erfolgreich, nachdem eine Downstream Transaktion bereits zurückgesetzt wurde. Eine Wartezeit auf Genehmigung wird fälschlicherweise in einen endgültigen Erfolg umgewandelt. AWS Vorschriftenempfiehlt, LLM Evidenz mit nachgelagerten Auswirkungen zu korrelieren. Eine Implementierung mit minimalem Datenschutz kann dies mit einer Ergebnisquittung erreichen: Die Quittung sollte durch die stärkste verfügbare deterministische Prüfung erstellt werden: ein Objekt HEAD , eine von einem stabilen Schlüssel gelesene Datenbank, ein öffentlicher API Abruf, eine Prüfsumme oder ein gezielter Test. Es sollte nicht den Objektkörper, die Eingabeaufforderung, die Antwort oder das Geheimnis enthalten. Halten Sie die beiden Urteile getrennt: Beweise aufspüren Ergebnisbeleg Zustand Fehlt oder ist veraltet Beliebig Der Nachweis der Beobachtbarkeit ist unzureichend Vollständig Fehlen false complete Warten auf die protokollierte Genehmigung Noch nicht erwartet waiting Komplett und frisch Vorhanden und verifiziert healthy für dieses getestete Ergebnis Die letzte Zeile ist bereichsbezogen. Es beweist den festen Kanarienvogel und das Ziel, nicht jede Route, jede Aufgabe oder die semantische Ausgabequalität. Führen Sie das Audit durch, ohne Inhalte zu sammeln Ein nützlicher Produktionsbeleg benötigt nur genügend Daten, um die Fehlerschichten zu unterscheiden: Agentenressourcen und Endpunkt IDs in geschwärzter oder gehashter Form; Region und Beobachtungszeit; Status der Transaktionssuche und des Verfolgungsziels; ADOT Version und einheitliche Zieleinstellung; aktuelle und frühere Zielklassen; ob beide Ziele für das Untersuchungsfenster durchsucht wurden; neueste passende kanarische Zeit; Vorhandensein einer Sitzungs ID und einer Trace ID; Ausführungsstatus und begrenzter Genehmigungsstatus; stabile Betriebsidentität und deterministischer Ergebnis Empfangsstatus. Halten Sie Aufforderungstext, Modellantworten, Toolargumente, Anmeldeinformationen, Rohkopfzeilen und Kundennutzlasten aus dieser Quittung fern. Wenn für einen bestimmten Vorfall eine tiefergehende Inhaltsprüfung erforderlich ist, genehmigen Sie diese separat und legen Sie den Umfang fest. Auch die Prüfung hat Grenzen. Es werden weder die Instrumentierungsabdeckung über alle Anwendungsrouten noch die Vollständigkeit der Stichproben, die CloudWatch Aufbewahrung, die Exportwiederherstellung oder die semantische Antwortqualität nachgewiesen. Es beweist, dass der ausgewählte Beweispfad konfiguriert und durchsuchbar ist, der Kanarienvogel frisch und korreliert ist und das ausgewählte externe Ergebnis über eine eigene Quittung verfügt. Das reicht aus, um einen teuren Kategoriefehler zu verhindern: den Agenten zu wechseln, weil ein Operator das falsche Span Ziel gesucht hat. Sidewisp befindet sich derzeit in einer privaten Vorschauphase.Seine beabsichtigte Aufgabe besteht darin, Beweise wie Zielabdeckung, Aktualität, Korrelation, Wartezustand und Ergebnisüberprüfung in eine klare Gesundheitsansicht umzuwandeln. Produktions AgentCore und CloudWatch Überwachungsadapter werden derzeit nicht ausgeliefert, daher handelt es sich bei diesem Artikel um ein Betriebsmuster, das Sie jetzt anwenden können – keinen Anspruch daraufSidewispführt dieses Audit bereits durch.