La IA ha cambiado la forma en que construimos software, pero no ha cambiado una verdad fundamental sobre las máquinas. Se ahogan en el ruido, al igual que nosotros. Cuando los ingenieros experimentan por primera vez con la depuración asistida por IA, el instinto es simple: alimentarlo todo al modelo. Los logs sin procesar, las trazas y las métricas se vuelcan por completo en la ventana de contexto. El resultado no es conocimiento, sino el fracaso. El volumen es demasiado alto. La señal colapsa. Las métricas están en una herramienta, las trazas en otra, y el modelo no puede unirlas para formar una historia coherente. Antes de que la IA pueda ayudarte a observar tus sistemas, tienes que observarlos tú mismo. Primero debes dar forma a los datos.

Por qué los logs sin procesar rompen los pipelines de IA

Los sistemas modernos generan telemetría a un ritmo que ningún humano puede leer. Eso debería hacerlos perfectos para la inteligencia artificial. No es así. La ventana de contexto de un modelo de lenguaje extenso, aunque está creciendo, sigue siendo un conducto finito. Si la llenas con logs de producción sin filtrar, desperdiciarás tokens en latidos de tareas cron y ruido de comprobaciones de estado (health-checks), enterrando el incidente real. Peor aún, los logs sin procesar carecen de relaciones. Un pico de latencia a las 2:00 p.m. y un error de conexión a la base de datos en un log con la misma marca de tiempo están claramente relacionados, pero a menos que alguien haya estructurado esa relación de antemano, la IA tendrá que adivinar. Adivinar es costoso, lento y, a menudo, erróneo.

La solución es arquitectónica, no algorítmica. Debes decidir qué se recopila, cómo se le da forma y qué backend responde a qué pregunta antes de siquiera enviarle un prompt a un modelo.

Cuatro ejes de monitoreo

En airCloset, el equipo de ingeniería dejó de tratar la observabilidad como una única manguera de alta presión. Dividieron el monitoreo en cuatro ejes distintos. Cada uno tiene una forma específica y responde a una pregunta concreta.

  • Application: Los logs y las trazas responden: "¿Qué está pasando ahora mismo?"
  • Infrastructure: Las métricas responden: "¿Tenemos suficientes recursos?"
  • CI: Los logs y las alertas responden: "¿Qué se rompió y cuándo?"
  • LLM: Las métricas y los registros estructurados responden: "¿Cuánto estamos gastando?"

Esta separación es importante porque la forma adecuada para un gráfico de latencia en tiempo real es inútil para un análisis de costos post-hoc. Forzar un único esquema en los cuatro dominios crea exactamente el tipo de ruido que hace que la asistencia de la IA sea inútil.

Observabilidad de CI: Pull, no Push

La integración continua es donde el código se encuentra con la realidad. Cuando una compilación falla, los desarrolladores necesitan la historia rápido. El enfoque ingenuo es hacer que el ejecutor de CI envíe (push) los logs directamente a tu backend de observabilidad mientras se ejecuta. Parece eficiente, pero en realidad es peligroso.

En airCloset, invirtieron el modelo. El ejecutor de CI no toca el stack de observabilidad. Después de que finaliza el flujo de trabajo de GitHub Actions, extraen (pull) los logs de la API de GitHub y los ingieren en Loki.

Esta arquitectura de extracción (pull) ofrece tres ventajas concretas.

Decoupling. Si el pipeline de ingesta tiene un problema o Grafana no está disponible, la ejecución de la prueba en sí no se ve afectada. La compilación pasa o falla por sus propios méritos. Un fallo en la observabilidad nunca debería detener un despliegue.

Security. El flujo de trabajo de CI nunca necesita una clave de API de Grafana. El código de prueba es conocido por manipular secretos que no debería, y eliminar esa exposición reduce el radio de impacto si una dependencia se ve comprometida.

Cross-querying. Una vez que el CI