OpenTelemetry-Connector stoppt nach wenigen Stunden mit dem Datenversand

Problem/Fehler/Frage beschreiben

Auf unserer n8n gehosteten Instanz haben wir einen OTLP-Kollektor (Dash0-Endpunkt) konfiguriert. Nach der anfänglichen Einrichtung hat er begonnen, Daten zu versenden, aber jedes Mal stoppt er das Versenden nach ein paar Stunden ohne Fehler- oder Warnmeldung.

Nur wenn wir eine Einstellung in der OpenTelemetry-Konfiguration ändern oder wenn wir einen Test-Trace versenden, wird er weitermachen, aber nach ein paar Stunden stoppt er erneut das Versenden von Daten.

Dieses Problem ist in einer Woche bereits 3 Mal aufgetreten.

Telemetrie-Konfiguration:

  • Startup-Konnektivitäts-Timeout = 20000ms
  • Trace-Abtastrate = 1
  • Node-Spans einschließen = Wahr
  • Ausgehenden Traceparent injizieren = Wahr
  • Nur veröffentlichte Workflows nachverfolgen = Wahr

Welche Fehlermeldung wird angezeigt (falls vorhanden)?

Telemetriedaten werden nicht mehr an den Connector versandt.

Informationen zu deinem n8n-Setup

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

Hey @Giel_Derks, während du auf eine Antwort wartest, könnten dir diese Ressourcen helfen:

Vorgeschlagene Ressourcen

Automatisch zu deiner Frage zugeordnet.

Dokumentation:

Forum:

@Mark_Schuddeboom - du hast bei ähnlichen Problemen schon geholfen, schaust du mal drüber?

Automatisch vorgeschlagen durch n8n’s Community-Bot. Das ist ein Pilot - bitte gib hier Feedback.

Hi @Giel_Derks
Nichts in der OpenTelemetry-Oberfläche wiederholt einen steckengebliebenen Exporter. Der vollständige Variablensatz umfasst den Endpunkt, den Tracing-Pfad, Header, Servicename, Sample Rate, die beiden Span-Umschalter und ein Startup-Konnektivitäts-Timeout, ohne Wiederholung, Backoff oder Export-Timeout irgendwo. Das Speichern von Einstellungen lädt den Exporter ohne Neustart neu, weshalb eine Konfigurationsänderung und das Test-Trace beide wiederhergestellt werden, während normale Ausführungen dies nicht tun.
Tracing ist Preview ab 2.19.0, daher gibt es auf deiner Seite keine Einstellung, die dies behebt. Die Exporter-Diagnose wird nur bei N8N_LOG_LEVEL=debug detailliert, was Cloud nicht bereitstellt. Sende daher die Instance-URL, 2.35.4 und die Zeitstempel der drei Stalls an help@n8n.io und lasse sie die Logs lesen.

Dies sieht so aus, als würde der OTLP-Exporter/die Verbindung nach einer Weile Inaktivität steckenbleiben.

Ich würde diese Punkte zuerst überprüfen:

  1. Dash0/OTLP-Endpunkt — bestätigen, dass er kontinuierlich erreichbar bleibt und keine Verbindungen bei Inaktivität trennt.
  2. n8n-Logs — Logging erhöhen und um die genaue Zeit überprüfen, zu der die Telemetrie stoppt, besonders auf OTEL-/Exporter-Fehler.
  3. Span-Volumen reduzieren — mit Trace sample rate = 1 und aktivierten Node-Spans senden Sie möglicherweise eine sehr große Datenmenge. Probieren Sie vorübergehend eine niedrigere Sample-Rate aus.
  4. Mit einem anderen OTLP-Endpunkt/Collector testen, um zu sehen, ob das Problem mit n8n oder Dash0 verknüpft ist.
  5. Da das Ändern der OTEL-Einstellung es sofort wieder aktiviert, vermute ich auch ein n8n OpenTelemetry-Exporter-/Verbindungslebenszyklus-Problem. Falls reproduzierbar, melden Sie es n8n mit Zeitstempel und Logs.

Der wichtige Hinweis ist: Es stoppt stillschweigend, dann startet wieder, wenn Sie die OTEL-Konfiguration ändern. Das deutet eher darauf hin, dass der Telemetrie-Exporter/die Verbindung steckenbleibt, als dass Ihre Workflows das Problem verursachen.

Der Hinweis, den noch niemand verwendet hat, ist die Form der Lücken, und du hast bereits die Daten, um sie zu lesen, ohne einen Zugriff zu benötigen, den du nicht hast.

Beide obigen Antworten landen bei „der Exporter bleibt stecken‟, was passt. Aber es gibt zwei sehr unterschiedliche Dinge, die beide so aussehen, und man unterscheidet sie nach wann die Ausfallzeiten beginnen, nicht danach, was die Logs sagen:

  • Wenn die Lücke immer ungefähr gleich lange Zeit nach der vorherigen Aktivität öffnet — eine Stunde, zwei Stunden, was auch immer es bei dir ist, aber jedes Mal gleich — dann wird eine untätige Verbindung irgendwo zwischen n8n und Dash0 gelöscht, und der Exporter erfährt nie, dass sie gestorben ist. Eine langlebige OTLP-Verbindung, die schweigt, wird von dem geschlossen, was in der Mitte sitzt, und Schreibvorgänge danach führen nirgendwo hin, ohne einen Fehler zu verursachen.
  • Wenn die Lücken in unzusammenhängenden Abständen beginnen, dann ist der Exporter selbst eingeklemmt, und das gehört in ein Support-Ticket.

Du kannst allein aus Dash0 überprüfen, welcher Fall vorliegt: Nimm die letzte Trace vor jeder der drei Ausfallzeiten und die erste Trace, nachdem n8n zurückgekommen ist, und schau dir das Intervall dazwischen an. Drei Datenpunkte reichen aus, um eine Konstante zu sehen.

Warum es für dich speziell wichtig ist: Du bist in der Cloud, also kannst du das Protokoll nicht ändern oder keepalive hinzufügen. Falls es der Fall der untätigen Verbindung ist, ist der Workaround, der zu Cloud passt, die Leitung warm zu halten — etwas, das garantiert, dass eine Trace mindestens so oft wie bei diesem Intervall exportiert wird. Track published workflows only = True macht ruhige Phasen wahrscheinlicher, weil nichts, das läuft, auch nichts bedeutet, das exportiert wird.

Die allgemeine Form davon ist diejenige, die Menschen in n8n die meiste Zeit kostet: etwas, das ständig Erfolg meldet, während es still und leise aufgehört hat, die Arbeit zu erledigen. Das ist das, wofür wir CatchLeak in Workflows gebaut haben. Wenn du möchtest, schicke mir einen ruhigen Export und ich werde ihn für diese Klasse von stillen Ausfallzeiten lesen und dir sagen, was ich finde — kostenlos, egal ob es sich am Ende herausstellt, dass es dieser Fall ist oder nicht.

Neue Version n8n@2.40.6 wurde veröffentlicht, die den GitHub PR 39368 enthält.

Eine neue Version n8n@2.41.2 wurde veröffentlicht, die den GitHub PR 39367 enthält.