Eventarc の既知の問題

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

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

  • 新しく作成されたトリガーが機能するまでに最大で 2 分かかります。

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

  • 一部の 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 のトリガーを作成するときにイベントが一意であることを確認する必要はありません。

  • プロジェクト間トリガーはまだサポートされていません。トリガーのイベントを受信するサービスは、トリガーと同じ Google Cloud プロジェクトに存在する必要があります。Pub/Sub トピックに公開されたメッセージによってサービスへのリクエストがトリガーされる場合は、そのトピックもトリガーと同じプロジェクトに存在する必要があります。Google Cloud プロジェクト間でのイベントのルーティングをご覧ください。

  • 仮想マシン インスタンスの実際の場所に関係なく、Compute Engine の Cloud Audit Logs のトリガーは、単一のリージョン us-central1 からのイベントになります。トリガーを作成する場合は、トリガーのロケーションが us-central1 または global に設定されていることを確認します。

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

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

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

  • Google Cloud プロジェクトで Eventarc トリガーを初めて作成するときに、Eventarc サービス エージェントのプロビジョニングに遅延が発生することがあります。この問題は通常、トリガーを再度作成することで解決できます。詳細については、権限拒否エラーをご覧ください。