已知問題

Managed Airflow (第 3 代) | Managed Airflow (第 2 代) | Managed Airflow (舊版第 1 代)

本頁列出 Managed Airflow 的已知問題。如要瞭解問題修正，請參閱版本資訊。

上傳的 DAG 檔案首次執行 DAG 執行作業時，有多項任務失敗

上傳 DAG 檔案時，DAG 首次執行作業的前幾項工作有時會失敗，並顯示 Unable to read remote log... 錯誤。發生這個問題的原因，是 DAG 檔案會在環境的 bucket、Airflow worker 和 Airflow 排程器之間同步。如果排程器取得 DAG 檔案並排定由 worker 執行，但 worker 尚未取得 DAG 檔案，工作執行就會失敗。

為緩解這個問題，搭載 Airflow 2 的環境預設會對失敗的工作重試兩次。如果工作失敗，系統會重試兩次，每次間隔 5 分鐘。

Managed Airflow 應不會受到 Apache Log4j 2 安全漏洞 (CVE-2021-44228) 的影響

Apache Log4j 2 安全漏洞 (CVE-2021-44228) 發生後，Managed Airflow 進行了詳細調查，我們認為 Managed Airflow 不會受到這個安全漏洞的影響。

Airflow UI 有時可能不會重新載入已變更的外掛程式

如果外掛程式包含許多匯入其他模組的檔案，Airflow UI 可能無法辨識外掛程式應重新載入。在這種情況下，請重新啟動環境的 Airflow 網路伺服器。

存取 Airflow UI 時發生錯誤 504

存取 Airflow UI 時，可能會收到 504 Gateway Timeout 錯誤。這個錯誤可能由多種原因造成：

  • 暫時性通訊問題。在這種情況下，請稍後再嘗試存取 Airflow UI。您也可以重新啟動 Airflow 網路伺服器。

  • (僅限 Managed Airflow (第 3 代)) 連線問題。如果 Airflow UI 永久無法使用，且產生逾時或 504 錯誤，請確認環境可以存取 *.composer.googleusercontent.com。

  • (僅限 Managed Airflow (第 2 代)) 連線問題。如果 Airflow UI 永久無法使用，且產生逾時或 504 錯誤，請確認環境可以存取 *.composer.cloud.google.com。如果您使用 Private Google Access 並透過 private.googleapis.com 虛擬 IP 傳送流量，或使用 VPC Service Controls 並透過 restricted.googleapis.com 虛擬 IP 傳送流量，請務必為 *.composer.cloud.google.com 網域名稱設定 Cloud DNS。

  • Airflow 網路伺服器沒有回應。如果 504 錯誤持續發生，但您仍可在特定時間存取 Airflow UI，則 Airflow 網路伺服器可能因負載過重而沒有回應。嘗試提高網路伺服器的規模和效能參數。

存取 Airflow UI 時發生錯誤 502

錯誤 502 Internal server exception 表示 Airflow UI 無法處理傳入的要求。這個錯誤可能由多種原因造成：

  • 暫時性通訊問題。請稍後再嘗試存取 Airflow UI。

  • 無法啟動網路伺服器。如要啟動，網路伺服器必須先同步處理設定檔。檢查網路伺服器記錄，找出類似 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 的記錄項目。如果看到這些錯誤，請檢查錯誤訊息中提及的檔案是否仍存在於環境的 bucket 中。

    如果意外移除 (例如設定了資料保留政策)，可以按照下列步驟還原：

    1. 在環境中設定新的環境變數。您可以使用任何變數名稱和值。

    2. 覆寫 Airflow 設定選項。您可以使用不存在的 Airflow 設定選項。

覆寫 [webserver]analytics_tool 後，存取 Airflow UI 時發生錯誤 500

