Mejores prácticas para mantener registros de ejecución de 30+ días en una instancia n8n auto-hospedada de alto volumen

Preguntas
1

¡Hola a todos!

Estamos ejecutando una instancia n8n autohospedada (v2.32.7) en un VPS de Hostinger en un entorno de producción.

Nuestra instancia ejecuta más de 1000 flujos de trabajo por día (aproximadamente 100k ejecuciones de producción según el panel de Insights), y nos gustaría mantener al menos 30 días de historial de ejecución para fines de auditoría y solución de problemas, incluidos los datos de ejecución (entradas, salidas y errores).

Somos conscientes de la configuración de poda de ejecuciones:

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

Nuestro objetivo era retener aproximadamente un mes de datos de ejecución, por lo que aumentamos la configuración de retención en consecuencia. Sin embargo, después de realizar estos cambios, la instancia de n8n comenzó a bloquearse repetidamente (4 bloqueos en menos de una hora). Revertimos la configuración para restaurar la estabilidad.

Algún contexto adicional:

  • Autohospedado en VPS de Hostinger
  • 16 GB de RAM
  • n8n v2.32.7
  • Base de datos PostgreSQL
  • Entorno de producción con muchos flujos de trabajo activos
  • Necesitamos datos de ejecución completos para observabilidad y auditoría (ejecuciones exitosas y fallidas).

Mis preguntas son:

  1. ¿Cómo suelen retener los registros de ejecución durante 30 o más días las empresas que ejecutan instancias n8n de alto volumen?
  2. ¿Mantienen los datos de ejecución directamente en PostgreSQL o los exportan a otra plataforma de observabilidad/registro?
  3. ¿Hay una arquitectura recomendada para el historial de ejecución a largo plazo?
  4. ¿Hay variables de entorno u optimizaciones de base de datos que deban considerarse antes de aumentar la retención de ejecuciones?
  5. ¿Ha experimentado alguien bloqueos después de aumentar la retención de ejecuciones? Si es así, ¿cuál fue la causa raíz?
  6. ¿Se considera un antipatrón almacenar un mes de datos de ejecución completos en PostgreSQL para n8n a esta escala, o es una configuración de producción común?

Nuestro objetivo es tener una auditoría completa sin comprometer la estabilidad de la instancia.

Se agradecería mucho cualquier recomendación o ejemplo de configuraciones de producción.

¡Gracias!

2

Hola @mellkadvescalavel

Almacenar 30 días de cargas de ejecución completas en la base de datos PostgreSQL operativa de n8n en tu volumen de ejecución causa una severa inflación de tablas y agotamiento de memoria (OOM) durante consultas de UI/API, por eso tu instancia se está bloqueando; la solución de grado producción es desacoplar la retención operativa a corto plazo del registro de auditoría a largo plazo.

3

¡Hola @mellkadvescalavel! ¡Ese es un gran sistema que tienes! Tu conteo de poda está configurado en 10,000, así que incluso con los 30 días configurados, te estás cortando alrededor de 10 días ¡a alrededor de 1000 ejecuciones al día! Antes de que aumentes o cambies cualquier configuración, cuando se bloqueó, ¿fue el contenedor de n8n quedándose sin memoria o postgres quedándose sin espacio en disco?

Con respecto a tus preguntas, aquí están mis recomendaciones, y además, tener solo 16GB de RAM para 1000 ejecuciones al día parece bastante limitado.

  1. No soy una empresa, así que no estoy seguro, pero veo a mucha gente usando nodos de poda y bucles para manejar limitaciones. No lo mantengas en n8n, Postgres puede mantener una ventana de 7-14 días para depuración, pero cualquier cosa más larga que eso debería ir a otro registrador o ubicación

  2. Deberías exportar, empujar datos que necesites a otra fuente.

  3. Deberías usar dos niveles, postgres con una poda grande, y luego resultados a tu propio almacén o ubicación separada. Quizás un webhook o algo que pueda recibir.
    Algo como N8N_EXECUTION_DATA_STORAGE_MODE=s3 para mantener postgres pequeño

  4. Sí, estos funcionan - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none - Mantiene solo errores

  5. Para los bloqueos, es postgres u errores OOM.

  6. A tu escala, probablemente sea un antipatrón, es lo que romperá tu BD y causará más problemas.

4

Esos dos ajustes de retención entran en conflicto. EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000 limita las ejecuciones retenidas a 10.000 incluso si EXECUTIONS_DATA_MAX_AGE=720. Con aproximadamente 1.000 ejecuciones al día, el límite de conteo prevalece después de aproximadamente diez días.

No llamaría aún al crecimiento de la tabla de fallos o a la falla de RAM. Verifica la razón de salida del contenedor y los registros de PostgreSQL por separado. También verifica el espacio libre en disco. Cada uno apunta a un fallo diferente y a una solución diferente.

Para un registro de auditoría de 30 días, mantén una ventana de diagnóstico más corta en n8n y escribe un registro de auditoría estrecho desde el flujo de trabajo en sí. Incluye el ID de ejecución, la versión del flujo de trabajo, marcas de tiempo, resultado e identificadores comerciales solamente los necesarios para rastrear la acción. Mantén cargas útiles completas solo cuando el requisito de auditoría las necesita, después de eliminar secretos y datos personales.

Mide un día normal de datos de ejecución retenidos, luego proyéctalo en 30 días. El conteo de ejecuciones solo no te dice si esta instancia de Postgres y el disco pueden mantener la ventana.