Una trampa en la capa de ejecuciones faltantes: si el heartbeat es un nodo dentro del flujo de trabajo, muere exactamente cuando el flujo de trabajo no se ejecuta, por lo que nunca te avisa. El ping tiene que provenir de algo externo que lo espera según un calendario y alerta sobre su ausencia, no de un nodo que solo se dispara en una ejecución exitosa.
El marco de tres niveles en este hilo – fallos duros, verde-pero-nada, ejecuciones perdidas – es el modelo mental correcto. Una capa más que vale la pena añadir si ejecutas flujos de trabajo para múltiples clientes desde una única instancia de n8n: enrutamiento de errores por cliente.
El problema con un canal de Slack compartido para todas las alertas de error: la responsabilidad es ambigua (¿quién es responsable de la alerta a las 3am cuando podría pertenecer a cualquiera de cinco clientes?), el volumen de un cliente activo entierra las alertas de los más silenciosos, y si alguna vez se les da acceso a los clientes a ese canal pueden ver los nombres de los flujos de trabajo de los demás.
El patrón que uso:
Coloca un nodo Set en la parte superior de cada flujo de trabajo y establece un campo sticky – algo como client_id = “acme_roofing” o client_id = “westside_clinic”. Esto se convierte en la única fuente de verdad sobre a qué cliente pertenece el flujo de trabajo.
En tu Flujo de Trabajo de Error, lee ese campo de los datos de error y enruta en consecuencia: si client_id es “acme_roofing”, envía a #alerts-acme; si es “westside_clinic”, envía a #alerts-westside o al correo electrónico del gestor de su cuenta.
El nodo Set también actúa como encabezado del flujo de trabajo: cualquiera que abra el flujo de trabajo sabe inmediatamente qué cliente y proceso maneja. Vale la pena añadir incluso si nunca segmentas los canales de alertas – ahorra mucho dolor de cabeza cuando alguien no familiarizado tiene que depurar un fallo a las 3am.
Para configuraciones más pequeñas que no necesitan canales separados, la misma idea sigue siendo útil: prefija cada alerta con el nombre del cliente, “[Acme Roofing] appointment reminder failed.” Eso solo hace que sea fácil filtrar en Slack y asignar la responsabilidad de la evaluación por la mañana.
Estoy trabajando en la implementación de detección de fallos silenciosos en AGD. Hoy estaré realizando pruebas exhaustivas en mi solución para esto y reportaré mis hallazgos aquí.
Hasta aquí todo bien, pero voy a implementarlo hoy: Mi solución propuesta aquí:
Queremos capturar estos fallos silenciosos de los datos de OpenTelemetry de n8n, fuera de los flujos de trabajo, en lugar de añadir una protección a cada nodo dentro de ellos. n8n ya emite un span por nodo, así que un observador puede supervisar todos tus flujos de trabajo a la vez y decidir si una ejecución realmente hizo su trabajo, independientemente del éxito o error que reporte n8n.
Lo clave que descubrimos es que no puedes confiar en el estado en ningún nivel. Un nodo Continue-On-Fail vuelve “éxito” en la ejecución, el nodo y el span. Así que en lugar de leer el estado, leemos el resultado en sí: el error que se propagó hacia los datos normales, y cuántos elementos produjo realmente cada nodo.
Eso es suficiente para capturar las tres formas en que una ejecución se ve en verde pero no lo está: un nodo que falló y continuó, un nodo que silenciosamente no devolvió nada cuando normalmente devuelve mucho, y un flujo de trabajo que nunca se ejecutó en absoluto. La única parte que necesita cuidado es el caso vacío, ya que muchos nodos devuelven legitimamente cero, así que evaluamos cada nodo contra su propio historial en lugar de tratar cero como roto.
Cómo el sistema de advertencia decide qué falló
Tres señales, y ninguna de ellas es el campo de estado.
Primero, un error silenciado. Si un nodo falló pero la ejecución aún se devolvió en verde, eso es un fallo silencioso. Solo lo contamos cuando la ejecución misma reportó éxito, así que una ejecución que n8n ya marca como fallida no se cuenta dos veces como silenciosa.
Segundo, un nodo que dejó de producir. Este es el que requiere criterio, porque cero elementos es normal para muchos nodos. Así que no tratamos cero como malo por sí solo. Miramos el historial reciente de cada nodo y lo clasificamos en algunos grupos:
- Nodos que producen de forma confiable, casi nunca vacíos. Si uno de estos no devuelve nada, o mucho menos de lo que usualmente hace, lo marcamos.
- Nodos que están vacíos a menudo por diseño, como un encuestador o un filtro que generalmente no coincide con nada. Cero es normal para ellos, así que los dejamos en paz.
- Nodos de los que aún no hemos visto suficientes ejecuciones. Esperamos hasta que haya suficiente historial en lugar de adivinar.
Cuando no estamos seguros, nos mantenemos en silencio. Un sistema de advertencia que grita al lobo termina siendo desactivado, así que preferimos perder un caso límite raro que marcar una ejecución saludable.
Hay una pieza más para el caso vacío. Si un nodo no tenía entrada, su salida vacía provino de upstream, no de ese nodo. Así que señalamos el primer nodo que realmente se rompió, no los downstream que simplemente pasaron el vacío.
Tercero, un flujo de trabajo que nunca se ejecutó. No hay datos para leer en ese caso, así que es una verificación separada sobre si cada flujo de trabajo se ejecutó cuando se suponía que debía hacerlo.