Eventarc-Übersicht

Mit Eventarc können Sie ereignisgesteuerte Architekturen erstellen, ohne die zugrunde liegende Infrastruktur implementieren, anpassen oder verwalten zu müssen. Es bietet eine standardisierte Lösung, um den Ablauf der Statusänderungen, die sogenannten Ereignisse, zwischen entkoppelten Mikrodiensten zu verwalten. Eventarc leitet diese Ereignisse bei Auslösung an verschiedene Ziele weiter (in diesem Dokument finden Sie weitere Informationen unter Ereignisziele) und verwaltet dabei die Bereitstellung, Sicherheit, Autorisierung, Beobachtbarkeit und Fehlerbehandlung.

Sie können Eventarc über die Google Cloud Console, über die Befehlszeile mit der glcoud CLI oder über die Eventarc API verwalten.

Eventarc entspricht diesen Zertifizierungen und Standards.

Eventarc leitet Ereignisse von Ereignisanbietern an Ereignisziele weiter. — **Abbildung 1.** Eventarc leitet Ereignisse von Ereignisanbietern an Ereignisziele weiter (zum Vergrößern auf das Diagramm klicken).

¹ Ereignisse von Google-Anbietern werden entweder direkt aus der Quelle (z. B. Cloud Storage) oder über Cloud-Audit-Logeinträge gesendet und verwenden Pub/Sub als Transportebene. Ereignisse aus Pub/Sub-Quellen können ein vorhandenes Pub/Sub-Thema verwenden oder Eventarc erstellt automatisch ein Thema und verwaltet es für Sie.

² Ereignisse für Google Kubernetes Engine-Ziele (GKE), einschließlich Knative-Bereitstellungsdienste, die in einem GKE-Cluster ausgeführt werden, verwenden die Ereignisweiterleitung von Eventarc, um neue Ereignisse aus Pub/Sub abzurufen und an das Ziel weiterzuleiten. Diese Komponente fungiert als Vermittler zwischen der Pub/Sub-Transportebene und dem Zieldienst. Es funktioniert mit vorhandenen Diensten und unterstützt auch Signalisierungsdienste (einschließlich Dienste, die nicht außerhalb des vollständig verwalteten Clusters verfügbar sind), während die Einrichtung und Wartung vereinfacht wird. Der Lebenszyklus des Ereignis-Forwarders wird von Eventarc verwaltet. Wenn Sie den Ereignis-Forwarder versehentlich löschen, wird diese Komponente von Eventarc wiederhergestellt.

³ Ereignisse für eine Workflowausführung werden transformiert und als Laufzeitargumente an den Workflow übergeben. Workflows können Google Cloud- und HTTP-basierte API-Dienste in einer von Ihnen definierten Reihenfolge kombinieren und orchestrieren.

⁴ Alle ereignisgesteuerten Funktionen in Cloud Functions (2. Generation) verwenden Eventarc-Trigger, um Ereignisse bereitzustellen. Sie können Eventarc-Trigger konfigurieren, wenn Sie eine Cloud Functions-Funktion über die Cloud Functions-Oberfläche bereitstellen.

Gängige Anwendungsfälle

Eventarc unterstützt viele Anwendungsfälle für Zielanwendungen. Dazu einige Beispiele:

Konfigurieren und Monitoring	Systemkonfiguration: Installieren Sie ein Konfigurationsverwaltungstool auf einer neuen VM, wenn sie gestartet wird. Automatisierte Korrektur: Erkennen, wenn ein Dienst nicht richtig reagiert, und ihn automatisch neustarten. Warnungen und Benachrichtigungen: Guthaben einer Kryptowährung-Wallet-Adresse überwachen und Benachrichtigungen auslösen.
Optimieren	Verzeichnisregistrierungen: Mitarbeiterlogo aktivieren, wenn ein neuer Mitarbeiter einem Unternehmen beitritt. Datensynchronisierung: Einen Abrechnungsworkflow auslösen, wenn ein Kunde in einem CRM-System konvertiert wird. Ressourcen-Labeling: Den Ersteller einer VM mit einem Label versehen, wenn die VM erstellt wird.
Analysieren	Sentimentanalyse: Die Cloud Natural Language API verwenden, um ein ML-Modell zu trainieren und bereitzustellen, das nach Abschluss eines Service-Tickets einen Zufriedenheitswert angibt. Retusche und Analyse von Bildern: Der Hintergrund wird entfernt und Bilder werden automatisch kategorisiert, wenn sie von einem Einzelhändler zu einem Objektspeicher hinzugefügt werden.

