Observabilité LLM sur AWS : Audit AgentCore Span Destinations

La réponse pratique à l' observabilité LLM sur AWS n'est pas « d'ouvrir le tableau de bord CloudWatch ». Prouvez d'abord où Amazon Bedrock AgentCore doit fournir des délais, puis recherchez chaque destination pouvant encore contenir des preuves, vérifiez l'identité de la session et de la trace, rejetez les observations obsolètes et joignez la trace à un reçu distinct pour le résultat externe souhaité. Cet ordre est important car la destination d'AgentCore peut changer. La documentation AWS actuelle indique que les nouveaux agents pris en charge peuvent envoyer des étendues à un groupe de journaux par agent, tandis que les anciennes configurations peuvent utiliser le partage. aws/spans groupe. Versions ADOT avant 0.18.0 ignorez le paramètre de destination unifiée. La modification du paramètre ne déplace pas les anciennes étendues. Une requête portant uniquement sur le groupe de journaux actuel peut donc produire un faux diagnostic « sans télémétrie », même lorsque les preuves manquantes se trouvent exactement là où les mettaient la configuration précédente. Ce guide construit un audit sans contenu pour cette limite. Il utilise l'identité de la ressource, la version, la destination, les horodatages, les identifiants de corrélation, l'état d'exécution et un reçu de résultat booléen. Il ne nécessite pas d'invites, de réponses, d'arguments d'outil ou de secrets. Localiser la preuve avant de la déclarer manquante Observabilité de AgentCorefournit des métriques intégrées pour les ressources AgentCore et stocke les métriques, les étendues et les journaux dans Amazon CloudWatch. La limite importante est que les métriques intégrées ne sont pas les mêmes que les traces d’application. AWS documente les étendues par défaut des ressources de mémoire, tandis que les détails de l'exécution de l'agent et de la trace de la passerelle dépendent de l'instrumentation. Cela crée trois questions distinctes : 1. Le chemin d'observation AWS est il activé ? CloudWatch Transaction Search doit être activé et la destination du segment de trace doit être CloudWatch Logs. 2. Où les délais actuels devraient ils atterrir ? La réponse dépend du paramètre de destination unifiée, de la prise en charge de la région, de l'âge de l'agent, du rôle d'exécution et de la version d'ADOT. 3. Où les périodes historiques peuvent elles rester ? Toute destination utilisée avant un changement reste partie de la fenêtre d'enquête car AWS ne migre pas les données de période existantes. LeGuide de configuration d'AgentCoredonne une limite opérationnelle particulièrement utile : la livraison unifiée par agent nécessite aws opentelemetry distro =0.18.0 . Les versions antérieures ignorent la configuration et fournissent des étendues au groupe partagé. Le même guide nécessite l'autorisation d'installer la stratégie de ressources CloudWatch Logs appropriée. Utilisez ces faits pour calculer une destination attendue avant d'interroger : Observation Portée de recherche actuelle attendue Conclusion de l'opérateur Recherche de transactions désactivée Aucun n'est encore fiable Corriger la configuration ; ne pas déduire la santé de l'agent Segments de trace non acheminés vers CloudWatch Logs Aucun n'est encore fiable Corriger la condition préalable de destination Unifié demandé, ADOT ci dessous 0.18.0 Commun aws/spans Un groupe vide par agent est une erreur de portée de requête Politique d'activité et de rôle unifiée autorisée Groupe de journaux d'exécution par agent Vérifiez les travées actuelles ici Destination modifiée pendant la période de révision Groupes actuels et précédents Recherchez les deux ; les vieilles travées restent là où elles ont atterri Ce tableau n'est délibérément pas un simple contrôle de « présence de télémétrie ». Un enregistrement manquant dans le groupe par agent peut signifier un échec de configuration, une livraison bloquée, une ancienne version d'ADOT ou un enregistrement historique correct dans le groupe partagé. Ces États ont besoin de réparations différentes. Tenir un registre de transition vers une destination Ne faites pas du paramètre actif votre seule source de vérité. Stockez un petit enregistrement de transition à côté du runbook : L'enregistrement ne contient aucun contenu d'invite ou de réponse. Il répond à la question de planification des requêtes qu'un tableau de bord ne peut pas reconstruire ultérieurement : quelles destinations chevauchent la fenêtre d'incident ? Exécuter un audit AgentCore prenant en compte la migration L'audit utilisé pour cet article évalue onze cas fixes. Son contrat d’entrée est volontairement petit : Son ordre de décision est plus important que sa syntaxe : L'exécution du classificateur sur le luminaire produit : Les cas couvrent la recherche de transactions désactivée, la mauvaise destination de trace, l'ancien ADOT interrogé uniquement dans le groupe par agent, les preuves historiques omises après un changement, l'autorité de livraison insuffisante, une période actuelle manquante, des preuves obsolètes, une corrélation rompue, une attente d'approbation légitime, un faux achèvement et un résultat sain tenant compte de la migration. Il s'agit d'un test de décision, et non d'une preuve d'un compte AWS actif. Adaptez ses entrées à partir de votre propre configuration et de vos requêtes Canary. Conserver l'ordre : sinon un générique telemetry missing Le verdict peut cacher le fait bien plus concret que l’opérateur a cherché au mauvais endroit. Préserver l’identité de la session, tracer l’identité et la fraîcheur AWS décrit l'observabilité d'AgentCore comme une hiérarchie : une session contient des traces et une trace contient des étendues. Ledocumentation de télémétrierend cette hiérarchie explicite. Cela n’est utile que si l’identité survit au chemin de la demande. Pour les appels d'exécution AgentCore instrumentés par ADOT, le guide de configuration documente deux détails de propagation : envoyer X Amzn Bedrock AgentCore Runtime Session Id ainsi l'ID de session atteint la télémétrie en aval ; invoquer le runtime avec traceId=<traceId lorsqu'un ID de trace doit être propagé. Enregistrez si ces identifiants sont présents, et non leur contexte de charge utile sensible. Une période sans session pouvant être jointe peut toujours prouver que le code a été exécuté, mais elle ne peut pas prendre en charge une chronologie des incidents au niveau de la session. Classez cela comme correlation broken , pas sain. La fraîcheur nécessite un contrat tout aussi explicite. Une trace retrouvée la semaine dernière ne prouve pas que la livraison fonctionne désormais. Définir: Choisissez l'âge maximum à partir de la cadence attendue du flux de travail et de la tolérance aux incidents. Cinq minutes sont raisonnables pour un canari toutes les minutes ; c'est déraisonnable pour un lot nocturne. Conservez le seuil avec le verdict afin que « frais » reste inspectable. Attendre a aussi besoin de preuves. Si une trace montre une dépendance d'approbation limitée avec un propriétaire et que l'exécution peut reprendre, retournez waiting . Ne le pagez pas comme étant bloqué simplement parce qu'aucune nouvelle étendue d'outil n'est apparue. Si le dossier d'approbation est absent, contradictoire ou expiré, renvoyez le uncertain ou escalader en fonction du runbook. Exiger un reçu de résultat après le traçage Une trace complète répond « le chemin d'exécution instrumenté est il terminé ? » Il ne répond pas nécessairement « le travail prévu a t il eu lieu ? » La distinction est visible dans les échecs courants : un outil de téléchargement revient avant que la destination ne valide l'objet ; une API de message accepte une requête mais le message n'atteint jamais le canal prévu ; un agent écrit un fichier local alors que l'artefact requis appartient au stockage distant ; l'appel de modèle final réussit après qu'une transaction en aval ait déjà été annulée ; une attente d'approbation est incorrectement convertie en succès terminal. Conseils prescriptifs AWSrecommande de corréler les preuves LLM avec l’impact en aval. Une implémentation minimale en termes de confidentialité peut le faire avec un reçu de résultat : Le reçu doit être produit par le contrôle déterministe le plus puissant disponible : un objet HEAD , une base de données lue par clé stable, une récupération d'API publique, une somme de contrôle ou un test ciblé. Il ne doit pas contenir le corps de l'objet, l'invite, la réponse ou le secret. Gardez les deux verdicts séparés : Tracer des preuves Réception du résultat État Manquant ou obsolète N'importe lequel Les preuves d’observabilité sont insuffisantes Complet Manquant false complete En attente d'approbation enregistrée Pas encore attendu waiting Complet et frais Présent et vérifié healthy pour ce résultat testé La dernière ligne est délimitée. Cela prouve le canari et la destination fixes, pas chaque itinéraire, chaque tâche ou la qualité de sortie sémantique. Adopter l’audit sans collecter de contenu Un reçu de production utile n’a besoin que de suffisamment de données pour distinguer les couches de défaillance : les identifiants de ressources d'agent et de point de terminaison sous une forme rédigée ou hachée ; Région et heure d'observation ; Recherche de transaction et statut de destination de trace ; Version ADOT et paramètre de destination unifiée ; classes de destination actuelles et précédentes ; si les deux destinations ont été recherchées pour la fenêtre d'enquête ; heure canari la plus récente correspondante ; présence de l'ID de session et de l'ID de trace ; état d'exécution et état d'approbation limité ; identité d'opération stable et statut de résultat réception déterministe. Conservez le texte d’invite, les réponses de modèle, les arguments de l’outil, les informations d’identification, les en têtes bruts et les charges utiles du client hors de ce reçu. Si une inspection plus approfondie du contenu est requise pour un incident spécifique, autorisez la et étendez la séparément. L'audit a également des limites. Il ne prouve pas la couverture de l'instrumentation sur chaque route d'application, l'exhaustivité de l'échantillonnage, la rétention CloudWatch, la récupération des exportations ou la qualité des réponses sémantiques. Cela prouve que le chemin de preuve sélectionné est configuré et consultable, que le canari est frais et corrélé et que le résultat externe sélectionné a son propre reçu. Cela suffit pour éviter une erreur de catégorie coûteuse : changer d'agent parce qu'un opérateur a recherché la mauvaise destination de span. Sidewisp est actuellement en préversion privée.Son rôle est de transformer des preuves telles que la couverture de la destination, la fraîcheur, la corrélation, l'état d'attente et la vérification des résultats en une vision claire de la santé. Les adaptateurs de surveillance Production AgentCore et CloudWatch ne sont pas actuellement livrés. Cet article est donc un modèle de fonctionnement que vous pouvez appliquer dès maintenant, et non une affirmation selon laquelleSidewispeffectue déjà cet audit.