本页面列出了 Eventarc 的已知问题。
您还可以在公开问题跟踪器中检查现有问题或添加新问题。
新创建的触发器最多可能需要两分钟才能开始运行。
如果您在传送生成的事件之前更新触发器,
则系统会根据之前的过滤路由事件,并在事件生成后三天内将事件传递到原始目的地。新过滤将应用于更新后生成的事件。 已知某些 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 创建触发器时,您无需确保事件是唯一的。
- Cloud Storage(serviceName:
尚不支持跨项目触发器。接收触发器事件的服务必须与触发器位于同一 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 消息失败。将 Workflows 作为 Eventarc 触发器的目标位置时,大于 Workflows 参数大小上限的事件将无法触发工作流执行。如需了解详情,请参阅配额和限制。
使用 Cloud Audit Logs 的触发器的每个结构化日志条目的最大嵌套深度上限为 64 层。超出此上限的日志事件会被丢弃,且 Eventarc 不会传送这些事件。
首次在 Google Cloud 项目中创建 Eventarc 触发器时,预配 Eventarc 服务代理可能会有延迟。通常,您可以尝试再次创建触发器,以解决此问题。如需了解详情,请参阅权限遭拒错误。