n8n — это не автоматизация. Это оркестратор.

Большинство людей используют n8n чтобы переложить данные из одного места в другое — пришёл вебхук, создай задачу, заполнили форму, отправь в CRM. Это полезно, спору нет, но это примерно как использовать хороший нож только чтобы вскрывать конверты.

n8n становится интересным когда его перестают воспринимать как исполнителя и начинают использовать как дирижёра. Он ничего не делает сам — зато знает кого позвать, в каком порядке и что передать дальше. Каждый участник оркестра играет своё, n8n просто держит партитуру и следит чтобы никто не вступил не вовремя.

Покажу на конкретном примере — благо он у меня живой.

Проблема: мониторинг который никто не настраивает

Небольшие команды почти никогда не настраивают нормальный мониторинг серверов, и дело тут не в том что они не понимают зачем — а в том что альтернатива выглядит как Zabbix или Prometheus. Это энтерпрайз-инструменты со своей экосистемой, своими специалистами и своей отдельной болью при настройке, и чтобы тот же Prometheus приносил реальную пользу, нужен человек который понимает что с ним делать и зачем. Для трёх серверов небольшого продукта это примерно как нанять шеф-повара чтобы сделать бутерброд — технически решение, но как-то несоразмерно.

Поэтому мониторинг откладывается до лучших времён, а лучшие времена наступают обычно тогда когда что-нибудь падает и выясняется что простои дорогие: интернет-магазин лежит два часа ночью — это потерянные заказы, утром злые клиенты и время на разбор полётов вместо нормальной работы.

Честное наблюдение

Когда что-то всё-таки падает, человек без DevOps в команде делает ровно одно и то же — копирует логи и кидает в ChatGPT с вопросом “вот ошибка, что это значит и как починить”. И знаете что, это работает. Просто происходит уже после того как клиент позвонил, вручную, с потерей времени на поиск нужных строк среди сотен строк событий.

Для одного из своих проектов я автоматизировал именно этот процесс — не “построил систему мониторинга” в каком-то серьёзном смысле, а просто убрал ручной труд из того что и так происходило. Сигнал пришёл, логи собраны, анализ готов — и пока ты читаешь уведомление, ответ уже в Telegram.

Архитектура: кто что делает

Система состоит из четырёх компонентов, каждый из которых делает ровно то для чего создан, и не пытается делать ничего лишнего.

Grafana + Loki следят за потоком логов в реальном времени — Loki их хранит, Grafana мониторит и когда в логах появляется критическое событие, например серия HTTP 5xx ошибок, срабатывает алерт.

n8n — оркестратор. Получает вебхук от Grafana и управляет всей дальнейшей логикой: куда идти, что забрать, кому передать.

LLM через OpenRouter — аналитик. Получает массив логов и возвращает человекочитаемый диагноз с рекомендацией.

Telegram — просто канал доставки, результат анализа прилетает ответственному человеку.

Grafana алерт → webhook → n8n → запрос логов из Loki → LLM → Telegram

Никакого агента на сервере, никакого доступа к инфраструктуре — система только читает логи и говорит что делать, сервер остаётся под полным контролем.

Технические детали

Алерт в Grafana

В Grafana Alerting создаётся правило на основе LogQL запроса к Loki, и здесь есть неочевидный момент с фильтрацией. Если искать просто текст “error”, алерт будет срабатывать на любой URL где встречается это слово — а это происходит чаще чем хотелось бы. Надёжнее матчить HTTP статус код по позиции в строке nginx лога:

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

Кавычка перед цифрой закрывает часть HTTP/1.1" в логе — так статус код не перепутается с цифрами в URL запроса. Мелочь, но без неё система будет генерировать ложные срабатывания и быстро надоест.

Алерт настраивается на Contact Point типа Webhook с URL вашего n8n workflow.

Получение логов в n8n

Если Loki запущен в том же Docker-окружении что и Grafana и не торчит наружу — не проблема, Grafana умеет проксировать запросы к своим datasources. Из n8n делается обычный HTTP GET запрос через Grafana API:

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

С параметрами:

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

Авторизация через Bearer токен — Service Account в Grafana с ролью Viewer, ничего лишнего. 900 секунд это 15 минут до момента алерта — достаточно чтобы поймать цепочку событий которая привела к аварии.

Подготовка логов для LLM

Loki возвращает вложенный JSON со стримами и значениями, и перед тем как передавать это в LLM, нода Code в n8n распаковывает всё в читаемый текст:

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") } }];

Запрос к LLM

Через OpenRouter можно использовать любую модель с одним API, и для анализа логов хорошо работает Claude Haiku — задача не требует сложных рассуждений, нужна точность в следовании инструкциям. Промпт намеренно ограничивающий:

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:
{сообщение из алерта Grafana}

Logs:
{логи за 15 минут до алерта}

Условие “не придумывай факты” здесь принципиально — без него модель начинает генерировать правдоподобные но ложные объяснения, что хуже чем просто сырые логи.

Почему это работает

Каждый инструмент стоит на своём месте и не пытается делать чужую работу. Grafana не анализирует логи — она мониторит и алертит. Loki не пытается быть аналитиком — он хранит и отдаёт данные по запросу. LLM не управляет инфраструктурой — она компрессирует шум в сигнал, и вот это она умеет хорошо. n8n не делает ничего из перечисленного — он знает кого позвать и в каком порядке, и именно в этом его ценность.

Это и есть правильное использование инструмента: не попытка сделать всё одним решением, а точное распределение ответственности между теми кто с этим справляется лучше всего.

Вместо вывода

Такую систему можно собрать за несколько часов не будучи DevOps инженером — не потому что это тривиально, а потому что сложность распределена по правильным местам и каждый компонент делает ровно то для чего создан.

AI здесь не заменяет инженера, он убирает ручной труд из процесса который и так происходил — только медленно и уже после факта. Ценность не в том что LLM умный, а в том что система реагирует до того как проблема успела стать дорогой.

Скучные проверенные инструменты, собранные в правильном порядке, часто решают задачу быстрее и дешевле чем специализированное enterprise-решение. Это не компромисс — это и есть системное мышление.