Observabilidad de LLM en AWS: Auditar destinos de tramos de AgentCore

La respuesta práctica a la observabilidad del LLM en AWS no es "abrir el panel de CloudWatch". Primero, demuestre dónde debe entregar Amazon Bedrock AgentCore los tramos, luego busque cada destino que aún pueda contener evidencia, verifique la sesión y rastree la identidad, rechace observaciones obsoletas y una el rastreo a un recibo separado para el resultado externo deseado. Ese orden es importante porque el destino de AgentCore puede cambiar. La documentación actual de AWS dice que los nuevos agentes admitidos pueden enviar intervalos a un grupo de registros por agente, mientras que las configuraciones más antiguas pueden usar el compartido. aws/spans grupo. Versiones ADOT anteriores 0.18.0 ignore la configuración de destino unificado. Cambiar la configuración no mueve los tramos antiguos. Por lo tanto, una consulta únicamente contra el grupo de registros actual puede producir un diagnóstico falso de "no telemetría" incluso cuando la evidencia faltante está exactamente donde la puso la configuración anterior. Esta guía crea una auditoría sin contenido para ese límite. Utiliza la identidad del recurso, la versión, el destino, las marcas de tiempo, los identificadores de correlación, el estado de ejecución y un recibo de resultado booleano. No requiere indicaciones, respuestas, argumentos de herramientas ni secretos. Localizar las pruebas antes de declararlas desaparecidas Observabilidad de AgentCoreproporciona métricas integradas para los recursos de AgentCore y almacena métricas, intervalos y registros en Amazon CloudWatch. El límite importante es que las métricas integradas no son lo mismo que los seguimientos de aplicaciones. AWS documenta los espacios predeterminados para los recursos de memoria, mientras que el tiempo de ejecución del agente y los detalles del seguimiento de la puerta de enlace dependen de la instrumentación. Eso crea tres preguntas separadas: 1. ¿Está habilitada la ruta de observación de AWS? CloudWatch Transaction Search debe estar habilitado y el destino del segmento de seguimiento debe ser CloudWatch Logs. 2. ¿Dónde deberían aterrizar los tramos actuales? La respuesta depende de la configuración del destino unificado, el soporte de la región, la antigüedad del agente, la función de ejecución y la versión de ADOT. 3. ¿Dónde pueden permanecer los intervalos históricos? Cualquier destino utilizado antes de un cambio sigue siendo parte de la ventana de investigación porque AWS no migra los datos de intervalos existentes. ElGuía de configuración de AgentCoreproporciona un límite operativo particularmente útil: la entrega unificada por agente requiere aws opentelemetry distro =0.18.0 . Las versiones anteriores ignoran la configuración y entregan intervalos al grupo compartido. La misma guía requiere permiso para instalar la política de recursos de CloudWatch Logs relevante. Utilice esos datos para calcular un destino esperado antes de realizar la consulta: Observación Alcance de búsqueda actual esperado Conclusión del operador Búsqueda de transacciones deshabilitada Ninguno es confiable todavía Arreglar la configuración; no inferir la salud del agente Segmentos de seguimiento no enrutados a CloudWatch Logs Ninguno es confiable todavía Corregir el requisito previo del destino Unificado solicitado, ADOT a continuación 0.18.0 Compartido aws/spans Un grupo por agente en blanco es un error de alcance de consulta Política unificada activa y de roles permitida Grupo de registros de tiempo de ejecución por agente Verifique los tramos actuales allí El destino cambió durante la ventana de revisión Grupos actuales y anteriores. Busque ambos; Los viejos tramos permanecen donde aterrizaron. Esta tabla no es deliberadamente una verificación única de "telemetría presente". Un registro faltante en el grupo por agente puede significar un error de configuración, una entrega bloqueada, una versión antigua de ADOT o un registro histórico correcto en el grupo compartido. Esos estados necesitan reparaciones diferentes. Mantenga un registro de transición de destino No haga del entorno activo su única fuente de verdad. Almacene un pequeño registro de transición al lado del runbook: El registro no contiene ningún mensaje o respuesta. Responde a la pregunta de planificación de consultas que un panel no puede reconstruir más adelante: ¿qué destinos se superponen a la ventana del incidente? Ejecute una auditoría AgentCore consciente de la migración La auditoría utilizada para este artículo evalúa once casos fijos. Su contrato de insumos es intencionalmente pequeño: Su orden de decisión es más importante que su sintaxis: Al ejecutar el clasificador sobre el dispositivo se produjo: Los casos cubren la búsqueda de transacciones deshabilitada, el destino de seguimiento incorrecto, el ADOT antiguo consultado solo en el grupo por agente, evidencia histórica omitida después de un cambio, autoridad de entrega insuficiente, falta de un intervalo actual, evidencia obsoleta, correlación rota, una espera de aprobación legítima, finalización falsa y un resultado saludable consciente de la migración. Esta es una prueba de decisión, no una prueba sobre una cuenta de AWS activa. Adapte sus entradas desde su propia configuración y consultas canarias. Preservar el orden: de lo contrario, un genérico. telemetry missing El veredicto puede ocultar el hecho mucho más procesable de que el operador buscó en el lugar equivocado. Preservar la identidad de la sesión, la identidad del rastreo y la frescura AWS describe la observabilidad de AgentCore como una jerarquía: una sesión contiene seguimientos y un seguimiento contiene intervalos. Eldocumentación de telemetríahace explícita esa jerarquía. Sólo es útil si la identidad sobrevive a la ruta de solicitud. Para las llamadas en tiempo de ejecución de AgentCore instrumentadas por ADOT, la guía de configuración documenta dos detalles de propagación: enviar X Amzn Bedrock AgentCore Runtime Session Id entonces el ID de la sesión llega a la telemetría descendente; invocar el tiempo de ejecución con traceId=<traceId cuándo se debe propagar un ID de seguimiento. Registre si esos identificadores están presentes, no su contexto de carga útil confidencial. Un lapso sin una sesión a la que se pueda unir aún puede demostrar que el código se ejecutó, pero no puede admitir una línea de tiempo de incidentes a nivel de sesión. Clasifícalo como correlation broken , no saludable. La frescura necesita un contrato igualmente explícito. Un rastro encontrado la semana pasada no prueba que la entrega funcione ahora. Definir: Elija la edad máxima entre la cadencia esperada del flujo de trabajo y la tolerancia a incidentes. Cinco minutos es razonable para un canario de cada minuto; no es razonable para un lote nocturno. Guarde el umbral con el veredicto para que "fresco" permanezca inspeccionable. La espera también necesita pruebas. Si un seguimiento muestra una dependencia de aprobación limitada con un propietario y la ejecución se puede reanudar, devuelva waiting . No lo indique como atascado simplemente porque no apareció ninguna nueva herramienta. Si el registro de aprobación está ausente, es contradictorio o está vencido, devolver uncertain o escalar según el runbook. Requerir un recibo de resultado después del seguimiento Un seguimiento completo responde "¿terminó la ruta de ejecución instrumentada?" No necesariamente responde "¿se realizó el trabajo previsto?" La distinción es visible en fallas comunes: una herramienta de carga regresa antes de que el destino confirme el objeto; una API de mensajes acepta una solicitud pero el mensaje nunca llega al canal previsto; un agente escribe un archivo local mientras el artefacto requerido pertenece al almacenamiento remoto; la llamada al modelo final tiene éxito después de que una transacción posterior ya se haya revertido; una espera de aprobación se convierte incorrectamente en éxito del terminal. Guía prescriptiva de AWSrecomienda correlacionar la evidencia de LLM con el impacto posterior. Una implementación con privacidad mínima puede hacer eso con un recibo de resultado: El recibo debe producirse mediante el control determinista más fuerte disponible: un objeto HEAD , una base de datos leída por clave estable, una recuperación de API pública, una suma de verificación o una prueba dirigida. No debe contener el cuerpo del objeto, el mensaje, la respuesta o el secreto. Mantenga los dos veredictos separados: Rastrear evidencia recibo de resultados Estado Desaparecido o obsoleto Cualquier La evidencia de observabilidad es insuficiente. Completo Desaparecido false complete Esperando aprobación registrada No esperado todavía waiting Completo y fresco Presente y verificado healthy para este resultado probado La última fila tiene alcance. Demuestra el canario y el destino fijos, no todas las rutas, todas las tareas o la calidad de la salida semántica. Adopte la auditoría sin recopilar contenido Un recibo de producción útil sólo necesita datos suficientes para distinguir las capas de falla: identificadores de recursos de agente y puntos finales en forma redactada o hash; Región y tiempo de observación; Búsqueda de transacciones y estado de rastreo del destino; Versión ADOT y configuración de destino unificado; clases de destino actuales y anteriores; si se buscaron ambos destinos en la ventana de investigación; hora canaria coincidente más reciente; presencia de ID de sesión y ID de seguimiento; estado de ejecución y estado de aprobación acotado; identidad de operación estable y estado determinista de resultado recepción. Mantenga el texto de las indicaciones, las respuestas de los modelos, los argumentos de las herramientas, las credenciales, los encabezados sin formato y las cargas útiles del cliente fuera de este recibo. Si se requiere una inspección de contenido más profunda para un incidente específico, autorícela y alcance su alcance por separado. La auditoría también tiene límites. No demuestra la cobertura de la instrumentación en todas las rutas de la aplicación, la integridad del muestreo, la retención de CloudWatch, la recuperación de exportaciones o la calidad de la respuesta semántica. Demuestra que la ruta de evidencia seleccionada está configurada y se puede buscar, el canario está actualizado y correlacionado, y el resultado externo seleccionado tiene su propio recibo. Esto es suficiente para evitar un costoso error de categoría: cambiar el agente porque un operador buscó el destino del tramo equivocado. Sidewisp se encuentra actualmente en versión preliminar privada.Su función prevista es convertir pruebas como la cobertura del destino, la actualidad, la correlación, el estado de espera y la verificación de resultados en una visión de salud clara. Los adaptadores de monitoreo Production AgentCore y CloudWatch no se envían actualmente, por lo que este artículo es un patrón operativo que puede aplicar ahora, no una afirmación queSidewispya ejecuta esta auditoría.