Datadog

Autonomy envía las trazas de las ejecuciones a Datadog a través de su endpoint de ingesta de trazas OTLP/HTTP. Cada ejecución se convierte en un span autonomy.run con un span autonomy.step por cada paso. Configúralo en Organization → Integrations → OpenTelemetry. Para saber qué contienen los spans, consulta Exportación a OpenTelemetry.

Antes de empezar

La credencial es una clave de API de Datadog. Las claves de aplicación de Datadog y las claves aut_ de Autonomy no funcionan. Ponla en el campo Headers, donde Autonomy la guarda como secreto y no la vuelve a mostrar.

Elegir tu endpoint de Datadog

Introduce la URL base de tu sitio de Datadog como OTLP endpoint. Autonomy añade /v1/traces y envía JSON por HTTPS, que Datadog acepta.

Siguen el selector de sitio de ingesta de trazas OTLP de Datadog. Una clave de un sitio no funciona en el endpoint de ingesta de otro sitio.

Conectar y verificar

1. Abre Organization → Integrations → OpenTelemetry y elige Datadog como Vendor.

2. Pega la URL base de tu sitio en OTLP endpoint. Escríbela aunque el texto de ejemplo ya muestre la dirección correcta.

3. Introduce esto en Headers, con tu clave de API en lugar de YOUR_DATADOG_API_KEY:

   dd-api-key=YOUR_DATADOG_API_KEY

4. Pulsa Send test span. Una respuesta correcta significa que Datadog aceptó la petición; el span puede tardar un poco en poder buscarse.

5. En Datadog, abre APM → Trace Explorer, elige un intervalo de tiempo reciente y busca service:autonomy-runner-labs. Localiza el span autonomy.test_connection.

6. Activa Trace export y pulsa Save settings. Inicia una ejecución nueva.

7. Cuando la ejecución termine, búscala. Sustituye RUN_ID por el ID que aparece al final de la dirección de la ejecución en Autonomy:

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

Para las métricas de trazas de APM de Datadog, añade ,compute_stats=true a Headers. Si no, Datadog no las calcula para las trazas ingeridas directamente. Cuando cambies o rotes las cabeceras, guarda el valor completo, incluido dd-api-key.

Localizar un paso fallido

Busca los pasos fallidos:

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

Limítalo a un proyecto con @autonomy.project_name:"Storefront".

Un span autonomy.step fallido tiene un estado de error. Su test.step_target es el resultado esperado del paso tal como está escrito en el caso de prueba, y autonomy.diagnosis.category, cuando existe, indica por qué no se superó. El nombre del caso de prueba (test.plan_name) está en el span de la ejecución.

Cada span tiene autonomy.run_url. Ábrelo para ver la ejecución en Autonomy, incluidas las Step Actions que realizó el agente y el Final check: esos detalles se quedan en Autonomy y no se exportan. Nunca se envían a Datadog detalles del modelo de IA, prompts, capturas ni mensajes de error en bruto.

Datadog puede mostrar los nombres de los spans en sus campos de operación y de recurso. Filtra por los atributos de arriba para ser preciso. Consulta la sintaxis de búsqueda de trazas de Datadog.

Comparar con una traza de la aplicación

Cada ejecución tiene su propio ID de traza. Autonomy no pasa ese ID ni una cabecera traceparent a tu app, así que la traza de la ejecución y las trazas de las peticiones de tu app están separadas. Una búsqueda por ID de ejecución no encontrará las peticiones de tu app.

1. Instrumenta tu app y su backend para que envíen sus propias trazas a Datadog, con el servicio, el entorno y el recurso de la petición. Los IDs de petición o de pedido ayudan a afinar la coincidencia.

2. Del paso fallido, anota su intervalo de tiempo y su resultado esperado. Abre autonomy.run_url y busca en la evidencia de la ejecución un ID de petición u otro identificador que muestre tu app.

3. En una segunda pestaña de Trace Explorer, con el mismo intervalo de tiempo, busca el servicio y el entorno de tu app y después acota por recurso o por ID de petición. Adáptalo a las etiquetas de tu app:

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

4. Comprueba que los identificadores y los tiempos coinciden antes de culpar a esa petición. Si la ejecución probó una previsualización, busca en el entorno de la previsualización: una petición de producción en un momento parecido no basta por sí sola.

Esto es manual. Sin trazas de la app o un identificador en la evidencia de la ejecución, no hay forma de aislar una petición concreta.

Solución de problemas

• 401 o 403: comprueba el sitio de Datadog y la clave de API. Usa dd-api-key, no una clave de aplicación ni una clave de Autonomy.
• 404: copia la URL base de la tabla. La ruta de la petición debe acabar siendo /v1/traces.
• El span de prueba llega, pero los spans de las ejecuciones no: comprueba que Trace export está activado y guardado, y que la ejecución empezó después.
• Los spans desaparecen de las búsquedas: revisa el intervalo de tiempo y los ajustes de retención de trazas de Datadog. Una exportación aceptada no siempre se indexa para búsquedas posteriores.
• Una ejecución se superó durante una caída de Datadog: la exportación nunca cambia el resultado de una ejecución. Usa el resultado en Autonomy para condicionar el CI, no la traza.

Para los runners autoalojados y la eliminación de credenciales, consulta Exportación a OpenTelemetry.