Que faire si Amazon Bedrock AgentCore n’affiche pas de données de trace en 2026 ?

L’observabilité d’Amazon Bedrock AgentCore distingue trois familles de données — journaux, métriques et traces — qui ne se consultent pas nécessairement au même endroit, comme le précise la documentation AWS sur l’observabilité AgentCore. Symptôme : aucune trace visible dans CloudWatch. Réponse rapide : vérifiez d’abord Transaction Search et la configuration de télémétrie de la ressource, puis son compte, sa région, sa destination et vos droits. Si l’agent n’est pas exécuté par AgentCore Runtime, ajoutez aussi le contrôle de son instrumentation OpenTelemetry.

Cet article s’adresse aux développeurs qui ont déployé un agent sur AgentCore Runtime, mais ne disposent pas de traces exploitables. Il concerne également les ingénieurs plateforme qui configurent CloudWatch, ainsi que les responsables qui veulent rendre les incidents reproductibles. Si vous cherchez plutôt un guide de premier déploiement, les vérifications ci-dessous ne remplacent pas une procédure de mise en service.

Commencez par identifier la donnée qui manque

Dire « CloudWatch ne montre rien » ne suffit pas pour localiser la panne. Un appel qui échoue, un journal absent et une trace absente correspondent à des symptômes différents. Un journal peut contenir une erreur d’exécution sans qu’une trace distribuée soit consultable ; inversement, une métrique peut remonter alors que les spans associés à une requête ne sont pas visibles. La documentation AWS distingue précisément ces catégories de télémétrie : journaux, métriques et traces.

Avant de modifier la configuration, consignez les paramètres de la recherche : compte AWS, région, identifiant de la ressource AgentCore, heure approximative de l’appel et type de donnée attendu. Vérifiez ensuite que la console CloudWatch est ouverte dans le compte et la région où la ressource a réellement fonctionné. Une requête exécutée dans le mauvais périmètre ressemble facilement à une absence d’ingestion.

Pourquoi AgentCore CloudWatch ne montre-t-il aucune trace ? Commencez par confirmer que vous cherchez bien des traces, et non des journaux ou des métriques, puis contrôlez le compte, la région et la période sélectionnée. Si les journaux de l’appel sont visibles, mais pas ses spans, concentrez-vous sur Transaction Search et la configuration des traces. Si aucune donnée n’apparaît, vérifiez d’abord la ressource et sa destination avant d’attribuer le problème à CloudWatch.

Un cas fréquent dans une équipe plateforme est le suivant : un agent répond en environnement de test, mais un opérateur examine une autre région ou filtre sur une période antérieure à l’appel. Dans ce scénario, modifier les autorisations ou redéployer l’agent ne corrige rien. Enregistrez l’heure de l’appel en heure UTC et refaites une recherche courte autour de cette heure, avec l’identifiant exact de l’environnement concerné.

Transaction Search et délai d’apparition

CloudWatch Transaction Search est un point de contrôle distinct de la production des données par l’agent. Une trace ne devient pas visible simplement parce que l’agent a émis des spans : la fonction doit être configurée conformément aux exigences CloudWatch, et les données doivent être ingérées puis indexées. Suivez la procédure AWS d’activation de Transaction Search dans le compte et la région concernés.

Séparez ces vérifications au lieu de les traiter comme une seule bascule :

• Paramètre au niveau du compte : vérifiez si Transaction Search est activé dans le périmètre où vous interrogez les données. Une configuration dans un autre compte ne rend pas les traces consultables ici.
• Configuration de la ressource : vérifiez qu’AgentCore envoie effectivement la télémétrie attendue. L’activation de Transaction Search ne crée pas les spans manquants et ne corrige pas à elle seule une destination mal définie.
• Recherche et indexation : après un changement, envoyez un nouvel appel identifiable, puis laissez le temps aux données d’arriver et d’être indexées avant de conclure à un échec.

Les conditions d’activation et de consultation sont décrites dans la procédure AWS citée plus haut. Ne transformez pas un délai cité dans un exemple documentaire en garantie de disponibilité pour chaque compte, région ou mode d’exécution. Pour une comparaison fiable, utilisez toujours un nouvel appel effectué après la modification, notez son heure, puis examinez la même fenêtre de recherche.

AWS indique où consulter les spans Runtime dans CloudWatch ; vérifiez cet emplacement avant de modifier vos filtres dans la vue des traces AgentCore Runtime. Une recherche dans les journaux ne remplace pas une recherche de transactions, et l’absence de résultats dans une vue ne prouve pas que l’agent n’a émis aucune télémétrie.

