---
title: "Логи и мониторинг n8n: Docker logs, executions — Nodbot"
source_url: "https://nodbot.ru/hosting/logs-monitoring/"
canonical_url: "https://nodbot.ru/hosting/logs-monitoring/"
language: "ru"
content_type: "HostingGuide"
section: "hosting"
generated_at: "2026-05-30"
word_count_source: 1015
---

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

## AI summary

Как настроить логи и мониторинг n8n self-hosted: N8N_LOG_LEVEL, Docker logs, failed executions, Error Trigger, log streaming, OpenTelemetry, алерты и runbook.

## Best used for

Страница объясняет «Логи и мониторинг n8n: Docker logs, executions — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Что именно мониторить
- Базовые env для логов
- Команды для быстрой диагностики
- Error Trigger workflow: алерт с контекстом
- Healthcheck для n8n
- OpenTelemetry и log streaming: когда нужно
- Runbook для инцидента
- Операционный runbook для self-hosted

## Source outline

# Логи и мониторинг 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 для дежурного.

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

- Слой | Сигнал | Почему важно
- n8n main | container restart, migrations, API errors | редактор, webhooks и scheduler зависят от main
- worker | job failed, stalled, memory, restarts | в queue mode тяжёлая работа идёт через workers
- PostgreSQL | connections, disk, locks, slow queries | без базы n8n не сохраняет state и executions
- Redis | memory, evictions, connection refused | очередь может застрять или потерять jobs
- Webhooks | 404/5xx/timeout | внешние заявки не доходят до workflow
- Business flow | нет заявок за ожидаемый период | ошибки могут быть не техническими, а бизнесовыми

## Базовые 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 для инцидента

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

## Операционный runbook для self-hosted

Для темы «Логи и мониторинг n8n» важно разделять настройку и эксплуатацию. Настройка отвечает на вопрос “запустилось ли”, эксплуатация — “сможем ли мы восстановиться, обновиться и расследовать инцидент без потери credentials и execution history”.

Перед изменениями проверьте бэкап базы, значение N8N_ENCRYPTION_KEY, состояние volume, логи web-процесса и worker-процесса. Главный риск — поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key.

- Слой | Что зафиксировать | Зачем
- Вход | состояние контейнеров, очередь, переменные окружения, volume и последние строки логов | позволяет повторить проблему без доступа к production-секретам
- Контроль | restart_count, memory_usage, queue_depth, worker_concurrency, failed_executions | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Логи и мониторинг n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
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
```

### Критерий готовности

- есть свежий backup базы и проверено значение N8N_ENCRYPTION_KEY
- web, worker, queue и database используют согласованные переменные окружения
- после изменения проверены логи, healthcheck и запуск критичных workflow
- записан rollback-план с командами и ответственным

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

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

## Эксплуатационный контекст для self-hosted n8n

Страницу «Логи и мониторинг n8n: Docker logs, executions, alerts, OpenTelemetry и дежурный runbook» лучше читать как часть production-карты self-hosted n8n. Любое изменение инфраструктуры должно иметь владельца, план проверки, понятный rollback и наблюдаемость. Перед применением на VPS или в Kubernetes зафиксируйте текущую версию n8n, способ запуска, путь к данным, переменные окружения и место хранения backup.

Главный риск self-hosted установки — исправить один симптом и не заметить побочный эффект: потерю credentials, рост execution data, недоступность webhooks, ошибку reverse proxy или зависшие workers. Поэтому после изменений проверяйте не только UI, но и healthcheck, production webhook URL, очередь, базу данных, логи контейнера и успешный тестовый execution.

### Ops-чеклист перед изменением

- Сделайте backup базы, файлового хранилища и критичных env-переменных.
- Проверьте, что есть понятный rollback и окно обслуживания.
- Сравните логи до и после изменения: 4xx/5xx, latency, memory, disk, stalled jobs.
- Проведите тест webhook, scheduled workflow и ручного запуска.
Для команды полезно хранить эту проверку рядом с runbook: что изменяли, кто подтвердил результат, какие метрики смотрели и какое условие считается неуспешным релизом.

### Связанные материалы для эксплуатации

- Self-hosted n8n — открыть связанный материал для проверки контекста.
- Backup и update — открыть связанный материал для проверки контекста.
- Launch checklist — открыть связанный материал для проверки контекста.

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.