编辑（2020-4-18）：添加了元数据数据库的上下文。添加了关于statsd的上下文。

背景

我操作气流1.10.3部署。它使用mysql 5.7作为元数据数据库。它使用 CeleryExecutor 以redis 3.2.5作为celery 经纪人。
我将气流包、我的dag代码和任何其他相关配置构建到1个docker映像中。
我的部署为每个webserver、flower server、scheduler和worker启动docker容器；它们都是从1 docker图像中派生出来的。redis也在docker容器中运行；但不是来自与其他气流组件相同的docker图像。mysql不是容器化的，并且像任何传统的oltp数据库一样保持和运行。部署序列包括：
建立一个新的docker图像与任何更改的dag代码等。
终止当前正在运行的airflow docker容器（即webserver、scheduler等）；除了redis容器。
从新建的docker映像旋转新的docker容器。
在部署过程中，唯一不会被“擦除并替换”的气流组件是redis容器。
我（连续）每天在任何地方部署3-7次。

发行

通常，在正常操作期间，一组气流任务最终会在其日志中显示以下内容：

[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容器是否会让我花~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.

问题

我担心celery 花了大约11个小时才注意到它需要重新安排一个任务（考虑到我的部署设置）有效吗？
我是否应该考虑杀死redis容器以及所有其他气流组件？这里我主要关心的是调度器是否足够聪明，一旦启动，它是否能够重建对世界的准确视图。
“dependencies not met”消息是否与celery 可见性超时以外的内容相关？如果是，什么？新的气流版本解决了这个问题吗？
我已经配置了statsd指标。有没有具体的指标，我可以分析，以了解这里发生了什么(或者在新的气流版本中引入了新的度量标准，这有助于观察？）