Datadog

Autonomy envoie les traces des exécutions à Datadog via son point d'ingestion de traces OTLP/HTTP. Chaque exécution devient un span autonomy.run avec un span autonomy.step par étape. Configurez-le dans Organization → Integrations → OpenTelemetry. Pour le contenu des spans, voir Export OpenTelemetry.

Avant de commencer

L'identifiant est une clé API Datadog. Les clés d'application Datadog et les clés Autonomy aut_ ne fonctionnent pas. Placez-la dans le champ Headers, où Autonomy la stocke comme secret et ne l'affiche plus jamais.

Choisir votre endpoint Datadog

Saisissez l'URL de base de votre site Datadog comme OTLP endpoint. Autonomy ajoute /v1/traces et envoie du JSON en HTTPS, ce que Datadog accepte.

Ces adresses suivent le sélecteur de site du point d'ingestion de traces OTLP de Datadog. Une clé d'un site ne fonctionne pas sur le point d'ingestion d'un autre site.

Connecter et vérifier

1. Ouvrez Organization → Integrations → OpenTelemetry et choisissez Datadog comme Vendor.

2. Collez l'URL de base de votre site dans OTLP endpoint. Saisissez-la même si le texte indicatif affiche déjà la bonne adresse.

3. Saisissez ceci dans Headers, en remplaçant YOUR_DATADOG_API_KEY par votre clé API :

   dd-api-key=YOUR_DATADOG_API_KEY

4. Cliquez sur Send test span. Une réponse positive signifie que Datadog a accepté la requête ; le span peut mettre un moment à devenir consultable.

5. Dans Datadog, ouvrez APM → Trace Explorer, choisissez une plage horaire récente et recherchez service:autonomy-runner-labs. Retrouvez le span autonomy.test_connection.

6. Activez Trace export et cliquez sur Save settings. Lancez une nouvelle exécution.

7. Quand l'exécution est terminée, recherchez-la. Remplacez RUN_ID par l'identifiant figurant à la fin de l'adresse de l'exécution dans Autonomy :

service:autonomy-runner-labs @test.run_id:"RUN_ID"

Pour obtenir les métriques de traces APM de Datadog, ajoutez ,compute_stats=true aux Headers. Sans cela, Datadog ne les calcule pas pour les traces ingérées directement. Quand vous modifiez ou renouvelez les en-têtes, enregistrez la valeur complète, dd-api-key compris.

Retrouver une étape échouée

Recherchez les étapes échouées :

service:autonomy-runner-labs status:error @test.status:failed @test.step_index:*

Limitez la recherche à un projet avec @autonomy.project_name:"Storefront".

Un span autonomy.step échoué porte un statut d'erreur. Son test.step_target est le résultat attendu de l'étape tel qu'il est rédigé dans le cas de test, et autonomy.diagnosis.category, quand il est présent, indique pourquoi l'étape n'a pas réussi. Le nom du cas de test (test.plan_name) figure sur le span de l'exécution.

Chaque span porte autonomy.run_url. Ouvrez-le pour voir l'exécution dans Autonomy, y compris les Step Actions effectuées par l'agent et la Final check : ces détails restent dans Autonomy et ne sont pas exportés. Les détails du modèle d'IA, les prompts, les captures d'écran et les messages d'erreur bruts ne sont jamais envoyés à Datadog.

Datadog peut afficher les noms des spans dans ses champs d'opération et de ressource. Filtrez sur les attributs ci-dessus pour être précis. Voir la syntaxe de recherche de traces de Datadog.

Comparer avec une trace de l'application

Chaque exécution a son propre identifiant de trace. Autonomy ne transmet ni cet identifiant ni d'en-tête traceparent à votre application : la trace de l'exécution et les traces des requêtes de votre application sont donc distinctes. Une recherche par identifiant d'exécution ne trouvera pas les requêtes de votre application.

1. Instrumentez votre application et son backend pour qu'ils envoient leurs propres traces à Datadog, avec le service, l'environnement et la ressource de la requête. Des identifiants de requête ou de commande aident à affiner la correspondance.

2. À partir de l'étape échouée, notez sa plage horaire et son résultat attendu. Ouvrez autonomy.run_url et cherchez dans les preuves de l'exécution un identifiant de requête ou un autre identifiant affiché par votre application.

3. Dans un second onglet Trace Explorer, sur la même plage horaire, recherchez le service et l'environnement de votre application, puis affinez par ressource ou par identifiant de requête. Adaptez ceci aux tags de votre application :

   service:checkout-api env:production resource_name:"POST /orders"

4. Vérifiez que les identifiants et la chronologie concordent avant d'incriminer cette requête. Si l'exécution a testé une prévisualisation, recherchez dans l'environnement de prévisualisation : une requête de production survenue à peu près au même moment ne suffit pas à établir une correspondance.

Cette démarche est manuelle. Sans traces de l'application ni identifiant dans les preuves de l'exécution, il est impossible d'isoler une requête précise.

Dépannage

• 401 ou 403 : vérifiez le site Datadog et la clé API. Utilisez dd-api-key, et non une clé d'application ou une clé Autonomy.
• 404 : copiez l'URL de base depuis le tableau. Le chemin de la requête doit aboutir à /v1/traces.
• Le span de test arrive, mais pas les spans des exécutions : vérifiez que Trace export est activé et enregistré, et que l'exécution a démarré après.
• Des spans disparaissent des recherches : vérifiez la plage horaire et les paramètres de rétention des traces de Datadog. Un export accepté n'est pas toujours indexé pour des recherches ultérieures.
• Une exécution a réussi pendant une panne de Datadog : l'export ne modifie jamais le résultat d'une exécution. Conditionnez votre CI au résultat dans Autonomy, pas à la trace.

Pour les runners auto-hébergés et la suppression des identifiants, voir Export OpenTelemetry.