在 Airflow 2 環境中，如果您覆寫 [webserver]analytics_tool Airflow 設定選項，將匿名 Airflow UI 使用資料轉送至數據分析服務 (例如 Google Analytics、Segment、MetaRouter 或 Matomo)，則在環境更新成功後存取 Airflow UI 時，可能會傳回 (500) Internal Server Error 回應，並在 Airflow 網路伺服器記錄中顯示下列其中一項錯誤：

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 網路伺服器會要求在轉譯 Airflow UI 時，也必須定義 [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 UI 中的樹狀檢視有時可能無法正常運作。如要解決這個問題，請在 Airflow UI 中明確設定時區。

排程器和工作站中的空白資料夾

Managed Airflow 不會主動從 Airflow worker 和排程器中移除空資料夾。如果 bucket 中有這些資料夾，且最終遭到移除，則環境 bucket 同步處理程序可能會建立這類實體。

建議：調整 DAG，讓 DAG 略過這類空白資料夾。

當 Airflow 排程器和 worker 重新啟動時 (例如因環境叢集縮減或維護作業)，這些實體最終會從本機儲存空間中移除。

支援 Kerberos

Managed Airflow 不支援 Airflow Kerberos 設定。

支援 Managed Airflow (第 2 代) 和 Managed Airflow (第 3 代) 的運算類別

Managed Airflow (第 3 代) 和 Managed Airflow (第 2 代) 僅支援一般用途 運算類別。也就是說，您無法執行要求其他運算類別 (例如 Balanced 或 Scale-Out) 的 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 UI。

如要允許存取，請按照「允許在 Google Workspace 中存取 Airflow UI」中的步驟操作。

存取 Airflow UI 時，登入程序陷入迴圈

這個問題的可能原因如下：

Airflow 網路伺服器不提供 /data 資料夾

在 Managed Airflow (第 2 代) 和 Managed Airflow (第 3 代) 中，Airflow 網路伺服器主要是唯讀元件，Managed Airflow 不會將 data/ 資料夾同步至這個元件。

有時，您可能需要在所有 Airflow 元件 (包括 Airflow 網路伺服器) 之間共用通用檔案。

解決方法：

  • 將要與網路伺服器共用的檔案包裝成 PYPI 模組，並以一般 PYPI 套件的形式安裝。在環境中安裝 PYPI 模組後，檔案會新增至 Airflow 元件的映像檔，並可供這些元件使用。

  • 將檔案新增至 plugins/ 資料夾。這個資料夾會同步到 Airflow 網路伺服器。

監控頁面中的非連續 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 團隊正在設法解決問題，並會在問題解決後發布公告。

解決方法：

  • 啟動 Pod 時分配更多 CPU。
  • 盡可能最佳化圖片 (減少圖層、縮小尺寸)。

專案的帳單帳戶遭到刪除或停用，或是 Cloud Composer API 遭到停用，導致環境處於「錯誤」狀態

受這些問題影響的 Managed Airflow 環境無法復原：

  • 專案的帳單帳戶遭到刪除或停用後，即使之後連結其他帳戶也一樣。
  • 專案中的 Cloud Composer API 已停用，即使之後啟用也一樣。

您可以採取下列做法解決問題：

  • 您仍可存取儲存在環境 bucket 中的資料，但環境本身已無法使用。您可以建立新的 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。

可能的解決方法：

  • 逐一刪除使用相同網路連結的環境。

  • 刪除環境前，請先停用虛擬私有雲網路連線。建議您使用這個解決方法，自動刪除環境。

多個 google-api-core 套件版本的環境效能降低

預先安裝的 google-api-core 套件版本 2.28.0 至 2.30.2 可能會導致環境效能降低，進而延長執行工作的時間，以及將工作從佇列狀態移至執行狀態的時間。

受影響的 Managed Airflow (第 3 代) 版本：

  • 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 代) 版本：

  • 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

建議您將環境升級至下列版本，其中包含已修正或不存在問題的套件版本：

  • composer-3-airflow-3.1.7-build.7 以上版本
  • composer-3-airflow-2.11.1-build.3 以上版本
  • composer-3-airflow-2.10.5-build.36 以上版本
  • composer-3-airflow-2.9.3-build.54 (包含 2.27.0)
  • composer-2.17.0-airflow-2.11.1 以上版本
  • composer-2.17.0-airflow-2.10.5 以上版本
  • composer-2.16.11-airflow-2.11.1 (包含 2.27.0)
  • composer-2.16.11-airflow-2.10.5 (包含 2.27.0)
  • composer-2.16.11-airflow-2.9.3 (包含 2.27.0)

如要解決這個問題，您可以手動將較新版本的 google-api-core 套件安裝到受影響的環境，並指定 >=2.30.3 為必要版本。

TI 不再處於執行狀態，工作應終止，且 Airflow 3 中出現「找不到工作」錯誤

Airflow 3 有兩個問題，與排程器重新啟動時遺失工作狀態有關：

  • 409 衝突狀態：排程器中的競爭狀況導致重複的工作執行個體排程 (#59378，已在 #60330 解決)。

    這個問題已在 Airflow 3.2.2 中修正。

  • 404 找不到網頁錯誤：排程器達到 [scheduler]num_runs 後，會定期重新啟動排程器迴圈，此時 Airflow worker 會失去工作執行個體的追蹤記錄。這會變更現有的工作執行個體 ID，並從未察覺變更的工作站產生後續 404 錯誤 (#53140、#60330，已在 #61631 中解決)。

    這個問題已在 Airflow 3.3.1 中修正。

症狀

  • 409 衝突：重新啟動的排程器孤立清除狀態會將執行中的任務標示為 FAILED，導致 worker 異常終止：

    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 找不到網頁：重新啟動的排程器會遺失工作狀態，且無法通過執行中 worker 的脈搏檢查：

    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 (在 3.2.2 之前的 Airflow 版本)。這類事件包括環境叢集中的節點自動升級、Pod 記憶體不足，或排程器耗用大量記憶體和 CPU。

  • 將環境縮減為一個排程器，並將 [scheduler]num_runs 設定選項設為 -1，即可減少排程器發生競爭狀況的原因。

    如果是高彈性 (高可用性) 環境，排程器數量無法減少至一個。您仍可將 [scheduler]num_runs 設為 -1。

  • 請確認排程器消耗的記憶體和 CPU 遠低於可用的資源限制。

後續步驟