Eine Falle auf der Ebene der fehlenden Durchläufe: Wenn der Heartbeat ein Knoten innerhalb des Workflows ist, „stirbt
Das dreiteilige Framework in diesem Thread – Hard Fails, Grün-aber-nichts, verpasste Durchläufe – ist das richtige mentale Modell. Eine weitere Schicht, die es wert ist hinzugefügt zu werden, wenn Sie Workflows für mehrere Clients von einer einzigen n8n-Instanz aus ausführen: Error Routing nach Client.
Das Problem mit einem gemeinsamen Slack-Channel für alle Error-Benachrichtigungen: Die Verantwortung ist mehrdeutig (wer kümmert sich um die Alert um 3 Uhr morgens, wenn sie einem von fünf Clients gehören könnte?), das Volumen von einem aktiven Client begraben Alerts von ruhigeren, und wenn Clients jemals Zugriff auf diesen Channel erhalten, können sie sich gegenseitig die Workflow-Namen sehen.
Das Muster, das ich verwende:
Platzieren Sie einen Set-Knoten ganz oben in jedem Workflow und legen Sie ein sticky Feld fest – etwas wie client_id = “acme_roofing” oder client_id = “westside_clinic”. Dies wird die Single Source of Truth dafür, welchem Client der Workflow gehört.
In Ihrem Error Workflow lesen Sie dieses Feld aus den Error-Daten und routen entsprechend: Wenn client_id “acme_roofing” ist, senden Sie an #alerts-acme; wenn “westside_clinic”, senden Sie an #alerts-westside oder die E-Mail des Account Managers.
Der Set-Knoten dient auch als Workflow-Header: Wer den Workflow öffnet, weiß sofort, welchen Client und Prozess er behandelt. Es lohnt sich, ihn hinzuzufügen, selbst wenn Sie nie die Alert-Channels segmentieren – es spart viel Kopfzerbrechen, wenn jemand Unbekanntes einen 3-Uhr-Fehler debuggen muss.
Bei kleineren Setups, die keine separaten Channels benötigen, hilft die gleiche Idee immer noch: Präfix jeder Alert mit dem Client-Namen, “[Acme Roofing] appointment reminder failed.” Allein das macht es einfach, in Slack zu filtern und die Triage-Eigenverantwortung am Morgen zuzuweisen.
Ich arbeite daran, die Erkennung von stillem Fehlschlag in AGD zu implementieren. Heute werde ich umfangreiche Tests meiner Lösung durchführen und meine Ergebnisse hier berichten.
Bisher läuft alles gut, aber ich werde das heute pushen: Hier mein Lösungsvorschlag:
Wir wollen diese stillen Fehler aus n8ns OpenTelemetry-Daten abfangen, außerhalb der Workflows, anstatt eine Schutzmaßnahme an jedem Node innerhalb davon hinzuzufügen. n8n sendet bereits einen Span pro Node, daher kann ein Watcher über all deine Workflows gleichzeitig sitzen und entscheiden, ob ein Run tatsächlich seine Arbeit geleistet hat, getrennt vom Success- oder Error-Status, den n8n meldet.
Das Wichtigste, das wir herausgefunden haben, ist, dass man dem Status auf keiner Ebene trauen kann. Ein Continue-On-Fail-Node kommt bei der Ausführung, dem Node und dem Span als „success
Wie das Warnsystem entscheidet, was fehlgeschlagen ist
Drei Signale, und keines davon ist das Statusfeld.
Erstens ein abgefangener Fehler. Wenn ein Node fehlgeschlagen ist, aber die Ausführung trotzdem grün zurückkam, handelt es sich um einen stillen Fehler. Wir zählen es nur, wenn die Ausführung selbst Erfolg gemeldet hat, also wird eine Ausführung, die n8n bereits als fehlgeschlagen markiert, nicht doppelt als stiller Fehler gezählt.
Zweitens ein Node, der keine Ausgabe mehr produziert. Das erfordert Urteilsfähigkeit, denn null Elemente sind bei vielen Nodes normal. Wir behandeln null also nicht von selbst als schlecht. Wir schauen uns die eigene aktuelle Historie jedes Nodes an und sortieren sie in ein paar Gruppen:
- Nodes, die zuverlässig produzieren und fast nie leer sind. Wenn einer dieser Nodes nichts oder viel weniger als gewöhnlich zurückgibt, flaggen wir das.
- Nodes, die von Design her oft leer sind, wie ein Polling- oder Filter-Node, der normalerweise nichts trifft. Null ist für sie normal, also lassen wir sie in Ruhe.
- Nodes, von denen wir noch nicht genug Ausführungen gesehen haben. Wir warten, bis es genug Historie gibt, statt zu raten.
Wenn wir uns nicht sicher sind, bleiben wir still. Ein Warnsystem, das ständig Fehlalarm auslöst, wird abgeschaltet, also ziehen wir es vor, einen seltenen Grenzfall zu übersehen, als eine gesunde Ausführung zu flaggen.
Es gibt noch ein weiteres Element zum leeren Fall. Wenn ein Node keine Eingabe hatte, kam seine leere Ausgabe von upstream, nicht von diesem Node. Also zeigen wir auf den ersten Node, der tatsächlich kaputt ist, nicht auf die nachgelagerten Nodes, die nur die Leere weitergeleitet haben.
Drittens ein Workflow, der nie ausgeführt wurde. In diesem Fall gibt es keine Daten zum Lesen, also ist es eine separate Überprüfung, ob jeder Workflow wann ausgeführt wurde, wie er sollte.