Observabilidad con IA en Grafana: lo que aprendimos analizando un incidente real

Sabíamos que algo había fallado. Lo que no sabíamos era por qué nadie se había enterado.

JOSÉ GINER
DevOps

Puedes tener dashboards para casi todo y aun así no enterarte de que algo se ha roto. Eso nos pasó hace poco: un fin de semana en el que un firewall hizo tan bien su trabajo (bloqueando el tráfico antes de que llegara a ningún servicio) que no saltó ni un error y, precisamente por eso, nadie se dio cuenta. Lo que cuento aquí sobre observabilidad con IA nace de ese fin de semana.

Trabajamos con una infraestructura, para un cliente, que mezcla Azure con servicios propios: Kubernetes, un broker con RabbitMQ y dos firewalls delante de cada dominio. Cuando algo se rompe ahí, no basta con mirar un panel suelto: necesitas ver el conjunto. Ahí es donde entra Grafana, una herramienta con la que pasamos de tener métricas repartidas en media docena de fuentes a poder preguntarle a un agente qué pasó en un servicio.

Por qué Grafana y no las alertas nativas de Azure

Grafana es una interfaz web donde montas dashboards, defines alertas sobre métricas y conectas cientos de plugins. Gestionamos el clúster de Kubernetes en Azure, pero preferimos no delegar en Azure el trabajo de alertar: lo hacemos con Grafana, por coste y por configuración, y porque nos permite vigilar de cerca las piezas más críticas, como el broker de mensajería y los servicios en Kubernetes.

El coste y la configuración de Azure no nos convencen

Las alertas nativas de Azure, bien configuradas, salen caras, motivo por el cual las rechazamos en un primer momento. Además, aunque ofrecen bastantes métricas, no las muestran al nivel de granularidad que necesitas para depurar un incidente real: la configuración fue el otro motivo por el que Grafana se impuso a Azure.

RabbitMQ y Kubernetes, los dos puntos que más vigilamos

Más allá de las alertas, vigilamos especialmente dos piezas: el broker de mensajería y los servicios en Kubernetes. El primero es RabbitMQ, el sistema que usan los servicios para comunicarse entre sí, y es de los puntos más críticos: tenemos una carpeta de Grafana solo para eso, con un dashboard general del clúster (dos nodos) y otro de colas que consultamos cuando alguien pide vaciar una y queremos confirmar que ha bajado a cero.

Con Kubernetes pasa algo parecido: cada proyecto tiene su namespace y sus métricas, y usamos mucho el selector de rango temporal para preguntar qué pasó entre el viernes y el domingo, y quedarnos con una fotografía exacta de ese momento.

En el día a día, esto nos resuelve dos cosas a la vez:

• Ver el estado de un servicio o clúster en tiempo real, sin saltar de consola en consola.
• Consultar cualquier ventana temporal pasada para reconstruir qué pasó, no solo lo que está pasando ahora.

El incidente que nos hizo ver el problema real

Para entender por qué necesitábamos algo más que dashboards sueltos, hay que explicar cómo entra el tráfico en nuestro cliente. Cualquier conexión que llega por un dominio pasa por tres capas antes de llegar al servicio:

1. Primero, el WAF o Web Application Firewall, con un conjunto de reglas para detectar scraping y patrones de ataque, cada vez más frecuentes con la IA de por medio.
2. Después, el firewall de red, el clásico Fail2ban: si tu IP falla demasiadas veces, se bloquea.
3. Y solo entonces la petición llega a Kubernetes, al servicio que realmente tiene que atenderla.

Estamos acostumbrados a que, si algo falla, el primer paso sea meternos en K9s, en kubectl o en cualquier UI de Kubernetes. Ese fin de semana, eso fue exactamente lo que no funcionó: uno de nuestros equipos reportó un problema y, al mirar, no encontramos nada, ni un error ni una traza rara. Ese silencio es el peor escenario en un incidente.

Todo se estaba parando en el Web Application Firewall. Las peticiones nunca llegaban al clúster, así que desde el servicio no había pasado nada. No nos faltaban datos, teníamos dashboards del WAF desde el principio. El problema era que la información estaba repartida en fuentes que no hablaban entre sí, así que no podíamos saber, en el momento, si un pico correspondía a un proyecto o servicio determinado.

Ese fue el punto de partida real de todo lo que cuento después: no hacía falta más telemetría, hacía falta cruzarla. Teníamos datos suficientes en distintos rincones, pero nadie los estaba mirando juntos.

Grafana ya es, de por sí, un visualizador de información agregada. Al conectar un MCP encima de eso, el agente pasa a tener acceso a todo lo que hay ahí dentro.

DANIEL ALARCÓN
Software Architect

Observabilidad con IA: qué cambia cuando conectas Claude a Grafana por MCP

A partir de ahí empezamos a cruzar fuentes y creamos un dashboard híbrido que une el clúster del proyecto donde detectamos el error con el WAF, para saber en qué momento una URI concreta desencadenó algo. En paralelo, empezamos a conectar Claude a Grafana mediante MCP para que se encargue de generar las alertas.

