Panoramica di Eventarc

Eventarc consente di creare architetture basate su eventi senza dover implementare, personalizzare o gestire l'infrastruttura sottostante. Eventarc offre una soluzione standardizzata per gestire il flusso di modifiche di stato, chiamate eventi, tra microservizi disaccoppiati. Quando viene attivato, Eventarc indirizza questi eventi a varie destinazioni (in questo documento, vedi Destinazioni eventi), gestendo per te la distribuzione, la sicurezza, l'autorizzazione, l'osservabilità e la gestione degli errori.

Puoi gestire Eventarc dalla console Google Cloud, dalla riga di comando utilizzando gcloud CLI o dall'API Eventarc.

Eventarc è conforme a queste certificazioni e standard.

¹ Gli eventi dei provider Google vengono inviati direttamente dall'origine (ad esempio Cloud Storage) o tramite le voci di Cloud Audit Logs e utilizzano Pub/Sub come livello di trasporto. Gli eventi provenienti da origini Pub/Sub possono utilizzare un argomento Pub/Sub esistente oppure Eventarc creerà automaticamente un argomento e lo gestirà per te.

² Gli eventi per le destinazioni Google Kubernetes Engine (GKE), inclusi i servizi Cloud Run for Anthos (CRfA) in esecuzione su un cluster GKE, utilizzano il forwarding di eventi di Eventarc per estrarre nuovi eventi da Pub/Sub e inoltrarli alla destinazione. Questo componente agisce da mediatore tra il livello di trasporto Pub/Sub e il servizio di destinazione. Funziona sui servizi esistenti e supporta anche i servizi di segnalazione (inclusi quelli non esposti al di fuori del cluster completamente gestito) semplificando la configurazione e la manutenzione. Tieni presente che il ciclo di vita del forwarding di eventi è gestito da Eventarc e, se lo elimini accidentalmente, Eventarc ripristinerà questo componente.

³ Gli eventi relativi all'esecuzione di un flusso di lavoro vengono trasformati e passati al flusso di lavoro come argomenti di runtime. Workflows possono combinare e orchestrare Google Cloud e i servizi API basati su HTTP in un ordine definito da te.

Casi d'uso principali

Eventarc supporta molti casi d'uso per le applicazioni di destinazione. Ecco alcuni esempi:

Configura e monitora	Configurazione del sistema: installa uno strumento di gestione della configurazione su una nuova VM all'avvio. Correzione automatica: per rilevare se un servizio non risponde correttamente e riavviarlo automaticamente. Avvisi e notifiche: monitora il saldo di un indirizzo di un portafoglio di criptovalute e attiva notifiche.
Armonizza	Registrazioni directory: attiva un badge dei dipendenti quando un nuovo dipendente si iscrive a un'azienda. Sincronizzazione dei dati: attiva un flusso di lavoro di contabilità quando un potenziale cliente viene convertito in un sistema CRM. Etichettatura delle risorse: etichetta e identifica l'autore di una VM al momento della sua creazione.
Analisi	Analisi del sentiment: utilizza l'API Cloud Natural Language per addestrare ed eseguire il deployment di un modello ML che associa un punteggio di soddisfazione a un ticket di assistenza clienti al termine. Ritocco e analisi delle immagini: rimuovi lo sfondo e classifica automaticamente un'immagine quando un rivenditore la aggiunge a un negozio di oggetti.

Eventi

Un evento è un record di dati che esprime un'occorrenza e il relativo contesto. Un evento è un'unità discreta di comunicazione, indipendente dagli altri eventi. Ad esempio, un evento potrebbe essere una modifica ai dati in un database, un file aggiunto a un sistema di archiviazione o un job pianificato.

Vedi Tipi di eventi supportati da Eventarc.

Provider di eventi

Gli eventi vengono instradati da un provider di eventi (la sorgente) a consumatori di eventi interessati. Il routing viene eseguito in base alle informazioni contenute nell'evento, ma quest'ultimo non identifica una destinazione di routing specifica. Attualmente, Eventarc supporta gli eventi dei seguenti provider:

Più di 130 provider Google Cloud. Questi provider inviano eventi (ad esempio, un aggiornamento di un oggetto in un bucket Cloud Storage o un messaggio pubblicato in un argomento Pub/Sub) direttamente dall'origine o tramite voci di Cloud Audit Logs.
Fornitori di terze parti. Questi provider inviano gli eventi direttamente dall'origine (ad esempio, provider SaaS di terze parti come Datadog o la piattaforma CheckPoint CloudGuard).

