Datadog LLM Observabilidad para la cama: prueba el rastro interno

Datadog LLM Observabilidad para Bedrock puede explicar una llamada de modelo capturada o una invocación de agente, pero un rastro visible aún no es un veredicto de salud. Para un Agente de Amazon Bedrock existente, se requieren cinco recibos: se preparó la configuración prevista, se ejecutó el alias o versión correcta, llegaron eventos de rastreo interno, cualquier transmisión de acción alcanzó un estado definido y el resultado prometido existe en su destino. Esa distinción es importante ahora. AWS dice que Amazon Bedrock Agents ahora es Amazon Bedrock Agents Classic y ya no estará abierto a nuevos clientes a partir del 30 de julio de 2026; los clientes existentes pueden continuar usando. Por lo tanto, esta guía es una auditoría de las implementaciones existentes de Bedrock Agents Classic. No se trata de una recomendación de campo verde, y no asume que una integración de AgentCore tenga una telemetría idéntica. Comience con el contrato exacto de Bedrock que está rastreando La primera trampa es tratar el trazado de Bedrock como una característica. Datadog documenta el seguimiento automático de los métodos de ejecución de Bedrock InvokeModel() y InvokeModelWithResponseStream() . Esos intervalos pueden llevar latencia, errores, mensajes y uso de tokens para una llamada modelo. Un agente de Bedrock usa una operación diferente: InvokeAgent . La actual referencia de instrumentación automática de Datadog dice que su integración Python Bedrock Agents rastrea la llamada general InvokeAgent por defecto. Para exponer los pasos intraagentes, la solicitud deberá utilizar enableTrace=True . AWS da al mismo interruptor un significado operativo: la habilitación de rastreo sigue el proceso de razonamiento, acciones y resultado del agente. La respuesta InvokeAgent es un flujo de eventos que puede contener trozos de salida, eventos de rastreo, errores, citas y una carga útil de control de retorno. Por lo tanto, ver sólo la llamada externa prueba menos que ver la orquestación, la base de conocimientos, el barranco y la evidencia del grupo de acción dentro de ella. Capas de pruebas Lo que demuestra Lo que no demuestra Espacio del modelo de cama Una invocación de modelo capturada, duración, errores y campos de uso disponibles ¿Qué versión del agente pidió la llamada o si la tarea terminó InvokeAgent extensión de raíz La solicitud invocó el tiempo de ejecución del agente Bedrock Esa orquestación anida fue capturada Eventos de rastreo anidados La invocación seleccionada expuso el razonamiento interno y los pasos de acción Que el proyecto previsto haya sido preparado o que exista el efecto externo Componente de respuesta completado Bedrock devolvió la respuesta final de la interacción Que el entregable prometido pasó aceptación Recibo de destino Un archivo, registro, mensaje u otro efecto esperado existe y es válido ¿Por qué un agente anterior se comportó como lo hizo? El defecto útil es mantener la instrumentación automática para las llamadas soportadas y agregar un pequeño recibo de salud libre de contenido alrededor de InvokeAgent . No cargue instrucciones, credenciales, argumentos de herramientas o respuestas completas solo para establecer el estado. Almacenar identificadores, sellos de tiempo, booleanos, recuentos y hashes cuando sean suficientes. Recoger cinco recibos por cada invocación importante La auditoría se hace manejable cuando cada límite posee un recibo. 1. Recibo de configuración preparada AWS distingue el borrador de trabajo de las versiones preparadas y alias. Después de cambiar el borrador de trabajo, debe prepararlo antes de su ensayo o despliegue. AWS también recomienda comprobar el valor preparedAt del agente. Registro: La regla determinista es simple: Si no funciona, clasifique la carrera como CONFIG NOT PREPARED . No depare un rastro detallado como si representara la configuración prevista. 2. Recibo de identidad de la invocación Reutilice el mismo Bedrock sessionId sólo cuando continúe la misma conversación. Mantenga el alias o la versión seleccionada junto a un hash unidireccional del identificador de sesión. Esto une el rango de raíz de Datadog, el flujo de eventos Bedrock y el alcance esperado del operador sin retener el contenido del usuario. Un rastro reciente con el alias equivocado es evidencia de alcance equivocado, no evidencia saludable. 3. Recibo de cobertura interna Establezca la habilidad de rastreo en la solicitud cuando la cuestión operativa dependa de los pasos internos: Nunca imprima los valores en un diagnóstico de producción. El recibo sólo necesita: Si existe el rango de raíz, pero el rastro está desactivado o no llega ningún evento anidado, devuelva TRACE INCOMPLETE . Ese es un veredicto de cobertura. No demuestra que el agente haya fallado. Asimismo, un espacio de raíz de Datadog faltante debe ser TRACE MISSING , no AGENT FAILED . El muestreo, la configuración del exportador, el transporte, las versiones de la biblioteca no compatibles o el pedido de instrumentos pueden eliminar todas las pruebas. Datadog expone un ajuste de la tasa de muestra de rastro, por lo que la ausencia debe preservar la incertidumbre. 4. Recibo por estado de acción Un agente puede invocar un grupo de acción respaldado por Lambda, consultar una base de conocimientos o devolver el control a la aplicación de llamada. En el camino de control de retorno, la solicitud recibe la acción prevista y debe presentar un resultado para continuar. Registrar si: se ha producido un error de acción; la llegada de una carga útil de control de devolución; la solicitud presentó el resultado de la acción correspondiente; Una pieza de respuesta todavía está pendiente. Cuando el control de devolución esté presente y no se haya presentado ningún resultado, el estado correcto será WAITING FOR ACTION RESULT . Tiene un propietario y una acción siguiente. Llamarlo atascado crea alertas ruidosas; llamarlo completo pierde el trabajo. 5. Recibo de resultados Datadog puede colocar evaluaciones personalizadas junto a un rastro, y esas evaluaciones son útiles para controles subjetivos de calidad o políticas. Preferir un verificador determinístico cuando la promesa es inspectable: entrega de archivos: ruta esperada, MIME, tamaño, suma de verificación y esquema; escribir la base de datos: clave de registro, versión y campos requeridos; mensaje de salida: recibo del proveedor y hash de destino; Despliegue: revisión del objetivo más un control de salud independiente; Respuesta de conocimiento: citas requeridas más una regla de aceptación de dominio. El recibo del resultado debe contener la evidencia mínima necesaria para reproducir el veredicto. Una respuesta que dice done no es uno de esos campos. Ejecutar la regla de la decisión de ocho estados El artefacto de acompañamiento aplica los recibos en orden fijo. Fronteras anteriores impiden que pruebas posteriores crean un falso verde: Ejecuté este clasificador contra ocho casos sin contenido. Los ocho coincidieron con sus veredictos esperados: El accesorio da deliberadamente outcomeVerified: true al estuche de preparación obsoleta. Todavía devuelve CONFIG NOT PREPARED , porque un resultado de la configuración preparada incorrecta no puede certificar la liberación prevista. También da una respuesta completa de Bedrock al caso falso completo; sin el recibo de destino, el veredicto final permanece en rojo. Dirigir cada veredicto a una acción limitada El clasificador solo es útil si sus estados cambian el próximo movimiento del operador. El veredicto Primera acción No lo hagas CONFIG NOT PREPARED Preparar el borrador previsto, confirmar preparedAt , luego volver a ejecutar un canario Diagnóstico de viejos rastros como la nueva liberación TRACE MISSING Compruebe las versiones de SDK y rastreador compatibles, el orden de inicialización, la entrega al exportador y la toma de muestras Intentar de nuevo al agente como si la ausencia resultara un fracaso. TRACE INCOMPLETE Confirme que enableTrace=True y que los eventos anidados llegan al rastro de Datadog Llame a la cobertura completa de agentes WORKING Esperar dentro del plazo de la invocación mientras los cambios de progreso anidados Alerta solo sobre el tiempo transcurrido WAITING FOR ACTION RESULT Enviar la solicitud de control de devolución a su propietario con un plazo Reinicie el agente o marque que se ha atascado ACTION FAILED Inspeccione la primera acción fallida y su límite de error; vuelva a intentarlo solo si el efecto es seguro Reproduce ciegamente un efecto secundario incierto FALSE COMPLETE Ejecutar el verificador de destino y reparar el resultado perdido Aceptar el texto final de respuesta como entrega HEALTHY Mantenga el recibo compacto y cierre la carrera Preservar cargas útiles sensibles solo en caso Esta orden también aclara la propiedad del incidente. Los problemas de cobertura de datos pertenecen a la instrumentación o al transporte. Una espera de control de devolución pertenece a la aplicación o al ser humano que posee la decisión externa. Una acción fallida pertenece al límite de la herramienta. Un documento de entrega faltante pertenece al verificador de resultados. Una alerta genérica de error de agente no puede contener esas distinciones. Mantenga los límites de Datadog y Sidewisp honestos Datadog Agent Observability es el lugar adecuado para inspeccionar las huellas capturadas, la estructura del rango, la latencia del modelo y la herramienta, el uso de tokens disponibles, errores y evaluaciones. La documentación de integración de Bedrock proporciona pasos concretos de configuración y validación, incluida la verificación del estado del rastreador y la depuración de problemas de transmisión. La auditoría anterior añade un límite de liberación y resultado; no disminuye la evidencia de rastro. Impide que esa evidencia responda a una pregunta que no fue diseñada para responder sola. Quedan tres limitaciones: 1. La fijación valida la prioridad de la decisión, no la veracidad de los datos de AWS, Datadog o destino. 2. La toma de muestras puede eliminar intencionalmente los rastros. Una cobertura SLO necesita un canario controlado u otro denominador; la ausencia de trazas de producción por sí sola es ambigua. 3. Un juez de LLM puede ayudar con la calidad de la respuesta subjetiva, pero no debe sustituir a una verificación determinista de destino por un efecto inspectable. Para los despliegues actuales de Bedrock Agents Classic, la línea de meta práctica es por lo tanto: versión preparada actual, alcance de invocación correcto, traza interna completa cuando sea necesario, estado de acción resuelto y resultado verificado. Cualquier cosa menos debería seguir funcionando, esperando, incierto o fallido. Sidewisp se encuentra actualmente en versión preliminar privada. Está destinado a añadir una capa de agente salud alrededor de los tiempos de ejecución existentes, pero sus adaptadores de producción Bedrock y Datadog no se envían. Únete a la vista previa privada si este flujo de trabajo de evidencia a la salud coincide con la forma en que operas a los agentes; sigue utilizando Datadog y AWS como su documentación actual apoya hoy. Fuentes Datadog Amazon integración de cama Instrumentación automática de Datadog para la observabilidad del agente Datadog: Agentes de monitoreo construidos en Amazon Bedrock Referencia de API de AWS InvokeAgent AWS: Prueba y resolución de problemas comportamiento del agente