n8n — no es automatización. Es un orquestador.

La mayoría de la gente usa n8n para mover datos de un lugar a otro: llega un webhook, crea una tarea, rellenan un formulario, envíalo al CRM. Es útil, no lo discuto, pero es algo así como usar un buen cuchillo solo para abrir sobres.

n8n se vuelve interesante cuando deja de percibirse como ejecutor y comienza a usarse como director de orquesta. Él no hace nada por sí mismo, pero sabe a quién llamar, en qué orden y qué pasar a continuación. Cada miembro de la orquesta toca lo suyo; n8n solo lleva la partitura y se asegura de que nadie entre fuera de tiempo.

Mostraré con un ejemplo concreto —casualmente tengo uno en producción.

Problema: monitorización que nadie configura

Los equipos pequeños casi nunca configuran una monitorización adecuada de servidores, y no es que no entiendan para qué sirve, sino que la alternativa suele parecer Zabbix o Prometheus. Son herramientas empresariales con su propia ecosistema, sus especialistas y sus dolores particulares al configurarlas, y para que Prometheus realmente aporte valor se necesita alguien que sepa qué hacer y por qué. Para tres servidores de un producto pequeño es como contratar a un chef para hacer un sándwich: técnicamente una solución, pero desproporcionada.

Por eso la monitorización se pospone hasta mejores tiempos, y los mejores tiempos generalmente llegan cuando algo cae y se descubre que el tiempo de inactividad es caro: una tienda online caída dos horas por la noche significa pedidos perdidos, clientes enfadados por la mañana y tiempo invertido en investigar en lugar de trabajar normalmente.

Observación honesta

Cuando algo efectivamente cae, la persona sin DevOps en el equipo hace exactamente lo mismo: copia los logs y los pega en ChatGPT con la pregunta «aquí hay un error, ¿qué significa y cómo arreglarlo?». Y saben qué, funciona. Solo que ocurre después de que el cliente llamó, manualmente, con pérdida de tiempo buscando las líneas necesarias entre cientos de eventos.

Para uno de mis proyectos automatizé precisamente ese proceso: no «construí un sistema de monitorización» en un sentido serio, sino que quité el trabajo manual de lo que ya pasaba. Llega la señal, se recogen los logs, el análisis está listo —y mientras lees la notificación, la respuesta ya llegó por Telegram.

Arquitectura: quién hace qué

El sistema consta de cuatro componentes, cada uno hace exactamente lo que fue diseñado para hacer y no intenta hacer nada de más.

Grafana + Loki vigilan el flujo de logs en tiempo real —Loki los almacena, Grafana monitoriza y, cuando en los logs aparece un evento crítico, por ejemplo una serie de errores HTTP 5xx, salta una alerta.

n8n — el orquestador. Recibe el webhook de Grafana y gestiona toda la lógica posterior: a dónde ir, qué recoger, a quién pasar la información.

LLM a través de OpenRouter — el analista. Recibe un conjunto de logs y devuelve un diagnóstico legible por humanos con una recomendación.

Telegram — simplemente el canal de entrega; el resultado del análisis llega a la persona responsable.

Grafana alert → webhook → n8n → solicitud de logs desde Loki → LLM → Telegram

Sin agentes en el servidor, sin acceso a la infraestructura —el sistema solo lee logs y dice qué hacer; el servidor permanece bajo control total.

Detalles técnicos

Alerta en Grafana

En Grafana Alerting se crea una regla basada en una consulta LogQL a Loki, y aquí hay un detalle no obvio con el filtrado. Si se busca simplemente el texto “error”, la alerta se disparará en cualquier URL donde aparezca esa palabra —y eso ocurre más a menudo de lo deseado. Es más fiable emparejar el código de estado HTTP por su posición en la línea del log de nginx:

count_over_time({service_name="ваш-сервис"} |~ "\" 5[0-9][0-9] " [1m])

La comilla antes del dígito cierra la parte HTTP/1.1" en el log —así el código de estado no se confundirá con números en la URL de la petición. Es un detalle pequeño, pero sin él el sistema generaría falsos positivos y pronto resultaría molesto.

La alerta se configura con un Contact Point de tipo Webhook con la URL de tu workflow de n8n.

Obtención de logs en n8n

Si Loki está ejecutándose en el mismo entorno Docker que Grafana y no es accesible desde fuera —no hay problema, Grafana puede proxyar las solicitudes a sus datasources. Desde n8n se hace una petición HTTP GET estándar a través de la API de Grafana:

GET https://ваша-графана.com/api/datasources/proxy/uid/loki/loki/api/v1/query_range

Con los parámetros:

query   {service_name="ваш-сервис"} |~ "\" 5[0-9][0-9] "
start   {{ Math.floor(Date.now() / 1000) - 900 }}
end     {{ Math.floor(Date.now() / 1000) }}
limit   200

Autenticación mediante token Bearer —una Service Account en Grafana con rol Viewer, nada más. 900 segundos son 15 minutos antes del momento de la alerta —suficiente para captar la cadena de eventos que llevó a la incidencia.

Preparación de los logs para la LLM

Loki devuelve un JSON anidado con streams y valores, y antes de pasar esto a la LLM, el nodo Code en n8n desempaqueta todo a texto legible:

const result = $input.first().json;
const streams = result.data?.result || [];

const lines = [];
for (const stream of streams) {
  for (const [ts, line] of stream.values) {
    lines.push(line);
  }
}

return [{ json: { logs: lines.join("\n") } }];

Consulta a la LLM

A través de OpenRouter se puede usar cualquier modelo con una sola API, y para el análisis de logs funciona bien Claude Haiku —la tarea no requiere razonamientos complejos, se necesita precisión en seguir instrucciones. El prompt es intencionalmente restrictivo:

You are a server monitoring assistant. Analyze these logs and identify 
what went wrong and how to fix it. Stick strictly to what's in the logs — 
do not invent facts or guess beyond the evidence.

Alert message:
{mensaje de la alerta de Grafana}

Logs:
{logs de los 15 minutos antes de la alerta}

La condición “no inventes hechos” aquí es fundamental —sin ella el modelo empieza a generar explicaciones verosímiles pero falsas, lo cual es peor que ver solo los logs crudos.

Por qué esto funciona

Cada herramienta está en su sitio y no intenta hacer el trabajo de otra. Grafana no analiza los logs —monitoriza y alerta. Loki no pretende ser analista —almacena y devuelve datos bajo demanda. La LLM no gestiona la infraestructura —comprime el ruido en señal, y eso es algo que hace bien. n8n no hace nada de lo anterior —sabe a quién llamar y en qué orden, y ahí está su valor.

Esto es el uso correcto de una herramienta: no intentar hacerlo todo con una sola solución, sino distribuir responsabilidades entre quienes lo hacen mejor.

En lugar de conclusión

Este sistema se puede montar en unas pocas horas sin ser ingeniero DevOps —no porque sea trivial, sino porque la complejidad se distribuye en los lugares adecuados y cada componente hace exactamente lo que fue diseñado para hacer.

La IA aquí no sustituye al ingeniero; elimina el trabajo manual de un proceso que ya existía —solo que lento y siempre después del evento. El valor no está en que la LLM sea inteligente, sino en que el sistema reacciona antes de que el problema llegue a ser costoso.

Herramientas probadas y aburridas, ensambladas en el orden correcto, a menudo resuelven el problema más rápido y barato que una solución enterprise especializada. No es un compromiso —es pensamiento sistémico.