Ich möchte automatisch einen Issue im Sentry-Monitoring-System erstellen, wenn ein Workflow fehlschlägt (selbst gehostetes n8n, selbst gehostetes Sentry).
Die Dokumentation „dealing with errors
1 „Gefällt mir“
Willkommen @cweiske!
Du kannst den Sentry-Node vollständig überspringen und stattdessen den Error Trigger + HTTP Request Node verwenden, um direkt an Sentrys Envelope API zu POSTen (denselben Endpoint, den das SDK nutzt). Richte einen separaten Error-Handling-Workflow mit dem Error Trigger als Start-Node auf, füge dann einen HTTP Request Node hinzu, der auf https://sentry.example.com/api/<project_id>/envelope/ zeigt, und verwende deinen DSN-Key im X-Sentry-Auth Header.
Der Body muss Sentrys Envelope-Format folgen – mindestens eine Header-Zeile und ein Event-Payload in JSON, getrennt durch Zeilenumbrüche. Du kannst das in einem Code Node vor dem HTTP Request erstellen:
const header = JSON.stringify({event_id: $execution.id.replace(/-/g,''), sent_at: new Date().toISOString(), dsn: 'YOUR_DSN'});
const eventMeta = JSON.stringify({type:'event'});
const event = JSON.stringify({level:'error', message: $json.execution.error.message, logger: $json.workflowData.name});
return [{json: {body: [header, eventMeta, event].join('\n')}}];
Stelle den HTTP Request Body auf raw/text ein und übergebe {{ $json.body }}. So behältst du vollständige Kontrolle über die Daten, die in Sentry landen, ohne den Sentry Node überhaupt zu benötigen.
1 „Gefällt mir“
Eine kleine Vorsichtsmaßnahme, bevor du das zu Sentry verdrahtest: Sende ein Event und lass Sentry es gruppieren, anstatt zu versuchen, direkt ein Issue zu erstellen. Setze einen stabilen Fingerprint, damit Wiederholungen vom selben defekten Workflow/Node in einem Issue zusammengefasst werden.
Für den Error Trigger Payload baue den Fingerprint aus der Workflow-ID/Name, dem Namen des fehlgeschlagenen Node und der Fehlermeldung/Klasse auf. Füge die Execution ID als Tag hinzu, nicht als Teil des Fingerprints. Führe dann denselben Workflow zweimal aus; das richtige Ergebnis ist ein Sentry Issue mit zwei Events, nicht zwei Issues.
Das macht genau das, was ihr beide beschrieben habt — Error Trigger → einen Sentry-Envelope bauen → zu deinem /envelope/-Endpoint POSTen (den Sentry-Node überspringen, wie @nguyenthieutoan sagte), mit dem stabilen Fingerprint, den @oimrqs_ops herausgestellt hat.
Der Fingerprint ist [Workflow-Name, fehlgeschlagener Node, Error-Klasse + Nachricht], sodass wiederholte Fehler desselben Workflows in EINEM Sentry-Issue zusammengefasst werden; die Execution-ID wird als Tag mitgeführt, nicht im Fingerprint. Sendest du denselben Workflow-Fehler zweimal, bekommst du ein Issue mit zwei Events.
Zwei Änderungen vor dem Start: die URL (dein-sentry-host/api/PROJECT_ID/envelope/) und der sentry_key im X-Sentry-Auth-Header (dein DSN Public Key). Dann stellst du diesen Workflow als Error Workflow auf den Workflows ein, die dir wichtig sind (Settings → Error Workflow), und er fängt sie alle.
1 „Gefällt mir“