Envía y verifica eventos con n8n workflow telemetry
Utilice n8n workflow telemetry en un límite de aplicación controlado, mantenga el contrato de evento pequeño y verifique un resultado conocido antes de crear vistas agregadas.
- 1
Elige el resultado
Monitoreo de finalización del flujo de trabajo
- 2
Definir el contrato
execution_id, workflow_name, workflow_version, trigger_type, schedule_name y versión
- 3
Emitir en el resultado
Configura POST https://api.telemetry.sh/log manualmente, activa Send Body y elige JSON. El fragmento es un esquema de configuración, no un flujo de n8n importable; selecciona por separado la credencial Header Auth guardada.
- 4
Verificar la evidencia
Exercise a known fixture, then inspect n8n_workflow_completed for one correctly typed terminal row.
Antes de empezar
Antes de empezar
- Un nodo de solicitud HTTP n8n colocado en una rama explícita de éxito o error
- En HTTP Request, elige Authentication: Generic Credential Type y después Generic Auth Type: Header Auth. Guarda una credencial con Name: Authorization y Value: tu clave API de Telemetry, sin el prefijo Bearer.
- Un nodo Conjunto que prepara solo metadatos de flujo de trabajo aprobados y campos de resultados delimitados.
Configuración de entrega
Instalar e inicializar el lado del servidor
Envíe la forma JSON documentada a Log API con una clave del lado del servidor y tiempos de espera HTTP limitados. Mantenga las credenciales de ingesta fuera de los paquetes de navegador, las variables de entorno visibles para el cliente, el control de fuente, los registros y los mensajes de excepción.
- 1Prepare un cliente de entrega del lado del servidor reutilizable con comportamiento de red limitado.
- 2Agregue el evento de resultado en el límite de éxito, error, reintento o tiempo de espera.
- 3Envíe accesorios controlados e inspeccione las filas almacenadas antes de habilitar una alerta.
Fragmento
Comience con un evento estructurado
Agregue esta forma donde el flujo de trabajo se completa, falla o se vuelve a intentar. Luego cree el panel a partir de campos reales.
Evento n8n workflow telemetry
{
"method": "POST",
"url": "https://api.telemetry.sh/log",
"timeout_ms": 2000,
"body": {
"table": "n8n_workflow_completed",
"data": {
"execution_id": "={{ $json.execution_id }}",
"workflow_name": "={{ $json.workflow_name }}",
"workflow_version": "={{ $json.workflow_version }}",
"trigger_type": "={{ $json.trigger_type }}",
"status": "={{ $json.status }}",
"duration_ms": "={{ $json.duration_ms }}",
"retry_count": "={{ $json.retry_count }}",
"item_count": "={{ $json.item_count }}",
"error_type": "={{ $json.error_type }}",
"release": "={{ $json.release }}"
}
}
}Esquema del evento
execution_id, workflow_name, workflow_version, trigger_type, schedule_name y versión
estado, duration_ms, retry_count, item_count, failed_step y error_type
account_id, integration_name, delivery_status, entorno y región cuando se apruebe
Comprueba tu configuración
Punto de control 1
Configura POST https://api.telemetry.sh/log manualmente, activa Send Body y elige JSON. El fragmento es un esquema de configuración, no un flujo de n8n importable; selecciona por separado la credencial Header Auth guardada.
Punto de control 2
Prepara los campos aprobados en un nodo anterior. La duración y los recuentos de elementos y reintentos deben ser números, no cadenas numéricas; valida el cuerpo real de la solicitud en tu versión de n8n antes de enviar eventos de la aplicación.
Punto de control 3
Utilice ramas de éxito y error explícitas separadas para que el nodo de solicitud HTTP reciba un resultado final del flujo de trabajo en lugar de un resultado de nodo intermedio.
Punto de control 4
Configure tiempos de espera limitados y Continuar en caso de error según si se permite que la entrega de observabilidad afecte el resultado de la automatización.
Punto de control 5
No envíe cuerpos de elementos de origen, credenciales, tokens, expresiones que contengan datos privados, mensajes de error arbitrarios o datos de ejecución n8n completos.
Verificación
Demuestra que el evento llegó
Ejecute esto después de ejercitar casos conocidos de éxito y fracaso. Reemplace el nombre de la tabla alternativa si su contrato de evento final difiere del fragmento.
Consulta de verificación n8n workflow telemetry
SELECT *
FROM n8n_workflow_completed
ORDER BY timestamp_utc DESC
LIMIT 20;Referencias de implementación
Revise el contrato del evento, la guía de seguridad de los datos y la documentación primaria previa antes de habilitar una nueva ruta de producción.
Dónde registrar eventos
Mantenga el evento de resultado pequeño y recuperable
Este patrón proporciona
- Un resultado limitado y listo para SQL junto al flujo de trabajo ascendente.
- Campos estables para paneles, alertas y correlación entre eventos.
- Una ruta basada en dispositivos para validar el comportamiento de éxito, fracaso, reintento y tiempo de espera.
Este patrón no proporciona
- Un exportador de OTLP, un canal de recopilación automática o un reemplazo para seguimientos detallados y registros de diagnóstico.
- Entrega exactamente una vez simplemente porque la carga útil contiene un ID de evento.
- Permiso para recopilar cargas útiles sin procesar del proveedor, contenido de usuario, credenciales o datos regulados.
Ejemplos de esquemas de eventos
Esquemas de eventos para este flujo de trabajo
Revise el detalle de la fila, el límite de emisión, los tipos requeridos, las clases de privacidad, la carga útil de ejemplo y la lista de verificación de validación antes de adaptar una consulta o fragmento a producción.
Función relacionada del producto
Continúe este flujo de trabajo en Alertas
Promueva la consulta de confiabilidad revisada a un umbral propio y un flujo de trabajo de respuesta.
Recetas SQL relacionadas
Más ejemplos de SQL
Ejecute la consulta en los campos estructurados de este flujo de trabajo, inspeccione el resultado del ejemplo y convierta una respuesta útil en un panel o alerta.
Reconstruir una línea de tiempo de flujo de trabajo correlacionado
¿Qué sucedió, en orden, durante el último flujo de trabajo fallido?
Receta abiertaMedir el reintento del trabajo en segundo plano y la tasa de fallas
¿Qué trabajos en segundo plano consumen más reintentos o aún fallan?
Receta abiertaEncuentre trabajos en segundo plano estancados con SQL
¿Qué trabajos comenzaron pero nunca produjeron un evento terminal?
Receta abiertaDetectar latidos de servicio faltantes
¿Qué fuentes de telemetría esperadas han dejado de enviar latidos?
Receta abiertaExplorar por familia de implementación
Comparar patrones de integración relacionados
Plantillas para combinar con esta integración
Monitor de fallas en el trabajo en segundo plano
Capture el estado de los trabajos de cola, cron, importación, sincronización de facturación y webhook desde la primera ejecución hasta los reintentos y fallas.
Abrir plantillaPlantilla de auditoría de seguridad del agente de IA
Instrumente decisiones de autorización de herramientas, versiones de políticas, aprobaciones humanas y resultados de terminales con eventos estructurados seguros para la privacidad.
Abrir plantillaPlantilla de observabilidad del agente de IA
Realice un seguimiento de las ejecuciones de agentes, llamadas de herramientas, reintentos, latencia de modelos, errores y resultados aceptados con eventos estructurados listos para SQL.
Abrir plantillaMás integraciones
Trabajo de Inngest y Trigger.dev Telemetry
Instrumente trabajadores asíncronos, trabajos programados, reintentos, fallas y eventos de mensajes no entregados con registros listos para SQL.
abrir guiaMonitoreo de eventos estructurados de AWS Lambda
Realice un seguimiento de las invocaciones de Lambda, los arranques en frío, la duración, los reintentos y los resultados comerciales con eventos estructurados compactos.
abrir guiaObservabilidad del flujo de trabajo temporal
Realice un seguimiento de los resultados del flujo de trabajo temporal, los reintentos de actividad, la latencia del inicio programado y los hitos comerciales sin registrar las cargas útiles del flujo de trabajo.
abrir guia