Enviar erros de fluxo de trabalho para o Sentry

Ajude-me a construir meu fluxo de trabalho
1

Gostaria de abrir automaticamente um issue no sistema de monitoramento Sentry quando um workflow falhar (n8n auto-hospedado, Sentry auto-hospedado).

A documentação “lidando com erros” fala apenas sobre mail, slack e telegram - e as ações do Sentry Node não permitem criar issues / enviar erros.

O próprio Sentry consegue enviar erros internos para o Sentry desde a PR 4394, mas não erros de workflow.

O que eu poderia fazer?

1 curtida
2

Bem-vindo @cweiske!

Você pode pular o nó Sentry inteiramente e usar o nó Error Trigger + HTTP Request para fazer POST diretamente na Envelope API do Sentry (o mesmo endpoint que o SDK usa). Configure um fluxo de trabalho separado para tratamento de erros com o Error Trigger como nó inicial, depois adicione um nó HTTP Request apontando para https://sentry.example.com/api/<project_id>/envelope/ com sua chave DSN no header X-Sentry-Auth.

O corpo precisa seguir o formato de envelope do Sentry - no mínimo uma linha de cabeçalho e um payload de evento em JSON, separados por quebras de linha. Você pode construir isso em um nó Code antes do HTTP Request:

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

Defina o corpo da HTTP Request como raw/text e passe {{ $json.body }}. Isso lhe dá controle total sobre quais dados chegam ao Sentry sem precisar do nó Sentry.

1 curtida
3

Uma pequena proteção antes de conectar isso ao Sentry: envie um evento e deixe o Sentry agrupá-lo, em vez de tentar criar uma issue diretamente. Defina uma fingerprint estável para que tentativas do mesmo workflow/nó quebrado sejam agrupadas em uma única issue.

Para o payload do Error Trigger, construa a fingerprint a partir do id/nome do workflow, do nome do nó que falhou e da mensagem de erro/classe. Adicione o id de execução como uma tag, não como parte da fingerprint. Depois falhe o mesmo workflow duas vezes; o resultado esperado é uma issue do Sentry com dois eventos, não duas issues.

4

Isso faz exatamente o que vocês dois descreveram — Error Trigger → construir um envelope do Sentry → POST para seu endpoint /envelope/ (pulando o nó Sentry, como @nguyenthieutoan disse), com a fingerprint estável que @oimrqs_ops destacou.

A fingerprint é [nome do workflow, nó que falhou, classe de erro + mensagem], então falhas repetidas do mesmo workflow se contraem em UM problema no Sentry; o id da execução acompanha como uma tag, não na fingerprint. Envie a falha do mesmo workflow duas vezes e você terá um problema com dois eventos.

Duas edições antes de executar: a URL (seu-host-sentry/api/PROJECT_ID/envelope/) e a sentry_key no header X-Sentry-Auth (a chave pública do seu DSN). Depois defina este workflow como o Error Workflow nos que você se importa (Settings → Error Workflow) e ele capturará todos.

1 curtida