排解 Cloud Scheduler 問題

本頁面說明如何解決 Cloud Scheduler 相關問題。

Cloud Scheduler 會在每次工作執行開始和結束時發布記錄。您可以擷取、查看及分析特定工作的記錄,包括 Cloud Scheduler 提供的稽核記錄。詳情請參閱「查看記錄」。

根據預設,如果 Cloud Scheduler 工作未收到目標服務 (工作要求處理常式) 的確認訊息,系統就會判定工作失敗。Cloud Scheduler 會根據您設定的指數輪詢重試工作。

如要瞭解影響 Google Cloud 服務的事件,請參閱Google Cloud Service Health 資訊主頁和所有 Cloud Scheduler 回報事件。

工作因下游服務問題而失敗

工作失敗的原因可能是 Cloud Scheduler 指定的下游服務 (例如 Cloud Run) 發生問題,而非 Cloud Scheduler 本身。如果符合下列條件,您可能會懷疑是下游服務發生問題:

  • Cloud Scheduler 的權限已正確設定。
  • Cloud Scheduler 可成功連上目標服務。
  • Cloud Scheduler 執行記錄中的錯誤訊息來自下游服務。

如要解決這個問題,請完成下列步驟:

  1. 直接叫用下游服務:確認下游服務可在不使用 Cloud Scheduler 的情況下成功叫用。如果叫用成功,代表問題可能出在 Cloud Scheduler;如果叫用失敗,則須進一步偵錯下游服務。
  2. 檢查目的地服務記錄:檢查目的地服務的記錄,判斷輸出的錯誤,並據此分類。
  3. 尋找長時間執行的作業:如果 Cloud Scheduler 針對長時間執行的作業 (超過 30 分鐘) 傳回 HTTP 504 錯誤,請檢查目的地服務記錄,確認執行成功或失敗,因為目的地服務的要求逾時時間可能較長。在這種情況下,Cloud Scheduler 會逾時,但目的地服務不會。

工作失敗,並顯示權限錯誤

權限可控管哪些主體能存取資源,以及允許哪些作業。權限設定錯誤可能會中斷工作執行,並導致權限遭拒錯誤。稽核記錄會詳細記錄所有權限變更,方便您找出問題來源。

如果 Cloud Scheduler 工作因權限錯誤而失敗,執行記錄可能會顯示類似 "debugInfo":"URL_ERROR-ERROR_OTHER. Original HTTP response code number = 403" 的訊息。

如要解決這個問題,請完成下列一或多項驗證:

  • 確認授予服務代理的 IAM 角色:Cloud Scheduler 服務代理需要 Cloud Scheduler 服務代理 (roles/cloudscheduler.serviceAgent) 角色。如果沒有這個角色,Cloud Scheduler 工作就會失敗。您可以手動將角色授予 Cloud Scheduler 服務代理。只有在 2019 年 3 月 19 日前啟用 Cloud Scheduler API,或移除 Cloud Scheduler 服務代理角色時,才需要手動授予。詳情請參閱「授予 Cloud Scheduler 服務代理角色」。

  • 驗證服務帳戶權限:確認附加至工作的服務帳戶具備正確的權限和範圍,可叫用目的地服務。包括目標位於其他專案,或是中介服務的最終目標。如果目標位於 Google Cloud,請確認您已將必要角色授予服務帳戶。 Google Cloud 中的每項服務都需要特定角色,接收服務會自動驗證產生的權杖。舉例來說,如果是 Cloud Run 和 Cloud Run functions,您必須授予 Cloud Run Invoker 角色。如果目標位於 Google Cloud外部,接收服務必須手動驗證權杖。詳情請參閱「向 Cloud Scheduler 進行驗證」和「搭配使用驗證與 HTTP 目標」。

  • 確認是否有任何 VPC Service Controls 違規事項:VPC Service Controls 是一項 Google Cloud功能,可用來設定安全 perimeter 以防範資料遭竊。如要確認錯誤是否與 VPC Service Controls 有關,請檢查是否已啟用 VPC Service Controls,並套用至嘗試使用的專案與服務。如要確認專案和服務是否受到 VPC Service Controls 保護,請檢查該資源階層層級的 VPC Service Controls 政策。

    如要瞭解問題範圍,您可以從稽核記錄擷取 VPC Service Controls 錯誤。

    1. 前往 Google Cloud 控制台的 「Logs Explorer」頁面:

      前往「Logs Explorer」(記錄檔探索工具)

      如果您是使用搜尋列尋找這個頁面,請選取子標題為「Logging」的結果。

    2. 查詢符合下列條件的稽核記錄:

      severity="ERROR" AND protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"

      具體來說,錯誤訊息可能包含以下文字:

      • Request is prohibited by organization's policy
      • Request violates VPC Service Controls

    如要進一步瞭解設定 VPC Service Controls 時可能遇到的問題,請參閱「排解常見問題」。

  • 驗證所有私人端點:Cloud Scheduler 只能叫用特定私人端點,例如 Cloud Run、Cloud Run functions,以及 Google Cloud VPC Service Controls perimeter 內的 API。請檢查目的地服務的輸入設定 (例如限制 Cloud Run 的網路輸入),以及附加服務帳戶的權限。您可能會收到 URL_ERROR-ERROR_DNS 錯誤訊息。詳情請參閱本文「工作因無法連上目的地目標而失敗」一節。

