Версия сайта для слабовидящих
Каждый дата-инженер, который работает с Apache Airflow, сталкивался с сигналом SIGTERM, который отправляется задачам и приводит к сбою DAG. Сегодня рассмотрим, почему случается исключение airflow.exceptions.AirflowException, которое генерирует этот сигнал, и как его избежать.
Тайм-аут выполнения DAG
Одна из причин, по которой задача получает сигнал SIGTERM, связана с небольшим значением параметра dagrun_timeout. Класс DAG принимает этот аргумент, который указывает, как долго DagRun должен работать до истечения времени ожидания или сбоя, чтобы можно было создавать новые запуски DAG. Этот тайм-аут применяется только для запланированных DagRun. Для DAG, содержащих много длительных задач, dagrun_timeout часто может быть превышен, поэтому активно работающие задачи получат сигнал SIGTERM. Это приведет к тому, что DAG выйдет из строя и будет выполнен новый DagRun.
Проверить продолжительность DagRun можно в пользовательском интерфейсе Airflow. Если она больше, чем значение dagrun_timeout, указанное при создании экземпляра DAG, следует увеличить его до разумного периода времени в зависимости от конкретного варианта использования.
Эта конфигурация применима к DAG, поэтому необходимо указать значение, которое обеспечит достаточно времени для выполнения всех входящих в него задач. Например, это можно сделать следующим образом:
from datetime import datetime, timedeltafrom airflow.models.dag import DAG with DAG( 'my_dag', start_date=datetime(2022, 1, 1), schedule_interval='0 * * * *', dagrun_timeout=timedelta(minutes=60), ) as dag: ...
Нехватка памяти
Задачи AirFlow могут отказывать, если на узле, где они выполняются, не хватает оперативной памяти. В этом случае нужно проверить потребление ресурсов рабочими процессами и убедиться, что у них достаточно памяти. Например, при развертывании AirFlow в кластере Kubernetes следует посмотреть, не был ли удален какой-либо из подов. Обычно поды вытесняются из-за нехватки ресурсов. Это вполне может привести к тому, что задача Airflow получила сигнал SIGTERM.
Предотвратить такую ситуацию поможет ручное администрирование узла кластера Kubernetes с помощью инструмента командной строки kubectl. В частности, можно установить метки на существующем узле или пометить его не назначаемым. Маркировка узла как не назначаемого не влияет на существующие на узле поды, но предотвращает размещение планировщиком новых подов. Для критичных подов можно использовать концепцию набора системных служб DaemonSet, которая допускают запуск на не назначаемом узле, обеспечивая его локальные сервисы узла, которые должны запускаться, даже если сам узел вытесняется для запуска приложений. Описание спецификации DaemonSet, т.е. набора полей и их значений, делается в соответствующем YAML-файле.
Загрузка ЦП из-за метаданных
Еще одна распространенная проблема, из-за которой задачи Airflow могут получать сигналы SIGTERM, — это использование ЦП в базе данных метаданных. По умолчанию Airflow использует легковесную СУБД SQLite, разработанную для поддержки серверной части базы данных для PostgreSQL, MySQL или MSSQL.
Если загрузка ЦП в базе данных составляет 100%, это может быть причиной того, что задачи Airflow получают сигнал SIGTERM. В этом случае рекомендуется увеличить значение конфигурации job_heartbeat_sec или переменной среды AIRFLOW__SCHEDULER__JOB_HEARTBEAT_SEC, которая по умолчанию установлена на 5 секунд. Параметр job_heartbeat_sec определяет частоту в секундах, с которой экземпляры задач прослушивают внешний сигнал уничтожения, когда пользователь удаляет задачи из CLI или пользовательского интерфейса.
Сделать эти изменения можно в файле конфигурации airflow.cfg, указав это в разделе планировщика, например, установив значение параметра job_heartbeat_sec равным 20 секундам:
[scheduler]
job_heartbeat_sec = 20
Также можно изменить значение этой конфигурации через соответствующую переменную среды:
export AIRFLOW__SCHEDULER__JOB_HEARTBEAT_SEC=20
Эти манипуляции должны устранить причину сбоя, снизив нагрузку на ЦП, если потребление его ресурсов на уровне базы данных было проблемой.
Работа мини-планировщика Apache AirFlow
По умолчанию процесс диспетчера задач Airflow пытается запланировать больше задач одного и того же DAG, чтобы повысить производительность и скорость выполнения конвейера обработки данных. Это поведение настраивается с помощью параметра schedule_after_task_execution, который по умолчанию имеет значение True. Параметр schedule_after_task_execution определяет, должен ли процесс диспетчера задач выполнять «мини-планировщик» (mini scheduler), чтобы запланировать больше задач в рамках одного DAG. Если оставить это включенным, задачи одного DAG будут выполняться быстрее, но в некоторых случаях это может привести к замедлению других конвейеров.
Ранее в Apache Airflow была ошибка, когда задачи уничтожались из-за сигнала LocalTaskJob. В июне 2021 года эта ошибка была исправлена. До исправления одним из самых простых способов обойти эту проблему было отключение мини-планировщика. Это делается через изменение файла конфигурации airflow.cfg, где необходимо установить для параметра schedule_after_task_execution значение False:
[scheduler] schedule_after_task_execution = False
Также перезаписать эту конфигурацию можно с помощью переменной среды AIRFLOW__SCHEDULER__SCHEDULE_AFTER_TASK_EXECUTION:
export AIRFLOW__SCHEDULER__SCHEDULE_AFTER_TASK_EXECUTION=False
Наконец, можно просто обновить Apache Airflow до версии, в которой эта ошибка была исправлена и добавлены новые полезные фичи, как в релизе 2.3, о чем мы писали здесь. В заключение отметим, что на практике сбой DAG в Apache AirFlow с генерацией сигнала SIGTERM может случаться по нескольким причинам, поэтому при отладке отказавшего конвейера придется проверить их различные комбинации.
Как применить все это на практике для эффективного администрирования и эксплуатации Apache AirFlow при организации ETL/ELT-процессов в аналитике больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
