Как настроить стратегии рестарта Flink, чтобы сбой не зациклился навсегда?

Когда задача Flink падает, стратегия рестарта решает, что дальше: рестартовать немедленно, рестартовать с задержкой, сдаться, или что-то среднее. Настройка по умолчанию для всего кластера — fixed-delay с небольшим числом попыток — нормально для нестабильного внешнего вызова, но откровенно плохо для бага, который падает на каждом рестарте.

Три стратегии и для чего на самом деле нужна каждая

fixed-delay повторяет попытки фиксированное число раз с постоянной задержкой между ними — просто, и нормально для временных сбоев, но задача, сломанная по реальной причине (плохой код в последнем деплое, схема, которую она больше не может разобрать), просто расходует все попытки и останавливается — или рестартует бесконечно, если число попыток выставлено слишком большим. exponential-delay увеличивает задержку после каждого падения, что помогает против страдающей downstream-зависимости, а не против задачи, которая реально неправа. failure-rate — это стратегия, созданная для прода: она отслеживает падения за временное окно и сдаётся только после превышения этой частоты, так что один сбой не убивает задачу, но задача, падающая непрерывно, всё же в итоге останавливается, а не зацикливается.

Настройка failure-rate

Эта конфигурация допускает до 3 падений в любом скользящем окне в 5 минут, ожидая 30 секунд между попытками рестарта — после 3 падений за 5 минут задача останавливается полностью вместо того, чтобы продолжать рестартовать. Правильные числа зависят от того, насколько дорог рестарт для конкретно этой задачи (объём состояния, время восстановления чекпоинта) — универсального значения по умолчанию, которое стоило бы просто скопировать без корректировки, не существует.

Во что реально обходится зацикливание

Задача, застрявшая в рестартах, не бесплатна, даже пока «автоматически справляется» со сбоем: каждая попытка рестарта перезагружает состояние из последнего чекпоинта, а для задачи с заметным объёмом состояния это реальный I/O и реальное время, повторяющиеся на каждом цикле. Зацикливание с короткой фиксированной задержкой и большим числом попыток может создать больше трафика чтения из хранилища чекпоинтов, чем реальная рабочая нагрузка задачи в стабильном режиме — стоит проверить, прежде чем считать рестартующую, но не алертящую задачу безобидной.