Brechas silenciosas en el rastreo y saturación de disco en Langfuse autoalojado

Un desarrollador descubrió que su plataforma de observabilidad Langfuse autoalojada capturaba solo una fracción de la actividad de sus agentes de IA, lo que generaba datos de rendimiento engañosos. La investigación reveló que descuidos en la configuración provocaron fallos silenciosos de monitoreo en la mayoría de los perfiles de agentes, mientras que la base de datos subyacente acumulaba gigabytes de registros internos innecesarios.

Qué ocurrió

El problema salió a la luz cuando un agente de IA tardó veinticinco minutos en responder a un simple comando para publicar una respuesta en un foro. En lugar de ejecutar la tarea, el modelo generó un resumen fabricado del artículo objetivo. El desarrollador consultó las trazas de Langfuse para diagnosticar el retraso, esperando ver latencia de red o cuellos de botella en la ejecución de herramientas. Los datos de traza mostraron que las herramientas web se ejecutaron en menos de cinco segundos, mientras que el modelo de lenguaje local pasó más de veinticinco minutos procesando. La causa raíz no fue el rendimiento, sino el contexto: la sesión del agente había comenzado antes de que la habilidad de publicación estuviera disponible, por lo que el modelo improvisó en lugar de usar una herramienta faltante.

Este incidente motivó una auditoría más profunda de la configuración de observabilidad. El desarrollador comparó el número de sesiones registradas en la base de datos interna de su agente contra las trazas almacenadas en Langfuse durante un período de catorce días. El agente había ejecutado 1.387 llamadas al modelo en 188 sesiones, pero Langfuse contenía solo 618 eventos de 79 trazas. Un análisis posterior mostró que el rastreo estaba habilitado en solo uno de diez perfiles de agente, lo que significaba que el sistema monitoreaba aproximadamente el 7% del tráfico total. Los perfiles más activos, incluidos aquellos para tareas de codificación y seguridad, eran completamente invisibles para la plataforma de observabilidad.

El segundo hallazgo importante involucró el consumo de almacenamiento. Langfuse versión 3 utiliza ClickHouse como su almacén principal de trazas, junto con PostgreSQL y Redis. Mientras que los datos reales de traza ocupaban apenas 2,2 MiB, la instancia de ClickHouse utilizaba más de 6 GiB de espacio en disco. La mayor parte de este espacio era consumido por las tablas de sistema de diagnóstico propias de ClickHouse, como los registros de trazas y métricas, que escribían continuamente. Este registro excesivo creaba una sobrecarga significativa de entrada/salida en la máquina anfitriona, contribuyendo a tormentas periódicas de rendimiento en el disco duro.

Detalles clave

• El rastreo estaba activo en solo uno de diez perfiles de agente, capturando aproximadamente el 7% de todas las llamadas al modelo.
• Los perfiles sin rastrear incluían agentes de alto volumen para tareas de codificación, seguridad y administración de TI.
• Los registros del sistema ClickHouse consumieron 6,03 GiB de espacio en disco, mientras que los datos reales de traza usaron solo 2,2 MiB.
• El complemento de rastreo falla silenciosamente cuando faltan las claves API, sin proporcionar mensajes de error ni advertencias en los registros.
• Los trabajos únicos (one-shot jobs) que se ejecutan en modo seguro omiten por completo los complementos, requiriendo una integración separada del SDK para el rastreo.
• Eliminar las tablas de registro del sistema de ClickHouse mediante configuración detiene nuevas escrituras, pero no elimina automáticamente los datos existentes.

Contexto

Langfuse es una plataforma de observabilidad de código abierto diseñada para aplicaciones de modelos de lenguaje grandes. Ayuda a los desarrolladores a rastrear costos, latencia y comentarios de usuarios registrando trazas de interacciones entre agentes y modelos. Autoalojar Langfuse otorga a los equipos control sobre sus datos, pero requiere gestionar la infraestructura subyacente, incluida la capa de base de datos. En la versión 3, Langfuse depende de ClickHouse, un sistema de gestión de bases de datos orientado a columnas optimizado para el procesamiento analítico en línea. ClickHouse es potente para manejar grandes volúmenes de datos de series temporales, pero incluye extensas funciones de registro interno que monitorean su propio rendimiento y operaciones.

Los patrones de diseño "fail-open" son comunes en los complementos de software para asegurar que una dependencia faltante no bloquee la aplicación principal. En este contexto, si el complemento de rastreo no puede encontrar credenciales de API válidas, simplemente se desactiva en lugar de lanzar un error. Si bien esto previene bloqueos de la aplicación, crea un punto ciego donde el monitoreo se detiene sin alertar al operador. Comprender la distinción entre errores a nivel de aplicación y brechas silenciosas de configuración es crítico para mantener una observabilidad fiable en sistemas distribuidos.

Por qué importa

Para los equipos que gestionan su propia infraestructura de IA, una observabilidad incompleta puede llevar a conclusiones incorrectas sobre el rendimiento y el costo del sistema. En este caso, el desarrollador sospechó inicialmente de problemas de red debido al largo tiempo de respuesta, pero la traza reveló que el problema era el razonamiento del modelo dentro de una sesión obsoleta. Si el rastreo hubiera estado activo en el agente de codificación, que representaba la mayoría de las llamadas, el equipo habría tenido visibilidad sobre la frecuencia con la que los modelos locales alcanzaban colas de latencia en comparación con las alternativas en la nube. Sin un rastreo exhaustivo, las decisiones de asignación de recursos se basan en hábitos en lugar de datos, lo que podría conducir a un uso ineficiente de costosos recursos de GPU o APIs en la nube.

La gestión del almacenamiento es otra preocupación práctica para los servicios autoalojados. Los registros de diagnóstico son útiles para resolver problemas de rendimiento de la base de datos, pero pueden abrumar rápidamente las implementaciones a pequeña escala. Cuando los registros internos consumen miles de veces más espacio que los datos reales de la aplicación, degradan el rendimiento del disco e incrementan los tiempos de copia de seguridad. Para los operadores que gestionan homelabs o pequeños clústeres de servidores, el crecimiento descontrolado de los registros puede causar interrupciones del servicio o requerir limpiezas manuales frecuentes. Configurar la base de datos para retener solo los datos operativos relevantes asegura que la plataforma de observabilidad permanezca ligera y sostenible.

Qué puedes hacer

• Compara el número de solicitudes registradas en los logs de tu aplicación con el número de trazas en tu plataforma de observabilidad para identificar brechas de cobertura.
• Verifica que las claves API y los complementos de rastreo estén configurados para cada perfil de agente, worker y servicio, no solo para el predeterminado.
• Envía una solicitud de prueba desde cada perfil de agente distinto y confirma que aparece una traza etiquetada en el panel de control.
• Revisa la configuración de retención de registros de ClickHouse para evitar el acumulación innecesaria de datos de diagnóstico.