Мониторинг и логи

Сценарий работает не только когда вы на него смотрите. В продакшене у вас будут десятки запусков в час, тысячи в день, и без минимального мониторинга вы не будете знать, что вообще происходит.

Executions: встроенный лог

Самое простое и доступное — executions. Это история запусков сценария: каждый запуск с временем, статусом (success, error, running, cancelled) и данными по узлам.

В каждом сценарии есть вкладка / раздел «Executions», где это видно. Полезные операции:

  • посмотреть, что попало в каждый узел при конкретном запуске;
  • сравнить успешный и неуспешный запуски, чтобы найти, где разошлось;
  • перезапустить execution с тем же входом (если такая опция доступна).

Сколько хранить executions

Executions занимают место в базе. Если вы храните всё — однажды база вырастет до неприличных размеров, и инстанс начнёт тормозить.

В настройках n8n обычно есть параметры, регулирующие, что и сколько хранить:

  • хранить только неуспешные;
  • хранить успешные N дней;
  • ограничить общий объём.

Точные имена и набор опций зависят от версии. Общий принцип:

  • успешные — храните 7-30 дней, дальше удаляйте;
  • неуспешные — храните дольше (30-90 дней), они полезны для разбора инцидентов;
  • тестовые / dev — можно вообще не хранить.

Что важно мониторить, помимо executions

Сами executions хорошо рассказывают про сценарий. Но они ничего не говорят про:

  • систему. Жив ли инстанс n8n? Хватает ли ему ресурсов? Не упал ли он час назад?
  • внешние сервисы. Возрастает ли время ответа API? Растёт ли частота 5xx-ошибок?
  • бизнес-метрики. Сколько заказов было обработано за день? Сколько оплат прошло? Сколько было откатов?

Health-check инстанса

Минимально полезное: внешний сервис, который раз в минуту делает HTTP-запрос на ваш инстанс n8n и проверяет, что он жив. Если несколько проверок подряд провалились — приходит уведомление.

Подойдут готовые: UptimeRobot, Better Stack, Healthchecks.io и многие другие. Настройка — минут на пять.

«Сердцебиение» через сам n8n

Простой приём: создаёте сценарий, который запускается по расписанию (раз в 5-10 минут) и отправляет «я жив» в health-check сервис. Если health-check не получает сигнал N минут — он бьёт тревогу.

Это покрывает не только «инстанс жив», но и «n8n обрабатывает расписания» — потому что если шедулер сломан, сигнал просто не придёт.

Бизнес-метрики

Важные числа — те, которые касаются бизнеса. Несколько способов их собирать:

  • Записывать события в Google Sheets — простейшее решение для маленького масштаба.
  • Записывать в базу данных (Postgres, MySQL, MongoDB) — масштабируется лучше.
  • Отправлять в системы метрик (например, в Grafana через ClickHouse или InfluxDB) — для серьёзного объёма.

Дальше эти данные можно визуализировать на дашборде и видеть тренды: «сегодня запросов в 2 раза меньше обычного» или «сегодня ошибок в 10 раз больше».

Внешние логи

Если у вас self-hosted инстанс, логи самого процесса n8n стоит собирать во внешнюю систему — Datadog, Loki, Papertrail, что угодно. Просто чтобы при сбое не приходилось лезть на сервер по SSH.

Чек-лист для критичных сценариев

Прежде чем сценарий с реальными деньгами или клиентами начнёт работать в проде:

  1. Включён error workflow с уведомлениями — да.
  2. Настроен health-check инстанса — да.
  3. Понятно, как откатить изменения — да (резервная копия, старая версия рядом, бэкап базы).
  4. Бизнес-метрики где-то накапливаются — да.
  5. Есть документация сценария — да.

Если хотя бы на один пункт «нет» — сценарий не готов к продакшену.