Ereignisse

Ein Ereignis ist ein Datensatz, der ein Vorkommen und seinen Kontext wiedergibt. Ein Ereignis ist eine von allen anderen Ereignissen unabhängige Kommunikationseinheit. Ein Ereignis kann z. B. eine Änderung von Daten in einer Datenbank, eine zu einem Speichersystem hinzugefügte Datei oder ein geplanter Auftrag sein.

Siehe Von Eventarc unterstützte Ereignistypen.

Ereignisanbieter

Ereignisse werden von einem Ereignisersteller (der Quelle) an interessierte Ereignisnutzer weitergeleitet. Das Routing wird auf der Grundlage der im Ereignis enthaltenen Informationen durchgeführt, aber ein Ereignis identifiziert kein bestimmtes Routing-Ziel. Derzeit unterstützt Eventarc Ereignisse aus den folgenden Quellen:

Mehr als 130 Google Cloud-Anbieter: Diese Anbieter senden Ereignisse (z. B. eine Aktualisierung eines Objekts in einem Cloud Storage-Bucket oder eine in einem Pub/Sub-Thema veröffentlichte Nachricht) direkt aus der Quelle oder über Cloud-Audit-Logeinträge.
Drittanbieter. Diese Anbieter senden Ereignisse direkt aus der Quelle (z. B. SaaS-Drittanbieter wie Datadog oder die Check Point CloudGuard-Plattform).

Ereignisziele

Ereignisse werden über ein Pub/Sub-Push-Abo an ein bestimmtes Ziel weitergeleitet, das als Ereignisempfänger (oder Nutzer) bezeichnet wird.

Cloud Functions (2nd gen)

Alle ereignisgesteuerten Funktionen in Cloud Functions (2. Generation) verwenden Eventarc-Trigger, um Ereignisse bereitzustellen. Ein Eventarc-Trigger ermöglicht die Auslösung einer Funktion durch jeden von Eventarc unterstützten Ereignistyp. Sie können Eventarc-Trigger konfigurieren, wenn Sie eine Cloud Functions-Funktion über die Cloud Functions-Oberfläche bereitstellen.

Cloud Run

Erfahren Sie, wie Sie einen Ereignisempfängerdienst erstellen, der in Cloud Run bereitgestellt werden kann.

Informationen zum Weiterleiten von Ereignissen an einen Cloud Run-Dienst finden Sie unter Optionen für die Ereignisweiterleitung.

GKE

Eventarc unterstützt das Erstellen von Triggern für GKE-Dienste (Google Kubernetes Engine). Dies schließt die öffentlichen Endpunkte privater und öffentlicher Dienste ein, die in einem GKE-Cluster ausgeführt werden.

Damit Eventarc Dienste in einem bestimmten Cluster als Ziel verwenden und verwalten kann, müssen Sie dem Eventarc-Dienstkonto alle erforderlichen Berechtigungen erteilen.
Sie müssen Workload Identity in dem GKE-Cluster aktivieren, in dem der Zieldienst ausgeführt wird. Workload Identity ist für die ordnungsgemäße Einrichtung der Ereignisweiterleitung erforderlich und wird empfohlen, um aus den in GKE ausgeführten Anwendungen aufgrund seiner verbesserten Sicherheitseigenschaften und -verwaltung auf Google Cloud-Dienste zuzugreifen. Weitere Informationen finden Sie unter Workload Identity aktivieren.

Interne HTTP-Endpunkte in einem VPC-Netzwerk

Sie können das Ereignisrouting für einen internen HTTP-Endpunkt in einem VPC-Netzwerk (Virtual Private Cloud) konfigurieren. Zum Konfigurieren des Triggers müssen Sie auch eine ID des Netzwerkanhangs angeben. Weitere Informationen finden Sie unter Ereignisse an einen internen HTTP-Endpunkt in einem VPC-Netzwerk weiterleiten.

Workflows

Die Ausführung Ihres Workflows wird anhand der folgenden Situationen ausgelöst:

Wenn Nachrichten in einem Pub/Sub-Thema veröffentlicht werden
Wenn ein Audit-Log erstellt wird, das den Filterkriterien des Triggers entspricht
Als Reaktion auf ein unmittelbares Ereignis, z. B. die Aktualisierung eines Objekts in einem Cloud Storage-Bucket

Für Workflows ist eine IAM-Dienstkonto-E-Mail-Adresse erforderlich, mit der Ihr Eventarc-Trigger die Workflowausführungen aufruft. Es wird empfohlen, ein Dienstkonto mit den geringsten Berechtigungen zu verwenden, die für den Zugriff auf die erforderlichen Ressourcen erforderlich sind. Weitere Informationen finden Sie unter Dienstkonten erstellen und verwalten.

Ereignisformat und Bibliotheken

Eventarc liefert unabhängig von der Quelle Ereignisse an das Ziel in einem CloudEvents-Format mithilfe einer HTTP-Anfrage im Binärinhaltsmodus. CloudEvents ist eine Spezifikation für die allgemeine Beschreibung von Ereignis-Metadaten, die der Cloud Native Computing Foundation untersteht und von der Serverless Working Group der Foundation organisiert wird.

Je nach Ereignisanbieter können Sie die Codierung der Ereignisnutzlastdaten als application/json oder application/protobuf angeben. Protocol Buffers (oder Protobuf) ist ein sprach- und plattformneutraler erweiterbarer Mechanismus zum Serialisieren von strukturierten Daten. Wichtige Hinweise:

Für benutzerdefinierte Quellen oder Drittanbieter oder für direkte Ereignisse aus Pub/Sub wird diese Formatierungsoption nicht unterstützt.
Eine im JSON-Format formatierte Ereignisnutzlast ist größer als eine in Protobuf formatierte. Dies kann sich je nach Ereignisziel und seine Limits für die Ereignisgröße auf die Zuverlässigkeit auswirken. Weitere Informationen finden Sie unter Bekannte Probleme.

Ziele wie Cloud Functions, Cloud Run und GKE verwenden Ereignisse im HTTP-Format. Bei Workflows-Zielen konvertiert der Workflows-Dienst das Ereignis in ein JSON-Objekt und übergibt das Ereignis als Laufzeitargument an die Workflowausführung.

