Me gustaría abrir automáticamente un problema en el sistema de monitoreo Sentry cuando falla un flujo de trabajo (n8n auto-hospedado, sentry auto-hospedado).
La documentación sobre «tratamiento de errores» solo habla sobre correo, slack y telegram - y las acciones del nodo Sentry no permiten crear problemas / enviar errores.
Sentry mismo es capaz de enviar errores internos a sentry desde PR 4394, pero no errores de flujo de trabajo.
¿Qué podría hacer?
¡Bienvenido @cweiske!
Puedes saltarte el nodo de Sentry completamente y usar el nodo Error Trigger + HTTP Request para hacer POST directamente a la Envelope API de Sentry (el mismo endpoint que usa el SDK). Configura un flujo de trabajo de manejo de errores separado con Error Trigger como nodo inicial, luego agrega un nodo HTTP Request apuntando a https://sentry.example.com/api/<project_id>/envelope/ con tu clave DSN en el encabezado X-Sentry-Auth.
El cuerpo debe seguir el formato de envelope de Sentry - como mínimo una línea de encabezado y una carga de evento en JSON, separadas por saltos de línea. Puedes construir esto en un nodo Code antes del 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')}}];
Establece el cuerpo de HTTP Request a raw/text y pasa {{ $json.body }}. Esto te da control total sobre qué datos llegan a Sentry sin necesidad del nodo de Sentry en absoluto.
Una pequeña precaución antes de conectar esto a Sentry: envía un evento y deja que Sentry lo agrupe, en lugar de intentar crear un problema directamente. Establece una huella digital estable para que los reintentos del mismo flujo de trabajo/nodo roto se colapsen en un único problema.
Para la carga útil de Error Trigger, construye la huella digital a partir del id/nombre del flujo de trabajo, el nombre del nodo fallido y el mensaje de error/clase. Añade el id de ejecución como una etiqueta, no como parte de la huella digital. Luego falla el mismo flujo de trabajo dos veces; el resultado esperado es un único problema de Sentry con dos eventos, no dos problemas.
Esto hace exactamente lo que ustedes dos describieron — Error Trigger → construir un sobre de Sentry → POST a tu endpoint /envelope/ (omitiendo el nodo de Sentry, como dijo @nguyenthieutoan), con la huella digital estable que @oimrqs_ops señaló.
La huella digital es [nombre del flujo de trabajo, nodo que falló, clase de error + mensaje], así que los fallos repetidos del mismo flujo de trabajo se colapsan en UN problema de Sentry; el id de ejecución va como una etiqueta, no en la huella digital. Envía el fallo del mismo flujo de trabajo dos veces y obtienes un problema con dos eventos.
Dos ediciones antes de que se ejecute: la URL (tu-host-sentry/api/PROJECT_ID/envelope/) y la sentry_key en el encabezado X-Sentry-Auth (tu clave pública del DSN). Luego configura este flujo de trabajo como el Flujo de Trabajo de Error en los que te importan (Settings → Error Workflow) y los captura todos.