Como configuro estratégias de restart do Flink para uma falha não entrar em loop para sempre?

Quando um job do Flink falha, sua estratégia de restart decide o que acontece a seguir: reiniciar imediatamente, reiniciar depois de um atraso, desistir, ou algo no meio termo. O padrão do cluster inteiro é fixed-delay com um número pequeno de tentativas - bom para uma chamada externa instável, ativamente ruim para um bug que falha em todo restart.

As três estratégias, e para que cada uma realmente serve

fixed-delay tenta de novo um número fixo de vezes com um atraso constante entre tentativas - simples, e bom para falhas transitórias, mas um job que está quebrado por um motivo real (código ruim no último deploy, um schema que ele não consegue mais interpretar) simplesmente esgota suas tentativas e para, ou reinicia para sempre se o número de tentativas estiver alto demais. exponential-delay recua ainda mais depois de cada falha, o que ajuda contra uma dependência downstream que está com dificuldade, em vez de um job que está genuinamente errado. failure-rate é a pensada para produção: ela rastreia falhas por janela de tempo e só desiste quando essa taxa é excedida, então uma falha isolada não mata o job, mas um job falhando continuamente eventualmente para em vez de ficar em loop.

Configurando failure-rate

Essa configuração permite até 3 falhas em qualquer janela móvel de 5 minutos, esperando 30 segundos entre tentativas de restart - passadas 3 falhas em 5 minutos, o job para completamente em vez de continuar reiniciando. Os números certos dependem de quão caro um restart realmente é para esse job (tamanho do estado, tempo de recuperação do checkpoint) - não existe um padrão universal que valha a pena copiar sem ajustar.

O que um crash-loop realmente custa

Um job preso reiniciando não é de graça mesmo enquanto está "lidando" com a falha automaticamente: cada tentativa de restart recarrega o estado a partir do último checkpoint, o que para um job com tamanho de estado relevante é I/O real e tempo real, repetido a cada ciclo. Um crash-loop com um atraso fixo curto e um número alto de tentativas pode gerar mais tráfego de leitura do armazenamento de checkpoints do que a carga de trabalho real do job em regime estável - vale a pena checar antes de assumir que um job reiniciando mas sem alertar é inofensivo.