Observability и метрики для n8n workflow ¶

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

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

Observability в n8n — это не только список failed executions. Production-команда должна видеть технические метрики, бизнес-результат, задержки, retries, DLQ, cost, payload quality и цепочку одного события через несколько workflow. Минимальная база: correlation ID, structured logs, normalized error codes, dashboards, alerting и runbook для каждого критичного workflow. Без observability n8n становится “чёрным ящиком”: automation вроде работает, но никто не знает, сколько заявок потеряно и где именно произошёл сбой.

Что именно нужно наблюдать ¶

Для n8n недостаточно смотреть только на красные failed executions. Workflow может формально завершиться успешно, но создать дубль, пропустить важное поле, отправить лид не в тот pipeline, получить плохой AI-output или обработать только 40 из 100 items. Поэтому observability должна включать четыре слоя: platform health, workflow health, business outcome и data quality.

Platform health отвечает за CPU, RAM, disk, Postgres, Redis, workers, queue depth, webhook latency. Workflow health — success/fail rate, duration, retries, stuck executions, error codes. Business outcome — сколько лидов создано, сколько платежей подтверждено, сколько тикетов маршрутизировано. Data quality — сколько payload не прошло validation, сколько enrichment пустой, сколько AI confidence ниже порога.

Correlation ID как основа ¶

Если у события нет correlation ID, расследование превращается в поиск по времени и догадкам. Correlation ID должен появляться на входе: из HTTP header, webhook payload, CRM event ID или генерироваться первым Code node. Дальше он должен идти во все логи, DLQ, idempotency table, external API metadata, AI tool output и alert.

Пример нормализации:

const crypto = require('crypto');
const correlationId = $json.headers?.['x-correlation-id']
  || $json.correlation_id
  || `corr_${crypto.randomUUID()}`;

return [{
  json: {
    ...$json,
    correlation_id: correlationId,
    observed_at: new Date().toISOString()
  }
}];

Для внешних API полезно передавать correlation ID в metadata или comment, если сервис это позволяет. Тогда support сможет связать запись в CRM, execution в n8n и событие в платежной системе.

Структурированные логи ¶

Лог должен быть машинно читаемым. Сообщение “что-то пошло не так” бесполезно. Минимальная структура: timestamp, workflow_name, workflow_version, execution_id, node_name, correlation_id, event_type, idempotency_key, status, error_code, duration_ms, attempt, external_service, external_object_id, masked_payload_summary.

Пример log object:

{
  "level": "warn",
  "workflow": "lead_to_crm",
  "execution_id": "12345",
  "correlation_id": "corr_abc",
  "event_type": "lead.created",
  "node": "Create or update lead",
  "status": "retry_scheduled",
  "error_code": "crm_502",
  "attempt": 2,
  "duration_ms": 1840,
  "next_retry_at": "2026-05-29T10:30:00Z"
}

Такой лог можно отправить в syslog/Sentry/webhook/log storage или хотя бы сохранить в Postgres для критичных процессов. Главное — маскировать PII и secrets.

Метрики, которые действительно нужны ¶

Начните с небольшого набора. Технические: execution count, success rate, failed rate, p95 duration, timeout count, retry count, DLQ size, queue depth, worker concurrency, webhook response time. Бизнесовые: leads accepted, leads rejected, payments confirmed, tickets routed, AI outputs approved, emails sent. Качество данных: validation error rate, missing required fields, duplicate prevention count, low confidence AI outputs, RAG no-answer rate.

Плохая метрика — “workflow запустился 1000 раз”. Хорошая метрика — “из 1000 событий 932 успешно завершили бизнес-действие, 41 ушли в validation quarantine, 19 ждут retry, 8 требуют ручной проверки”. Именно такой разрез показывает реальное состояние automation.

Prometheus, logs и OpenTelemetry ¶

Для self-hosted n8n можно включать метрики и интегрировать их с существующим monitoring stack. Если используется queue mode, следите отдельно за main instance и workers: worker может быть перегружен, пока UI выглядит живым. Если доступны traces, связывайте node execution latency с upstream/downstream системами.

Но не начинайте с инструментов. Сначала определите, какие вопросы должна отвечать панель: “поступают ли webhook?”, “растёт ли DLQ?”, “какой provider тормозит?”, “какой workflow создаёт больше ошибок?”, “есть ли retry storm?”, “падает ли качество AI-ответов после изменения prompt?”. После этого выбирайте Prometheus, OpenTelemetry, log streaming, Sentry или обычную Postgres-таблицу.

Dashboards для владельца процесса ¶

Dashboard для DevOps и dashboard для бизнеса должны отличаться. DevOps нужны Redis, Postgres, workers, CPU/RAM, latency, 5xx. Владельцу продаж нужны новые лиды, дубли, rejected payload, SLA передачи в CRM, доля ручной проверки. Владельцу поддержки нужны тикеты по категориям, first response, escalation rate, AI draft approval rate.

Для каждой критичной automation сделайте маленькую карточку: входящие события, успешные бизнес-действия, ошибки по категориям, DLQ, средняя задержка, последние инциденты, ссылка на runbook. Это гораздо полезнее, чем единая огромная панель на 80 графиков.

Alerting без шума ¶

Alert должен требовать действия. Не нужно будить команду из-за одного transient 502, если retry успешно обработал событие. Нужно алертить, когда DLQ старше SLA, rate of validation errors резко вырос, credentials invalid, Postgres/Redis недоступен, webhook latency выше лимита, success rate упал ниже порога, stuck executions превышают норму, AI cost spike продолжается больше N минут.

Каждый alert должен содержать: affected workflow, impact, correlation examples, error_code, последние изменения, ссылку на dashboard, ссылку на runbook. Alert без runbook — это просто шум.

Production checklist ¶

Проверьте: correlation ID создаётся на входе; logs структурированы; error codes нормализованы; есть business metrics; DLQ size виден; retries видны отдельно от failures; dashboard разделяет platform/workflow/business/data quality; PII маскируется; alert routing настроен по severity; у каждого critical alert есть runbook; после релиза проверяются smoke metrics; AI workflow имеют cost и quality metrics.

FAQ ¶

Execution logs n8n достаточно для observability? ¶

Для маленьких процессов — частично. Для production нужны структурированные business logs, метрики, DLQ, correlation ID и alerting.

Что логировать в AI workflow? ¶

Prompt version, input hash, model, token/cost estimate, output schema status, confidence, tool calls, human review decision и error_code.

Нужно ли хранить весь payload? ¶

Не всегда. Для PII лучше хранить masked summary и ссылку на защищённое хранилище. Полный payload храните только по политике доступа.

Какой первый dashboard сделать? ¶

Сделайте dashboard по критичным workflow: входящие события, успехи, ошибки по типам, DLQ, retry, p95 duration и business outcome.

Что важнее: logs или metrics? ¶

Нужны оба. Metrics показывают масштаб проблемы, logs объясняют конкретный случай.