Configuration de télémétrie selon la ressource

AgentCore ne doit pas être diagnostiqué comme une ressource unique. Runtime, Memory et Gateway n’ont pas forcément la même configuration de journaux, de métriques et de spans. Examinez la ressource réellement impliquée dans l’appel, puis comparez son état à la documentation AWS de configuration de l’observabilité. Pour comprendre les données disponibles et leur emplacement, utilisez aussi le guide de démarrage de l’observabilité AgentCore.

Pour Runtime, comparez ce qui est activé avec les informations AWS sur les métriques Runtime et les paramètres de télémétrie configurables. Une métrique de disponibilité ou de volume indique qu’une activité est mesurée ; elle ne garantit pas qu’un span applicatif décrivant chaque étape de l’agent existe. Si vous devez localiser une opération dans la chaîne d’exécution, vérifiez précisément l’émission et la recherche des traces, plutôt que de vous contenter d’un tableau de métriques.

Les destinations méritent un contrôle séparé. Identifiez celle qui est configurée pour la ressource, puis vérifiez que vous consultez le service et le groupe correspondant. Les options et les comportements ont évolué ; les notes de version AgentCore permettent de repérer les changements documentés. Ne copiez pas aveuglément une configuration d’un autre type de ressource ou d’un ancien environnement : le fait que deux composants participent au même agent ne signifie pas qu’ils utilisent le même paramétrage de télémétrie.

Attention : un appel qui réussit n’est pas une preuve que les journaux et les traces sont correctement configurés. Testez séparément la réponse fonctionnelle et la visibilité des données de diagnostic.

Journaux vides, spans absents et droits insuffisants

Quand les données manquent, vérifiez permissions et destination, mais dans cet ordre logique : identifiez d’abord la sortie attendue et l’émetteur, puis vérifiez si celui-ci est autorisé à l’envoyer. Une politique IAM ne peut pas faire apparaître une trace qu’aucun composant n’a produite. À l’inverse, une instrumentation correcte peut rester invisible si le rôle ne dispose pas des autorisations requises ou si la ressource envoie les données vers une destination différente de celle consultée.

Pour les permissions propres à l’exécution, comparez le rôle effectivement utilisé avec les exigences AWS relatives aux permissions Runtime. Contrôlez également l’identité qui lit les journaux ou consulte les traces : les droits d’écriture du composant d’exécution et les droits de lecture de l’opérateur sont deux questions différentes. Une vérification administrative effectuée avec un rôle privilégié ne garantit pas que l’accès de l’équipe d’astreinte est correctement configuré.

Faut-il commencer par les permissions ou par la destination ? Si aucune donnée n’est présente à l’emplacement attendu, vérifiez d’abord l’émetteur et sa destination ; contrôlez ensuite ses droits d’écriture. Si les données existent mais que votre compte d’exploitation ne les voit pas, examinez plutôt les droits de lecture et le périmètre intercompte. Cette distinction évite de demander des autorisations trop larges pour résoudre un simple problème de destination.

Agents hors Runtime et instrumentation OpenTelemetry

Un agent exécuté sur une autre infrastructure ne bénéficie pas automatiquement de l’instrumentation associée à AgentCore Runtime. Dans ce cas, l’absence de traces peut venir du code applicatif : SDK OpenTelemetry absent ou mal initialisé, instrumentation du cadre non chargée, variables d’environnement manquantes, exporteur mal configuré ou contexte de trace non propagé entre les composants. Les étapes de configuration indiquées par AWS dans son guide d’observabilité AgentCore doivent être adaptées à votre mode d’exécution ; elles ne remplacent pas l’instrumentation de l’agent auto-hébergé.

Procédez par comparaison contrôlée :

• Choisissez une requête de test qui ne contient ni donnée personnelle ni secret, et notez son heure ainsi qu’un identifiant non sensible.
• Exécutez la même action dans l’environnement local et dans l’environnement hébergé, sans changer simultanément de modèle, de configuration ou de chemin de code.
• Vérifiez que l’application initialise bien le fournisseur OpenTelemetry et l’exporteur utilisé par votre architecture.
• Confirmez que les bibliothèques d’instrumentation du cadre d’agent sont activées et qu’elles créent les spans attendus.
• Contrôlez les variables d’environnement de télémétrie et la propagation du contexte entre les appels, puis comparez les journaux d’exportation.
• Rejouez la requête après avoir corrigé un seul élément, afin de savoir quelle modification a réellement changé le résultat.

