Eventarc Standard 的已知問題

Eventarc Standard 目前的服務限制、徵兆和解決方法，可協助您找出並解決作業問題。

您也可以在公開的 Issue Tracker 中查看現有問題或開啟新問題。

佈建和時間

  • 觸發條件部署時間：新建立的觸發條件最多可能需要兩分鐘才會開始運作。

  • 佈建服務代理：首次在 Google Cloud 專案中建立 Eventarc 觸發條件時，佈建 Eventarc 服務代理可能會延遲。這個問題通常可以透過再次建立觸發條件來解決。詳情請參閱「權限遭拒錯誤」。

觸發條件設定

  • 跨專案觸發條件：目前不支援跨專案觸發條件。接收觸發條件事件的服務必須與觸發條件位於同一個Google Cloud 專案。如果服務的要求是由發布至 Pub/Sub 主題的訊息觸發，則該主題也必須與觸發條件位於相同專案。請參閱「跨 Google Cloud 專案傳送事件」。

  • Compute Engine 的 Cloud 稽核記錄觸發條件：無論虛擬機器執行個體實際位於何處，Compute Engine 的 Cloud 稽核記錄觸發條件都會產生來自單一區域的事件：us-central1。建立觸發條件時，請確認觸發條件位置已設為 us-central1 或 global。

  • 多區域位置的 Cloud Storage 觸發條件：如果 Cloud Storage 事件來自 Pub/Sub 訊息儲存政策不允許的區域，且強制執行傳輸中作業 ("enforceInTransit": true)，Cloud Storage 觸發條件可能會失敗。在多區域位置建立 Cloud Storage 觸發條件時，請確保訊息儲存政策允許該多區域內的所有來源區域。這項政策會定義郵件在傳送期間的儲存位置，以及強制執行的傳輸中作業。詳情請參閱「設定訊息儲存政策」。

  • 更新觸發條件：如果在觸發條件產生的事件傳送前更新觸發條件，系統會根據先前的篩選條件轉送事件，並在事件產生後三天內傳送至原始目的地。新篩選條件會套用至更新後產生的事件。

事件酬載和傳送

  • 重複傳輸 Cloud 稽核記錄：已知部分 Google Cloud 事件來源會重複傳輸 Cloud 稽核記錄。發布重複記錄時，系統會將重複事件傳送至目的地。為避免重複事件，請為確保事件不重複的欄位建立觸發條件。這項規定適用於下列事件類型：

    • Cloud Storage (serviceName：storage.googleapis.com)，methodName：storage.buckets.list
    • Compute Engine (serviceName: compute.googleapis.com)，methodName: beta.compute.instances.insert
    • BigQuery (serviceName：bigquery.googleapis.com)

    請注意，由於 Workflows 會處理事件重複資料刪除作業，因此為 Workflows 建立觸發條件時，不必確保事件是唯一的。

  • 處理直接 Pub/Sub 事件的訊息傳送失敗問題：直接 Pub/Sub 事件不包含 delivery_attempt 欄位，除非事件目的地是 Cloud Run 或 Cloud Run 函式。這可能會影響您處理訊息傳送失敗的方式。

  • 事件酬載編碼：對於部分事件供應商，您可以選擇將事件酬載編碼為 application/json 或 application/protobuf。不過，以 JSON 格式設定的事件酬載會比以 Protobuf 格式設定的酬載大，這可能會影響可靠性，具體取決於事件目的地及其事件大小限制。達到這個上限後，系統會根據 Eventarc 傳輸層 (Pub/Sub) 的重試特性重試事件。如果重試次數達到上限，請參閱這篇文章，瞭解如何處理 Pub/Sub 訊息傳送失敗的問題。

目的地和限制

  • 工作流程引數大小：使用 Workflows 做為 Eventarc 觸發條件的目的地時，如果事件大於工作流程引數大小上限，工作流程執行作業就會觸發失敗。詳情請參閱「配額與限制」。

  • 記錄項目的巢狀深度限制：使用 Cloud 稽核記錄的觸發程序，每個結構化記錄項目的巢狀深度上限為 64 層。如果記錄事件超過這個上限，Eventarc 會捨棄這些事件，不會傳送。