Типовые проблемы YTsaurus Flow
Начните с состояния, flow view и логов. Запишите кластер, путь пайплайна, ID операции и джобы, время первой ошибки. Изменяйте спеку или перезапускайте операцию только после того, как причина локализована: повторный запуск может уничтожить логи живой джобы.
Падающие джобы
Симптом: контроллер повторно планирует джобу, а она завершается ошибкой. Прочитайте первую ошибку в логе контроллера и получите stderr завершившейся джобы по её ID. Если это ошибка пользовательского кода или спеки, воспроизведите её на тестовом пайплайне и исправьте; при OOM сравните лимит памяти с фактическим потреблением и снимите профиль памяти. Не повышайте лимиты без проверки причины.
Повторяемые ошибки
Симптом: джобы остаются живыми, но в логах постоянно повторяется ошибка обращения к YTsaurus или внешнему приёмнику. Найдите первое повторяющееся сообщение и проверьте доступность цели, права и квоту. Если ошибка временная, наблюдайте, сокращается ли лаг после восстановления сервиса. Если нет, исправьте адрес или учётные данные в конфигурации и повторите развёртывание по правилам релиза.
Зависшая обработка или дрейн
Симптом: stop-pipeline долго оставляет пайплайн в draining либо выход перестаёт изменяться в working. По get-flow-view найдите компьютейшен с заполненным входным или выходным буфером, затем проверьте его воркер-лог. Снимите бектрейсы тредов и файберов до перезапуска. Если зависает пользовательский C++ код, проверьте ожидания и перехват catch (...): исключения управления файберами могут не наследоваться от std::exception. Исправьте код и сначала проверьте его в тестовом окружении. Для обновления, которое не может задренироваться из-за падающих джоб, следуйте процедуре восстановления после неудачной спеки.
Медленная обработка
Симптом: лаг растёт при работающих джобах. Сравните время частей эпох и размеры буферов, если эти метрики доступны; без панели используйте get-flow-view и логи проблемной партиции. Начните с компьютейшена ближе к выходу, у которого очередь или обработка растут.
Поскольку все сообщения между computation-ами пайплайна хранятся в памяти, их не может храниться слишком много, поэтому более поздние в пайплайне computation-ы могут тормозить более ранние. Поэтому стоит расследовать в первую очередь тормоза более поздних computation-ов.
Если время уходит на пользовательский Process, снимите CPU-профиль и проверьте внешние вызовы. Один горячий ключ нельзя разгрузить простым увеличением числа партиций: сначала уменьшите работу для этого ключа. При переполнении выходного буфера проверьте следующий компьютейшен, прежде чем увеличивать буфер. Если ожидание вызвано Input.ReadWindow, проверьте тормозящую партицию ниже по графу и настройки окна чтения; увеличивайте окно только при намеренно редких коммитах.
Медленная работа с YTsaurus
Симптом: в логах и времени эпох преобладают ожидания чтения или записи таблиц. Проверьте нагрузку, состояние таблетов и ошибки конкретных таблиц через доступные инструменты кластера; сопоставьте их с FAQ по динамическим таблицам. При перекосе нагрузки проверьте шарды и распределение ключей. Перешардирование и смену режима обработки планируйте отдельно: они меняют нагрузку и, возможно, гарантии обработки.
Ошибки троттлера
Симптом: джоба получает исключения от Throttle() либо часто ждёт Input.Throttle. Сравните запрошенную скорость с квотой Distributed Throttler и проверьте доступность контроллера. Если спрос существенно выше квоты, уменьшите нагрузку или запросите подходящий лимит; если недоступен контроллер, сначала восстановите связь. Не отключайте троттлер как обход ошибки.
Зомби-процессы и несовпадение версий
Симптом: после релиза новые джобы не назначаются или пайплайн переходит в paused, а в блоке Messages появляется сообщение binary mismatch. Попытка обновить спеку может завершиться ошибкой FlowCoreTargetMismatch. Сравните версии раннера, контроллера и воркеров и проверьте, остались ли процессы старой операции. Дождитесь завершения переключения или заново запустите релиз единым набором бинарей. Сброс проверки версий допустим только как контролируемое восстановление после проверки всех процессов: он снимает защиту от зомби-процессов.