Melhor prática para manter 30+ dias de logs de execução em uma instância n8n auto-hospedada de alto volume

Perguntas
1

Olá a todos,

Estamos executando uma instância n8n auto-hospedada (v2.32.7) em um VPS Hostinger em um ambiente de produção.

Nossa instância executa mais de 1.000 workflows por dia (aproximadamente 100 mil execuções de produção conforme o painel de Insights), e gostaríamos de manter pelo menos 30 dias de histórico de execução para fins de auditoria e resolução de problemas, incluindo dados de execução (entradas, saídas e erros).

Estamos cientes das configurações de limpeza de execução:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=720
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
EXECUTIONS_DATA_PRUNE_INTERVAL=3600

Nosso objetivo era reter aproximadamente um mês de dados de execução, então aumentamos as configurações de retenção adequadamente. No entanto, após fazer essas alterações, a instância n8n começou a falhar repetidamente (4 travamentos em menos de uma hora). Revertemos a configuração para restaurar a estabilidade.

Algum contexto adicional:

  • Auto-hospedado em VPS Hostinger
  • 16 GB de RAM
  • n8n v2.32.7
  • Banco de dados PostgreSQL
  • Ambiente de produção com muitos workflows ativos
  • Precisamos de dados completos de execução para observabilidade e auditoria (execuções bem-sucedidas e com falha).

Minhas dúvidas são:

  1. Como empresas que executam instâncias n8n de alto volume geralmente retêm logs de execução por 30+ dias?
  2. Vocês mantêm dados de execução diretamente no PostgreSQL ou exportam para outra plataforma de observabilidade/logging?
  3. Existe uma arquitetura recomendada para histórico de execução de longo prazo?
  4. Existem variáveis de ambiente ou otimizações de banco de dados que devem ser consideradas antes de aumentar a retenção de execução?
  5. Alguém já experenciou travamentos após aumentar a retenção de execução? Se sim, qual foi a causa raiz?
  6. Armazenar um mês de dados completos de execução no PostgreSQL é considerado um anti-padrão para n8n nessa escala, ou é uma configuração de produção comum?

Nosso objetivo é ter auditabilidade completa sem comprometer a estabilidade da instância.

Qualquer recomendação ou exemplos de configurações de produção seriam muito apreciados.

Obrigado!

2

Oi @mellkadvescalavel

Armazenar 30 dias de payloads completos de execução no banco de dados PostgreSQL operacional do n8n no seu volume de execução causa inchaço severo da tabela e esgotamento de memória (OOM) durante consultas de UI/API, o que é por isso que sua instância está travando; a solução de nível de produção é desacoplar a retenção operacional de curto prazo do registro de auditoria de longo prazo.

3

Olá @mellkadvescalavel ! Que setup grande você tem! Sua contagem de pruning está configurada para 10.000, então mesmo com 30 dias configurados, você está sendo recortado por volta de 10 dias com cerca de 1000 execuções por dia! Antes de aumentar ou alterar qualquer configuração, quando travou, foi o contêiner n8n ficando sem memória ou postgres ficando sem espaço em disco?

Quanto às suas perguntas, aqui estão minhas recomendações, e ter apenas 16GB de RAM para 1000 execuções por dia parece bem apertado.

  1. Não sou uma empresa, então não tenho certeza, mas vejo muitas pessoas usando pruning e loop nodes para lidar com limitações. Não mantenha isso no n8n, o Postgres pode armazenar uma janela de 7-14 dias para debug, mas qualquer coisa mais longa do que isso deve ir para outro logger ou local

  2. Você deveria exportar, enviar dados que precisa para outra fonte.

  3. Você deveria usar dois níveis, postgres com pruning grande, e depois outcomes para seu próprio armazenamento ou local separado. Talvez um webhook ou algo que possa receber.
    Algo como N8N_EXECUTION_DATA_STORAGE_MODE=s3 para manter o postgres minúsculo

  4. Sim, esses funcionam - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none - Mantém apenas erros

  5. Para os travamentos, é postgres ou erros de OOM.

  6. Na sua escala, provavelmente é um anti-padrão, é o que vai quebrar seu banco de dados e causar mais problemas.

4

Essas duas configurações de retenção entram em conflito. EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000 limita execuções retidas a 10.000, mesmo que EXECUTIONS_DATA_MAX_AGE=720. Com aproximadamente 1.000 execuções por dia, o limite de contagem vence após cerca de dez dias.

Eu não chamaria o inchaço da tabela de crashes ou falha de RAM ainda. Verifique o motivo de saída do container e os logs do PostgreSQL separadamente. Também verifique o espaço em disco disponível. Cada um aponta para uma falha diferente e uma solução diferente.

Para uma trilha de auditoria de 30 dias, mantenha uma janela de diagnóstico mais curta no n8n e escreva um registro de auditoria restrito do próprio workflow. Inclua o ID de execução, versão do workflow, timestamps, resultado e apenas os identificadores de negócio necessários para rastrear a ação. Mantenha payloads completos apenas quando o requisito de auditoria precisar deles, após remover segredos e dados pessoais.

Meça um dia normal de dados de execução retidos e, em seguida, projete isso ao longo de 30 dias. A contagem de execuções sozinha não lhe diz se essa instância do Postgres e disco podem suportar a janela.