Exportez les traces de vos exécutions de test vers Datadog, Grafana, Honeycomb ou tout backend OTLP — et pivotez d'une étape de test échouée vers la trace de production correspondante.

Autonomy exporte chaque exécution de test sous forme de trace OpenTelemetry vers le backend d'observabilité que votre équipe utilise déjà. Une exécution devient un span autonomy.run avec des enfants autonomy.step et autonomy.action.* imbriqués — les étapes échouées portent le statut d'erreur OTLP, elles remontent donc dans les mêmes suivis d'erreurs, tableaux de bord et alertes que votre trafic de production.

Ce qu'elle fait

Exporte une trace par exécution : autonomy.run → autonomy.step (une par étape du plan) → autonomy.action.* (navigate, fill, tap, wait, …) avec les durées réelles.
Marque les exécutions, étapes et actions échouées avec le statut d'erreur OTLP — les explorateurs de traces les peignent en rouge et les comptent dans les taux d'erreur.
Attache autonomy.run_url à chaque span : un lien profond depuis n'importe quel span de votre backend directement vers la page de preuves de l'exécution dans Autonomy.
Livre automatiquement les identifiants du fournisseur aux runners hébergés — configurez une fois dans le tableau de bord, aucun changement d'environnement runner.
L'export est « fire-and-forget » : un endpoint lent ou injoignable ne retarde ni ne fait échouer une exécution de test.

Ce qui est exporté

Les spans portent un ensemble fixe d'attributs sur liste blanche :

Attribut	Contenu
`test.status`	`passed` / `failed` par étape, statut final sur le span d'exécution
`test.platform`	`web`, `ios`, `android` ou `api`
`test.plan_name`, `test.plan_id`	Le cas de test exécuté
`test.step_index`, `test.step_action`, `test.step_target`	Votre étape de plan telle que rédigée
`autonomy.diagnosis.category`	Classification de l'échec (`app_bug`, `test_flaky`, `environment`, …)
`autonomy.recovery_count`	Tentatives consommées avant le verdict de l'étape — un signal de flakiness sur lequel alerter
`autonomy.run_url`	Lien profond vers l'exécution dans le tableau de bord Autonomy

Rien d'autre ne quitte Autonomy. L'identité des modèles, l'usage de tokens, les prompts, les captures d'écran, le contenu des pages, les messages d'erreur bruts et les noms d'outillage interne ne sont jamais exportés — les échecs sont réduits à des codes de catégorie, et le contrat est appliqué par une liste blanche d'attributs dans l'exporteur.

Configuration

Avant de commencer

Un compte administrateur d'espace de travail — les réglages Observabilité sont réservés aux admins.
Un endpoint d'ingestion OTLP/HTTP sur un nom d'hôte public en https.
Un identifiant d'ingestion pour votre fournisseur (clé API, token ou en-tête basic-auth).

Ouvrez Settings → Observability dans le tableau de bord Autonomy.
Choisissez le préréglage de votre fournisseur — il préremplit la forme de l'endpoint et le format des en-têtes.
Saisissez l'endpoint OTLP. Autonomy ajoute /v1/traces automatiquement ; https est requis.
Saisissez les Headers en paires clé=valeur séparées par des virgules. Ils sont stockés chiffrés et en écriture seule — plus jamais affichés après l'enregistrement.
Cliquez sur Send Test Span. Autonomy poste côté serveur un span synthétique autonomy.test_connection et rapporte le statut HTTP et la latence.
Confirmez l'arrivée du span dans votre explorateur de traces sous le service autonomy-runner-labs, puis activez Trace Export et enregistrez.

Configuration par fournisseur

Datadog

