已知问题

Managed Airflow（第 3 代） | Managed Airflow（第 2 代） | Managed Airflow（旧版第 1 代）

本页面列出了 Managed Airflow 的已知问题。如需了解问题修复，请参阅版本说明。

上传的 DAG 文件的首次 DAG 运行有多个失败的任务

当您上传某个 DAG 文件时，有时针对该文件的首次 DAG 运行的前几个任务会失败，并显示 Unable to read remote log... 错误。出现此问题的原因是 DAG 文件在环境的存储分区、Airflow 工作器和环境的 Airflow 调度器之间同步。如果调度器获取 DAG 文件并安排工作器执行该文件，而工作器还没有该 DAG 文件，则任务执行会失败。

为了缓解此问题，默认情况下，具有 Airflow 2 的环境配置为对失败的任务执行两次重试。如果任务失败，系统会重试两次， 每次间隔 5 分钟。

Managed Airflow 不应受 Apache Log4j 2 漏洞 (CVE-2021-44228) 影响

针对 Apache Log4j 2 漏洞 (CVE-2021-44228)，Managed Airflow 开展了详细调查，我们认为 Managed Airflow 不会受到此漏洞的影响。

更改插件后，Airflow 界面有时有时不重新加载插件

如果插件包含多个会导入其他模块的文件，则 Airflow 界面可能无法识别应该重新加载插件的情况。在这种情况下，请重启环境的 Airflow Web 服务器。

访问 Airflow 界面时出现错误 504

访问 Airflow 界面时，您可能会收到 504 Gateway Timeout 错误。此错误可能由以下几个原因造成：

  • 暂时性通信问题。在这种情况下，请稍后尝试访问 Airflow 界面。您还可以重启 Airflow Web 服务器。

  • （仅限 Managed Airflow [第 3 代]）连接问题。如果 Airflow 界面永久不可用，并且生成了超时或 504 错误，请确保您的环境可以访问 *.composer.googleusercontent.com。

  • （仅限 Managed Airflow [第 2 代]）连接问题。如果 Airflow 界面永久不可用，并且生成了超时或 504 错误，请确保您的环境可以访问 *.composer.cloud.google.com。如果您使用专用 Google 访问通道并通过 private.googleapis.com 虚拟 IP 发送流量，或者使用 VPC Service Controls 并通过 restricted.googleapis.com 虚拟 IP 发送流量，请确保您的 Cloud DNS 也针对 *.composer.cloud.google.com 域名进行了配置。

  • Airflow Web 服务器无响应。如果错误 504 仍然存在，但您仍然可以在特定时间访问 Airflow 界面，则 Airflow Web 服务器可能因不堪重负而无响应。尝试提高 Web 服务器的扩缩和性能参数。

访问 Airflow 界面时出现错误 502

错误 502 Internal server exception 表示 Airflow 界面无法处理传入请求。此错误可能由以下几个原因造成：

  • 暂时性通信问题。请稍后尝试访问 Airflow 界面。

  • 未能启动 Web 服务器。为了启动，Web 服务器需要先同步配置文件。检查 Web 服务器日志中是否有类似于 GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp 或 GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp 的日志条目。如果您看到这些出错提示，请检查出错提示中提到的文件是否仍存在于环境的存储桶中。

    如果这些文件被意外移除（例如，由于配置了保留政策），您可以将其恢复：

    1. 在您的环境中设置新的环境变量。您可以使用任何变量名称和值。

    2. 替换 Airflow 配置选项。您可以使用不存在的 Airflow 配置选项。

替换 [webserver]analytics_tool 后访问 Airflow 界面时出现错误 500

在具有 Airflow 2 的环境中，如果您替换 [webserver]analytics_tool Airflow 配置选项，以将匿名 Airflow 界面使用情况数据路由到分析服务（例如 Google Analytics、Segment、MetaRouter 或 Matomo），则在环境更新成功后访问 Airflow 界面可能会返回 (500) Internal Server Error 响应，并在 Airflow Web 服务器日志中显示以下错误之一：

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

