Observabilidad de New Relic LLM: demuestre que una ruta es dueña de cada llamada

La observabilidad de New Relic LLM puede mostrar la latencia del modelo, tokens, errores, seguimientos y datos de respuesta de la IA. Por sí solo, no puede decirle a un operador si dos recolectores contaron la misma llamada de modelo o si el agente produjo el resultado externo solicitado. Lo práctico por defecto es nombrar un propietario de instrumentación para cada límite de llamada de modelo , correlacionar cada registro con una identificación de llamada sin contenido y conservar un recibo separado para el entregable. Esa regla es importante porque New Relic documenta varios caminos legítimos. es nativoMonitoreo de IAutiliza agentes APM. New Relic también documentaOpenLIT sobre OTLPpara trazas y métricas yOpenLLMetry sobre OTLPpor rastros. LiteLLM tiene un separadoNueva integración de reliquiasconstruido alrededor de su devolución de llamada y el agente New Relic Python. Esos caminos son opciones, no evidencia de que todos deban instrumentar el mismo límite. Se puede completar un panel mientras la propiedad es incorrecta, la evidencia está obsoleta, falta un campo obligatorio o una llamada de modelo completada no tiene un resultado verificado. Declare la ruta antes de confiar en la carta Comience con un manifiesto de implementación, no con una consulta. Debe identificar el servicio, el límite que se está instrumentando, el propietario autorizado a informar ese límite, los tipos de señales que ese propietario puede emitir, el campo de correlación y el límite de frescura. La distinción entre un propietario y un tipo de señal evita un grave error de deduplicación. Un propietario declarado puede emitir deliberadamente un intervalo de APM y un evento de mensaje de IA para la misma llamada. Esos registros son complementarios cuando comparten el mismo ID de llamada y el contrato de implementación prevé ambos. Un registro OpenLIT y un registro OpenLLMetry para ese mismo límite son dos propietarios, incluso si sus campos parecen similares. El manifiesto debe ser producido por la implementación que permitió la instrumentación. No lo infieras a partir de cualquier entidad que aparezca en la interfaz de usuario. Las rutas de configuración establecen la identidad de manera diferente: El monitoreo de New Relic AI comienza con un agente APM y una biblioteca o marco compatible. OpenLIT envía seguimientos y métricas al punto final OTLP de New Relic. OpenLLMetry envía seguimientos a ese punto final y New Relic deriva la entidad de servicio de OpenTelemetry service.name atributo de recurso. LiteLLM permite una newrelic devolución de llamada y utiliza el agente New Relic Python para la telemetría APM. Su documentación dice que la devolución de llamada registra un mensaje de inicialización y que los detalles del seguimiento pueden tardar de dos a tres minutos en aparecer. Esto es suficiente para requerir un registro de ruta explícito. No es evidencia de que un par en particular siempre duplique una llamada. La afirmación de que hay operaciones seguras es más limitada: si se observa a dos propietarios en un límite cuyo manifiesto permite uno, los totales y los veredictos de salud son ambiguos hasta que se concilie el despliegue. Utilice un identificador de llamada opaco en lugar de un hash de aviso. Un sobre de observación útil puede permanecer libre de contenido: El contenido de avisos y respuestas no es necesario para la propiedad, la actualización, la presencia en el campo del token o la verificación del destino. LiteLLM documenta tanto una nueva reliquia específica turn off message logging configuración y un interruptor de entorno que deshabilita la grabación de contenido de monitoreo de IA. Trate la retención de contenido como una decisión de privacidad separada; no lo encienda simplemente para que funcione la auditoría de propiedad. Vuelva a reproducir los ocho estados que oculta una vista verde La auditoría adjunta utiliza ocho llamadas sintéticas. Se aplica esta precedencia: 1. sin observación; 2. propietario esperado ausente; 3. más de un propietario; 4. tipo de señal inesperada o falta un campo obligatorio; 5. evidencia obsoleta; 6. espera legítima; 7. finalización sin recibo de resultado; 8. finalización con un recibo de resultado. La precedencia importa. Un registro obsoleto del propietario correcto no es saludable. Un registro nuevo del propietario equivocado tampoco es saludable. La espera se evalúa solo después de que pasan la propiedad, la forma y la frescura, por lo que una pausa de aprobación no puede ocultar una colección rota. El dispositivo completo no contiene indicaciones ni respuestas. Ejecutarlo produce ocho veredictos diferentes: El clasificador es deliberadamente pequeño: Cada veredicto no saludable apunta a una reparación diferente: Veredicto lo que establece Próxima acción limitada NO TELEMETRY No llegó ningún registro de la llamada esperada Verifique la inicialización de la instrumentación, la accesibilidad del exportador y la ventana de consulta ROUTE DRIFT Llegaron datos, pero no del propietario declarado. Compare el manifiesto de implementación con el proceso en ejecución y deshabilite la ruta no deseada MULTIPLE OWNERS Más de un propietario de instrumentación observó el límite. Poner en cuarentena la llamada de los totales; elija un propietario o registre una excepción de migración con un límite de tiempo SCHEMA GAP La propiedad es correcta, pero la evidencia no se puede utilizar o está incompleta. Arreglar el mapeo de campo o el contrato de tipo de señal antes de alertar sobre él. STALE La última evidencia supera la edad permitida Inspeccionar el retraso del exportador, las colas, la alineación del reloj y el tiempo de consulta WAITING La colección está en buen estado y permanece una dependencia con nombre Notificar al propietario o esperar hasta la fecha límite registrada; no reiniciar el agente OUTCOME UNVERIFIED El modelo de convocatoria finalizado sin acreditar el efecto solicitado Ejecute la verificación de destino determinista HEALTHY La propiedad, la evidencia, el estado del trabajo y el resultado están todos de acuerdo Guarde el recibo y aplique la ventana de estabilidad normal. MULTIPLE OWNERS no debe eliminar ni fusionar registros automáticamente. Durante una migración planificada, la recopilación dual puede resultar útil. Haga explícita la excepción con una hora de inicio, una hora de finalización, propietarios y una regla de conciliación. Mantenga las observaciones de migración fuera de los denominadores de costo de producción y confiabilidad hasta que se comparen las dos rutas. De lo contrario, un aparente aumento de tokens puede ser un cambio de instrumentación en lugar de un cambio de comportamiento. El aparato también muestra por qué un estado rojo genérico es débil. ROUTE DRIFT es un problema de implementación; STALE puede ser un problema de ingesta o de ventana de consulta; WAITING no es un fracaso; y OUTCOME UNVERIFIED requiere una verificación de destino en lugar de otra consulta de seguimiento. Unir la observabilidad a un recibo de resultados La documentación de monitoreo de IA de New Relic describe evidencia de rendimiento, costo, token, respuesta, seguimiento y comentarios de los usuarios. Esas son señales útiles sobre la capa de IA. Una respuesta modelo aún puede ir seguida de una llamada fallida a una herramienta, un archivo no confirmado, un correo electrónico que nunca se envió o un trabajo que está esperando aprobación. Por ese motivo, mantenga el recibo de destino fuera de la telemetría de llamada del modelo: El destino y el método de verificación dependen del trabajo. Utilice una versión de objeto para la carga de un archivo, un hash de confirmación más comprobaciones de un cambio de código, un ID de mensaje del proveedor para una entrega o una lectura de API para una mutación de configuración. Un código de salida de comando es más débil cuando el resultado prometido existe en otro lugar. En la repetición, false complete y healthy tienen los mismos dos tipos de señales del lado de New Relic: propietario, campos y frescura. Sólo cambia el recibo de destino. Ese es el límite operativo: la observabilidad del LLM explica la evidencia de la llamada del modelo; el recibo demuestra que existe el resultado previsto por el agente. Una implementación práctica es pequeña: 1. Elija un límite de llamada de modelo real. 2. Registre el propietario de instrumentación esperado y los tipos de señales permitidas en la implementación. 3. Genere un ID de llamada sintético y consulte cada tipo de evento de New Relic relevante. 4. Falla la implementación si el propietario esperado está ausente o aparece algún propietario no declarado. 5. Verifique los campos obligatorios y un intervalo de actualización acotado. 6. Registro working , una dependencia de espera con nombre, o complete por separado. 7. Requerir un recibo de destino determinista antes de mudarse complete a saludable. 8. Repita después de una actualización de SDK, devolución de llamada, exportador o agente. Este procedimiento tiene una limitación: no prueba que cada integración respaldada por New Relic instrumentará doblemente cada combinación de marcos. Demuestra si su implementación observada coincide con su contrato de propiedad declarado. Tampoco reemplaza las comprobaciones de compatibilidad de New Relic ni una prueba completa de conformidad del esquema OpenTelemetry. El papel previsto por Sidewisp es adyacente a esta distinción: combinar evidencia sobre accesibilidad, progreso útil, herramientas, resultados, tiempo y presupuesto en una visión de la salud del agente. Sidewisp se encuentra actualmente en versión preliminar privada. El producto en vivo es un sitio web de acceso temprano y una demostración; No se envían un adaptador New Relic de producción, un motor de monitoreo ni un ejecutor de recuperación automatizado. Utilice la auditoría anterior con sus sistemas de telemetría y destino actuales en lugar de asumir que Sidewisp los recopila o repara hoy. La resolución es bastante simple de hacer cumplir: un propietario de instrumentación declarado por límite de llamada de modelo, múltiples tipos de señales solo cuando el manifiesto lo permite, evidencia nueva y libre de contenido, un estado de espera explícito y una recepción de resultado independiente. Una vista verde de New Relic se vuelve confiable para las operaciones de los agentes solo después de que esos límites coincidan.