無法連上目的地目標,導致工作失敗

如果 Cloud Scheduler 工作因無法連上目的地目標而失敗,就會發生這個問題。執行記錄會顯示開頭為 URL_ERROR 或 URL_UNREACHABLE 的錯誤。

如要解決這個問題,請根據收到的錯誤訊息,完成下列其中一項檢查:

  • URL_ERROR-ERROR_AUTHENTICATION:傳回 HTTP 401 (Unauthorized) 或 HTTP 407 (Proxy Authentication Required) 錯誤。目的地目標需要驗證,但 Cloud Scheduler 要求不含有效的驗證權杖,例如要求缺少授權標頭或憑證無效。請檢查工作的驗證設定。如果目標端點要求在要求標頭中提供 API 金鑰,請務必確保標頭名稱與目標服務預期的名稱相符,例如 x-api-key 或 X-Goog-Api-Key,而非 api_key。詳情請參閱「向 Cloud Scheduler 進行驗證」和「搭配使用驗證機制與 HTTP 目標」。

  • URL_ERROR-ERROR_DNS:表示網址擷取失敗,因為無法使用網域名稱系統 (DNS) 解析主機名稱,例如主機名稱不存在或沒有相關聯的 IP 位址。錯誤訊息可能包含 Original HTTP response code number = 0 文字。請檢查主機名稱是否有效。叫用私人端點時,請確認 Cloud Scheduler 支援該端點,並檢查其輸入設定。

  • URL_ERROR-ERROR_NOT_FOUND:網路伺服器傳回 HTTP 404 Not Found 錯誤。請檢查目標網址是否正確,以及資源是否存在。

  • URL_ERROR-ERROR_OTHER:這代表先前未詳細說明的通用 HTTP 4xx 錯誤。請查看記錄,擷取原始 HTTP 回應代碼。如果收到 HTTP 403 錯誤,請參閱本文件中的「工作失敗並顯示權限錯誤」一節。

  • URL_UNREACHABLE-UNREACHABLE_5xx:目的地目標傳回 HTTP 5xx 或 429 錯誤。這可能是暫時性狀況,例如伺服器超載。請查看目的地目標的記錄,對問題進行偵錯。

  • URL_UNREACHABLE-UNREACHABLE_CONNECTION_RESET:對等端重設連線。檢查外部伺服器端是否有問題。

  • URL_UNREACHABLE-UNREACHABLE_ERROR:表示發生網路錯誤。請檢查目標網址是否正確,以及是否有任何防火牆規則封鎖存取。

使用安全 perimeter 時不支援的目標

如果 Cloud Scheduler 是 VPC Service Controls perimeter 中的受限服務,嘗試建立或更新目標不受支援的工作時,就會失敗並傳回 TARGET_TYPE_NOT_PERMITTED_FOR_VPC 錯誤代碼。詳情請參閱「使用 VPC Service Controls 保護 Cron 工作」。

工作執行問題

Cloud Scheduler 工作會按照指定的時間或頻率執行。工作執行期間可能會發生下列問題。

先前正常運作的工作停止執行

如果 Cloud Scheduler API 遭到停用,先前成功執行的 Cloud Scheduler 工作就會停止執行,並發生這個問題。您可以查詢稽核記錄,確認 API 停用的時間,查詢條件如下:

resource.type="audited_resource" AND
protoPayload.serviceName="cloudscheduler.googleapis.com" AND
operation.producer="serviceusage.googleapis.com" AND
protoPayload.authorizationInfo.permission="serviceusage.services.disable"

如要解決這個問題,請啟用 Cloud Scheduler API。

後續工作執行作業未啟動

如果工作仍在執行,或正在等待目標的回應,就會發生這個問題。在目前執行作業完成或逾時前,系統會略過其他排定的工作執行作業。

在記錄項目中,找出最新的 type.googleapis.com/google.cloud.scheduler.logging.AttemptStarted 項目和對應的 type.googleapis.com/google.cloud.scheduler.logging.AttemptFinished 項目。如果缺少 AttemptFinished 項目,或該項目在工作下次排定執行後才出現,其他待處理的執行作業就會遭到封鎖,無法啟動。視工作排程而定,這可能會導致多項工作執行作業無法啟動。如要進一步調查,請確認工作目的地目標的逾時時間,以及該目標是否發生任何問題。

請注意,任何時候都只能執行一個工作例項。在極少數情況下,系統可能會要求同一個工作的多個執行個體。因此,要求處理常式應具備冪等性,且程式碼應確保發生這種情況時不會產生有害的副作用。

日光節約時間導致工作執行不規律

使用 Google Cloud 控制台建立 Cloud Scheduler 工作時,必須指定時區。使用 Google Cloud CLI 時,您可以選擇使用 --time-zone 旗標指定時區,否則預設時區為世界標準時間或 UTC。

如果工作設定的時區不是世界標準時間,且因日光節約時間 (DST) 變更而導致執行不規律,就會發生這個問題。這是正常現象。

如果工作需要非常精確的頻率,請選擇不採用日光節約時間的時區。具體來說,為徹底避免這個問題,請將工作排程設為使用世界標準時間時區。

詳情請參閱「Cron 工作格式和時區」。

後續步驟

如果您在 Cloud Scheduler 說明文件中找不到問題的解決方案,請考慮下列選項:

詳情請參閱「Cloud Scheduler 支援」。