Destinazioni eventi

Gli eventi vengono instradati a una destinazione specifica (la destinazione) nota come ricevitore (o consumer) di eventi tramite le sottoscrizioni push Pub/Sub.

Cloud Functions (2nd gen)

Tutte le funzioni basate su eventi in Cloud Functions (2nd gen) utilizzano i trigger Eventarc per la distribuzione di eventi. Un trigger Eventarc consente di attivare una funzione da qualsiasi tipo di evento supportato da Eventarc. Puoi configurare i trigger Eventarc quando esegui il deployment di una Cloud Function utilizzando l'interfaccia Cloud Functions.

Cloud Run

Scopri come creare un servizio di ricezione di eventi di cui eseguire il deployment in Cloud Run.

Per determinare il modo migliore per instradare gli eventi a un servizio Cloud Run, consulta Opzioni di routing degli eventi.

GKE

Eventarc supporta la creazione di trigger che hanno come target i servizi Google Kubernetes Engine (GKE). Questo include gli endpoint pubblici dei servizi privati e pubblici in esecuzione in un cluster GKE.

Affinché Eventarc possa scegliere come target e gestire i servizi in un dato cluster, devi concedere all'account di servizio Eventarc le tutte le autorizzazioni necessarie.
Devi abilitare Workload Identity sul cluster GKE su cui è in esecuzione il servizio di destinazione. Workload Identity è necessario per configurare correttamente il forwarding di eventi ed è il modo consigliato per accedere ai servizi Google Cloud dalle applicazioni in esecuzione all'interno di GKE, grazie alle sue proprietà di sicurezza e alla sua gestibilità migliorate. Per ulteriori informazioni, consulta Utilizzo di Workload Identity.

Workflows

L'esecuzione del flusso di lavoro viene attivata dai messaggi pubblicati in un argomento Pub/Sub, quando viene creato un audit log che corrisponde ai criteri di filtro dell'attivatore o in risposta a vari eventi all'interno di un bucket Cloud Storage, ovvero creazione, eliminazione, archiviazione di oggetti e aggiornamenti dei metadati.

Workflows richiede un indirizzo email dell'account di servizio IAM che il trigger Eventarc utilizzerà per richiamare le esecuzioni del flusso di lavoro. Ti consigliamo di utilizzare un account di servizio con i privilegi minimi necessari per accedere alle risorse richieste. Per scoprire di più sugli account di servizio, vedi Creare e gestire gli account di servizio.

Formato degli eventi e librerie

Eventarc invia gli eventi, indipendentemente dal provider, nella destinazione di destinazione in un formato CloudEvents utilizzando una richiesta HTTP in modalità di contenuto binario. CloudEvents è una specifica per descrivere i metadati degli eventi in modo comune, nell'ambito della Cloud Native Computing Foundation e organizzata dal Serverless Working Group della fondazione.

A seconda del provider di eventi, puoi specificare la codifica dei dati del payload dell'evento come application/json o application/protobuf. I buffer di protocollo (o Protobuf) sono un meccanismo estensibile basato sul linguaggio e sulla piattaforma per la serie dei dati strutturati. Tieni presente quanto segue:

Per le origini personalizzate o i provider di terze parti o per gli eventi diretti di Pub/Sub, questa opzione di formattazione non è supportata.
Un payload di eventi in formato JSON ha dimensioni maggiori di uno in Protobuf e questo potrebbe influire sull'affidabilità a seconda della destinazione dell'evento e dei suoi limiti per le dimensioni degli eventi. Per ulteriori informazioni, consulta la pagina Problemi noti.

Destinazioni di destinazione come Cloud Functions, Cloud Run e GKE consumano eventi nel formato HTTP. Per le destinazioni di Workflows, il servizio Workflows converte l'evento in un oggetto JSON e lo passa all'esecuzione del flusso di lavoro come argomento di runtime.

L'utilizzo di un metodo standard per descrivere i metadati degli eventi garantisce coerenza, accessibilità e portabilità. I consumer di eventi possono leggere direttamente questi eventi oppure puoi utilizzare gli SDK e le librerie Google CloudEvents in vari linguaggi (tra cui C#, Go, Java, Node.js e Python) per leggere e analizzare gli eventi:

