Datadog

Connectez Autonomy à Datadog via son ingestion de traces OTLP/HTTP. Chaque exécution produit un span autonomy.run, des spans autonomy.step imbriqués et des enfants autonomy.action.*. L'intégration est disponible dès maintenant dans Settings → Observability pour les exécutions effectuées par runner-labs.

Avant de commencer

L'identifiant d'ingestion est une clé API Datadog. Les clés d'application et les clés Autonomy aut_ ne permettent pas de s'authentifier auprès de Datadog. Conservez-la dans le champ Headers, où Autonomy la stocke chiffrée sans jamais la renvoyer au tableau de bord.

Choisir votre endpoint Datadog

Saisissez l'URL de base correspondant à votre site Datadog dans OTLP Endpoint. Autonomy ajoute /v1/traces et envoie du JSON via HTTPS. Datadog prend en charge cet encodage http/json.

Ces URL correspondent au sélecteur de site de l'ingestion OTLP de traces actuel de Datadog. Une clé d'un site ne permet pas de s'authentifier auprès de l'ingestion d'un autre site.

Connecter et vérifier

1. Ouvrez Settings → Observability dans Autonomy et sélectionnez Datadog.

2. Collez l'URL de base de votre site dans OTLP Endpoint. Saisissez-la explicitement, même si le texte indicatif affiche la bonne adresse.

3. Saisissez cette valeur 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 HTTP réussie confirme que l'ingestion a accepté la requête ; elle ne prouve pas que le span est déjà consultable.

5. Dans Datadog, ouvrez APM → Trace Explorer, sélectionnez une période récente et recherchez service:autonomy-runner-labs. Repérez le span autonomy.test_connection.

6. Activez Trace Export et cliquez sur Save Configuration. Lancez une nouvelle exécution de cas de test pour que son runner reçoive la configuration enregistrée.

7. Une fois l'exécution terminée, recherchez son identifiant avec la requête ci-dessous. Remplacez RUN_ID par l'identifiant présent dans l'URL de l'exécution Autonomy. Ouvrez la trace et confirmez la réception des spans d'exécution et d'étape.

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

Pour obtenir les métriques de traces APM de Datadog, vous pouvez ajouter ,compute_stats=true à Headers. L'ingestion directe ne calcule pas ces métriques par défaut. Enregistrez la valeur complète de l'en-tête, y compris dd-api-key, lors d'une modification ou d'une rotation.

Examiner une étape échouée dans APM

Exécutez un cas de test contenant une assertion dont l'échec est connu dans un environnement de test. Réglez la période de Trace Explorer sur cette exécution et recherchez :

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

Le span autonomy.step échoué porte le statut d'erreur OTLP (code: 2). Examinez test.step_action, test.step_target, autonomy.recovery_count et autonomy.diagnosis.category lorsqu'il est présent. Ouvrez la cascade de sa trace pour voir les durées des actions. Il s'agit de spans APM, pas d'une intégration distincte de gestion des tests Datadog.

Les spans d'exécution et d'étape contiennent autonomy.run_url ; ouvrez cette URL pour retrouver les preuves de l'exécution dans Autonomy. Les spans d'action contiennent autonomy.action.success et héritent de leur position dans la trace, mais ne portent pas eux-mêmes l'URL de l'exécution. Les noms des cas de test (test.plan_name) figurent sur le span d'exécution. Cette intégration n'exporte ni détails des modèles, ni prompts, ni captures d'écran, ni messages d'erreur bruts.

Datadog peut associer les noms de span à ses champs d'opération et de ressource. Utilisez les attributs exportés pour filtrer de façon fiable ; la syntaxe de recherche des traces Datadog explique les requêtes par attribut.

Passer à une trace de l'application

Autonomy crée un identifiant de trace indépendant pour chaque exécution. Il n'injecte ni cet identifiant ni un en-tête traceparent dans votre application web ou mobile. La trace Autonomy et celle de la requête applicative sont donc distinctes ; rechercher un identifiant d'exécution ne retrouve pas automatiquement les requêtes de production.

1. Instrumentez l'application et ses services backend pour envoyer leurs propres traces à Datadog. Ils doivent enregistrer le service, l'environnement et la ressource de requête concernés ; les identifiants de requête ou de commande facilitent la recherche.

2. Notez la période et la cible de l'étape Autonomy échouée. Utilisez autonomy.run_url pour examiner les preuves de l'exécution et y trouver un identifiant de requête ou un autre identifiant, si votre application l'expose.

3. Ouvrez un second onglet Trace Explorer sur la même période. Recherchez le service et l'environnement de l'application, puis affinez avec la ressource réelle ou l'identifiant de requête. Par exemple, adaptez ces valeurs aux tags de votre application :

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

4. Ouvrez la trace candidate et confirmez que ses identifiants et ses horaires correspondent avant d'y attribuer l'échec. Si l'exécution ciblait une prévisualisation, utilisez son environnement ; une trace de production proche dans le temps ne suffit pas à établir une correspondance.

Cette corrélation est manuelle. Sans instrumentation applicative ou preuves permettant de distinguer la requête, l'intégration ne peut pas identifier une trace de production unique.

Dépannage

• HTTP 401 ou 403 : vérifiez le site Datadog et la clé API. Utilisez dd-api-key, pas une clé d'application ni une clé Autonomy.
• HTTP 404 : copiez l'URL de base du tableau. Le chemin de la requête obtenue doit être /v1/traces.
• Le span de test arrive, mais pas les spans d'exécution : confirmez que Trace Export est activé et enregistré, que l'exécution a commencé ensuite et qu'elle s'est déroulée sur runner-labs. Les runners auto-hébergés peuvent modifier le nom du service avec OTEL_SERVICE_NAME.
• Des spans disparaissent des recherches : vérifiez la période sélectionnée et les paramètres de rétention des traces Datadog. L'acceptation d'un export ne garantit pas que chaque span sera indexé pour les recherches ultérieures.
• Une exécution réussit malgré une panne Datadog : l'export tente de livrer les traces sans modifier le verdict de l'exécution. Utilisez le résultat Autonomy pour autoriser ou bloquer la suite de votre CI.

Pour les variables d'environnement des runners auto-hébergés et la suppression des identifiants, consultez Observabilité (OTLP).