Cómo usar LLMs para analizar logs CI/CD con ClickHouse

Cuando los terabytes de datos se encuentran con la inteligencia artificial

En el ecosistema de startups tecnológicas, la gestión eficiente de datos operacionales puede marcar la diferencia entre escalar con éxito o colapsar bajo el peso de la complejidad técnica. Mendral ha compartido un caso de uso particularmente revelador: cómo utilizaron modelos de lenguaje grande (LLM) para analizar terabytes de logs de integración continua (CI), transformando datos masivos en insights accionables mediante consultas SQL automáticas.

Este enfoque representa una evolución natural en la automatización de procesos DevOps. En lugar de configurar dashboards estáticos o escribir scripts de análisis complejos, los founders ahora pueden literalmente conversar con sus datos y obtener respuestas en lenguaje natural respaldadas por consultas SQL precisas y ejecutadas a velocidad empresarial.

La infraestructura detrás del análisis: ClickHouse como columna vertebral

Para manejar el volumen descomunal de logs generados por sistemas CI/CD —hablamos de miles de millones de líneas de logs— la empresa implementó ClickHouse, una base de datos columnar diseñada específicamente para consultas analíticas de alto rendimiento.

¿Por qué ClickHouse? Tres razones clave:

• Compresión extrema: permite almacenar terabytes de datos con un footprint de almacenamiento reducido, optimizando costos en infraestructura cloud.
• Baja latencia: consultas complejas sobre billones de registros se ejecutan en segundos, no en minutos u horas.
• Escalabilidad horizontal: conforme crece el volumen de logs, la arquitectura puede expandirse sin rediseñar el sistema.

Esta decisión arquitectónica es crítica. Muchas startups cometen el error de tratar logs como texto plano en S3 o similares, lo que dificulta análisis complejos y en tiempo real. ClickHouse transforma esos logs en un activo consultable y valioso.

LLMs que escriben SQL: el agente analítico

El corazón del sistema es un agente basado en LLM que convierte preguntas en lenguaje natural en consultas SQL optimizadas para ClickHouse. Este enfoque elimina la barrera técnica entre equipos no técnicos (producto, growth, customer success) y los datos operacionales críticos.

El flujo funciona así:

1. Un usuario (founder, PM, ingeniero) hace una pregunta: ‘¿Cuáles fueron las builds más lentas esta semana en el repositorio X?’
2. El LLM interpreta la intención, identifica las tablas y columnas relevantes en ClickHouse.
3. Genera una consulta SQL optimizada considerando índices, particiones y mejores prácticas.
4. Ejecuta la consulta y presenta resultados en formato legible, con contexto y recomendaciones.

Esta capacidad de traducir lenguaje natural a SQL no es trivial. Requiere que el LLM comprenda el esquema de datos, las relaciones entre tablas, y las peculiaridades del dialecto SQL de ClickHouse. Pero cuando funciona bien, democratiza el acceso a insights que tradicionalmente requerían un analista de datos o ingeniero senior.

El desafío del rate limiting con la API de GitHub

Un obstáculo real que enfrenta cualquier startup integrando datos de GitHub es el rate limiting: límites estrictos en la cantidad de requests que puedes hacer a su API por hora. Para mantener logs frescos y análisis oportunos sin exceder estos límites, Mendral implementó dos estrategias clave:

Ejecución duradera (Durable Execution)

En lugar de ejecutar procesos de sincronización en ventanas fijas que pueden fallar si el volumen de datos aumenta inesperadamente, utilizan un modelo de ejecución duradera. Esto significa que el proceso de ingesta puede pausarse, reiniciarse y continuar exactamente donde se quedó, sin perder contexto ni duplicar trabajo.

Este patrón es especialmente útil en startups de rápido crecimiento, donde el volumen de commits, pull requests y builds puede duplicarse de un mes a otro.

Throttling inteligente

Implementaron un sistema de throttling que monitorea en tiempo real el estado de los límites de la API de GitHub y ajusta dinámicamente la tasa de requests. Si están cerca del límite, el sistema reduce la velocidad; si hay margen, acelera la ingesta.

Esto asegura:

• Datos siempre frescos: ingesta continua sin interrupciones por límites excedidos.
• Uso óptimo del rate limit: no desperdician capacidad disponible, pero tampoco arriesgan bloqueos.
• Resiliencia: si GitHub cambia sus políticas de rate limiting, el sistema se adapta automáticamente.

Aplicaciones prácticas para founders y equipos técnicos

Este caso de uso tiene implicaciones directas para founders de startups tech que buscan optimizar procesos CI/CD y tomar decisiones basadas en datos operacionales:

1. Detección temprana de degradación de performance

Con análisis automatizado de logs CI, puedes identificar tendencias de ralentización en builds antes de que se conviertan en cuellos de botella críticos. Por ejemplo: ‘Las builds del microservicio Y han incrementado su tiempo promedio un 40% en las últimas dos semanas’. Esto puede señalar dependencias problemáticas, tests ineficientes o regresiones de código.