在 Airflow 2 中设置 [webserver]analytics_tool 时，Airflow Web 服务器要求在呈现 Airflow 界面时也定义 [webserver] 部分中的配套分析选项。

在 Airflow 3 中，[webserver]analytics_tool、[webserver]analytics_id 和 [webserver]analytics_url 配置选项已被移除。

解决方案：

  • 移除 [webserver]analytics_tool Airflow 配置选项的替换，或
  • 同时指定所有必需的 Airflow 配置选项：
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • [webserver]analytics_url（在 Airflow 2.9 及更高版本中是必需的，即使您的分析工具不使用自定义网址也是如此）

将鼠标悬停在树状视图中的任务实例上会抛出未捕获的 TypeError

在 Airflow 2 中，使用非默认时区时，Airflow 界面中的树状视图有时可能无法正常工作。如需解决此问题，请在 Airflow 界面中明确配置时区。

Scheduler 和 Worker 中的空文件夹

Managed Airflow 不会主动从 Airflow 工作器和调度器中移除空文件夹。当这些文件夹存在于存储桶中并最终被移除时，环境存储桶同步过程可能会创建此类实体。

建议：调整 DAG，使其准备好跳过此类空文件夹。

当这些组件重启时（例如，由于环境集群中的缩容或维护操作），这些实体最终会从 Airflow 调度器和工作器的本地存储空间中移除。

支持 Kerberos

Managed Airflow 不支持 Airflow Kerberos 配置。

Managed Airflow（第 2 代）和 Managed Airflow（第 3 代）支持计算类

Managed Airflow（第 3 代）和 Managed Airflow（第 2 代）仅支持通用 计算类。这意味着无法运行请求其他计算类（例如均衡或横向扩容）的 Pod。

通用类允许运行请求最多 110 GB 内存和最多 30 个 CPU 的 Pod（如计算类最大请求数中所述）。

如果您想使用基于 ARM 的架构或需要更多 CPU 和内存，则必须使用其他计算类，Managed Airflow（第 3 代）和 Managed Airflow（第 2 代）集群不支持这些计算类。

建议：使用 GKEStartPodOperator 在支持所选计算类的其他集群上运行 Kubernetes Pod。如果您运行需要其他计算类的自定义 Pod，则它们也必须在非 Managed Airflow 集群上运行。

无法缩减 Cloud SQL 存储空间

Managed Airflow 使用 Cloud SQL 运行 Airflow 数据库。随着时间的推移，Cloud SQL 实例的磁盘存储空间可能会增加，因为当 Airflow 数据库增长时，磁盘会扩容以适应 Cloud SQL 操作存储的数据。

无法缩减 Cloud SQL 磁盘大小。

作为一种解决方法，如果您想使用最小的 Cloud SQL 磁盘大小，可以使用快照重新创建 Managed Airflow 环境。

从 Cloud SQL 中移除记录后，数据库磁盘用量指标并未减少

关系型数据库（例如 Postgres 或 MySQL）在删除或更新行时不会实际移除这些行。而是将其标记为“死元组”，以保持数据一致性并避免阻塞并发事务。

MySQL 和 Postgres 都实现了在删除记录后回收空间的机制。

虽然可以强制数据库回收未使用的磁盘可用空间，但这是一项资源密集型操作，还会锁定数据库，导致 Managed Airflow 无法使用。因此，建议您依靠构建机制来回收未使用的空间。

禁止访问：发生了授权错误

如果此问题影响到用户，访问权限遭拒：授权错误对话框会包含 Error 400: admin_policy_enforced 消息。

如果在 Google Workspace 中启用了 API 控件 > 未配置的第三方应用 > 不允许用户访问任何第三方应用选项，并且未明确允许 Managed Airflow 应用中的 Apache Airflow，则用户无法访问 Airflow 界面，除非他们明确允许该应用。

