N8n logs

N8n Logs: Полное руководство по журналированию, мониторингу и отладке

N8n logs (журналы) представляют собой систематически записываемые записи событий, действий и ошибок, происходящих в платформе автоматизации n8n. Эти данные являются фундаментальным инструментом для разработки, отладки, аудита и мониторинга рабочих процессов (workflows). Каждое выполнение ноды, триггера или всего workflow оставляет детальный след в логах, позволяя пользователю понять, что произошло, на каком этапе возникла проблема и каков был контекст выполнения.

Архитектура и типы логов в n8n

Система журналирования в n8n является многоуровневой и может быть категоризирована по источнику и назначению.

1. Логи выполнения рабочих процессов (Execution Logs)

Это наиболее важные и часто используемые логи. Они создаются для каждого запуска workflow, будь то ручной запуск, запуск по триггеру или по расписанию. Каждое выполнение получает уникальный идентификатор (Execution ID). Логи этого типа имеют иерархическую структуру:

• Уровень Workflow: Запись о начале и завершении выполнения, общий статус (success, error, running), метаданные (инициатор, время старта/окончания).
• Уровень Ноды (Node): Для каждой ноды в рабочем процессе записывается отдельная запись. Она включает:
  • Название ноды и её тип.
  • Входные данные (input data), полученные нодой.
  • Выходные данные (output data), сгенерированные нодой.
  • Статус выполнения ноды.
  • Временные метки начала и окончания работы ноды.

2. Логи приложения (Application Logs)

Эти логи относятся к работе самого сервера n8n, а не к выполнению конкретных workflows. Они записываются в стандартные потоки вывода (stdout/stderr) или в файлы, в зависимости от конфигурации. Уровни логирования определяются переменной окружения N8N_LOG_LEVEL.

Уровень логирования	Описание	Типичные сообщения
error	Критические ошибки, требующие немедленного внимания.	Сбой подключения к базе данных, ошибки аутентификации.
warn	Предупреждения о потенциально проблемных ситуациях.	Использование устаревших функций, неоптимальные конфигурации.
info	Информационные сообщения о нормальной работе приложения.	«Server started on port 5678», «Webhook listener started».
debug	Детальная отладочная информация для разработчиков.	Запросы к базе данных, детали внутренних процессов.
verbose	Наиболее подробный уровень, включает трассировку.	Детализация каждого шага в обработке запроса.

3. Логи аудита (Audit Logs)

При использовании корпоративной версии n8n (n8n Enterprise) доступны расширенные логи аудита. Они фиксируют события, связанные с безопасностью и управлением доступом:

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

Методы доступа и просмотра логов

1. Интерфейс n8n Editor UI

Основной и наиболее удобный способ для анализа выполнения workflows.

• Вкладка «Executions»: Список всех выполнений с возможностью фильтрации по статусу, workflow и дате. Для каждого выполнения можно открыть детализированное представление.
• Детали выполнения (Execution Details): Визуальное представление workflow с цветовой индикацией статуса каждой ноды (зеленый = успех, красный = ошибка, серый = не выполнена). При клике на ноду отображается панель с её входными и выходными данными для данного конкретного запуска.
• Режим отладки (Debug Mode): При ручном запуске workflow можно активировать режим отладки. Это позволяет выполнять workflow пошагово, наблюдая данные после каждой ноды в реальном времени.

2. Файловые логи (Application Logs)

При развертывании n8n с помощью Docker, Docker Compose или напрямую на сервере, логи приложения по умолчанию выводятся в консоль. Для перенаправления в файлы необходима дополнительная конфигурация.

Пример конфигурации в docker-compose.yml для записи логов в файл:

version: '3.8'
services:
  n8n:
    image: n8nio/n8n
    environment:
      - N8N_LOG_LEVEL=info
      - N8N_LOG_OUTPUT=file
      - N8N_LOG_FILE_LOCATION=/home/node/.n8n/logs/n8n.log
    volumes:
      - n8n_data:/home/node/.n8n
      - ./logs:/home/node/.n8n/logs

3. База данных

Все метаданные о выполнениях (статус, время, инициатор, ID) и сами данные выполнения (input/output нод) хранятся в базе данных n8n (по умолчанию SQLite, может быть PostgreSQL, MySQL). Прямой запрос к БД позволяет выполнять сложную аналитику. Основные таблицы: execution_entity, workflow_entity.

4. Внешние системы мониторинга (ELK Stack, Grafana Loki, Datadog)

Для промышленной эксплуатации критически важно направлять логи в централизованную систему. Это можно сделать несколькими способами:

• Агент на уровне ОС (Filebeat, Fluentd): Агент читает файловые логи n8n и отправляет их в Elasticsearch или Loki.
• Отправка логов через стандартные потоки в Docker: Настройка драйвера логирования Docker для отправки логов в syslog или другой сборщик.
• Интеграция на уровне приложения: Использование библиотек для Node.js (например, Winston) через кастомную конфигурацию, что требует модификации кода n8n.

Практическое использование логов для отладки

Процесс отладки в n8n строится на последовательном анализе логов выполнения.

Типичные сценарии и анализ логов:

Сценарий 1: «Workflow завершается с ошибкой на определенной ноде».

• Откройте выполнение с ошибкой во вкладке «Executions».
• Найдите ноду, отмеченную красным цветом.
• Кликните на неё. В панели деталей будет отображено сообщение об ошибке (например, «HTTP Request failed with status code 404»).
• Проанализируйте входные данные этой ноды (кликните на предыдущую ноду), чтобы понять, какие данные привели к ошибке. Возможно, пришел неожиданный формат данных или пустое значение.

