调整 Airflow 的 Celery 可见性超时

Question

编辑 (2020-4-18)： 添加了有关元数据数据库的上下文。添加了有关 StatsD 的上下文。

背景

我运行 Airflow 1.10.3 部署。它使用 MySQL 5.7 作为元数据数据库。它使用 CeleryExecutor 和 Redis 3.2.5 作为 Celery 代理。

我将 Airflow 包、我的 DAG 代码和任何其他相关配置构建到 1 Docker 映像中。

我的部署为每个 Webserver、Flower server、Scheduler 和 Workers 启动 Docker 容器；它们都是从那 1 个 Docker 映像中生成的。 Redis 也在 Docker 容器中运行；但不是来自与其他 Airflow 组件相同的 Docker 映像。 MySQL 不是容器化的，而是像任何传统的 OLTP 数据库一样保持正常运行。部署序列包括：

1. 使用任何更改的 DAG 代码等构建新的 Docker 映像。
2. 杀死当前正在运行的 Airflow Docker 容器（即 Webserver、Scheduler 等）； 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.

这些任务通常运行时间很长。当我进行调查时，基本任务通常仍在合法地运行。我的 DAG 具有处理大量数据的任务，并且合法地需要运行 6-10 小时才能成功完成。因此，关于分解这些任务以处理更少数据的讨论应该超出这个问题的范围。

我相信这与我的部署方式和上述日志通常何时显示有关。但我没有确凿的数据来支持这一点。

一些在线搜索表明，将 Celery 可见性超时增加到高于我预期的最长运行任务（跨所有 DAG）的值应该可以解决此问题。 我计划实施。

但我主要担心的是增加可见性超时（可能到 ~11 小时）+ 不杀死部署时的 Redis 容器是否会让 Celery 需要约 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 容器以及所有其他 Airflow 组件？我主要关心的是调度程序是否足够聪明，一旦启动就可以重建准确的世界视图。
3. “未满足依赖项”消息是否与 Celery 可见性超时以外的其他内容有关？如果是这样，是什么？新的 Airflow 版本是否解决了这个问题？
4. 我配置了 StatsD 指标。是否有我可以分析的具体指标来了解这里发生了什么？ （或者新 Airflow 版本中引入的新指标有助于提高此处的可观察性？）

Answer 1

无法回答您的所有问题，但是：

• 您将哪个数据库用于 Airflow？后格雷斯？你还在坚持吗？

我认为你不应该碰你的 Redis 容器（换句话说——保持它）。 我认为您也应该将其配置为 Celery 的后端结果。 另外，考虑以下配置（我正在使用）：

• CELERY_ACKS_LATE - 任务将在任务执行后得到确认。另请阅读faq：

  acks_late 设置将在您需要任务时使用 如果工作人员（由于某种原因）在执行过程中崩溃，则再次执行。

• CELERY_TRACK_STARTED - 当有长时间运行的任务并且需要报告当前正在运行的任务时，具有“已启动”状态可能很有用。

关于指标，对于 Celery，您可以使用 Flower（不要重新启动此容器！），我看到有一个选项可以为 Airflow 配置 Statsd（我没有尝试过）。查看airflow.cfg中的以下配置：

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