如需允许访问，请执行允许在 Google Workspace 中访问 Airflow 界面中提供的步骤。

访问 Airflow 界面时出现登录循环

此问题可能由以下原因引起：

Airflow Web 服务器中不提供 /data 文件夹

在 Managed Airflow（第 2 代）和 Managed Airflow（第 3 代）中，Airflow Web 服务器主要用作只读组件，Managed Airflow 不会将 data/ 文件夹同步到此组件。

有时，您可能希望在所有 Airflow 组件（包括 Airflow Web 服务器）之间共享通用文件。

解决方案：

  • 将要与 Web 服务器共享的文件封装到 PYPI 模块中，并将其作为常规 PYPI 软件包进行安装。在环境中安装 PYPI 模块后，这些文件会添加到 Airflow 组件的映像中，并可供这些组件使用。

  • 将文件添加到 plugins/ 文件夹中。此文件夹会同步到 Airflow Web 服务器。

监控中的非连续 DAG 解析时间和 DAG 包大小图表

监控信息中心上的非连续 DAG 解析时间和 DAG 包大小图表表示 DAG 解析时间过长（超过 5 分钟）的问题。

Airflow DAG 解析时间和 DAG 包大小图表，显示一系列非连续的时间间隔
图 1. 非连续 DAG 解析时间和 DAG 包大小图表（点击可放大）

解决方案：我们建议将 DAG 总解析时间控制在 5 分钟以内。如需缩短 DAG 解析时间，请遵循 DAG 编写指南。

任务日志延迟显示

具体情况：

  • 在 Managed Airflow（第 3 代）中，Airflow 任务日志不会立即显示，而是会延迟几分钟。
  • 您可能会在 Airflow 日志中找到 Logs not found for Cloud Logging filter 消息

原因：

如果您的环境同时运行大量任务，则任务日志可能会延迟，因为环境的基础设施大小不足以快速处理所有日志。

解决方案：

  • 请考虑增加环境的基础设施大小以提高性能。
  • 随着时间的推移分配 DAG 运行，以便任务不会同时执行。

KubernetesPodOperator 和 KubernetesExecutor 的启动时间增加

使用 KubernetesPodOperator 创建的 Pod 和使用 KubernetesExecutor 执行的任务的启动时间会增加。Managed Airflow 团队正在努力寻找解决方案，并会在问题解决后发布公告。

解决方法：

  • 启动具有更多 CPU 的 Pod。
  • 如果可能，请优化映像（减少层数、缩小大小）。

在项目的结算账号被删除或停用，或者 Cloud Composer API 被停用后，环境处于错误状态

受这些问题影响的 Managed Airflow 环境无法恢复：

  • 项目的结算账号被删除或停用后，即使后来关联了其他账号，也是如此。
  • 在项目中停用 Cloud Composer API 之后，即使后来又启用了该 API。

您可以执行以下操作来解决此问题：

  • 您仍然可以访问存储在环境存储桶中的数据，但环境本身不再可用。您可以创建新的 Managed Airflow 环境，然后转移 DAG 和数据。

  • 如果您想执行任何会导致环境无法恢复的操作，请务必备份数据，例如创建环境快照。这样，您就可以创建另一个环境，并通过加载此快照来转移其数据。

如果 [core]execute_tasks_new_python_interpreter 设置为 True，则系统不会收集 Airflow 任务的日志

如果 [core]execute_tasks_new_python_interpreter Airflow 配置选项设置为 True，则 Managed Airflow 不会收集 Airflow 任务的日志。

可能的解决方法：

  • 移除此配置选项的替换设置，或将其值设置为 False。

删除环境时移除网络连接出错

如果同时删除共享同一网络连接的多个环境，则某些删除操作会失败并报错。

症状：

系统会生成以下错误：

Got error while removing Network Attachment: <error code>

报告的错误代码可以是 Bad request: <resource> is not ready 或 Precondition failed: Invalid fingerprint。

