Eventarc Standard の既知の問題

このページには、Eventarc Standard の既知の問題が記載されています。

また、公開 Issue Tracker で既存の問題の確認や、新しい問題の報告を行うことができます。

プロビジョニングとタイミング

  • トリガーのデプロイ時間: 新しく作成されたトリガーが機能するまでに最大で 2 分かかります。

  • サービス エージェントのプロビジョニング: 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 トリガーを作成する場合は、メッセージ ストレージ ポリシーでそのマルチリージョン内のすべてのソースリージョンが許可されていることを確認してください。このポリシーは、配信中にメッセージが保存される場所と、転送中のオペレーションが適用される場所を定義します。詳細については、メッセージ ストレージ ポリシーを構成するをご覧ください。

  • トリガーの更新: 生成されたイベントが配信される前にトリガーを更新すると、イベントは前のフィルタリングに従ってルーティングされ、イベントの生成から 3 日以内に元の宛先に配信されます。新しいフィルタリングは、更新後に生成されたイベントに適用されます。

イベント ペイロードと配信

  • Cloud Audit Logs の重複送信: 一部の Google Cloud イベントソースから Cloud Audit Logs が重複して送信されることが確認されています。重複するログが公開されると、重複したイベントが宛先に配信されます。このような重複イベントの発生を防ぐには、イベントが一意になるようにフィールドにトリガーを作成する必要があります。これは、次のイベントタイプに適用されます。

    • 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 イベントのメッセージ エラーの処理: イベントの宛先が Cloud Run または Cloud Run functions でない限り、直接 Pub/Sub イベントには delivery_attempt フィールドは含まれません。これは、メッセージ エラーの処理に影響する可能性があります。

  • イベント ペイロードのエンコード: 一部のイベント プロバイダでは、イベント ペイロードを application/json または application/protobuf としてエンコードできます。ただし、JSON 形式のイベント ペイロードは Protobuf 形式のイベントよりも大きく、イベントの宛先とイベントサイズの制限によっては信頼性に影響する可能性があります。この上限に達すると、Eventarc のトランスポート レイヤである Pub/Sub の再試行特性に従ってイベントが再試行されます。最大再試行回数に達した場合の Pub/Sub メッセージ エラーの処理方法を確認してください。

宛先と上限

  • Workflows の引数サイズ: Eventarc トリガーの宛先として Workflows を使用している場合、Workflows の最大引数サイズを超えるイベントは、ワークフローの実行をトリガーできません。詳細については、割り当てと上限をご覧ください。

  • ログエントリのネストの深さの上限: Cloud Audit Logs を使用するトリガーの各構造化ログエントリに対するネストの深さの上限は 64 レベルです。この上限を超えるログイベントは破棄され、Eventarc によって配信されません。