La struttura del corpo HTTP per tutti gli eventi è disponibile nel repository GitHub di Google CloudEvents.

Compatibilità con le versioni precedenti

Eventarc considera l'aggiunta dei seguenti attributi e campi compatibili con le versioni precedenti:

Attributi di filtro facoltativi o attributi solo di output
Campi facoltativi per il payload dell'evento

Trigger Eventarc

Gli eventi si verificano indipendentemente dal fatto che una destinazione target reagisca o meno a questi eventi. Puoi creare una risposta a un evento con un trigger. Un attivatore è una dichiarazione secondo cui sei interessato a un determinato evento o insieme di eventi. Quando crei un trigger, devi specificare filtri che ti consentono di acquisire questi eventi specifici e intervenire su questi eventi, incluso il routing da un'origine evento a una destinazione. Per ulteriori informazioni, consulta la sezione Rappresentazione REST di una risorsa trigger e Fornitori e destinazioni di eventi.

Tieni presente che le sottoscrizioni Pub/Sub create per Eventarc rimangono indipendentemente dall'attività e non scadono. Per modificare le proprietà della sottoscrizione, consulta Proprietà degli abbonamenti.

Eventarc supporta i trigger per questi tipi di eventi:

Eventi Cloud Audit Logs (CAL)
Descrizione	Cloud Audit Logs forniscono gli audit log delle attività di amministrazione e di accesso ai dati per ogni progetto, cartella e organizzazione Cloud. I servizi Google Cloud scrivono le voci in questi log. Questo elenco di eventi supportati include una directory di valori `serviceName` e `methodName`.
Tipo di filtro eventi	I trigger Eventarc con `type=google.cloud.audit.log.v1.written` inviano richieste al tuo servizio o flusso di lavoro quando viene creato un audit log che corrisponde ai criteri di filtro del trigger.
Eventi diretti
Descrizione	Eventarc può essere attivato da vari eventi diretti come un aggiornamento a un bucket Cloud Storage, un aggiornamento a un modello Firebase Remote Config o modifiche alle risorse sui servizi Google Cloud. Eventarc può essere attivato anche dai messaggi pubblicati in argomenti Pub/Sub. Pub/Sub è un bus di messaggi distribuito globale che scala automaticamente in base alle tue esigenze. Poiché Eventarc può essere richiamato dai messaggi su un argomento Pub/Sub, puoi integrarlo facilmente con qualsiasi altro servizio che supporti Pub/Sub come destinazione.
Tipo di filtro eventi	I trigger Eventarc con tipi di filtro eventi specifici inviano richieste al tuo servizio o flusso di lavoro quando si verifica un evento che corrisponde ai criteri di filtro del trigger; ad esempio, `type=google.cloud.storage.object.v1.finalized` (quando viene creato un oggetto in un bucket Cloud Storage) o `type=google.cloud.pubsub.topic.v1.messagePublished` (quando viene pubblicato un messaggio nell'argomento Pub/Sub specificato).

Località attivatore

I servizi Google Cloud, come Cloud Storage, possono essere configurati in modo da essere regionali o multiregionali. Alcuni servizi, come Cloud Build, possono essere configurati a livello globale.

Eventarc consente di creare trigger a livello di regione o, per alcuni eventi, di creare un trigger globale e ricevere eventi da tutte le regioni. Per saperne di più, consulta Informazioni sulle località Eventarc.

Devi specificare la località del trigger Eventarc in modo che corrisponda alla località del servizio Google Cloud che genera eventi ed evitare eventuali problemi di prestazioni e localizzazione dei dati causati da un trigger globale.

Puoi specificare le località dei trigger utilizzando un flag --location con ogni comando. Se non viene specificato un flag --destination-run-region, si presume che il servizio si trovi nella stessa regione del trigger. Per ulteriori informazioni, consulta la documentazione di riferimento per Google Cloud CLI.

Affidabilità e distribuzione

Le aspettative di consegna sono le seguenti:

Gli eventi che utilizzano Cloud Audit Logs vengono consegnati in meno di un minuto. Tieni presente che, anche se un trigger di Cloud Audit Logs viene creato immediatamente, possono essere necessari fino a due minuti prima che un trigger propaghi e filtri gli eventi.
Gli eventi che utilizzano Pub/Sub vengono recapitati in pochi secondi.

Non esiste una garanzia di consegna degli ordini "first-in-first-out". Tieni presente che un ordinamento rigoroso comprometterebbe la disponibilità e le funzionalità di scalabilità di Eventarc, che corrispondono a quelle del suo livello di trasporto Cloud Pub/Sub. Per ulteriori informazioni, consulta la sezione Ordinare messaggi.

Latenza e velocità effettiva sono i migliori. variano in base a più fattori, ad esempio se il trigger Eventarc è a livello di regione, multiregionale o globale, la configurazione di un particolare servizio e il carico di rete sulle risorse in una regione Google Cloud.

Tieni presente che esistono quote e limiti di utilizzo che si applicano in generale a Eventarc. Sono inoltre previsti limiti e quote di utilizzo specifici di Workflows.

Criterio di ripetizione degli eventi

Le caratteristiche di nuovo tentativo di Eventarc corrispondono a quelle del suo livello di trasporto, Cloud Pub/Sub. Per ulteriori informazioni, vedi Ripetere le richieste e Eseguire il push di backoff.

La durata predefinita di conservazione dei messaggi impostata da Eventarc è di 24 ore con un ritardo di backoff esponenziale.

Puoi aggiornare il criterio di nuovo tentativo tramite la sottoscrizione Pub/Sub associata al trigger Eventarc:

Apri la pagina dei dettagli dell'attivatore.
Fai clic sull'argomento.
Fai clic sulla scheda Sottoscrizioni.

Qualsiasi abbonamento creato automaticamente da Eventarc avrà questo formato: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Per ulteriori informazioni sui limiti degli abbonamenti, consulta Limiti delle risorse Pub/Sub.

Se Pub/Sub tenta di recapitare un messaggio, ma la destinazione non riesce a confermarlo, Pub/Sub invierà di nuovo il messaggio con un backoff esponenziale minimo di 10 secondi. Se la destinazione continua a non riconoscere il messaggio, viene aggiunto altro tempo al ritardo in ogni nuovo tentativo (fino a un massimo di 600 secondi) e il messaggio viene inviato nuovamente alla destinazione.

Argomenti messaggi non recapitabili

Se la destinazione non riceve il messaggio, puoi inoltrare i messaggi non recapitati a un argomento messaggi non recapitabili (noto anche come coda messaggi non recapitabili). Un argomento messaggi non recapitabili può archiviare messaggi che la destinazione non può riconoscere. Devi impostare un argomento messaggi non recapitabili quando crei o aggiorni una sottoscrizione Pub/Sub, non quando crei un argomento Pub/Sub o quando Eventarc crea un argomento Pub/Sub. Per ulteriori informazioni, consulta Gestire gli errori relativi ai messaggi.

Errori che non giustificano nuovi tentativi

Quando le applicazioni utilizzano Pub/Sub come origine dell'evento e l'evento non viene consegnato, viene eseguito automaticamente un nuovo tentativo, ad eccezione degli errori che non giustificano l'esecuzione di nuovi tentativi. Tieni presente che Workflows riconosce gli eventi non appena inizia l'esecuzione del flusso di lavoro. Gli eventi nella destinazione del flusso di lavoro da qualsiasi origine non verranno tentati se il flusso di lavoro non viene eseguito. Se l'esecuzione del flusso di lavoro inizia ma in seguito non va a buon fine, le esecuzioni non vengono tentate di nuovo. Per risolvere questi problemi relativi ai servizi, è necessario gestire gli errori e i nuovi tentativi all'interno del flusso di lavoro.

Duplicare gli eventi

È possibile che eventi duplicati vengano inviati ai gestori di eventi. In base alla specifica CloudEvents, la combinazione degli attributi source e id è considerata univoca, pertanto tutti gli eventi con la stessa combinazione sono considerati duplicati. Come best practice generale, dovresti implementare i gestori di eventi idempotenti.

Osservabilità

I log dettagliati per Eventarc, Cloud Run, GKE, Pub/Sub e Flussi di lavoro sono disponibili da Cloud Audit Logs.

Ripristino di emergenza

Puoi sfruttare zone e regioni per ottenere affidabilità in caso di interruzioni. Per scoprire di più su come garantire il raggiungimento degli obiettivi RTO (Recovery Time Objective) e RPO (Recovery Point Objective) per i tempi di backup e ripristino quando si utilizza Eventarc, consulta la pagina Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud.