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 über Pub/Sub-Abos 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.

¹ Ereignisse von Google Cloud-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 GKE-Ziele 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.

Gängige Anwendungsfälle

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

Konfigurieren und Monitoring	Systemkonfiguration: Sofort nach dem Start auf einer neuen VM ein Konfigurationsverwaltungstool installieren. 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, sobald 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 90 Google Cloud-Anbieter: Diese Anbieter senden Ereignisse entweder direkt aus der Quelle (z. B. Cloud Storage) oder über Cloud-Audit-Logeinträge.
Pub/Sub-Anbieter: Diese Anbieter senden Ereignisse über Pub/Sub-Nachrichten an Eventarc.

Ereignisziele

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

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 private und öffentliche Cloud Run for Anthos-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 verwenden.

Workflows

Die Ausführung des Workflows wird entweder durch Nachrichten ausgelöst, die in einem Pub/Sub-Thema veröffentlicht werden, wenn ein Audit-Log erstellt wird, das den Filterkriterien des Triggers entspricht, oder als Reaktion auf verschiedene Ereignisse innerhalb eines Cloud Storage-Buckets – Objekte erstellen, löschen, archivieren und Metadaten aktualisieren.

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 zu Dienstkonten 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.

Cloud Run- und GKE-Ziele verwenden Ereignisse im HTTP-Format. Bei Workflow-Zielen konvertiert der Workflows-Dienst das Ereignis jedoch in ein JSON-Objekt (gemäß der JSON CloudEvents-Spezifikation) und übergibt das Ereignis an die Workflowausführung. als Laufzeitargument.

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:

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 Trigger erstellen.

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

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.
Cloud Pub/Sub-Ereignisse
Beschreibung	Eventarc kann 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 problemlos in jeden anderen Dienst einbinden, der Pub/Sub als Ziel unterstützt.
Ereignisfiltertyp	Eventarc löst mit `type=google.cloud.pubsub.topic.v1.messagePublished` Anfragen an Ihren Dienst oder Workflow aus, wenn eine Nachricht im angegebenen Pub/Sub-Thema veröffentlicht wird.
Direkte Ereignisse
Beschreibung	Eventarc kann durch verschiedene direkte Ereignisse ausgelöst werden, z. B. eine Aktualisierung in einem Cloud Storage-Bucket oder eine Aktualisierung auf eine Firebase Remote Config-Vorlage.
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`.

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 das Flag --destination-run-region nicht 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.
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. Die Standardeinstellung für Wiederholungsversuche 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 "Triggerdetails", klicken Sie auf das Thema und dann auf den Tab Abos. Alle von Eventarc automatisch erstellten Abos haben folgendes Format: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID.

Wenn Pub/Sub eine Nachricht zustellen soll, das Ziel sie jedoch nicht bestätigen kann, versucht Pub/Sub sofort, die Nachricht noch einmal zu senden. Wenn sich die Bedingungen des Ziels, die die Nachrichtenbestätigung verhindert haben, nicht geändert haben, wird die Nachricht kontinuierlich noch einmal zugestellt, aber nicht am Ziel empfangen. Zur Behebung dieses Problems können Sie eine Pub/Sub-Abo-Wiederholungsrichtlinie einrichten oder nicht zugestellte Nachrichten an ein Thema für unzustellbare Nachrichten weiterleiten. Dies wird auch als Warteschlange für unzustellbare Nachrichten bezeichnet. Weitere Informationen finden Sie unter Umgang mit Nachrichtenfehlern. Wenn der Zieldienst beispielsweise Nachrichten nicht bestätigt, speichert Pub/Sub Ereignisse standardmäßig sieben Tage lang und sendet noch einmal Ereignisse an das Ziel. Weitere Informationen finden Sie unter Pub/Sub-Ressourcenlimits.

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. Beachten Sie, dass Workflows Ereignisse bestätigen, sobald die Workflowausführung beginnt. 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.

Beobachtbarkeit

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

Nächste Schritte

Erste Schritte mit Eventarc finden Sie in den Kurzanleitungen und im Codelab.
Erstellen Sie einen Cloud Run-Trigger, einen GKE-Trigger oder einen Workflow-Trigger.
Fehlerbehebung