Тайм-аут видимости Celling Airflow's Celery

Question

Редактировать (2020-4-18): Добавлен контекст о базе данных метаданных. Добавлен контекст о StatsD.

Фон

Я управляю развертыванием Airflow 1.10.3 . Он использует MySQL 5.7 в качестве базы данных метаданных. Он использует CeleryExecutor с Redis 3.2.5 в качестве брокера Celery.

Я встраиваю пакет Airflow, мой код DAG и любые другие соответствующие конфиги в 1 Docker image .

Мое развертывание запускает Docker контейнеров для каждого из веб-сервера, сервера Flower, планировщика и рабочих; все они порождены этим 1 Docker изображением. Redis также работает в контейнере Docker; но не из того же Docker изображения, что и другие компоненты Airflow. MySQL не является контейнером и поддерживается и работает, как любая традиционная база данных OLTP. Последовательность развертывания состоит из:

1. Создание нового Docker образа с любым измененным кодом DAG и т. Д. c.
2. Уничтожение работающих в настоящий момент контейнеров Airflow Docker (т.е. Webserver, Scheduler, et c.); кроме контейнера Redis.
3. Раскрутка новых Docker контейнеров из недавно созданного Docker образа.

Единственный компонент Airflow, который не получает " уничтожен и заменен »во время развертывания находится контейнер Redis.

Я (постоянно) развертываю в любом месте 3-7 раз в день.

выпуск

часто во время нормальной работы набор задач Airflow в конечном итоге отображает в своих журналах следующее:

[2018-02-23 12:57:01,711] {models.py:1190} INFO - Dependencies not met for <TaskInstance: userdbs.dump.dedicated 2018-02-21 02:00:00 [running]>, dependency 'Task Instance State' FAILED: Task is in the 'running' state which is not a valid state for execution. The task must be cleared in order to be run.
[2018-02-23 12:57:01,711] {models.py:1190} INFO - Dependencies not met for <TaskInstance: userdbs.dump.clustered 2018-02-21 02:00:00 [running]>, dependency 'Task Instance Not Already Running' FAILED: Task is already running, it started on 2018-02-23 06:54:44.431988.

Эти задачи обычно выполняются очень долго. И когда я расследую, основная задача обычно законно все еще выполняется. У меня есть группы обеспечения доступности баз данных, в которых есть задачи, которые обрабатывают большие объемы данных, и на законных основаниях для их успешного выполнения требуется от 6 до 10 часов. Таким образом, обсуждение вопроса о разбивке этих задач для обработки меньшего количества данных должно выходить за рамки этого вопроса.

Я полагаю, что существует корреляция с тем, как я выполняю развертывание, и когда обычно появляются вышеуказанные журналы. Но у меня нет точных данных, подтверждающих это.

Некоторые онлайн-поиски показывают, что увеличение времени ожидания видимости Celery до значения, превышающего ожидаемое для меня время выполнения самой длинной задачи (для всех групп DAG), должно решить эту проблему. вопрос. Я планирую реализовать это.

Но меня больше всего беспокоит то, увеличит ли тайм-аут увеличенной видимости (вероятно, ~ 11 часов) + не убьет контейнер Redis при развертывании оставьте меня с Сельерией, потратив ~ 11 часов, чтобы заметить, что нужно перенести задачу. Это беспокойство вытекает из этого комментария здесь из документов Celery (https://docs.celeryproject.org/en/latest/getting-started/brokers/redis.html#id1):

Note that Celery will redeliver messages at worker shutdown, so having a long visibility timeout will only delay the redelivery of ‘lost’ tasks in the event of a power failure or forcefully terminated workers.

Вопросы

1. Является ли мое беспокойство о том, что Celery требуется ~ 11 часов, чтобы заметить, что ему нужно перенести задачу действителен (с учетом моих настроек развертывания)?
2. Стоит ли рассматривать убийство контейнера Redis вместе со всеми другими компонентами воздушного потока? Моя главная задача здесь заключается в том, достаточно ли умён планировщик, чтобы восстановить точное представление о мире после его запуска.
3. Связаны ли сообщения "Зависимости не встречаются" с чем-то , кроме времени ожидания видимости Celery ? Если так, то? И новые версии Airflow решают эту проблему?
4. У меня настроены метрики StatsD. Есть ли конкретные c метрики, которые я мог бы анализировать, чтобы понять, что здесь происходит? (Или новые метрики, введенные в более новых версиях Airflow, которые могут помочь с наблюдаемостью здесь?)

Answer 1

Не можете ответить на все ваши вопросы, но:

• какую БД вы используете для Airflow? Postgres? Ты продолжаешь это?

Я не думаю, что ты должен касаться своего контейнера Redis (другими словами - продолжай в том же духе). Я думаю, что вы должны настроить его как бэкэнд вашего Celery. Кроме того, рассмотрите следующие конфигурации (я использую это):

• CELERY_ACKS_LATE - задачи будут подтверждены после того, как задача была выполнена. Прочтите также faq :

  Параметр acks_late будет использоваться, когда вам потребуется снова выполнить задачу, если рабочий (по какой-то причине) аварийно завершает работу в середине выполнения.

• CELERY_TRACK_STARTED - Наличие состояния «запущено» может быть полезно в тех случаях, когда существуют долго выполняющиеся задачи и существует необходимость сообщить, какая задача выполняется в данный момент.

Что касается метрик, для Celery вы можете использовать Flower (не перезагружать этот контейнер!), И я увидел, что есть возможность настроить Statsd для Airflow (я не сделал попробуй это). Проверьте следующие конфигурации в airflow.cfg:

# Statsd (https://github.com/etsy/statsd) integration settings
statsd_on = False
statsd_host = localhost
statsd_port = 8125
statsd_prefix = airflow