Как мониторить подвисшие сенсоры?
Начнем с того, что в Airflow есть несколько состояний для таски:
⭐️none - пока отдыхает ⭐️scheduled - должна быть запущена, все зависимости выполнены ⭐️queued - ждет свободный воркер ⭐️running - работает ⭐️success - успешно завершилась ⭐️restarting - перезапустили ⭐️failed - упала ⭐️skipped - пропущена ⭐️upstream_failed - упала предыдущая таска, которая нам нужна ⭐️up_for_retry - упала, но будет перезапущена ⭐️up_for_reschedule - сенсор будет перезапущен ⭐️deferred - отложена и ждет триггер ⭐️removed - удалена из дага после запуска
Подвисшие сенсоры уходят в статус deferred. У нас они имеют такой нейминг - mytask_awaiting_somedag. Я написала себе запрос, который выводит:
⭕️название дага, на который смотрит сенсор ⭕️количество сенсоров, которые ждут этот даг ⭕️общее количество подвисших сенсоров
И так можно сразу понять, на какой даг смотрит наибольшее количество сенсоров, и посмотреть причину
with sensored as ( SELECT substr( task_id, strpos(task_id, 'awaiting_') + length('awaiting_') ) as sensor, dag_id FROM airflow.public.task_instance WHERE state = 'deferred' ) select sensor, count(1) over(partition by sensor) as sensor_cnt, count(1) over() as total_cnt, dag_id from sensored order by 2 desc, sensor, dag_id;
· 03.10.2025
А зачем из сенсора смотреть за Дагом, почему не реализовать это через посредника? БД например?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 05.10.2025
это use case для сенсора… а как через бд?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 06.10.2025
Если я правильно понял пост, то речь идет про сенсоры, которые смотрят на другие даги, а с такими сенсорами проблема, если вдруг изменилось расписание. Они привязаны к конкретному времени запуска таски или дага. И если измениться время запуска первого дага, то все сенсоры смотрящие на него прийдется править, ведь они перестанут работать. И при загрузке истории можем получить проблемы, особенно если менялось расписание или старт у дагов был в разные дни. И при переименованиях можно получить проблем. А когда разные люди отвечают за разные даги - любая из этих проблем может легко случиться. Мы это у себя организовали так, через callback пишем в БД, и у нас теперь не ExternalTaskSensor, а свой Кастомный сенсор для мониторинга БД. Тоже со своими вопросами, но по-моему получше. А вчера я послушал доклад про Datasets. По моему Datsets может стать самым оптимальным решением.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён