Instrada gli eventi Firebase Alert a Workflows

Un trigger Eventarc dichiara il tuo interesse per un determinato evento o insieme di eventi. Puoi configurare il routing degli eventi specificando i filtri per il trigger, tra cui l'origine evento e il flusso di lavoro di destinazione.

Gli eventi vengono pubblicati nel formato CloudEvents tramite una richiesta HTTP. Il servizio Workflows converte l'evento in un oggetto JSON (in base alla specifica CloudEvents) e lo passa all'esecuzione del flusso di lavoro come argomento di runtime del flusso di lavoro. Assicurati che le dimensioni dell'evento non superino i 512 kB. Gli eventi superiori alla dimensione massima degli argomenti Workflows non attiveranno le esecuzioni del flusso di lavoro.

Queste istruzioni mostrano come configurare il routing degli eventi in modo che venga attivata un'esecuzione del tuo flusso di lavoro in risposta a un evento Firebase Alerts diretto. Per ulteriori dettagli, consulta l'elenco degli eventi diretti supportati.

Le richieste al tuo servizio vengono attivate in risposta a un evento quando un servizio Firebase pubblica un avviso Firebase.

Nota: se un provider Google supporta sia eventi diretti che eventi del log di controllo, ti consigliamo di creare un trigger che filtri l'evento diretto. Gli eventi diretti offrono una serie di vantaggi rispetto agli eventi degli audit log. Per ulteriori informazioni, consulta la sezione Route di eventi.

Prepararsi a creare un trigger

Prima di creare un trigger Eventarc per un flusso di lavoro di destinazione, completa le attività seguenti.

Console

1. Nella console Google Cloud, nella pagina del selettore dei progetti, seleziona o crea un progetto Google Cloud.

   Nota: se non prevedi di conservare le risorse che crei in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

   Vai al selettore di progetti

2. Abilita le API Eventarc, Eventarc Publishing, Workflows ed Workflow Executions.

   Abilita le API

3. Se applicabile, abilita l'API relativa agli eventi. Ad esempio, per gli eventi di Cloud Functions, abilita cloudfunctions.googleapis.com.

4. Se non ne hai già uno, crea un account di servizio gestito dall'utente, quindi concedigli i ruoli e le autorizzazioni necessari in modo che Eventarc possa gestire gli eventi per un flusso di lavoro di destinazione.

   1. Nella console Google Cloud, vai alla pagina Account di servizio.

      Vai ad Account di servizio

   2. Seleziona il progetto.

   3. Inserisci un nome nel campo Nome account di servizio. La console Google Cloud compila il campo ID account di servizio in base a questo nome.

      Nel campo Descrizione account di servizio, inserisci una descrizione. Ad esempio, Service account for event trigger.

   4. Fai clic su Crea e continua.

   5. Per fornire l'accesso appropriato, nell'elenco Seleziona un ruolo seleziona i ruoli Identity and Access Management (IAM) richiesti da concedere al tuo account di servizio. Per ulteriori informazioni, consulta Ruoli e autorizzazioni per le destinazioni di Workflows.

      Per ulteriori ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni altro ruolo.

   6. Fai clic su Continua.

   7. Per completare la creazione dell'account, fai clic su Fine.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Abilita le API Eventarc, Eventarc Publishing, Workflows ed Workflow Executions:

   gcloud services enable eventarc.googleapis.com \
       eventarcpublishing.googleapis.com \
       workflows.googleapis.com \
       workflowexecutions.googleapis.com

3. Se applicabile, abilita l'API relativa agli eventi diretti. Ad esempio, per gli eventi di Cloud Functions, abilita cloudfunctions.googleapis.com.

4. Se non ne hai già uno, crea un account di servizio gestito dall'utente, quindi concedigli i ruoli e le autorizzazioni necessari in modo che Eventarc possa gestire gli eventi per un flusso di lavoro di destinazione.

   1. Crea l'account di servizio:

      gcloud iam service-accounts create SERVICE_ACCOUNT_NAME

      Sostituisci SERVICE_ACCOUNT_NAME con il nome dell'account di servizio. Deve essere compreso tra 6 e 30 caratteri e può contenere caratteri alfanumerici minuscoli e trattini. Dopo aver creato un account di servizio, non puoi modificarne il nome.

   2. Concedi le autorizzazioni o i ruoli Identity and Access Management (IAM) richiesti. Per saperne di più, consulta Ruoli e autorizzazioni per le destinazioni di Workflows.

Crea un trigger

Puoi creare un trigger Eventarc con un flusso di lavoro di cui è stato eseguito il deployment come ricevitore di eventi utilizzando Google Cloud CLI (gcloud o Terraform) o tramite la console Google Cloud.

Nota: il filtro viene applicato tramite una corrispondenza esatta e non supporta caratteri jolly o espressioni regolari. Tuttavia, puoi utilizzare il flag --event-filters-path-pattern nel seguente comando gcloud CLI oppure definire un pattern del percorso tramite la console. Per ulteriori informazioni, consulta Comprendere i pattern dei percorsi.

Console

1. Nella console Google Cloud, vai alla pagina Trigger di Eventarc.

   Vai ai trigger

2. Fai clic su Crea trigger.
3. Digita un Nome trigger.

   Si tratta dell'ID dell'attivatore e deve iniziare con una lettera. Può contenere fino a 63 lettere minuscole, numeri o trattini.

4. Per il Tipo di attivatore, seleziona Origini Google.
5. Nell'elenco Provider di eventi, seleziona Firebase Alerts.

   Tieni presente che il nome del provider di eventi utilizzato nella documentazione di Google Cloud associata potrebbe non avere un prefisso di Cloud o Google Cloud. Ad esempio, nella console, Memorystore per Redis viene chiamato Google Cloud Memorystore for Redis.

6. Nell'elenco Evento, seleziona un evento per il tipo di evento Diretto.
7. Per specificare la codifica del payload dell'evento, nell'elenco Tipo di contenuto dei dati sugli eventi, seleziona application/json o application/protobuf.

   Tieni presente che un payload di evento in formato JSON è più grande di uno formattato in Protobuf. Questo potrebbe influire sull'affidabilità a seconda della destinazione e dei limiti delle dimensioni dell'evento. Per ulteriori informazioni, consulta la pagina Problemi noti.

8. Nell'elenco Regione, seleziona globale (globale).

   Per ulteriori informazioni, consulta le località Eventarc.

9. Nel campo Attributo 1, l'ID risorsa alerttype agisce come un filtro di eventi. Seleziona un operatore per questo filtro:
   • Uguale
   • Pattern del percorso

     Per maggiori informazioni, consulta la pagina Comprendere i pattern dei percorsi.

10. Nel campo Valore attributo 1, inserisci uno dei seguenti valori:
    • appDistribution.inAppFeedback: l'evento viene inviato quando un tester invia un feedback in-app per una determinata app
    • appDistribution.newTesterIosDevice: l'evento viene inviato quando viene registrato un nuovo dispositivo tester iOS per una determinata app
    • billing.planAutomatedUpdate: l'evento viene inviato quando il piano di fatturazione per un progetto Firebase viene aggiornato automaticamente, ad esempio quando viene eseguito il downgrade di un piano a causa di problemi con i pagamenti
    • billing.planUpdate: l'evento viene inviato quando il piano di fatturazione di un progetto Firebase viene modificato da un utente, ad esempio quando un account di fatturazione è collegato o scollegato da un progetto
    • crashlytics.missingSymbolFile: l'evento viene inviato quando Firebase Crashlytics stabilisce che non dispone dei simboli di debug appropriati per simbolizzare un report sugli arresti anomali in arrivo
    • crashlytics.newAnrIssue: l'evento viene inviato quando un'app riscontra un errore nuova L'applicazione non risponde (ANR) (non per eventi identici successivi).
    • crashlytics.newFatalIssue: l'evento viene inviato quando un'app riscontra un nuovo arresto anomalo irreversibile (non per eventuali eventi identici successivi)
    • crashlytics.newNonfatalIssue: l'evento viene inviato quando un'app riscontra un nuovo errore non irreversibile (non per eventuali eventi identici successivi)
    • crashlytics.regression: l'evento viene inviato quando un'app riscontra un arresto anomalo per un problema contrassegnato come chiuso per una versione precedente dell'app
    • crashlytics.stabilityDigest: l'evento viene inviato quando viene visualizzata una notifica dei principali problemi di tendenza in Crashlytics
    • crashlytics.velocity: l'evento viene inviato quando un singolo problema causa l'arresto anomalo di un numero significativo di sessioni dell'app.
    • performance.threshold: l'evento viene inviato quando le prestazioni di una metrica superano la soglia impostata
11. Se vuoi, puoi filtrare gli eventi in base a uno specifico ID app Firebase. Fai clic su Aggiungi filtro e specifica l'appid.
12. Seleziona l'account di servizio che richiama il servizio o il flusso di lavoro.

    In alternativa, puoi creare un nuovo account di servizio.

    Specifica l'indirizzo email dell'account di servizio Identity and Access Management (IAM) associato al trigger e a cui hai precedentemente concesso i ruoli specifici richiesti da Eventarc.

13. Nell'elenco Destinazione evento, seleziona Workflows.
14. Seleziona un flusso di lavoro.
    

    Questo è il nome del flusso di lavoro a cui trasmettere gli eventi. Gli eventi per l'esecuzione di un flusso di lavoro vengono trasformati e passati al flusso di lavoro come argomenti di runtime.

    Per ulteriori informazioni, consulta Creare un trigger per Workflows.

15. Fai clic su Crea.

Una volta creato un attivatore, i filtri dell'origine evento non possono essere modificati. Crea invece un nuovo attivatore ed elimina quello precedente. Per ulteriori informazioni, consulta Gestire i trigger.

gcloud

gcloud eventarc triggers create TRIGGER \
    --location=global \
    --destination-workflow=DESTINATION_WORKFLOW  \
    --destination-workflow-location=DESTINATION_WORKFLOW_LOCATION \
    --event-filters="type=google.firebase.firebasealerts.alerts.v1.published" \
    --event-filters="alerttype=ALERT_TYPE" \
    --event-data-content-type="EVENT_DATA_CONTENT_TYPE" \
    --service-account="MY_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com"

Sostituisci quanto segue:

• TRIGGER: l'ID dell'attivatore o un identificatore completo.
• DESTINATION_WORKFLOW: l'ID del flusso di lavoro di cui è stato eseguito il deployment che riceve gli eventi dal trigger. Il flusso di lavoro può trovarsi in una qualsiasi delle località supportate di Workflows e non deve necessariamente trovarsi nella stessa località del trigger. Tuttavia, il flusso di lavoro deve trovarsi nello stesso progetto del trigger.
• DESTINATION_WORKFLOW_LOCATION (facoltativo): la località in cui viene eseguito il deployment del flusso di lavoro di destinazione. Se non specificato, si presume che il flusso di lavoro si trovi nella stessa posizione del trigger.
• ALERT_TYPE: il tipo di avviso Firebase e può corrispondere a uno dei seguenti valori:
  • appDistribution.inAppFeedback: l'evento viene inviato quando un tester invia un feedback in-app per una determinata app
  • appDistribution.newTesterIosDevice: l'evento viene inviato quando viene registrato un nuovo dispositivo tester iOS per una determinata app
  • billing.planAutomatedUpdate: l'evento viene inviato quando il piano di fatturazione per un progetto Firebase viene aggiornato automaticamente, ad esempio quando viene eseguito il downgrade di un piano a causa di problemi con i pagamenti
  • billing.planUpdate: l'evento viene inviato quando il piano di fatturazione di un progetto Firebase viene modificato da un utente, ad esempio quando un account di fatturazione è collegato o scollegato da un progetto
  • crashlytics.missingSymbolFile: l'evento viene inviato quando Firebase Crashlytics stabilisce che non dispone dei simboli di debug appropriati per simbolizzare un report sugli arresti anomali in arrivo
  • crashlytics.newAnrIssue: l'evento viene inviato quando un'app riscontra un errore nuova L'applicazione non risponde (ANR) (non per eventi identici successivi).
  • crashlytics.newFatalIssue: l'evento viene inviato quando un'app riscontra un nuovo arresto anomalo irreversibile (non per eventuali eventi identici successivi)
  • crashlytics.newNonfatalIssue: l'evento viene inviato quando un'app riscontra un nuovo errore non irreversibile (non per eventuali eventi identici successivi)
  • crashlytics.regression: l'evento viene inviato quando un'app riscontra un arresto anomalo per un problema contrassegnato come chiuso per una versione precedente dell'app
  • crashlytics.stabilityDigest: l'evento viene inviato quando viene visualizzata una notifica dei principali problemi di tendenza in Crashlytics
  • crashlytics.velocity: l'evento viene inviato quando un singolo problema causa l'arresto anomalo di un numero significativo di sessioni dell'app.
  • performance.threshold: l'evento viene inviato quando le prestazioni di una metrica superano la soglia impostata
  L'operatore di ALERT_TYPE deve essere uno dei seguenti:
  • Uguale; ad esempio, --event-filters="alerttype=appDistribution.inAppFeedback"
  • Pattern del percorso, ad esempio --event-filters-path-pattern="alerttype=appDistribution." o --event-filters-path-pattern="alerttype=crashlytics.new".

    Per maggiori informazioni, consulta la pagina Comprendere i pattern dei percorsi.

• EVENT_DATA_CONTENT_TYPE: (facoltativo) la codifica del payload dell'evento. Il valore può essere application/json o application/protobuf. La codifica predefinita è application/json.

  Tieni presente che un payload di evento in formato JSON è più grande di uno formattato in Protobuf. Questo potrebbe influire sull'affidabilità a seconda della destinazione dell'evento e dei limiti relativi alle dimensioni degli eventi. Per maggiori informazioni, consulta la pagina Problemi noti.

• SERVICE_ACCOUNT_NAME: il nome dell'account di servizio IAM creato a cui hai concesso ruoli specifici richiesti da Workflows.
• PROJECT_ID: il tuo ID progetto Google Cloud

Note:

• Il flag --location deve essere global. Per ulteriori informazioni, consulta le località Eventarc.
• Questi flag sono obbligatori:
  • --event-filters="type=google.firebase.firebasealerts.alerts.v1.published"
  • --event-filters="alerttype=ALERT_TYPE" oppure --event-filters-path-pattern="alerttype=ALERT_TYPE"
• Una volta creato un attivatore, il tipo di filtro per eventi non può essere modificato. Per un tipo di evento diverso, devi creare un nuovo attivatore.
• Se vuoi, puoi filtrare gli eventi per uno specifico ID app Firebase utilizzando il flag --event-filters="appid=APP_ID" e specificando una corrispondenza esatta.
• --service-account: l'email dell'account di servizio IAM che verrà utilizzata dal trigger Eventarc 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.
• Per impostazione predefinita, le sottoscrizioni Pub/Sub create per Eventarc rimangono indipendentemente dall'attività e non scadono. Per modificare la durata di inattività, consulta la sezione Proprietà degli abbonamenti.

Esempio:

gcloud eventarc triggers create firealerts-workflows-trigger \
    --location=global \
    --destination-workflow=my-workflow \
    --destination-workflow-location=europe-west4 \
    --event-filters="type=google.firebase.firebasealerts.alerts.v1.published" \
    --event-filters="alerttype=crashlytics.velocity" \
    --service-account="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

Questo comando crea un trigger denominato firealerts-workflows-trigger per l'evento identificato come google.firebase.firebasealerts.alerts.v1.published e per un tipo di avviso crashlytics.velocity.

Terraform

Puoi creare un trigger per un flusso di lavoro utilizzando Terraform. Per maggiori dettagli, consulta Attivare un flusso di lavoro utilizzando Eventarc e Terraform.

Nota: anche se il trigger viene creato immediatamente, la propagazione e il filtro degli eventi possono richiedere fino a due minuti.

Elenca un trigger

Puoi confermare la creazione di un trigger elencando i trigger Eventarc utilizzando Google Cloud CLI o la console Google Cloud.

Console

1. Nella console Google Cloud, vai alla pagina Trigger di Eventarc.

   Vai ai trigger

   Questa pagina elenca i tuoi trigger in tutte le località e include dettagli come nomi, regioni, fornitori di eventi, destinazioni e altro ancora.

2. Per filtrare gli attivatori:

   1. Fai clic su Filtro o sul campo Attivatori filtro.
   2. Nell'elenco Proprietà, seleziona un'opzione per filtrare gli attivatori.

   Puoi selezionare una singola proprietà o utilizzare l'operatore logico OR per aggiungerne altre.

3. Per ordinare gli attivatori, accanto a qualsiasi intestazione di colonna supportata, fai clic su Ordina.

gcloud

Esegui questo comando per elencare i trigger:

gcloud eventarc triggers list --location=-

Questo comando elenca i trigger in tutte le località e include dettagli come nomi, tipi, destinazioni e stati.

Passaggi successivi

• Attiva un flusso di lavoro utilizzando Eventarc e Terraform

• Scopri di più su Eventarc