Reducción de los costes de telemetría de agentes de IA con OpenTelemetry Collector

Adnan Rahic, de Bindplane by Dynatrace, publicó el 22 de octubre de 2026 una guía práctica sobre cómo optimizar los pipelines de OpenTelemetry para agentes de IA. El artículo aborda un problema común en producción: el exceso de datos de telemetría generados por herramientas como Claude Code, lo que provoca altos costes de almacenamiento y una cardinalidad inmanejable.

Qué ocurrió

Activar la telemetría para un agente de codificación de IA suele resultar en un volumen masivo de datos costoso de almacenar y difícil de interpretar. En un caso de prueba donde Claude Code corrigió dos pruebas fallidas y añadió pruebas de límite, una sola ejecución produjo 181 registros de telemetría y 289 KB de JSON. Estos datos incluyen prompts completos, cuerpos de archivos y diffs, la mayoría innecesarios para el monitoreo operativo continuo.

El problema central es que la instrumentación predeterminada está diseñada para depurar sesiones individuales de desarrolladores, no para gestionar una flota de agentes. A escala, como con 200 sesiones al día, este enfoque se vuelve insostenible. Las métricas llevan atributos de alta cardinalidad como ID de sesión y correo electrónico del usuario, creando cientos de series temporales únicas que nunca expiran. Además, el contenido de las herramientas se duplica entre trazas y logs, inflando aún más los requisitos de almacenamiento.

Rahic demuestra que el objetivo no es recopilar menos datos arbitrariamente, sino mantener solo lo que responde a preguntas operativas específicas. Al dar forma a los datos en OpenTelemetry Collector antes de que lleguen al backend, los equipos pueden reducir significativamente los costes sin perder visibilidad sobre métricas críticas de rendimiento y coste.

Cómo funciona

La solución implica configurar OpenTelemetry Collector para distribuir cada señal en dos pipelines separados: un pipeline bruto y un pipeline optimizado. Ambos pipelines reciben entradas idénticas byte por byte desde un único receptor OTLP, asegurando una comparación honesta. El pipeline bruto actúa como grupo de control, conteniendo solo un nombre de servicio y un procesador de lotes, mientras que el pipeline optimizado aplica filtros y transformaciones específicos.

En el pipeline optimizado, los procesadores eliminan dimensiones de alta cardinalidad y contenido redundante. Por ejemplo, los contenidos completos de archivos de las salidas de herramientas se eliminan de los spans y logs, dejando solo metadatos esenciales. Las métricas se pre-suman o ajustan para eliminar identificadores por sesión que causan explosiones de cardinalidad. Esto asegura que los datos enviados al backend sean ligeros y estén enfocados en insights accionables.

La configuración utiliza Grafana LGTM para ambos pipelines para visualizar la diferencia. Los dashboards comparan cardinalidad, bytes por minuto y conteos de registros lado a lado. En un entorno de producción, el pipeline bruto podría dirigirse a almacenamiento de objetos para depuración profunda ocasional, o descartarse por completo, mientras que el pipeline optimizado alimenta el backend principal de monitoreo.

Detalles clave

• Una sola ejecución de Claude Code generó 181 registros de telemetría y 289 KB de JSON con todas las banderas de contenido habilitadas.
• Las métricas predeterminadas incluyen atributos de alta cardinalidad como session.id y user.email, creando 300 series para solo ocho métricas en 25 sesiones.
• El contenido de las herramientas se duplica tanto en trazas como en logs, con los contenidos de archivos almacenados como eventos de span y atributos de log.
• El pipeline optimizado reduce las series de métricas de 300 a 12 al eliminar dimensiones por sesión.
• Seis preguntas clave impulsan la optimización: coste por modelo, uso de tokens, tasas de fallo de herramientas, rechazos de ediciones, latencia y errores.
• La métrica otelcol_exporter_enqueue_size_bytes existe solo a nivel detallado con la cola de envío habilitada.

Por qué importa

Para equipos de ingeniería que construyen con agentes de IA, los costes de telemetría pueden salirse rápidamente de control si no se gestionan. La alta cardinalidad en métricas lleva a mayores costes de almacenamiento y consulta en plataformas de observabilidad, mientras que grandes cargas útiles de trazas y logs consumen ancho de banda y recursos de indexación. Al filtrar estos datos a nivel del collector, las organizaciones pueden mantener una visibilidad comprehensiva sin el prohibitivo gasto de almacenar cada prompt y diff de archivo.

Además, enfocarse en preguntas operativas específicas mejora la relación señal-ruido para desarrolladores y SREs. En lugar de tamizar muros de texto, los equipos pueden monitorear indicadores claros del rendimiento del agente, como uso de tokens por tipo, tasas de éxito de herramientas y latencia. Este cambio de recopilación de datos brutos a observabilidad dirigida permite una resolución de problemas más rápida y una gestión de costes más efectiva.

Qué puedes hacer

• Identifica las seis preguntas clave que tu equipo necesita responder sobre el rendimiento de los agentes de IA, como coste por modelo y tasas de fallo de herramientas.
• Configura tu OpenTelemetry Collector para crear pipelines separados, bruto y optimizado, para la telemetría de agentes de IA.
• Elimina atributos de alta cardinalidad como IDs de sesión y correos electrónicos de usuarios de las métricas para prevenir la explosión de series temporales.
• Despoja los contenidos completos de archivos y prompts de los spans de traza y logs, reteniendo solo metadatos esenciales e información de error.
• Usa métricas pre-sumadas cuando sea posible para reducir el número de puntos de datos enviados a tu backend.
• Visualiza la diferencia entre streams brutos y optimizados para validar ahorros de almacenamiento y asegurar que no se pierda ningún dato crítico.