Логи и мониторинг n8n: Docker logs, executions, alerts, OpenTelemetry и дежурный runbook ¶

Обновлено: 2026-05-29

Мониторинг n8n нужен не для красивого dashboard, а чтобы заявка, платёж, webhook или AI-ответ не терялись молча. В n8n есть два уровня наблюдаемости: системные логи контейнеров и прикладная история executions. Если смотреть только UI executions, вы пропустите проблемы базы, Redis, reverse proxy и workers. Если смотреть только Docker logs, вы не увидите бизнес-контекст конкретной заявки.

Нормальная схема для малого и среднего self-hosted проекта: Docker logs + retention executions + Error Trigger workflow + healthcheck + алерты в Telegram/Slack + отдельный runbook для дежурного.

Что именно мониторить ¶

Базовые env для логов ¶

N8N_LOG_LEVEL=info
N8N_LOG_OUTPUT=console
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_PROGRESS=false
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336

debug включайте точечно и ненадолго: подробные логи могут раскрывать payload, заголовки или внутренние URL. Для production чаще достаточно info, а проблемные workflow разбирают через отдельные executions.

Команды для быстрой диагностики ¶

cd /opt/n8n
# последние ошибки main
docker compose logs --tail=200 n8n | grep -iE 'error|warn|failed|migration'

# workers в queue mode
docker compose logs --tail=200 n8n-worker | grep -iE 'job|failed|stalled|redis|error'

# перезапуски контейнеров
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

# диск
df -h

docker system df

Эти команды должны быть в runbook, а не вспоминаться во время аварии. Если проект обслуживает продажи, добавьте проверку “когда была последняя успешная заявка”.

Error Trigger workflow: алерт с контекстом ¶

Отдельный error workflow должен отправлять не просто “что-то упало”, а минимум данных для действия:

{
  "workflow_name": "Tilda to Bitrix24",
  "execution_id": "12345",
  "last_node": "Create Bitrix lead",
  "error_message": "401 Unauthorized",
  "source": "tilda",
  "external_id": "lead_987",
  "created_at": "2026-05-29T10:00:00+03:00"
}

В алерт не кладите токены, полные cookies, персональные данные без необходимости и большие body. Для расследования достаточно execution id, workflow name, node name, короткой ошибки и бизнес-ключа.

Healthcheck для n8n ¶

#!/usr/bin/env bash
set -euo pipefail
URL="https://n8n.example.ru/healthz"
code=$(curl -s -o /tmp/n8n-health.txt -w '%{http_code}' "$URL")
if [ "$code" != "200" ]; then
  echo "n8n healthcheck failed: $code"
  cat /tmp/n8n-health.txt
  exit 1
fi
echo "n8n OK"

Healthcheck домена не заменяет проверку бизнес-процесса. Отдельно сделайте synthetic webhook: тестовый POST, который проходит через минимальный workflow и возвращает понятный ответ.

OpenTelemetry и log streaming: когда нужно ¶

Если у вас один VPS и 20 workflows, достаточно Docker logs и error workflow. Если несколько workers, много интеграций, SLA и расследования по цепочке событий, добавляйте централизованные логи, log streaming и tracing. Важно настроить одинаковые переменные трассировки на main и workers, иначе часть span будет теряться.

Runbook для инцидента ¶

1. Понять масштаб: все workflows или один сервис.
2. Проверить домен и reverse proxy: HTTP status, TLS, 502/504.
3. Проверить n8n main и worker: restarts, migrations, memory.
4. Проверить PostgreSQL и Redis: доступность, диск, connections.
5. Остановить повторную обработку, если есть риск дублей.
6. Починить причину и прогнать smoke-test.
7. Разобрать failed executions и переиграть только безопасные.

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY

Связанные материалы ¶

• Error Trigger и error workflow
• Алерты об ошибках в Telegram
• Queue mode и workers
• Incident response для n8n