Hallo zusammen,
Ich betreibe mehrere n8n-Instanzen auf Google Cloud Run mit einem einzigen Lizenzschlüssel.
Was ist die beste Möglichkeit, die Nutzung pro Deployment/Mandant (Ausführungen, aktive Workflows, API-Nutzung usw.) zu verfolgen?
Hallo @rgrzesk
Ich denke, der beste Weg ist die Verwendung von Insights:
Aber wenn du mehrere Instanzen von Daten in einem einzelnen Frame haben möchtest, würde ich dir das empfehlen:
Ich habe es verwendet, und es funktioniert immer.
Auch kannst du einfach die N8N API aufrufen:
GET /api/v1/executions?status=success&limit=250
Wenn du nicht auf der n8n Cloud bist, ist die Ud-Metrik-Option die beste.
Hilft dir das weiter, @rgrzesk ?
Um das Tracking über mehrere Cloud Run-Instanzen an einem zentralen Ort durchzuführen, skaliert der API-Polling-Ansatz nicht gut – jede Instanz hat ihren eigenen API-Endpunkt und es gibt keine einheitliche Sicht. Ein sauberes Muster ist, einen dedizierten „Execution Logger
Das klingt wirklich schön, aber das Problem ist, dass ich nicht und werde keinen Zugriff auf jede Instanz haben. Ich kann es orchestrieren, aber kann kein Benutzer sein.
Ich müsste einen solchen vordefinierten Workflow bei der Bereitstellung erstellen, aber ich denke, das ist nicht einfach möglich. Der einzige Weg ist, irgendwie öffentlich verfügbare Daten zu nutzen. Ist es möglich, den Endpunkt /metric zu verwenden? Werde ich genug Daten bekommen, die ich nutzen könnte?
Wenn Sie keinen API-/Benutzerzugriff auf jede Instanz haben, würde ich metrics als partielles Infrastruktursignal behandeln, nicht als vollständiges Nutzungsmodell.
Es kann bei Fragen wie „läuft diese Instanz noch, wie ausgelastet ist sie, fallen mehr Ausführungen fehl als gewöhnlich
Danke, das ergibt Sinn.
Wie wäre es, die DB als Quelle der Wahrheit für historische/Lizenznutzung zu verwenden? Würde das Sinn ergeben, behält es die Daten, die ich brauche?
Überprüfung nach execution_entity und Zählung aller nicht als manual markierten?
Hallo @rgrzesk
es gibt noch einen anderen Ansatz für dein Setup, nämlich OpenTelemetry Tracing. Da du die Bereitstellung kontrollierst, setze diese Umgebungsvariablen während der Provisionierung:
N8N_OTEL_TRACE_ENABLED=true
N8N_OTEL_TRACE_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=https://your-central-collector:4318
Jede Ausführung erzeugt einen workflow.execute Span mit dem Ausführungsmodus, Status, der Workflow-ID und der eindeutigen n8n.instance.id der Instanz. Leite alle Instanzen zu einem Collector (Jaeger, Grafana Tempo, etc.) und du erhältst pro-Instanz-, pro-Ausführungs-Tracking mit Modusfilterung. Kein DB-Zugriff erforderlich, kein Löschungsrisiko, Standardprotokoll und es wird vollständig zur Bereitstellungszeit konfiguriert, was perfekt zu deinen Anforderungen passt.
Für die DB-Route als Fallback: Ja, execution_entity mit mode != 'manual' funktioniert, aber beachte, dass die Bereinigung diese Datensätze basierend auf EXECUTIONS_DATA_MAX_AGE löscht. Aggregiere in deinen eigenen Speicher in einem kürzeren Intervall als das Bereinigungsfenster.
Sag mir, wenn es hilft 
Sehr gut!
OL ist eine gute Lösung für bereits neue Instanzen. Können wir irgendwie auch auf historische Daten zugreifen?
OTel erfasst nur ab dem Zeitpunkt der Aktivierung, keine rückwirkenden Traces.
Für historische Daten bei bestehenden Instanzen gibt es zwei Optionen, da du DB-Zugriff hast:
-
execution_entityTabelle: Fragemode != 'manual'für Produktionszählungen ab. Nur so weit zurück, wie das Löschen erlaubt. -
Insights-Tabellen: n8n speichert komprimierte Insights-Daten separat von execution_entity, standardmäßig bis zu 365 Tage lang (
N8N_INSIGHTS_MAX_AGE_DAYS). Dies bleibt nach dem Löschen von Ausführungen erhalten. Überprüfe dieinsight_*Tabellen in deinem Postgres-Schema auf aggregierte historische Zählungen.
Für alles, das älter ist als das, was in der DB gespeichert ist, ist es weg.
Hallo!
Ich hatte eine längere Pause zum Thema, aber ich bin zurück 
Schön, dass ich ab Version 2.27.0 auch OpenTelemetry in der Benutzeroberfläche konfigurieren kann.
Allerdings habe ich zwei Fragen:
- Kann ich diese Optionen ausblenden? Weil sie den API-Schlüssel des OpenTelemetry-Systems offenlegen.
- Bei welchem execution.mode sollte ich in OTL nachschauen? Ich meine - welche davon sind kostenpflichtig? Auch die !manual?
EDIT - für Frage 2 - ich habe gerade bemerkt, dass es bereits ein Flag gibt N8N_OTEL_TRACES_PRODUCTION_ONLY
Es gibt keine integrierte Umschaltfläche zum Ausblenden des OTel-API-Schlüsselfelds in den Einstellungen — das ist ein bekanntes Problem, das hier als Feature-Request verfolgt wird: OpenTelemetry visible UI . Bis das implementiert ist, besteht die Problemumgehung darin, den Zugriff auf Einstellungen über RBAC/Projektrollen zu beschränken oder OTel-Umgebungsvariablen direkt (N8N_OTEL_*) statt über die Benutzeroberfläche zu setzen, damit der Schlüssel dort nie angezeigt wird.
Bei execution.mode: Nur produktionsgesteuerte Ausführungen zählen zu Ihrem abrechenbaren Kontingent (Webhook-, Zeitplan-, Poll-with
Was ist der Modus integrated? Zählt dieser auch?
Wie sind dann Sub-Workflows sichtbar, wenn sie nicht zählen – als manuell?
„integrated
Unverschämte Eigenwerbung für LumaTrack – wir können das ganz einfach mit unserem verifizierten Community-Node, OTel, MCP, API usw. machen.
Ok, also wenn ich dich richtig verstehe, wenn wir eine Production Execution haben, die 5 verschiedene Sub-Workflows auslöst und diese 5 Sub-Workflows laufen (z.B. wenn Bedingungen erfüllt sind), zahlen wir dann nur EINMAL für die Main Production Execution?
@rgrzesk Ja, das ist korrekt. Die Abrechnung richtet sich nach dem Ausführungsmodus des übergeordneten Workflows, nicht nach dem der einzelnen Sub-Workflows. Wenn der Hauptworkflow im Produktionsmodus ausgelöst wird (Webhook/Schedule/Poll) und dieser 5 Sub-Workflows über Execute Workflow aufruft, werden diese untergeordneten Ausführungen im „integrierten