2. Análisis de costos de infraestructura CI

Los logs contienen información sobre uso de recursos (CPU, memoria, tiempo de ejecución). Un LLM puede correlacionar estos datos con costos de cloud para responder preguntas como: ‘¿Cuánto nos cuesta ejecutar tests end-to-end por día?’ o ‘¿Qué repositorio consume más recursos CI este mes?’

3. Debugging asistido por IA

Cuando una build falla, en lugar de revisar manualmente miles de líneas de logs, un agente LLM puede identificar el error específico, contextualizarlo con fallos similares históricos, y sugerir soluciones basadas en cómo se resolvieron problemas parecidos en el pasado.

4. Métricas de productividad de ingeniería

Análisis de frecuencia de commits, tasa de éxito de builds, tiempo desde commit hasta deployment. Todo esto se vuelve consultable sin necesidad de configurar herramientas adicionales como DataDog o New Relic (aunque pueden complementarse).

Consideraciones técnicas y desafíos a anticipar

Implementar un sistema similar no es trivial. Algunos desafíos que enfrentarás:

Diseño de esquema

ClickHouse requiere un esquema bien diseñado desde el inicio. A diferencia de bases NoSQL donde puedes iterar libremente, aquí las decisiones sobre particiones, índices y tipos de datos tienen impacto directo en performance. Recomendación: empieza con un MVP simple (logs de builds) y expande gradualmente.

Calidad del contexto del LLM

Para que el LLM genere SQL correcto, necesitas proporcionarle contexto preciso sobre tu esquema: nombres de tablas, columnas, tipos de datos, relaciones. Esto puede gestionarse mediante embeddings y retrieval augmented generation (RAG), pero requiere mantenimiento conforme evoluciona tu esquema.

Costos de inferencia

Ejecutar un LLM para cada consulta tiene un costo. Si tu equipo hace 100 consultas al día, esto es manejable. Si automatizas análisis que corren cada minuto, los costos pueden escalar rápidamente. Evalúa bien el trade-off entre automatización y costo de infraestructura IA.

Privacidad y seguridad

Los logs pueden contener información sensible (keys, URLs internas, nombres de clientes). Asegúrate de sanitizar datos antes de enviarlos a un LLM externo, o considera modelos self-hosted si manejas información crítica.

Herramientas y stack tecnológico recomendado

Si quieres implementar algo similar en tu startup, aquí un stack sugerido:

• Base de datos: ClickHouse (open-source) o alternativas como TimescaleDB para series temporales.
• LLM: GPT-4 vía API de OpenAI para prototipado rápido; considera Llama 3 o Mistral self-hosted para reducir costos en producción.
• Orquestación: Temporal.io para ejecución duradera y gestión de workflows complejos.
• Ingesta de datos: Airbyte o Fivetran para conectar fuentes externas (GitHub, GitLab, CircleCI).
• Interfaz: Retool o una app custom en Next.js para que el equipo interactúe con el agente LLM.

El futuro de la automatización DevOps con IA

Este caso de Mendral es solo la punta del iceberg. Estamos entrando en una era donde la IA no solo asiste en tareas DevOps, sino que las automatiza completamente. Imagina agentes que:

• Detectan builds rotas y automáticamente abren pull requests con fixes sugeridos.
• Optimizan pipelines CI eliminando pasos redundantes o ineficientes.
• Predicen cuándo un servicio está a punto de fallar basándose en patrones en logs.
• Generan reportes ejecutivos semanales sobre salud de ingeniería sin intervención humana.

Para founders, esto significa menos tiempo apagando incendios y más tiempo construyendo producto. La clave está en invertir temprano en infraestructura de datos sólida (como ClickHouse) y adoptar herramientas de IA de forma pragmática, no por hype.

Conclusión

El experimento de Mendral con LLMs analizando terabytes de logs CI demuestra que la IA aplicada puede transformar datos operacionales masivos en ventaja competitiva. Al combinar ClickHouse para almacenamiento y consulta de alto rendimiento con modelos de lenguaje capaces de traducir preguntas naturales en SQL optimizado, eliminan fricciones entre equipos y datos.

Para startups en fase de crecimiento, este enfoque ofrece una ruta clara: invierte en infraestructura de datos escalable desde el inicio, automatiza análisis con IA, y libera a tu equipo técnico para enfocarse en problemas de producto en lugar de tareas operacionales repetitivas. El rate limiting y otros desafíos técnicos son superables con arquitectura inteligente y herramientas modernas.

La democratización del análisis de datos mediante IA no es futuro lejano —es posible hoy, y las startups que lo adopten temprano tendrán una ventaja significativa en velocidad de iteración y toma de decisiones.

Fuentes

1. https://www.mendral.com/blog/llms-are-good-at-sql (fuente original)
2. https://clickhouse.com/docs/en/intro (documentación ClickHouse)
3. https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting (GitHub API rate limiting)