Bonnes pratiques pour conserver 30+ jours de logs d'exécution dans une instance n8n auto-hébergée à haut volume

Questions
1

Bonjour à tous,

Nous exécutons une instance n8n auto-hébergée (v2.32.7) sur un VPS Hostinger dans un environnement de production.

Notre instance exécute plus de 1 000 workflows par jour (environ 100k exécutions de production selon le tableau de bord Insights), et nous aimerions conserver au moins 30 jours d’historique d’exécution à des fins d’audit et de dépannage, incluant les données d’exécution (entrées, sorties et erreurs).

Nous sommes conscients des paramètres d’élagage d’exécution :

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

Notre objectif était de conserver environ un mois de données d’exécution, nous avons donc augmenté les paramètres de rétention en conséquence. Cependant, après avoir apporté ces modifications, l’instance n8n a commencé à planter à plusieurs reprises (4 plantages en moins d’une heure). Nous avons annulé la configuration pour restaurer la stabilité.

Alguns contextes supplémentaires :

  • Auto-hébergé sur un VPS Hostinger
  • 16 Go de RAM
  • n8n v2.32.7
  • Base de données PostgreSQL
  • Environnement de production avec de nombreux workflows actifs
  • Nous avons besoin de données d’exécution complètes pour l’observabilité et l’audit (exécutions réussies et échouées).

Mes questions sont :

  1. Comment les entreprises exécutant des instances n8n à haut volume conservent-elles généralement les journaux d’exécution pendant 30+ jours ?
  2. Conservez-vous les données d’exécution directement dans PostgreSQL ou les exportez-vous vers une autre plateforme d’observabilité/journalisation ?
  3. Existe-t-il une architecture recommandée pour un historique d’exécution à long terme ?
  4. Quelles variables d’environnement ou optimisations de base de données doivent être prises en compte avant d’augmenter la rétention d’exécution ?
  5. Y a-t-il quelqu’un qui a connu des plantages après avoir augmenté la rétention d’exécution ? Si oui, quelle en était la cause première ?
  6. Le stockage d’un mois de données d’exécution complètes dans PostgreSQL est-il considéré comme un anti-pattern pour n8n à cette échelle, ou s’agit-il d’une configuration de production courante ?

Notre objectif est d’avoir une auditabilité complète sans compromettre la stabilité de l’instance.

Toute recommandation ou exemple de configurations de production serait grandement apprécié.

Merci !

2

Salut @mellkadvescalavel

Conserver 30 jours de charges utiles d’exécution complètes dans la base de données PostgreSQL opérationnelle de n8n à votre volume d’exécution provoque un gonflage sévère des tables et un épuisement de la mémoire (OOM) lors des requêtes UI/API, c’est pourquoi votre instance s’arrête ; la solution de qualité production consiste à découpler la rétention opérationnelle à court terme de l’enregistrement d’audit à long terme.

3

Bonjour @mellkadvescalavel ! C’est une belle infrastructure que tu as ! Ton nombre de pruning est défini à 10 000, donc même avec une durée de 30 jours, tu es limité à environ 10 jours avec environ 1000 exécutions par jour ! Avant de modifier ou de changer un paramètre, quand ça s’est crashé, c’était le conteneur n8n qui manquait de mémoire ou postgres qui manquait d’espace disque ?

Voici mes recommandations pour répondre à tes questions, et avoir seulement 16 Go de RAM pour 1000 exécutions par jour semble bien serré.

  1. Je ne suis pas une entreprise, donc je ne suis pas sûr, mais je vois beaucoup de gens utiliser le pruning et les nœuds de boucle pour gérer les limitations. Ne les conserve pas dans n8n, Postgres peut conserver une fenêtre de 7 à 14 jours pour le débogage, mais tout ce qui dépasse cela devrait être envoyé à un autre logger ou une autre localisation.

  2. Tu devrais exporter et pousser les données dont tu as besoin vers une autre source.

  3. Tu devrais utiliser deux niveaux : postgres avec un grand pruning, puis envoyer les résultats vers ton propre magasin ou ta propre localisation séparé. Peut-être un webhook ou quelque chose qui peut recevoir.
    Quelque chose comme N8N_EXECUTION_DATA_STORAGE_MODE=s3 pour garder postgres minuscule.

  4. Oui, ça marche — EXECUTIONS_DATA_SAVE_ON_SUCCESS=none — Conserve seulement les erreurs.

  5. Pour les crashes, c’est soit postgres soit des erreurs OOM.

  6. À ton échelle, c’est probablement un anti-pattern, c’est ce qui va casser ta DB et causer plus de problèmes.

4

Ces deux paramètres de rétention entrent en conflit. EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000 limite les exécutions conservées à 10 000 même si EXECUTIONS_DATA_MAX_AGE=720. Avec environ 1 000 exécutions par jour, la limite de décompte l’emporte après environ dix jours.

Je n’appellerais pas encore le gonflement de la table crashes ou une défaillance RAM. Vérifiez séparément la raison de sortie du conteneur et les journaux PostgreSQL. Vérifiez également l’espace disque disponible. Chacun pointe vers une défaillance différente et un correctif différent.

Pour une piste d’audit de 30 jours, conservez une fenêtre de diagnostic plus courte dans n8n et écrivez un enregistrement d’audit étroit à partir du workflow lui-même. Incluez l’ID d’exécution, la version du workflow, les horodatages, le résultat et uniquement les identificateurs métier nécessaires pour tracer l’action. Conservez les charges utiles complètes uniquement lorsque l’exigence d’audit en a besoin, après suppression des secrets et des données personnelles.

Mesurez un jour normal de données d’exécution conservées, puis projetez-le sur 30 jours. Le nombre d’exécutions seul ne vous dit pas si cette instance Postgres et ce disque peuvent supporter la fenêtre.