清除气流的任务无法执行

Question

前言

另一个气流任务没有得到执行的问题...

直到这个周末，一切都变得顺风顺水，直到今天这个周末，我的气流体验还是差不多。

我已经检查了所有标准的东西，例如这篇有用的文章中概述的内容。

我已多次重设整个实例，以使其正常工作，但我在这里完全失去了战斗。

环境

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

问题

这是我对无限循环/重复发生的噩梦进行故障排除时发生的事情。

1. 我重置了元数据数据库（或者可能是整个virtualenv和config等）并重新输入了连接信息。
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，这最终导致了一个很大的日志文件。 解决方案：这已在 commit 中修复[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，然后小心合并。另一种策略是仅依赖环境变量，这样您的配置应该始终是全新安装，并且您的 env 变量中的唯一参数是参数覆盖，可能还有连接。
4. 在这种情况下，Airflow 可能不会在任何地方记录错误；一切看起来都很好，除了调度程序没有排队作业，或者它会排队一两个然后停止，没有任何错误消息。 解决方案可以包括(1) 在您的云计算提供商上添加空间不足警报，(2) 弄清楚如何确保调度程序在这种情况下引发一些有用的异常并将它们贡献给气流。