Les contrôles portant sur l’activation de Transaction Search, l’emplacement des spans Runtime et les paramètres documentés d’AgentCore sont fondés sur les guides AWS cités plus haut. En revanche, l’installation du SDK, le choix des bibliothèques de votre cadre et la propagation dans votre code relèvent de l’application que vous exécutez. Si les traces sont visibles localement, mais pas dans CloudWatch, comparez d’abord l’exporteur et son point d’arrivée ; ne concluez pas que le code d’agent est correctement instrumenté uniquement parce qu’un journal applicatif est présent.

Pour un agent de génération audio ou vidéo, par exemple, séparez le span de réception de la demande, celui du traitement applicatif et celui de l’appel au composant de génération. Cette décomposition aide à distinguer une requête qui n’a jamais atteint l’agent d’un traitement commencé mais dont les spans ne sont pas exportés. Elle permet aussi d’éviter d’inscrire le contenu complet des créations, des invites ou des fichiers dans les journaux : l’identifiant de test et les étapes techniques suffisent souvent à reproduire le chemin d’exécution.

Les charges utiles peuvent contenir des instructions, des données client ou des éléments créatifs confidentiels. Avant d’activer la journalisation des requêtes, vérifiez les règles de masquage, la durée de conservation et les personnes autorisées à consulter ces données.

Parcours de décision et dossier de reproduction

Utilisez ces conditions pour éviter les changements au hasard :

• Si aucun journal ni aucune métrique n’apparaît, confirmez d’abord le compte, la région, l’identifiant Runtime et la période ; si tout est exact, vérifiez la destination de journaux et le rôle d’exécution.
• Si des journaux existent mais pas de traces, vérifiez l’activation de Transaction Search, puis la configuration des spans de la ressource et l’emplacement de recherche CloudWatch.
• Si seules les métriques sont visibles, ne concluez pas que les traces sont émises ; inspectez les paramètres dédiés aux traces et refaites un appel test après leur modification.
• Si les données existent dans un compte mais pas dans un autre, vérifiez le périmètre de lecture, les accès intercomptes et la destination avant d’élargir les politiques IAM.
• Si l’agent ne tourne pas sur AgentCore Runtime, ajoutez le diagnostic OpenTelemetry côté application ; ne cherchez pas une configuration Runtime qui ne correspond pas à son mode d’exécution.

Pour rendre l’incident reproductible, consignez les éléments suivants dans un ticket : compte et région examinés ; type et identifiant de ressource ; heure UTC et identifiant non sensible de l’appel ; donnée recherchée — journal, métrique ou trace ; vue CloudWatch utilisée ; état de Transaction Search ; destination configurée ; rôle d’exécution et identité de lecture ; résultat avant et après une modification isolée. Ajoutez les erreurs pertinentes en supprimant les secrets et les charges utiles sensibles.

Si vous suivez plusieurs environnements, consignez séparément les paramètres de test et de production. Une configuration qui fonctionne en développement n’est pas une preuve que la ressource de production utilise le même rôle, la même destination ou le même périmètre CloudWatch. Pour les erreurs d’exécution qui persistent après ces contrôles, comparez votre symptôme avec la documentation AWS de dépannage Runtime, plutôt que de traiter toute absence de trace comme une panne du service de journaux.

Une fois l’observabilité rétablie, reliez ce dossier de reproduction à votre procédure de mise en production : vous pouvez consulter notre centre d’aide pour les questions liées à un environnement de travail, ou contacter kvmboot si vous avez besoin d’aide sur une solution temporaire de test. Pour comparer les options d’exécution, gardez à l’esprit que le cloud AWS reste adapté à un agent hébergé et intégré à ses services, mais que les changements de permissions, les destinations multiples et les périmètres de compte compliquent parfois les essais locaux ; un Mac local, lui, ne reproduit pas automatiquement les rôles ou les services gérés AWS. Si vous devez surtout valider temporairement un client, un outil de développement ou un flux créatif audio et vidéo sur macOS, la location d’un Mac via kvmboot peut offrir un environnement de test séparé sans achat immédiat. Pour une charge de production durable qui dépend de Runtime, de ses permissions ou de ses interfaces cloud, conservez plutôt une validation dans AWS et documentez la configuration de télémétrie qui y est réellement utilisée.