Logging standards n8n: логи, метрики и алерты ¶

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

Короткий ответ ¶

Logging standards для n8n задают единый формат журналов: какой ID события писать, где хранить статус, какие ошибки фиксировать, как связывать execution с внешним объектом и какие поля нельзя логировать. Без стандарта команда видит только «workflow упал», но не может быстро ответить, какой клиент, заказ, тикет или payload затронут.

Почему executions недостаточно ¶

Встроенные executions полезны, но они не заменяют продуманный журнал. Execution показывает путь внутри n8n, а бизнесу и поддержке нужны другие ответы: был ли обработан заказ, создан ли лид, отправлено ли письмо, какой внешний ID у результата, можно ли безопасно повторить событие.

Logging standard нужен, когда workflow влияет на клиентов, деньги, CRM, поддержку, отчёты или AI-ответы.

1. Три уровня логирования ¶

Не смешивайте всё в один поток. У n8n-команды обычно есть три разных вида журналов.

Technical log помогает чинить. Business audit log помогает доказать результат. Incident log помогает улучшить процесс после сбоя.

2. Обязательные поля ¶

Каждый production workflow должен иметь минимальный набор полей, которые можно найти в логах без открытия всех nodes вручную.

Если внешнего event ID нет, создайте собственный correlation ID в начале workflow и используйте его во всех ветках.

3. Где писать журнал ¶

Не обязательно сразу подключать сложную observability-платформу. Начать можно с таблицы, Postgres-таблицы, внутреннего API или отдельного logging workflow.

Главное правило: журнал не должен ломать основной процесс. Если logging target недоступен, workflow не должен терять заказ или платеж, если только это не обязательный compliance-контроль.

4. Маскирование и запретные поля ¶

Лог должен помогать расследовать, а не становиться вторым хранилищем персональных данных.

Не логируйте без необходимости:

• access tokens и refresh tokens;
• API keys и passwords;
• полные номера карт;
• cookie и Authorization headers;
• полный текст частной переписки;
• вложения и документы;
• слишком длинный RAG context;
• prompt с приватными данными клиента.

Можно логировать безопаснее:

• последние 4 символа ID, если нужен поиск;
• hash email/phone для дедупликации;
• external object ID;
• статус и код ошибки;
• количество обработанных строк;
• ссылку на защищённую систему-источник.

5. Ошибки и retry ¶

Ошибки должны быть классифицированы. Текст Something went wrong не помогает ни человеку, ни алерту.

Пример классификации:

Разделяйте ошибки, которые можно повторять, и ошибки, которые нужно отправлять на ручную проверку.

6. Логи для AI workflow ¶

AI-сценарии требуют особых полей. Недостаточно знать, что модель ответила успешно. Нужно понимать, какой контекст использовался и можно ли доверять ответу.

Логируйте:

• model name;
• prompt version;
• retrieval query;
• source document IDs;
• confidence/validation status, если есть;
• structured output validation result;
• human approval status;
• token/cost estimate, если контролируете бюджет.

Не храните полный prompt и private context без причины. Лучше хранить версию prompt и ID источников.

7. Пример записи business audit log ¶

{
  "timestamp": "2026-05-29T10:15:00+02:00",
  "workflow": "prod-crm-lead-create",
  "execution_id": "123456",
  "correlation_id": "site_form_8f2c",
  "source": "site_form",
  "target": "crm",
  "external_event_id": "evt_9821",
  "result_object_id": "lead_551",
  "status": "created",
  "retry_count": 0,
  "error_code": null
}

Такой лог позволяет быстро ответить, что произошло, не открывая каждый node.

FAQ ¶

Достаточно ли встроенных executions?
Для маленьких workflow — иногда да. Для production лучше иметь отдельный business audit log с безопасными полями и внешними ID.

Нужно ли логировать весь payload?
Обычно нет. Логируйте ID, статус, ошибки и ссылки на источник. Полный payload храните только там, где это оправдано и разрешено.

Что делать, если logging node упал?
Решите заранее. Для некритичных логов основной процесс должен продолжиться. Для compliance-событий может быть нужен fail-closed режим.

Как связать несколько workflow между собой?
Передавайте один correlation_id через все вызовы, sub-workflows, webhooks и внешние записи.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}