¿Cómo configuro las estrategias de reinicio de Flink para que un fallo no entre en loop para siempre?

Cuando un job de Flink falla, su estrategia de reinicio decide qué pasa después: reiniciar de inmediato, reiniciar tras un retraso, rendirse, o algo intermedio. El valor por defecto a nivel de cluster es fixed-delay con un número pequeño de intentos - está bien para una llamada externa inestable, activamente malo para un bug que falla en cada reinicio.

Las tres estrategias, y para qué sirve realmente cada una

fixed-delay reintenta un número fijo de veces con un retraso constante entre intentos - simple, y está bien para fallos transitorios, pero un job que está roto por una razón real (código malo en el último deploy, un esquema que ya no puede parsear) simplemente agota sus intentos y se detiene, o reinicia para siempre si el número de intentos está configurado demasiado alto. exponential-delay retrocede aún más después de cada fallo, lo que ayuda contra una dependencia downstream que está sufriendo en vez de un job que está genuinamente equivocado. failure-rate es la pensada para producción: rastrea fallos por ventana de tiempo y solo se rinde una vez que se excede esa tasa, así que un solo tropiezo no mata el job, pero un job que falla continuamente eventualmente se detiene en vez de quedar en loop.

Configurando failure-rate

Esa configuración permite hasta 3 fallos en cualquier ventana móvil de 5 minutos, esperando 30 segundos entre intentos de reinicio - pasados 3 fallos en 5 minutos, el job se detiene por completo en vez de seguir reiniciando. Los números correctos dependen de cuán costoso sea realmente un reinicio para este job en particular (tamaño del estado, tiempo de recuperación del checkpoint) - no hay un valor universal por defecto que valga la pena copiar sin ajustar.

Lo que realmente cuesta un loop de crashes

Un job atascado reiniciando no es gratis ni siquiera mientras "maneja" el fallo automáticamente: cada intento de reinicio recarga el estado desde el último checkpoint, lo cual para un job con tamaño de estado significativo es I/O real y tiempo real, repetido en cada ciclo. Un loop de crashes con un retraso fijo corto y un número alto de intentos puede generar más tráfico de lectura del almacenamiento de checkpoints que la carga de trabajo real del job en estado estable - vale la pena revisarlo antes de asumir que un job que reinicia pero no alerta es inofensivo.