已知問題

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

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

上傳的 DAG 檔案首次執行 DAG 時，有數項工作失敗

上傳 DAG 檔案時，有時第一個 DAG 執行作業的前幾項工作會失敗，並顯示 Unable to read remote log... 錯誤。發生這個問題的原因是，DAG 檔案會在環境的 bucket、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 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 設定選項。

在樹狀檢視中將滑鼠游標懸停在工作執行個體上時，會擲回未捕捉到的 TypeError

在 Airflow 2 中，使用非預設時區時，Airflow UI 中的樹狀檢視畫面有時可能無法正常運作。如要解決這個問題，請在 Airflow UI 中明確設定時區。

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

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

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

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

支援 Kerberos

Managed Airflow 不支援 Airflow Kerberos 設定。

代管 Airflow (第 2 代) 和代管 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，這些 Pod 也必須在非受管理 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 使用者介面」一文中的步驟操作。

存取 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 bag 大小圖表，表示 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 遭停用後，環境處於 ERROR 狀態

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

  • 專案的帳單帳戶遭刪除或停用後，即使之後連結了其他帳戶，也無法再使用。
  • 在專案中停用 Cloud Composer API 後，即使後來啟用也一樣。

如要解決這個問題，請採取下列做法：

  • 您仍可存取環境值區中儲存的資料，但環境本身已無法使用。您可以建立新的 Managed Airflow 環境，然後轉移 DAG 和資料。

  • 如要執行任何會導致環境無法復原的作業，請務必備份資料，例如建立環境的快照。這樣一來，您就能建立另一個環境，並載入這個快照來轉移資料。

如果 [core]execute_tasks_new_python_interpreter 設為 True，系統就不會收集 Airflow 工作記錄

如果 Airflow 設定選項設為 True，Managed Airflow 就不會收集 Airflow 工作的記錄。[core]execute_tasks_new_python_interpreter

參考解法：

  • 移除這項設定選項的覆寫，或將其值設為 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)

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

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

Airflow 3.3.1 之前的版本有幾個問題，與排程器遺失工作狀態有關：

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

  • 404 錯誤：在排程器超出 [scheduler]max_runs 後，Airflow 工作站會在排程器迴圈重新啟動時，遺失工作例項的追蹤記錄。這會變更現有的工作例項 ID，並從不知道這項變更的工作人員產生後續的 404 錯誤 (#53140、#60330，已在 #61631 中解決)。

症狀

重新啟動排程器的孤立清除狀態會將有效工作標示為 FAILED，導致工作人員異常終止，狀態為 409：

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('...')

重新啟動的排程器會遺失工作狀態，且無法通過有效 worker 的脈衝檢查，並顯示 404 錯誤：

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 以上版本中修正。我們正努力在 Managed Airflow (第 3 代) 中提供這個版本。

  • 這個問題無法完全解決，在 3.3.1 之前的 Airflow 版本中，任何導致單一排程器意外重新啟動的外部事件，都會觸發 404 和 409 錯誤。這類事件的例子包括環境叢集中的節點自動升級、Pod 中的 OOM 狀況，或是排程器耗用大量記憶體和 CPU。

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

    對於具備高度彈性的環境 (高可用性)，無法將排程器數量減少至一個。你還是可以將 [scheduler]num_runs設為 -1。

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

後續步驟