Best Practice zum Speichern von über 30 Tagen Ausführungsprotokollen in einer selbstgehosteten n8n-Instanz mit hohem Volumen

Fragen
1

Hallo zusammen,

wir betreiben eine selbstgehostete n8n-Instanz (v2.32.7) auf einem Hostinger VPS in einer Produktionsumgebung.

Unsere Instanz führt täglich über 1.000 Workflows aus (etwa 100k Produktionsausführungen laut Insights-Dashboard), und wir möchten mindestens 30 Tage Ausführungsverlauf für Audit- und Troubleshooting-Zwecke behalten, einschließlich Ausführungsdaten (Eingaben, Ausgaben und Fehler).

Wir sind uns der Ausführungs-Pruning-Einstellungen bewusst:

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

Unser Ziel war es, etwa einen Monat Ausführungsdaten zu speichern, also haben wir die Aufbewahrungseinstellungen entsprechend erhöht. Allerdings begann die n8n-Instanz nach diesen Änderungen, wiederholt abzustürzen (4 Abstürze in weniger als einer Stunde). Wir haben die Konfiguration zurückgesetzt, um die Stabilität wiederherzustellen.

Etwas zusätzlicher Kontext:

  • Selbstgehostet auf Hostinger VPS
  • 16 GB RAM
  • n8n v2.32.7
  • PostgreSQL-Datenbank
  • Produktionsumgebung mit vielen aktiven Workflows
  • Wir benötigen vollständige Ausführungsdaten zur Überwachung und Revision (erfolgreiche und fehlgeschlagene Ausführungen).

Meine Fragen sind:

  1. Wie behalten Unternehmen, die hochvolumige n8n-Instanzen betreiben, normalerweise Ausführungsprotokolle für 30+ Tage?
  2. Speichern Sie Ausführungsdaten direkt in PostgreSQL, oder exportieren Sie diese auf eine andere Observability-/Logging-Plattform?
  3. Gibt es eine empfohlene Architektur für einen langfristigen Ausführungsverlauf?
  4. Gibt es Umgebungsvariablen oder Datenbankoptimierungen, die vor einer Erhöhung der Ausführungsaufbewahrung berücksichtigt werden sollten?
  5. Hat jemand Abstürze nach einer Erhöhung der Ausführungsaufbewahrung erlebt? Wenn ja, was war die Grundursache?
  6. Ist die Speicherung von einem Monat vollständiger Ausführungsdaten in PostgreSQL bei dieser Skala ein Anti-Pattern für n8n, oder ist dies eine häufige Produktionseinrichtung?

Unser Ziel ist es, vollständige Nachverfolgbarkeit zu haben, ohne die Instanzstabilität zu beeinträchtigen.

Alle Empfehlungen oder Beispiele von Produktionseinrichtungen wären sehr hilfreich.

Danke!

2

Hi @mellkadvescalavel

Das Speichern von 30 Tagen vollständiger Execution-Payloads in n8ns operativer PostgreSQL-Datenbank bei deinem Execution-Volumen verursacht schwere Table-Bloat und Memory-Erschöpfung (OOM) während UI/API-Abfragen, weshalb deine Instanz abstürzt; die produktionsreife Lösung besteht darin, die kurzfristige operative Aufbewahrung von der langfristigen Audit-Protokollierung zu entkoppeln.

3

Hallo @mellkadvescalavel! Das ist eine beeindruckende Einrichtung, die du da hast! Deine Prune-Anzahl ist auf 10.000 eingestellt, also selbst bei den 30 Tagen, die du eingestellt hast, wirst du nach etwa 10 Tagen bei 1000 Ausführungen pro Tag gekürzt! Bevor du aber irgendwelche Einstellungen erhöhst oder änderst, stürzte es ab, weil dem n8n-Container der Speicher ausging oder PostgreSQL nicht genug Speicherplatz hatte?

Zu deinen Fragen hin, hier sind meine Empfehlungen, und ehrlich gesagt scheinen 16GB RAM für 1000 Ausführungen pro Tag ziemlich knapp zu sein.

  1. Ich bin kein Unternehmen, also bin ich mir nicht sicher, aber ich sehe viele Menschen, die Pruning und Loop-Nodes verwenden, um Einschränkungen zu handhaben. Behalte es nicht in n8n, PostgreSQL kann ein Fenster von 7–14 Tagen zum Debuggen speichern, aber alles, das länger als das ist, sollte zu einem anderen Logger oder Speicherort gehen

  2. Du solltest exportieren und Daten, die du brauchst, zu einer anderen Quelle pushen.

  3. Du solltest zwei Ebenen verwenden, PostgreSQL mit aggressivem Pruning und dann Ergebnisse zu deinem eigenen separaten Speicher oder Speicherort. Vielleicht ein Webhook oder etwas, das das empfangen kann.
    Etwas wie N8N_EXECUTION_DATA_STORAGE_MODE=s3, um PostgreSQL winzig zu halten

  4. Ja, diese funktionieren – EXECUTIONS_DATA_SAVE_ON_SUCCESS=none – Speichert nur Fehler

  5. Bei den Abstürzen ist es entweder PostgreSQL oder OOM-Fehler.

  6. In deinem Maßstab ist es wahrscheinlich ein Antipattern, das wird deine DB zerstören und mehr Probleme verursachen.

4

Diese zwei Aufbewahrungseinstellungen stehen in Konflikt. EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000 begrenzt beibehaltene Ausführungen auf 10.000, auch wenn EXECUTIONS_DATA_MAX_AGE=720 gesetzt ist. Bei etwa 1.000 Ausführungen pro Tag gewinnt das Zählerlimit nach etwa zehn Tagen.

Ich würde die Crashes-Tabelle noch nicht als Bloat oder RAM-Fehler bezeichnen. Überprüfe den Container-Exit-Grund und die PostgreSQL-Logs separat. Überprüfe auch den verfügbaren Speicherplatz. Jeder dieser Punkte deutet auf einen anderen Fehler und eine andere Lösung hin.

Für eine 30-Tage-Audit-Trail behälte ein kürzeres Diagnose-Fenster in n8n und schreibe einen engen Audit-Datensatz aus dem Workflow selbst. Füge die Ausführungs-ID, Workflow-Version, Zeitstempel, Ergebnis und nur die geschäftlichen Kennungen ein, die zum Nachverfolgen der Aktion nötig sind. Behalte vollständige Payloads nur, wenn die Audit-Anforderung sie braucht, nachdem du Geheimnisse und persönliche Daten entfernt hast.

Messe einen normalen Tag beibehaltener Ausführungsdaten, dann projiziere ihn auf 30 Tage. Die Ausführungsanzahl allein zeigt dir nicht, ob diese Postgres-Instanz und die Festplatte das Fenster tragen können.