Die Verwendung einer Standardmethode zum Beschreiben von Ereignismetadaten sorgt für Konsistenz, Barrierefreiheit und Übertragbarkeit. Ereignisnutzer können diese Ereignisse direkt lesen, oder Sie können Google CloudEvents SDKs und Bibliotheken in verschiedenen Sprachen (einschließlich C#, Go, Java, Node.js und Python) verwenden, um die Ereignisse zu lesen und zu analysieren:

Eventarc liefert Ereignisse in einem CloudEvents-Format. Sie können Ereignisse direkt lesen oder die Ereignisse mithilfe von Google CloudEvents SDKs oder Bibliotheken parsen. — **Abbildung 2.** Eventarc liefert Ereignisse in einem CloudEvents-Format an Ereignisziele. Sie können diese Ereignisse direkt lesen oder die Ereignisse mit Google CloudEvents SDKs oder Bibliotheken lesen und parsen.

Die Struktur des HTTP-Texts für alle Ereignisse ist im GitHub-Repository von Google CloudEvents verfügbar.

Abwärtskompatibilität

Eventarc berücksichtigt das Hinzufügen der folgenden Attribute und Felder abwärtskompatibel:

Optionale Filterattribute oder reine Ausgabeattribute
Optionale Felder für die Ereignisnutzlast

Eventarc-Trigger

Ereignisse geschehen, ob ein Ziel auf sie reagiert oder nicht. Mit einem Trigger können Sie eine Reaktion auf ein Ereignis erstellen. Sie geben damit an, dass Sie an einem bestimmten Ereignis oder an einer Reihe von Ereignissen interessiert sind. Wenn Sie einen Trigger erstellen, geben Sie Filter für den Trigger an, mit denen Sie diese spezifischen Ereignisse erfassen und darauf reagieren können, einschließlich ihres Routings von einer Ereignisquelle zu einem Ziel. Weitere Informationen finden Sie in der REST-Darstellung einer Triggerressource und unter Ereignisanbieter und -ziele.

Beachten Sie, dass für Eventarc erstellte Pub/Sub-Abos unabhängig von der Aktivität bestehen bleiben und nicht ablaufen. Informationen zum Ändern der Abo-Attribute finden Sie unter Abo-Attribute.

Eventarc unterstützt Trigger für diese Ereignistypen:

CAL-Ereignisse (Cloud-Audit-Logs)
Beschreibung	Cloud-Audit-Logs bieten Audit-Logs für Admin-Aktivitäten und Audit-Logs zum Datenzugriff für jedes Cloud-Projekt, jeden Ordner und jede Organisation. Google Cloud-Dienste schreiben Einträge in diese Logs. Diese Liste der unterstützten Ereignisse enthält ein Verzeichnis mit den Werten `serviceName` und `methodName`.
Ereignisfiltertyp	Eventarc-Trigger mit `type=google.cloud.audit.log.v1.written` senden Anfragen an Ihren Dienst oder Workflow, wenn ein Audit-Log erstellt wird, das den Filterkriterien des Triggers entspricht.
Direkte Ereignisse
Beschreibung	Eventarc kann durch verschiedene direkte Ereignisse ausgelöst werden, z. B. eine Aktualisierung in einem Cloud Storage-Bucket, eine Aktualisierung einer Firebase Remote Config-Vorlage oder Änderungen an Ressourcen in Google Cloud-Diensten. Eventarc kann auch durch Nachrichten ausgelöst werden, die in Pub/Sub-Themen veröffentlicht wurden. Pub/Sub ist ein global verteilter Nachrichtenbus, der automatisch nach Bedarf skaliert wird. Da Eventarc von Nachrichten in einem Pub/Sub-Thema aufgerufen werden kann, können Sie Eventarc in jeden anderen Dienst einbinden, der Pub/Sub als Ziel unterstützt.
Ereignisfiltertyp	Eventarc-Trigger mit bestimmten Ereignisfiltertypen senden Anfragen an Ihren Dienst oder Workflow, wenn ein Ereignis eintritt, das den Filterkriterien des Triggers entspricht. Beispiel: `type=google.cloud.storage.object.v1.finalized` (wenn ein Objekt in einem Cloud Storage-Bucket erstellt wird) oder `type=google.cloud.pubsub.topic.v1.messagePublished` (wenn eine Nachricht im angegebenen Pub/Sub-Thema veröffentlicht wird).

Triggerstandort

Google Cloud-Dienste wie Cloud Storage können als regional oder multiregional eingerichtet werden. Einige Dienste wie Cloud Build können global eingerichtet werden.

Mit Eventarc können Sie regionale Trigger erstellen. Für einige Ereignisse können Sie auch einen globalen Trigger erstellen und Ereignisse aus allen Regionen empfangen. Weitere Informationen finden Sie unter Informationen zu Eventarc-Standorten.

Sie sollten den Speicherort des Eventarc-Triggers so festlegen, dass er mit dem Speicherort des Google Cloud-Dienstes übereinstimmt, der die Ereignisse generiert, um Probleme mit der Leistung und dem Datenstandort zu vermeiden, die durch einen globalen Trigger verursacht werden.

Mit dem Flag --location für jeden Befehl können Sie Triggerstandorte angeben. Wenn für Cloud Run-Ziele kein --destination-run-region-Flag angegeben ist, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet. Weitere Informationen finden Sie in der Referenz zur Google Cloud CLI.

Zuverlässigkeit und Bereitstellung

Die Erwartungen an die Bereitstellung sind:

Ereignisse, die Cloud-Audit-Logs verwenden, werden in weniger als einer Minute bereitgestellt. (Beachten Sie, dass es, obwohl ein Cloud-Audit-Log-Trigger sofort erstellt wird, bis zu zwei Minuten dauern kann, bis der Trigger weitergegeben wird und Ereignisse filtert.)
Ereignisse, die Pub/Sub verwenden, werden in Sekunden bereitgestellt.

Es gibt keine garantierte Reihenfolge der Bereitstellung, etwa nach dem Prinzip "First-in-First-out". Beachten Sie, dass eine strikte Reihenfolge die Verfügbarkeits- und Skalierbarkeitsfunktionen von Eventarc beeinträchtigen würde, die mit denen der Transportebene Cloud Pub/Sub übereinstimmen. Weitere Informationen finden Sie unter Nachrichten sortieren.

Latenz und Durchsatz sind Best-Effort. Sie variieren auf Basis verschiedener Faktoren: ob der Eventarc-Trigger regional, multiregional oder global ist; der Konfiguration eines bestimmten Dienstes und der Netzwerkauslastung von Ressourcen in einer Google Cloud-Region.

Es gibt Nutzungskontingente und -limits, die im Allgemeinen für Eventarc gelten. Für Workflows gibt es außerdem Nutzungskontingente und -limits.

Richtlinie für Ereigniswiederholung

Die Wiederholungsmerkmale von Eventarc entsprechen denen der Transportebene, Cloud Pub/Sub. Weitere Informationen finden Sie unter Anfragen wiederholen und Push-Backoff.

Die von Eventarc festgelegte Standardaufbewahrungsdauer für Nachrichten beträgt 24 Stunden mit einer exponentiellen Backoff-Verzögerung.

Sie können die Wiederholungsrichtlinie über das Pub/Sub-Abo aktualisieren, das dem Eventarc-Trigger zugeordnet ist:

Öffnen Sie die Seite "Trigger-Details".
Klicken Sie auf das Thema.
Klicken Sie auf den Tab Abos.

Alle von Eventarc automatisch erstellten Abos haben folgendes Format: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Weitere Informationen zu Abolimits finden Sie unter Pub/Sub-Ressourcenlimits.

Wenn Pub/Sub eine Nachricht zustellen soll, das Ziel sie jedoch nicht bestätigen kann, sendet Pub/Sub die Nachricht noch einmal mit einem minimalen exponentiellen Backoff von zehn Sekunden. Wenn das Ziel die Nachricht weiterhin nicht bestätigt, wird der Verzögerung bei jedem Wiederholungsversuch (bis zu einem Maximum von 600 Sekunden) mehr Zeit hinzugefügt und die Nachricht wird noch einmal an das Ziel gesendet.

Beachten Sie, dass Workflows Ereignisse bestätigt, sobald die Workflowausführung beginnt.

Themen für unzustellbare Nachrichten

Wenn das Ziel die Nachricht nicht empfängt, können Sie nicht zugestellte Nachrichten an ein Thema für unzustellbare Nachrichten weiterleiten (auch als Dead-Letter-Warteschlange bezeichnet). In einem Thema für unzustellbare Nachrichten können Nachrichten gespeichert werden, die vom Ziel nicht bestätigt werden können. Sie müssen ein Thema für unzustellbare Nachrichten festlegen, wenn Sie ein Pub/Sub-Abo erstellen oder aktualisieren, und nicht, wenn Sie ein Pub/Sub-Thema erstellen oder wenn Eventarc ein Pub/Sub-Thema erstellt. Weitere Informationen finden Sie unter Umgang mit Nachrichtenfehlern.

Fehler, die keine Wiederholungen rechtfertigen

Wenn Anwendungen Pub/Sub als Ereignisquelle verwenden und das Ereignis nicht zugestellt wird, wird das Ereignis automatisch wiederholt, außer bei Fehlern, die keine Wiederholungen rechtfertigen. Ereignisse für das Workflowziel von einer beliebigen Quelle werden nicht wiederholt, wenn der Workflow nicht ausgeführt wird. Wenn die Workflowausführung beginnt, aber später fehlschlägt, werden die Ausführungen nicht wiederholt. Zum Beheben dieser Dienstprobleme sollten Sie Fehler und Wiederholungsversuche innerhalb des Workflows beheben.

Duplizierte Termine

Ereignis-Duplikate werden möglicherweise an Event-Handler gesendet. Gemäß der CloudEvents-Spezifikation wird die Kombination der Attribute source und id als eindeutig angesehen und daher werden alle Ereignisse mit derselben Kombination als Duplikate betrachtet. Implementieren Sie idempotente Event-Handler als allgemeine Best Practice.

Beobachtbarkeit

Detaillierte Logs für Eventarc, Cloud Run, GKE, Pub/Sub und Workflows sind in Cloud-Audit-Logs verfügbar.

Notfallwiederherstellung

Sie können Zonen und Regionen nutzen, um im Falle von Ausfällen Zuverlässigkeit zu ermöglichen. Weitere Informationen zur Sicherstellung, dass RTO-Ziele (Recovery Time Objective) und RPO-Ziele (Recovery Point Objective) für Sicherungs- und Wiederherstellungszeiten bei der Verwendung von Eventarc erfüllt werden, finden Sie unter Architektur der Notfallwiederherstellung für Ausfälle der Cloud-Infrastruktur entwickeln.