Eventarc allows you to build event-driven architectures without having to implement, customize, or maintain the underlying infrastructure. It offers a standardized solution to manage the flow of state changes, called events, between decoupled microservices. Eventarc routes these events to Cloud Run while managing delivery, security, authorization, observability, and error-handling for you.
You can manage Eventarc from the Google Cloud Console (using Cloud Run), from the command line using the Cloud SDK, or using the Eventarc API.
Key use cases
Eventarc supports many use cases for applications running on Cloud Run. Some examples:
|Configure and monitor||
An event is a data record expressing an occurrence and its context. An event is a discrete unit of communication, independent of other events. For example, an event might be a change to data in a database, a file added to a storage system, or a scheduled job.
For a list of the events supported by Eventarc, see Events supported by Eventarc.
Events are routed from an event producer (the source) to interested event consumers. The routing is performed based on information contained in the event, but an event does not identify a specific routing destination. Currently, Eventarc supports events from the following two kinds of sources:
- More than 90 Google Cloud sources. Events from these sources are Cloud Audit Logs entries, and use Events Core and Pub/Sub as the transport layer.
- Custom sources. Events from custom applications use Pub/Sub to send event notification messages.
To determine how best to route events to a Cloud Run service, see Event routing options.
Events are routed to a specific destination (the target) known as the event receiver (or consumer). Currently, Cloud Run is Eventarc's only event receiver. Learn how to build an event receiver service that can be deployed to Cloud Run.
Event format and libraries
Eventarc delivers events, regardless of source, to the target Cloud Run service in a CloudEvents format using an HTTP request in binary content mode. CloudEvents is a specification for describing event metadata in a common way, under the Cloud Native Computing Foundation and organized by the foundation's Serverless Working Group.
Using a standard way to describe event metadata ensures consistency, accessibility, and portability. Event consumers can read these events directly, or you can use Google CloudEvents SDKs and libraries in various languages (including C#, Go, Java, Node.js, and Python) to read and parse the events:
Events occur whether or not you choose to respond to them. You create a response to an event with a trigger. A trigger is a declaration that you are interested in a certain event or set of events, and binding a Cloud Run service to a trigger allows you to capture and act on specific events. For more information, see Creating a trigger and the REST representation of a trigger resource.
Eventarc supports two trigger types:
|Cloud Audit Logs (CAL) events|
|Description||Cloud Audit Logs provide Admin Activity and
Data Access audit logs for each Cloud project, folder, and organization.
Google Cloud services write
entries to these logs. The Cloud Audit Log Catalog
includes a directory of
|Event filter type||Eventarc triggers with
|Cloud Pub/Sub events|
|Description||Eventarc can be triggered by messages published to Pub/Sub topics. Pub/Sub is a globally distributed message bus that automatically scales as you need it. Because Eventarc can be invoked by messages on a Pub/Sub topic, you can easily integrate Eventarc with any other service that supports Pub/Sub as a destination.|
|Event filter type||Eventarc triggers with
Google Cloud services such as Cloud Storage can be set up to be regional or multi-regional. Some services, such as Cloud Build can be set up globally.
Eventarc lets you create regional triggers in eight regions. Eventarc is not available in dual-region and multi-region locations; however, you can create a global trigger (not applicable to Pub/Sub events) and receive events from all regions. For more information, see Eventarc locations.
You should specify the location of the Eventarc trigger to match the location of the Google Cloud service that is generating events and avoid any performance and data residency issues caused by a global trigger.
You can specify trigger locations using a
--location flag with each command.
--destination-run-region flag is not specified, it is assumed that the
service is in the same region as the trigger. For more information, see the
gcloud command-line tool Reference.
Reliability and delivery
Delivery expectations are as follows:
- Events using Cloud Audit Logs are delivered in under a minute.
- Events using Pub/Sub are delivered in seconds.
There is no in-order, first-in-first-out delivery guarantee. Note that having strict ordering would undermine Eventarc's availability and scalability features which match those of its transport layer, Cloud Pub/Sub. For more information, see Ordering messages.
Latency and throughput are best effort. They vary based on multiple factors, including whether the Eventarc trigger is regional, multi-regional, or global; the configuration of a particular service; and the network load on resources in a Google Cloud region.
Note that there are usage quotas and limits that apply to Eventarc when used with Cloud Run.
Event retry policy
Event issuing failures are automatically retried, except for errors that do not warrant retries. This matches the retry characteristics of Eventarc's transport layer, Cloud Pub/Sub. If the Cloud Run service is not acknowledging messages, Pub/Sub retains events for seven days by default and will retry sending events to the target. For more information, see Pub/Sub resource limits.
Detailed logs are available from:
- Cloud Audit Logs, including the Eventarc audit logs
- Cloud Run
- To get started using Eventarc, see the quickstarts or the Codelab.
- To create an event receiver service that can be deployed to Cloud Run, see Developing event receivers.
- To create a trigger, see Creating a trigger.
- To resolve issues that you might encounter when using Eventarc, see Troubleshooting.