Eventarc Standard 的已知問題

本頁列出 Eventarc Standard 的已知問題。

您也可以在公開問題追蹤工具中查看現有問題或開啟新問題。

佈建和時間

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

  • 服務代理程式的佈建：在 Google Cloud 專案中首次建立 Eventarc 觸發條件時，Eventarc 服務代理程式的佈建作業可能會延遲。通常只要再次嘗試建立觸發條件，即可解決這個問題。詳情請參閱「權限遭拒錯誤」。

觸發條件設定

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

  • Compute Engine 的 Cloud Audit Logs 觸發條件：無論虛擬機器執行個體實際位於何處，Compute Engine 的 Cloud Audit Logs 觸發條件都會導致事件源自單一區域：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)

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

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

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

目的地和限制

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

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