Эксплуатация
Средний уровеньКак получать оповещения раньше, чем проблема пайплайна станет дорогой?
Полноценные observability-платформы решают эту задачу, но это слишком много платформы для вопроса, который обычно сводится к четырём-пяти цифрам, движущимся не в ту сторону.
Большинство инцидентов с пайплайнами не начинаются как инциденты — они начинаются как медленный тренд, за которым никто не следил, пока он не пересёк какой-то порог и не стал чрезвычайной ситуацией. Полноценная observability-платформа для того, чтобы заметить тренд рано, не нужна; нужно следить за правильной небольшой группой сигналов.
Горстка метрик, которые реально предсказывают проблемы
- Время GC как % от времени задач (Spark) — стабильный рост в последовательных прогонах предсказывает OOM ещё до того, как он случится, часто за недели до реального сбоя.
- Тренд длительности чекпоинта (Flink) — растущее время чекпоинта предсказывает будущие таймауты чекпоинтов и последующие перезапуски задачи задолго до первого реального таймаута.
- Объём сброса при shuffle (Spark) — медленный рост здесь означает, что размер shuffle-партиций не поспевает за ростом данных, задолго до того, как это станет многочасовой регрессией времени выполнения.
- Elapsed time против числа строк по каждой модели (dbt) — если это соотношение ухудшается от прогона к прогону, модель масштабируется хуже, чем линейно, с ростом ваших данных, и будет только ухудшаться дальше.
Тренд важнее порога
Фиксированный порог оповещения («звонить мне, если время выполнения превышает 30 минут») срабатывает только когда проблема уже реальна. Сравнение каждого прогона со скользящей базой по недавним прогонам ловит тренд, пока он ещё маленький и дёшевый в исправлении — та же метрика, используемая проактивно вместо реактивно, через вопрос «хуже ли это, чем последние N прогонов», а не «пересекло ли это произвольную черту».
Нужны не все метрики — нужна правильная горстка, отслеживаемая последовательно
Соблазн в observability — инструментировать всё. Более устойчивый подход для небольшой команды: выберите горстку метрик выше, специфичных для типа вашего пайплайна, отслеживайте их на каждом прогоне (не только когда что-то кажется не так) и относитесь к плохому тренду в любой из них как к поводу присмотреться — задолго до того, как он станет поводом для звонка.
Как это выглядит в opti-pipe сегодня: каждая загрузка добавляется в историю метрик этого пайплайна, и правила по памяти/числу инстансов уже переоцениваются на основе накопленной истории, а не одного снимка — так что рекомендация может сработать повторно со скорректированным предложением по мере сдвига тренда, а не только при первом пересечении порога. Отдельная функция проактивных оповещений (уведомить раньше, чем вы вообще подумаете проверить) в планах, но пока не реализована — см. статью выше о разрыве между dev и prod, там та же ситуация.
Посмотрите, как это выглядит на вашем собственном пайплайне.
Загрузите реальный event log Spark, run_results.json от dbt или экспорт метрик Flink — и получите конкретные рекомендации, которые нужно одобрить, а не ещё одно эмпирическое правило.