Endpoint : https://otlp.datadoghq.com — utilisez le domaine de votre site (otlp.datadoghq.eu, otlp.us5.datadoghq.com, …).
Headers : dd-api-key=<votre clé API> (une clé API, pas une clé d'application).
Où apparaissent les traces : APM → Traces, service autonomy-runner-labs. Les étapes échouées apparaissent comme spans en erreur ; facettez sur @autonomy.diagnosis.category ou @test.plan_name pour construire des monitors.

Grafana Cloud (Tempo)

Endpoint : https://otlp-gateway-<region>.grafana.net/otlp — copiez-le depuis la page OpenTelemetry → OTLP de votre stack.
Headers : Authorization=Basic <base64 de instanceID:token> — générez le token avec un scope metrics:write/traces:write.
Où apparaissent les traces : Explore avec la source de données Tempo ; requête TraceQL {resource.service.name="autonomy-runner-labs"}.

Honeycomb

Endpoint : https://api.honeycomb.io (UE : https://api.eu1.honeycomb.io).
Headers : x-honeycomb-team=<votre clé d'ingestion>. Sur Honeycomb Classic, ajoutez x-honeycomb-dataset=<dataset>.
Où apparaissent les traces : le dataset autonomy-runner-labs (ou l'environnement de la clé d'ingestion). Un BubbleUp sur test.status = failed est une bonne première requête.

OTLP générique

Tout collecteur ou fournisseur acceptant OTLP/HTTP en JSON sur /v1/traces fonctionne — un OpenTelemetry Collector, SigNoz, Axiom, et la plupart des ingestions natives des fournisseurs. Pointez l'endpoint vers l'URL de base (nom d'hôte public en https — les IP littérales et les noms d'hôtes internes sont rejetés) et fournissez les en-têtes d'authentification attendus par l'ingestion.

Runners auto-hébergés

La configuration du tableau de bord est prioritaire et ne demande aucun changement côté runner. Les runners auto-hébergés sans configuration d'organisation peuvent activer l'export via l'environnement :

Variable	Required	Description
AUTONOMY_OBSERVABILITY_EXPORT	Yes	Mettre à `otel` pour activer l'export basé sur l'environnement.
OTEL_EXPORTER_OTLP_ENDPOINT	Yes	Endpoint OTLP de base ; `/v1/traces` est ajouté automatiquement.
OTEL_EXPORTER_OTLP_HEADERS	No	Paires `clé=valeur` séparées par des virgules, envoyées avec chaque export.
OTEL_SERVICE_NAME	No	Nom de service sur les spans exportés. Par défaut `autonomy-runner-labs`.

Rotation ou suppression des identifiants

Les headers sont en écriture seule : pour effectuer une rotation, collez la nouvelle valeur et enregistrez — elle remplace le secret stocké. Pour déconnecter un fournisseur, utilisez Clear stored headers ; la configuration de l'endpoint reste, mais les exports partent sans en-têtes d'authentification (que la plupart des fournisseurs rejettent) jusqu'à l'enregistrement de nouveaux.

Dépannage

Send Test Span échoue avec HTTP 401 ou 403

L'ingestion a rejeté les identifiants. Revérifiez la clé d'en-tête de votre fournisseur (dd-api-key, Authorization, x-honeycomb-team) et que l'identifiant a bien un scope d'ingestion/écriture.

Send Test Span échoue avec HTTP 404

Aucune ingestion de traces OTLP à cette URL. Saisissez uniquement l'endpoint de base — Autonomy ajoute /v1/traces lui-même ; un chemin doublé est la cause habituelle.

« Endpoint must use https » ou « must be a public hostname »

Seuls les noms d'hôtes publics en https sont acceptés — http simple, IP littérales, localhost et les noms en .internal/.local sont rejetés. Pour un collecteur interne, exposez un ingress https devant lui.

Le span de test fonctionne mais les exécutions n'exportent rien

Confirmez que Trace Export est activé et enregistré, et que vos runners ont repris du travail après le changement — la configuration est livrée quand un runner réclame une exécution. Les échecs de livraison ne font jamais échouer les exécutions ; un identifiant erroné se manifeste par du silence, pas par des erreurs d'exécution. Relancez Send Test Span pour revérifier.

Automation notes

Lors de la configuration de l'intégration observabilité, envoyez toujours un span de test avant d'activer l'export — l'action rapporte le statut HTTP et la latence et valide les en-têtes candidats sans les enregistrer. Ne demandez jamais aux utilisateurs de coller des identifiants ailleurs que dans le champ Headers ; les valeurs sont chiffrées, en écriture seule et illisibles ensuite. L'ensemble d'attributs exportés est une liste blanche fixe — ne promettez pas de noms de modèles, de comptes de tokens, de captures d'écran ni de texte d'erreur brut dans le backend du client ; ces données restent volontairement dans Autonomy. Les endpoints doivent être des noms d'hôtes publics en https ; pour un collecteur interne, recommandez un ingress https, pas une exception de pare-feu.

Observabilité (OTLP)