Envoyer les erreurs de workflow à Sentry

Aidez-moi à Construire mon Flux de Travail
1

Je voudrais ouvrir automatiquement un problème dans le système de surveillance Sentry en cas d’échec d’un workflow (n8n auto-hébergé, Sentry auto-hébergé).

La documentation sur la gestion des erreurs parle uniquement de mail, Slack et Telegram - et les actions du nœud Sentry ne permettent pas de créer des problèmes / d’envoyer des erreurs.

Sentry lui-même est capable d’envoyer les erreurs internes à Sentry depuis la PR 4394, mais pas les erreurs de workflow.

Que pourrais-je faire ?

1 « J'aime »
2

Bienvenue @cweiske !

Vous pouvez ignorer complètement le nœud Sentry et utiliser le nœud Error Trigger + HTTP Request pour envoyer directement une requête POST à l’API Envelope de Sentry (le même point de terminaison utilisé par le SDK). Configurez un flux de travail de gestion des erreurs séparé avec Error Trigger comme nœud de départ, puis ajoutez un nœud HTTP Request pointant vers https://sentry.example.com/api/<project_id>/envelope/ avec votre clé DSN dans l’en-tête X-Sentry-Auth.

Le corps doit suivre le format d’enveloppe de Sentry - au minimum une ligne d’en-tête et une charge utile d’événement en JSON, séparées par des retours à la ligne. Vous pouvez construire cela dans un nœud Code avant la requête HTTP :

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')}}];

Définissez le corps de la requête HTTP sur raw/text et passez {{ $json.body }}. Cela vous donne un contrôle total sur les données qui arrivent dans Sentry sans avoir besoin du nœud Sentry du tout.

1 « J'aime »
3

Une petite précaution avant de connecter cela à Sentry : envoyer un événement et laisser Sentry le grouper, au lieu d’essayer de créer un problème directement. Définissez une empreinte stable afin que les nouvelles tentatives du même workflow/nœud défaillant s’effondrent en un seul problème.

Pour la charge utile Error Trigger, construisez l’empreinte à partir de l’identifiant/nom du workflow, du nom du nœud défaillant et du message/classe d’erreur. Ajoutez l’identifiant d’exécution en tant qu’étiquette, pas comme partie de l’empreinte. Ensuite, faites échouer le même workflow deux fois ; le bon résultat est un problème Sentry avec deux événements, pas deux problèmes.

4

Cela fait exactement ce que vous deux avez décrit — Déclencheur d’erreur → construire une enveloppe Sentry → POST à votre endpoint /envelope/ (en contournant le nœud Sentry, comme l’a dit @nguyenthieutoan), avec l’empreinte stable que @oimrqs_ops a signalée.

L’empreinte est [nom du workflow, nœud défaillant, classe d'erreur + message], donc les défaillances répétées du même workflow se regroupent en UN seul problème Sentry ; l’ID d’exécution s’y ajoute comme étiquette, pas dans l’empreinte. Envoyez l’échec du même workflow deux fois et vous obtenez un problème avec deux événements.

Deux modifications avant son exécution : l’URL (your-sentry-host/api/PROJECT_ID/envelope/) et la sentry_key dans l’en-tête X-Sentry-Auth (votre clé publique DSN). Ensuite, définissez ce workflow comme Workflow d’erreur sur ceux qui vous intéressent (Paramètres → Workflow d’erreur) et il les attrapera tous.

1 « J'aime »