可能的解决方法：

  • 逐个删除使用同一网络连接的环境。

  • 在删除环境之前，请先停用与 VPC 网络的连接。我们建议您使用此解决方法来自动删除环境。

多个 google-api-core 软件包版本中的环境性能下降

2.28.0 至 2.30.2 版

2.28.0 到 2.30.2 之间的 google-api-core 预安装软件包版本可能会导致环境性能下降，从而导致执行任务的时间更长，以及将任务从已加入队列状态移至正在执行状态的时间更长。

受影响的Managed Airflow（第 3 代） build：

  • composer-3-airflow-3.1.7-build.0 至 composer-3-airflow-3.1.7-build.5
  • composer-3-airflow-3.1.0-build.5 至 composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • composer-3-airflow-2.10.5-build.22 至 composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 至 composer-3-airflow-2.9.3-build.53

受影响的Managed Airflow（第 2 代） build：

  • composer-2.16.10-airflow-2.11.1
  • composer-2.16.0-airflow-2.10.5 至 composer-2.16.10-airflow-2.10.5
  • composer-2.16.0-airflow-2.9.3 至 composer-2.16.10-airflow-2.9.3

将您的环境升级到以下 build 之一，这些 build 包含预安装的 google-api-core 2.27.0 版，不受此问题影响：

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

或者，升级到包含 google-api-core 2.43.1 或更高版本的映像，或手动安装兼容版本。

在 Python 3.11 上，自 2026 年 10 月 24 日起，google-api-core 2.30.3 至 2.43.0 版会导致单独的性能问题。如果您的环境运行 Python 3.11，请应用 Python 3.11 上的 2.30.3 到 2.43.0 版本中列出的解决方法之一。

Python 3.11 上的 2.30.3 至 2.43.0 版本

自 2026 年 10 月 24 日起，google-api-core 软件包版本 2.30.3 至 2.43.0 会运行 Python 3.11 弃用检查，每当在新的 Python 子进程中导入 Google Cloud 客户端库时，该检查都会扫描已安装的软件包元数据。

在运行 Python 3.11 的 Managed Airflow 环境中，此行为可能会降低性能。在具有许多 DAG、频繁的短期运行任务或启用了数据沿袭集成的环境中，此问题更为严重。

症状包括：

  • Airflow DAG 处理器上的 DAG 解析时间增加，CPU 使用率提高。
  • Airflow 工作器的任务执行时间更长，CPU 使用率更高。
  • google/api_core/_python_version_support.py 频繁生成 FutureWarning 日志条目，指出 Python 3.11 支持将于 2027 年 10 月 24 日终止。

此问题会影响预安装或手动安装了 google-api-core 2.30.3 至 2.43.0 版的任何 Python 3.11 环境，包括以下 build。

此问题会影响以下Managed Airflow（第 3 代） build：

  • composer-3-airflow-3.3.1-build.0 至 composer-3-airflow-3.3.1-build.5
  • composer-3-airflow-3.2.2-build.0 至 composer-3-airflow-3.2.2-build.9
  • composer-3-airflow-3.1.8-build.0 至 composer-3-airflow-3.1.8-build.4
  • composer-3-airflow-3.1.7-build.7 至 composer-3-airflow-3.1.7-build.13
  • composer-3-airflow-2.11.1-build.3 至 composer-3-airflow-2.11.1-build.22
  • composer-3-airflow-2.10.5-build.36 至 composer-3-airflow-2.10.5-build.52

受影响的Managed Airflow（第 2 代） build：

  • composer-2.17.0-airflow-2.11.1 至 composer-2.17.16-airflow-2.11.1
  • composer-2.17.0-airflow-2.10.5 至 composer-2.17.13-airflow-2.10.5

解决方法：