Сценарий 2: «Workflow выполняется, но результат неверный».

• Используйте режим отладки при ручном запуске.
• Выполняйте workflow пошагово, проверяя выходные данные каждой ноды.
• Сравните фактические данные с ожидаемыми. Частая проблема — неправильная настройка выражений (expressions) в полях нод.
• Ищите предупреждения (желтый цвет) на нодах, которые могут указывать на частичный успех или нестандартные условия.

Сценарий 3: «Workflow не запускается по триггеру (например, Webhook)».

• Проверьте логи приложения (application logs) уровня info или debug.
• Убедитесь, что сообщение «Webhook listener started on path /webhook/…» присутствует.
• При уровне debug вы увидите входящие HTTP-запросы к webhook, что поможет определить, приходит ли запрос вообще и с какими данными.
• Проверьте, не блокируется ли запрос брандмауэром, балансировщиком нагрузки или CORS-политиками.

Управление и ротация логов

Логи выполнения, хранящиеся в базе данных, могут занимать значительный объем. Необходимо настроить политики их очистки.

Метод управления	Механизм	Конфигурация
Очистка через настройки n8n	Встроенный механизм, удаляющий старые выполнения из БД.	Переменные окружения: EXECUTIONS_DATA_PRUNE (вкл/выкл), EXECUTIONS_DATA_MAX_AGE (часы), EXECUTIONS_DATA_PRUNE_TIMEOUT (таймаут).
Прямые запросы к БД	Ручное или запланированное удаление записей из таблиц execution_entity.	SQL-запрос: DELETE FROM execution_entity WHERE startedAt < 'дата';
Ротация файловых логов	Использование инструментов ОС (logrotate) или Docker.	Конфигурационный файл logrotate для файла n8n.log с политиками размера/времени.

Интеграция с системами оповещения

Для proactive-мониторинга необходимо настраивать оповещения об ошибках.

• Внутри n8n: Создайте workflow, который запускается по расписанию и проверяет наличие неудачных выполнений за последний период (через API n8n или запрос к БД). При обнаружении ошибок workflow может отправить сообщение в Slack, Telegram, Email или создать инцидент в PagerDuty/Opsgenie.
• Внешние системы: Централизованная система логирования (например, Elasticsearch с Kibana Alerting или Grafana с Alertmanager) может анализировать поток логов n8n и генерировать оповещения при появлении ключевых слов, таких как «ERROR» или «failed», с определенной частотой.

Ответы на часто задаваемые вопросы (FAQ)

Как увеличить детализацию логов для сложной отладки?

Установите переменную окружения N8N_LOG_LEVEL=debug перед запуском n8n. Для Docker добавьте строку - N8N_LOG_LEVEL=debug в секцию environment файла docker-compose.yml. Это позволит видеть максимально подробную информацию о внутренних процессах, HTTP-запросах и взаимодействии с базами данных.

Где физически хранятся логи выполнения?

Метаданные и данные выполнений хранятся в основной базе данных n8n (SQLite, PostgreSQL, MySQL). Файловые логи приложения (application logs) по умолчанию выводятся в консоль (stdout/stderr). При настройке N8N_LOG_OUTPUT=file они будут записаны в файл, путь к которому указан в переменной N8N_LOG_FILE_LOCATION.

Можно ли экспортировать логи выполнения для передачи в службу поддержки?

Да. В интерфейсе n8n на вкладке «Executions» откройте детали нужного выполнения. В правом верхнем углу есть кнопка «Download» (иконка с облаком и стрелкой), которая позволяет скачать полный лог выполнения в формате JSON. Этот файл содержит всю цепочку данных и ошибок и может быть отправлен для анализа.

Как очистить историю выполнений, чтобы не перегружать базу данных?

Используйте встроенную политику очистки. Установите переменные окружения: EXECUTIONS_DATA_PRUNE=true, EXECUTIONS_DATA_MAX_AGE=168 (сохранять выполнения за последние 168 часов, т.е. 7 дней). N8n будет автоматически удалять старые записи. Альтернативно, в настройках Workflow («Settings» вверху редактора) для каждого workflow можно включить опцию «Delete data of past executions after a period of time».

Почему я не вижу входные/выходные данные для некоторых нод в логах?

Это может происходить по двум причинам. Во-первых, для сохранения конфиденциальности данные нод, работающих с учетными данными (Credentials), по умолчанию не записываются в лог. Во-вторых, если workflow содержит много данных или сложные объекты, их отображение в UI может быть ограничено для производительности. Полные данные все равно хранятся в БД и доступны для скачивания в JSON.

Как настроить отправку логов ошибок n8n в Telegram или Slack?

Создайте отдельный workflow-сторож (watchdog). Он должен запускаться по расписанию (например, каждые 5 минут). Добавьте ноду «Get All Executions» (используйте триггер Schedule) и настройте фильтрацию по статусу «error» и времени. Если такие выполнения найдены, используйте ноду «Slack» или «Telegram» для отправки сообщения с деталями (Execution ID, имя workflow, время ошибки).

В чем разница между логами в UI и файловыми логами?

Логи в интерфейсе пользователя (Execution Logs) — это высокоуровневые, структурированные данные, специфичные для выполнения бизнес-процессов. Файловые логи (Application Logs) — это низкоуровневые технические логи сервера n8n как приложения, включающие запуск сервисов, подключение к БД, общие ошибки приложения и (при уровне debug) детализацию всех внутренних операций.