Elastica LLM Observabilidad: apoyo a la auditoría antes de que se produzca el verde

La observabilidad elástica de LLM puede decir mucho sobre las llamadas de modelo, pero una vista verde de Kibana aún no es un veredicto de salud para el agente. Antes de confiar en él, verifique cinco capas en orden: el camino de recogida, el soporte para el par exacto de idioma/proveedor, la actualidad de la telemetría, los campos de GenAI requeridos y el resultado de destino. Esa orden importa. Los documentos elastónicos utilizan dos métodos de recogida: integraciones de proveedores para métricas y registros, y rastreo de aplicaciones a través de las distribuciones elastónicas de OpenTelemetry (EDOT). Esos métodos tienen una cobertura diferente. Incluso un período LLM sin errores y compatible no demuestra que se haya ejecutado la lógica de negocio específica de la aplicación o que exista el producto entregado prometido. Esta guía convierte esos límites en una pequeña auditoría que puedes realizar antes de despejar un incidente. Identifique el camino de recogida antes de leer el panel El LLM y AI observabilidad general de Elastic describe un amplio conjunto de integraciones de proveedores, rastros APM, métricas, registros y tablas de control. El primer error operativo es comprimir todo eso en una capacidad llamada monitoreo elástico. Mantenga dos aviones de recogida separados: El avión Lo que produce la evidencia Útil para Lo que no establece Integración de proveedores Un proveedor o servicio en la nube envía métricas y registros Errores del proveedor, latencia, uso, eventos de barandilla, salud de la plataforma Que su solicitud emitió un LLM span o completó su propio efecto herramienta Seguimiento de las aplicaciones EDOT Un proceso de Java, Node.js o Python con instrumentos exporta extensiones OTLP Flujo de solicitudes, llamadas de modelo, duración, errores, campos de tokens, correlación Que las bibliotecas no soportadas fueron instrumentalizadas o que existe el entregable externo Esto no es una debilidad del producto. Es un límite de pruebas. Una integración de Bedrock puede ofrecer nuevas métricas de servicio mientras que una aplicación Java no tiene una instrumentación documentada EDOT Bedrock LLM. Por el contrario, un espacio de tiempo del cliente OpenAI puede ser completo mientras que una escritura de base de datos personalizada posterior no está instrumentada. El actual Página de apoyo EDOT LLM de Elastic hace concreto el límite entre el idioma y el proveedor: Camino del proveedor EDOT Java EDOT Node.js EDOT Python : : : Cliente de OpenAI El apoyo El apoyo El apoyo AWS Bedrock No incluidos en la lista No incluidos en la lista El apoyo Google Vertex AI No incluidos en la lista No incluidos en la lista El apoyo La página etiqueta la observabilidad de LLM en las tres distribuciones EDOT como vista previa técnica y dirige a los operadores a páginas específicas de SDK para obtener versiones exactas. Trata esa mesa como un instantáneo de apoyo datado, no una promesa de capacidad eterna. Por lo tanto, la auditoría comienza con dos preguntas que un panel no puede responder por usted: 1. ¿Qué avión contendrá la evidencia de este incidente? 2. ¿Tiene el lenguaje implementado, el proveedor, el paquete del cliente y la versión documentada la instrumentación en ese avión? Si la respuesta a la segunda pregunta es no, no espere a que aparezca un espacio que falta. Clasifique la ruta como no compatible, elija la instrumentación OpenTelemetry nativa o manual documentada o cambie el requisito de evidencia. No hay errores en Elastic no es significativo cuando nunca se esperaba que el evento relevante fuera capturado. Soporte de prueba y esquema como puertas separadas Apoyado no significa observado, y observado no significa completo. El Tabla de tecnología Python EDOT documenta las versiones de Python, los rangos de paquetes de clientes, los nombres de rastreadores y el estado de la convención semántica. En el momento de la presente revisión, su línea de instrumentación OpenAI etiqueta las convenciones semánticas como development . La misma página dice explícitamente que la instrumentación automática no puede cubrir marcos personalizados o propietarios, componentes sin soporte de código cerrado o lógica de negocio específica de aplicaciones. Eso nos da cuatro controles distintos: 1. Support: la matriz documentada incluye el par de idioma/proveedor. 2. Reaccionabilidad: el receptor y el camino de ingesta aceptan la telemetría de corriente. 3. Presencia: la carrera produce el lapso esperado de LLM. 4. Schema: el intervalo contiene los campos requeridos para la decisión del operador. Un contrato de campo mínimo puede requerir: No confundas este ejemplo con un esquema universal. Pinta las versiones de convención semántica e instrumentación utilizadas por tu despliegue. Las antiguas páginas de convenciones de GenAI de OpenTelemetry ahora apuntan a un repositorio dedicado de convenciones semánticas de GenAI, que es otra razón para registrar la procedencia en lugar de suponer que un conjunto de atributos es atemporal. El siguiente clasificador conserva los estados de falla importantes: Ejecutar la auditoría contra una fijación en lugar de probar sólo el camino feliz: El conjunto de nueve casos que lo acompañó produjo nueve veredictos esperados: Esta prioridad evita un error de seguimiento común: dejar que una señal verde posterior oculte una brecha de evidencia anterior. Un período exitoso no puede anular un cheque de colector inaccesible, y una carrera completada no puede anular un recibo de destino faltante. Preservar la espera, la falta de evidencia y el fracaso como estados diferentes Una pausa de aprobación no es un fallo de la instrumentación. Un lapso faltante no es automáticamente un fallo del proveedor. Un sendero sin soporte no es una telemetría obsoleta. Estas distinciones cambian el siguiente movimiento del operador: El veredicto Significado La próxima acción restringida UNSUPPORTED PATH La instrumentación automática LLM prevista está fuera de la matriz documentada Añadir extensiones documentadas nativas/manuales o cambiar el contrato de pruebas TELEMETRY STALE Existen pruebas relevantes, pero no dentro de la ventana de frescura de la carrera Compruebe exportación, colector, ingesta, reloj y ventana de consulta INSTRUMENTATION GAP El camino está soportado y llega una nueva telemetría, pero el espacio LLM está ausente. Verificar el rango de paquetes, la banda de arranque, la instrumentación desactivada y la identidad del rastreador SCHEMA GAP El plazo existe pero no puede responder a la pregunta requerida Verifique la versión de la convención y el mapeo de campos; informe que el campo no está disponible mientras tanto WAITING Una dependencia o aprobación nombrada es excepcional Notifique al propietario registrado; no vuelva a probar la herramienta a ciegas FALSE COMPLETE El Elastic muestra una finalización limpia pero el resultado prometido no está verificado Realice una verificación determinista del destino antes de cerrar el incidente Observe lo que la tabla no recomienda: tratar cada hueco como una razón para reiniciar el agente. La recuperación sin diagnóstico puede duplicar efectos externos, gastar más tokens o borrar evidencia útil. Para la espera legítima, retenga un propietario, razón, hora de inicio, fecha límite y condición de reanudación. Eso transforma una pausa ambigua en un estado operativo inspectable. Si el plazo pasa, el estado puede quedar atascado o necesitar atención humana, pero la pausa original no fue un fracaso simplemente porque no llegaron nuevos períodos. Requerir un recibo de resultado fuera del rastro Un LLM span responde a una pregunta de llamada de modelo. El producto entregado pertenece a la solicitud. Supongamos que un agente pide a un modelo que prepare una factura, llama a una API interna e informa la finalización. Elástico puede mostrar: un rastro fresco; el proveedor esperado y el modelo; no hay excepción; la latencia plausible y el recuento de tokens; una transacción de raíz completada. La factura aún puede estar ausente. La API personalizada puede haber aceptado la solicitud sin comprometerla, un trabajador asincrónico puede haber fallado o el agente puede haber saltado la herramienta y producido solo una reclamación textual. Definir el recibo determinista más pequeño que demuestre el efecto prometido. Los ejemplos incluyen: el objeto esperado existe en el destino y coincide con un hash de contenido; una fila de base de datos tiene la clave de negocio prevista y el estado de compromiso; existe una solicitud de extracción en el repositorio esperado y en la SHA principal; un punto final del informe devuelve la nueva versión y aprueba la validación del esquema; un proveedor de mensajes devuelve un identificador de entrega que puede ser reconciliado posteriormente. Solo debe almacenarse la evidencia mínima segura: La identificación de rastro proporciona una correlación. No es la prueba en sí misma. En la fijación, la única diferencia entre FALSE COMPLETE y HEALTHY es outcomeVerified: true ; ninguno de los campos de extensión Elastic cambia. Esta es la regla central de funcionamiento: limpiar un incidente sólo cuando la cobertura telemétrica y la evidencia de resultados de la aplicación coinciden. Tratar la privacidad y la deriva de versiones como parte de la salud La visión general de Elastic dice que el rastreo de LLM puede capturar las instrucciones y respuestas. Eso puede ser útil para el diagnóstico, pero también cambia los límites de los datos. Decida explícitamente si el contenido está permitido antes de permitirlo. Prefiere identificadores, longitudes, hashes, clasificaciones, recuentos de tokens y categorías de errores editados cuando no se requiere el contenido completo. Registrar estos valores en cada auditoría de cobertura: la versión de distribución de EDOT y el despliegue elástico; el tiempo de ejecución del lenguaje y la versión del paquete del cliente con instrumentos; el paquete de instrumentos activos y el nombre del rastreador; fuente y revisión de la convención semántica; la vía de recogida y ingesta; los campos requeridos y la ventana de frescura; la política de captura de contenido; versión del verificador de destino. Vuelve a ejecutar la fijación cuando alguno de esos valores cambie. Una actualización del paquete puede agregar soporte, renombrar o migrar campos, o alterar la instrumentación predeterminada. Un objeto guardado en el tablero de instrumentos puede permanecer verde mientras sus suposiciones se vuelven obsoletas. El defecto práctico es modesto: utilizar Elastic para el modelo y la evidencia de aplicación que realmente recopila, mantener explícitas las señales no soportadas o faltantes, y agregar un recibo determinista para el resultado al que el usuario se preocupa. Eso produce una decisión de salud defendible sin pretender que un tablero posee cada capa. Sidewisp se encuentra actualmente en versión preliminar privada. Su dirección de producto es convertir pruebas como la accesibilidad, el progreso, el acceso a las herramientas, el contexto, el costo y los resultados verificados en una visión clara de la salud; los adaptadores de monitoreo Elastic en vivo no se envían actualmente. Si esta distinción entre la finalización del rastro y el trabajo real importa en su pila de agentes, la lista de espera de vista previa privada es el lugar adecuado para compartir el caso de falla que necesita cubrir.