气流清除的任务没有被执行

Question

序言

又一个气流任务没有被执行的问题......

在我的气流体验中，一切都或多或少地进展顺利，直到本周末事情真的走下坡路。

我已经检查了所有标准的东西，例如如this helpful post 中所述。

我已多次重置整个实例以使其正常工作，但我在这里完全输了。

环境

• 版本：气流1.10.2
• 操作系统：centos 7
• python：python 3.6
• virtualenv：是的
• 执行者：LocalExecutor
• 后端数据库：mysql

问题

这是我在解决无限循环/重复噩梦时发生的情况。

1. 我重置了元数据数据库（或者可能是整个 virtualenv 和配置等）并重新输入了连接信息。
2. 任务将执行一次。他们可能会成功。如果我错过了设置中的某些内容，则任务可能会失败。
3. 当任务失败时，它会进入重试状态。
4. 我解决了这个问题（例如忘记输入连接）并手动清除任务实例。
5. 已清除的任务实例不会运行，而只是处于“无”状态
6. 尝试让 dag 再次运行失败。

在我开始遇到这个问题之前，在清除了一个任务实例之后，它总是会很快被拾取并再次执行。

但是现在，清除任务实例通常会导致任务实例卡在清除状态。它只是坐在那里。

更糟糕的是，如果我尝试使 dag 和所有实例失败，并再次手动触发 dag，则任务实例会被创建但仍处于“无”状态。重新启动调度程序没有帮助。

其他观察

这可能是一个红鲱鱼，但我最近才注意到的一件事是，当我单击代表停留在“无”状态的任务实例的图标时，它会将我带到一个“任务实例”视图过滤器，该过滤器过滤器错误；过滤器设置为“字符串等于空”。

但您需要将其切换为“string empty yes”，以便它实际返回卡住的任务实例。

我假设这只是一个不相关的 UI 错误，就我而言，这是一个红鲱鱼，但我想我会提到它以防万一。

编辑 1

我注意到有一些“空运算符”正在进行：

编辑 2

null 是任务实例状态的有效值吗？或者这是否表明有问题。

编辑 3

更多none的东西。

以下是任务实例详细信息页面中的一些内容。很多属性都是none:

Task Instance Details
Dependencies Blocking Task From Getting Scheduled
Dependency  Reason
Unknown All dependencies are met but the task instance is not running. In most cases this just means that the task will probably be scheduled soon unless:
- The scheduler is down or under heavy load
- The following configuration values may be limiting the number of queueable processes: parallelism, dag_concurrency, max_active_dag_runs_per_dag, non_pooled_task_slot_count
- This task instance already ran and had its state changed manually (e.g. cleared in the UI)

If this task instance does not start soon please contact your Airflow administrator for assistance.
Task Instance Attributes
Attribute   Value
duration    None
end_date    None
is_premature    False
job_id  None
operator    None
pid None
queued_dttm None
raw False
run_as_user None
start_date  None
state   None

更新

我可能终于开始做点什么了……

在我噩梦般的、马拉松、卡在暮光区故障排除会议之后，我举起双手，决定使用 docker 容器而不是本地运行。这太奇怪了。事情只是没有意义。我需要迁移到 docker，以便完全控制和复制环境。

所以我开始研究基于 puckel/docker-airflow 的 docker 设置。这也不是一件容易的事，因为我决定对所有参数和连接使用环境变量。并非所有钩子都以相同的方式解析连接 URI，因此您必须小心并查看代码并进行一些试验和错误。

然后我就这样做了，我终于让我的 docker 设置在本地工作了。但是当我在我的 EC2 实例上构建映像时，我发现 磁盘已满。而且它在很大程度上是由于气流日志，它是满的。

所以，我的新理论是磁盘空间不足可能与此有关。我不确定我是否能够在日志中找到确凿证据，但我会看看。

Answer 1

好的，我将关闭它并将假定的根本原因标记为服务器空间不足。

有许多促成因素：

1. 我的服务器没有大量存储空间。只有10GB。我没有意识到它是如此之低。 解决方法：添加更多空间
2. 登录气流 1.10.2 有点疯狂。 INFO 日志消息每隔一两秒输出一次 Harvesting DAG parsing results，最终导致生成一个大的日志文件。 解决方案： 这已在提交 [AIRFLOW-3911] Change Harvesting DAG parsing results to DEBUG log level (#4729) 中得到修复，该提交在 1.10.3 中，但如果您卡在 1.10.2 上，您始终可以分叉和樱桃挑选。
3. 此外，我的一些调度程序/网络服务器间隔参数可能会受益于增加。结果，我得到了多 GB 的日志文件。我认为这可能部分是由于更改了气流版本而没有正确更新airflow.cfg。 解决方法：升级（或更改版本）时，暂时移动airflow.cfg，以便生成与版本兼容的cfg，然后小心合并。另一种策略是仅依赖环境变量，这样您的配置应该始终像全新安装一样，并且环境变量中的唯一参数是参数覆盖，并且可能，连接。
4. 在这种情况下，Airflow 可能不会在任何地方记录错误；一切看起来都很好，除了调度程序没有排队作业，或者它会排队一两个然后停止，没有任何错误消息。 解决方案可以包括 (1) 在您的云计算提供商上添加空间不足警报，(2) 弄清楚如何确保调度程序在这种情况下引发一些有用的异常并将它们贡献给气流。李>