根据环境的映像版本，选择以下选项之一：

  • 选项 1。仅限与 Airflow 3 兼容的 Managed Airflow（第 3 代） build：安装具有 >=2.43.1 版本限制条件的 google-api-core PyPI 软件包。

    兼容的 Managed Airflow（第 3 代） build：

    • composer-3-airflow-3.3.1-build.0 至 composer-3-airflow-3.3.1-build.5
    • composer-3-airflow-3.2.2-build.1 至 composer-3-airflow-3.2.2-build.9
    • composer-3-airflow-3.1.8-build.3 到 composer-3-airflow-3.1.8-build.4

    请勿在 Airflow 2 build 或更早的 Airflow 3 build（包括 composer-3-airflow-3.2.2-build.0 以及 composer-3-airflow-3.1.8-build.0 到 build.2）中使用此选项。在这些 build 中，google-api-core 2.43.1 会导致依赖项冲突，因为它需要 opentelemetry-api>=1.44.0。对于这些 build，请使用选项 2。

  • 方法 2.所有受影响的 Managed Airflow（第 3 代）和 Managed Airflow（第 2 代） build： 应用 sitecustomize.py 运行时补丁。

    1. 从 GitHub 下载 sitecustomize.py。

    2. 将 sitecustomize.py 上传到环境存储桶中的 dags/patches 文件夹。

    3. 将 PYTHONPATH 环境变量设置为 /home/airflow/gcs/dags/patches。

      如果已设置 PYTHONPATH，请将 /home/airflow/gcs/dags/patches: 附加到现有值的前面。示例：/home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    升级后清理：在未来的 Managed Airflow 版本中，系统会预安装 google-api-core 软件包 2.43.1 或更高版本。升级到具有 google-api-core 2.43.1 或更高版本的映像后，您可以移除 PYTHONPATH 替换项并删除 dags/patches/sitecustomize.py。

TI 不再处于运行状态，任务应终止，并且 Airflow 3 中出现“找不到任务”错误

Airflow 3 有两个与调度器在重启期间丢失任务状态相关的问题：

  • 409 冲突状态：调度器中的竞态条件导致重复的任务实例调度（#59378，已在 #60330 中解决）。

    此问题已在 Airflow 3.2.2 中修复。

  • 404 未找到错误：Airflow 工作器在常规调度器循环重启期间无法跟踪任务实例，这种情况发生在调度器达到 [scheduler]num_runs 之后。这会更改现有任务实例 ID，并导致不知道此更改的工作器生成后续 404 错误（#53140、#60330，已在 #61631 中解决）。

    此问题已在 Airflow 3.3.1 中得到解决。

表现

  • 409 冲突：重启的调度器的孤立清理状态会将活跃任务标记为 FAILED，从而导致工作器异常终止：

    Server indicated the task shouldn't be running anymore [supervisor]
detail={'detail': {'reason': 'not_running', 'message': 'TI is no longer in
the running state and task should terminate', 'current_state': 'scheduled'}} status_code=409 ti_id=UUID('...')

  • 404 Not Found：重启的调度器会丢失任务状态，并且无法通过活跃工作器脉搏检查：

    Server indicated the task shouldn't be running anymore [detail={'detail':
{'reason': 'not_found', 'message': 'Task Instance not found'}}]
[status_code=404] [ti_id=...]

解决方案：

  • 这两个问题均已在 Airflow 3.3.1 及更高版本中得到修复。 将环境升级到使用 Airflow 3.3.1 的版本。

可能的解决方法：

  • 在 3.3.1 之前的 Airflow 版本中，无法完全缓解此问题。任何导致单个调度器意外重启的外部事件都会触发 404 和 409（在 Airflow 3.2.2 之前的版本中）。此类事件的示例包括环境集群中节点的自动升级、Pod 中的 OOM 条件，或调度器的高内存和 CPU 消耗。

  • 将环境缩减到一个调度器，并将 [scheduler]num_runs 配置选项设置为 -1，可缓解调度器中出现竞态条件的原因。

    对于高弹性（高可用性）环境，无法将调度器数量减少到一个。您仍然可以将 [scheduler]num_runs 设置为 -1。

  • 确保调度器的内存和 CPU 消耗量在可用资源限制内。

后续步骤