Observability auf einer großen Multi-Tenant n8n Plattform

Fragen
1

Hey zusammen,
Ich skaliere eine Multi-Tenant-n8n-Plattform und stelle fest, dass einfache Logs nicht mehr ausreichen.
Aktuelle Architektur:Load Balancer
↓
Mehrere n8n Workers
↓
PostgreSQL + Redis + External APIs
Mit der wachsenden Anzahl von Tenants und Workflows fällt es mir schwer, Fragen wie diese zu beantworten:
• Welcher Tenant erzeugt die meiste Last?
• Warum ist ein bestimmter Workflow fehlgeschlagen?
• Wo sind die Engpässe im System?
• Welche externen APIs verursachen Latenz?
• Wie erkenne ich Probleme, bevor Kunden sie bemerken?
Ich erwäge, folgende Komponenten hinzuzufügen:
• Zentralisierte Protokollierung
• Metrik-Erfassung
• Verteiltes Tracing
• Dashboards pro Tenant
• Alerting und Anomalieerkennung
Beispielmetriken:tenant_id
workflow_id
execution_time
error_rate
queue_depth
API_latency
Welchen Observability-Stack nutzt ihr?
Welche Metriken waren für euch am wertvollsten?

Beschreibung des Problems/Fehlers/der Frage

Welche Fehlermeldung wird angezeigt (falls vorhanden)?

Bitte teilt euren Workflow

(Wählt die Knoten auf eurer Canvas aus und nutzt die Tastenkombinationen CMD+C/STRG+C und CMD+V/STRG+V zum Kopieren und Einfügen des Workflows.)

Geben Sie die vom letzten Knoten zurückgegebene Ausgabe an

Informationen zu eurem n8n-Setup

  • n8n-Version:
  • Datenbank (Standard: SQLite):
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main):
  • n8n wird ausgeführt über (Docker, npm, n8n cloud, Desktop-App):
  • Betriebssystem:
2

Hey @Greg_John Wenn deine Plattform wächst, wird es immer schwieriger zu verstehen, was passiert, wenn man nur die Logs anschaut. Deshalb ist eine gute Observability so wichtig.

Ein typisches Production-Setup umfasst:
Zentralisiertes Logging
Metrics-Erfassung
Alarme
Tracing (falls nötig)

Die nützlichsten Dinge zum Überwachen sind:
• tenant_id
• workflow_id
• Ausführungszeit
• Fehlerquote
• Warteschlangen-Tiefe
• Antwortzeit externer APIs

Wenn du tenant_id und workflow_id zu deinen Logs und Metrics hinzufügst, wird es viel einfacher, Probleme für einen bestimmten Kunden oder Workflow zu finden und zu beheben.

Es ist auch eine gute Idee, Alarme für Folgendes einzurichten:
Hohe Fehlerquoten
Warteschlangen-Rückstau
Ausfälle von Workern
Langsame externe APIs
Unerwartete Datenverkehrsspitzen

Ein Fehler, den du vermeiden solltest, ist es, dich nur auf Application Logs zu verlassen oder nur deine Infrastruktur zu überwachen. Du brauchst Sichtbarkeit sowohl in deine Workflows als auch in die Systeme, die sie ausführen.

Kurz gesagt: Wenn du deine Logs und Metrics zentralisierst, sie richtig tagst und Dashboards und Alarme einrichtest, kannst du Probleme früh erkennen und deine Plattform am Laufen halten, während sie wächst.

3

Hallo @Greg_John
n8n hat seinen eigenen Prometheus-Endpunkt, daher ist die Sammlungsschicht eine Konfigurationsänderung, nicht etwas, das du selbst erstellst. Stelle dies auf den Mains und den Workers ein:

N8N_METRICS=true
N8N_METRICS_INCLUDE_WORKFLOW_ID_LABEL=true
N8N_METRICS_INCLUDE_NODE_TYPE_LABEL=true
N8N_METRICS_INCLUDE_API_ENDPOINTS=true
N8N_METRICS_INCLUDE_QUEUE_METRICS=true

Die Warteschlangentiefe kommt von n8n_scaling_mode_queue_jobs_waiting und n8n_scaling_mode_queue_jobs_active. n8n liest diese aus Bull und zeigt sie nur auf den Mains, daher richte den Scrape-Job auf den Mains für den Warteschlangenstatus und auf den Workers für Ausführung und Node-Timings. Workflow-ID ist das detaillierteste Label, das n8n ausgibt, es gibt keine Tenant-Dimension, daher führe die Workflow-to-Tenant-Verknüpfung in Prometheus Relabeling oder einer Recording Rule durch und erstelle die Tenant-Ansichten auf dieser Serie. Halte /metrics im internen Netzwerk, es zeigt operative Details über die Instanz.

4

Danke, das ist wirklich hilfreich. Mir gefällt der Punkt zum Tagging aller Elemente mit tenant_id und workflow_id – das würde das Troubleshooting in einer Multi-Tenant-Umgebung viel einfacher machen. Ich stimme auch zu, dass die Überwachung von Workflows genauso wichtig ist wie die Überwachung der Infrastruktur. Danke, dass du das geteilt hast.

5

Danke für den Einblick! Das ist eine hilfreiche Perspektive und gibt mir ein paar Ideen, um mein Setup zu verbessern. Ich werde mir diesen Ansatz mal anschauen und sehen, wie er zu meiner Architektur passt.

6

Der Großteil dieses Threads ist generische Observability-Beratung. Die n8n-spezifischen Teile sind der Ort, wo die Antworten auf deine fünf Fragen tatsächlich zu finden sind, also:

Queue-Tiefe und Pro-Tenant-Last sind bereits verfügbar — du musst sie nicht selbst erstellen. n8n liefert einen Prometheus-Endpoint, der standardmäßig deaktiviert ist: N8N_METRICS=true gibt dir /metrics auf dem Main. Die Flags, die für deinen Fall wichtig sind, sind N8N_METRICS_INCLUDE_QUEUE_METRICS (das ist deine queue_depth), N8N_METRICS_INCLUDE_WORKFLOW_ID_LABEL und N8N_METRICS_INCLUDE_NODE_TYPE_LABEL (Pro-Workflow- und Pro-Node-Type-Series, durch die „welcher Tenant erzeugt die meiste Last