El flujo que usamos ahora es sencillo:

┌────────────────────────────────────────────────────┐
│               métrica fuera de rango               │
└────────────────────────────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────┐
│                se genera la alerta                 │
└────────────────────────────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────┐
│      se captura el dashboard, en ese instante      │
└────────────────────────────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────┐
│ se publica en Slack: canal del servicio + contexto │
└────────────────────────────────────────────────────┘

Ese flujo nos ha dado canales de alerta por servicio donde, en cualquier momento, ves una instantánea de qué está pasando: cuando alguien lanza un reindex y empiezan a fallar cosas, vemos crecer las peticiones en cola en tiempo real; cuando paran, lo vemos en verde.

Nuestro compañero Daniel Alarcón, arquitecto de software, apuntó en la sesión por qué esto se vuelve tan potente: Grafana ya es, de por sí, un visualizador de información agregada de todas las fuentes que le conectes, tanto infraestructura como lógica de negocio. Al conectar un MCP encima de eso, el agente pasa a tener acceso a todo lo que hay ahí dentro: logs, CPU, métricas de negocio, cualquier KPI conectado a un panel, incluso si viene directo de la base de datos de producción.

Lo mismo aplica a los recursos de Azure: si algo falla ahí, el agente va directo a esos logs sin que tengamos que montar una integración específica para cada pieza, porque Grafana ya está mirando ahí.

Un caso real: pedirle a Claude que revise cómo fue una PR en producción

Durante la sesión, ofrecimos una demo en directo para que el resto del equipo pudiera ver claro dónde está hoy el límite de lo que le podemos preguntar al agente. Para ello, le pedimos que analizara el impacto en producción de una pull request reciente utilizando el contexto disponible a través de MCP.

La petición a Claude

Daniel había fusionado y desplegado el día anterior una pull request con cambios en las ingestiones. En lugar de revisar logs y métricas a mano, le pidió a Claude, con acceso al repositorio y a Grafana por MCP, que analizara el despliegue.

El agente replicó el trabajo que haría cualquiera de nosotros: construyó consultas contra las métricas del clúster, encontró el nombre de la aplicación en Loki sin que nadie le dijera dónde buscar, comparó marcas de tiempo antes y después del despliegue y calculó duraciones, señalando anomalías. Sin que fuera el objetivo, ya nos ha encontrado bugs reales en ingestiones.

Daniel remarcó que cuanto más concreta es la pregunta, más precisa es la respuesta que devuelve. Los logs son pesados y consumen mucho contexto, así que sin acotar el acceso, el agente lee más de lo necesario. Por eso hemos empezado a dejar de escribir datos sensibles en crudo en los logs.

Lo que aún no tenemos: las trazas

Felipe Polo, CEO de Orbitant, planteó un punto que está por resolver: investigar a fondo requiere ver tanto la traza física de las peticiones como la traza lógica, es decir, qué ha hecho el sistema paso a paso. De los tres pilares de la observabilidad tenemos dos: métricas, con Grafana y Prometheus donde ya está desplegado; y logs, en proceso de limpieza para no exponer datos sensibles. Falta el tercero: las trazas. El siguiente paso es incorporar Grafana Tempo y reconstruir qué pasó exactamente cuando entró un mensaje concreto de un cliente.

Un cambio en la forma de investigar incidencias

El siguiente paso técnico ya está claro: sumar Tempo, seguir la migración de logs a JSON en marcha, e ir incorporando Prometheus a más servicios para tener métricas internas más finas.

El cambio real está en el orden de las preguntas: antes mirábamos Kubernetes primero y adivinábamos qué capa había fallado; ahora el punto de partida es preguntarle a un agente con acceso a todas las fuentes qué pasó, y dejar que baje al detalle que haga falta. Daniel ya apunta hacia dónde va esto: agentes que vigilen de forma continua la salud del sistema, no solo cuando alguien pregunta, aunque todavía no está construida.

Preguntas frecuentes

¿Necesito tener trazas (Tempo) para poder conectar un agente de IA a Grafana por MCP?
No. Con métricas y logs ya se puede analizar bastante: es lo que hemos estado haciendo hasta ahora. Las trazas añaden una capa más de precisión (el «por qué» a nivel de código), pero no son un requisito para empezar.

¿Por qué no usar directamente las alertas nativas de Azure si ya tenemos el clúster ahí?
En nuestro caso, coste y flexibilidad de configuración. Las alertas nativas de Azure han mejorado, pero seguimos necesitando el nivel de correlación entre fuentes que nos da Grafana, sobre todo cuando el problema no está en una sola capa sino en la frontera entre varias.

¿Es seguro dar acceso a los logs en crudo a un agente de IA?
No por defecto. Los logs pueden contener datos sensibles, así que antes de dar ese acceso conviene revisar qué se está escribiendo ahí. Es justo lo que hemos empezado a hacer nosotros: hemos dejado de volcar datos sensibles en crudo en los logs precisamente porque ahora sabemos que ese acceso existe.