Eventi di ripetizione

Un evento può essere rifiutato per diversi motivi. Ad esempio, il servizio di ricezione eventi potrebbe non essere temporaneamente disponibile a causa di un'interruzione; il servizio potrebbe riscontrare un errore durante l'elaborazione di un evento oppure le risorse del servizio potrebbero esaurirsi. Gli errori temporanei come questo possono essere ritentati.

Un evento potrebbe anche non essere recapitato al destinatario. Ad esempio, l'evento potrebbe non corrispondere allo schema previsto configurato oppure la mediazione dell'evento potrebbe non riuscire prima che il messaggio evento possa essere indirizzato alla sua destinazione finale. Questi casi generano errori persistenti.

Errori temporanei

Eventarc Advanced ti offre la possibilità di gestire gli errori temporanei. Questi errori temporanei possono essere ritentati e includono quelli con i seguenti codici di errore:

• HTTP 408 Request Timeout
• HTTP 409 Conflict
• HTTP 429 Too Many Requests
• HTTP 500 Internal Server Error
• HTTP 502 Bad Gateway
• HTTP 503 Service Unavailable
• HTTP 504 Gateway Time-out

Errori permanenti

A differenza degli errori temporanei, gli errori permanenti includono quanto segue:

• Errori che si verificano quando il numero di tentativi configurati è esaurito
• Errori che si verificano quando un evento non va a buon fine prima di poter essere indirizzato alla sua destinazione
• Errori che generano un codice di errore considerato non riproducibile. Ad esempio, codici di errore diversi da quelli elencati per gli errori temporanei.

Puoi identificare manualmente gli errori persistenti e gestirli in modo appropriato.

Riprova errori temporanei

Eventarc Advanced utilizza un ritardo di backoff esponenziale per gestire gli errori che possono essere riprovati. Il criterio di ripetizione predefinito inizia con un ritardo di un secondo e il ritardo viene raddoppiato dopo ogni tentativo non riuscito (fino a un massimo di 60 secondi e cinque tentativi).

Puoi modificare il criterio di ripetizione predefinito utilizzando la console Google Cloud o il comando gcloud beta eventarc pipelines update.

Tieni presente che il fattore di backoff predefinito di 2 non può essere modificato.

gcloud beta eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

gcloud beta eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

Archiviare i messaggi per gestire gli errori persistenti

Puoi scrivere i messaggi in una tabella BigQuery non appena vengono ricevuti. In questo modo puoi identificare manualmente gli errori persistenti e gestirli in modo appropriato.

Di seguito è riportata una panoramica dei passaggi necessari per archiviare i messaggi degli eventi, identificare gli errori persistenti e riprovare a inviare gli eventi interessati.

1. Crea un bus. Configura il bus in modo appropriato, ad esempio per pubblicare eventi da origini Google.
2. Crea un argomento Pub/Sub. Questo argomento Pub/Sub sarà la destinazione di destinazione della pipeline.
3. Crea una sottoscrizione BigQuery per l'argomento Pub/Sub. Una sottoscrizione BigQuery è un tipo di sottoscrizione dell'esportazione che scrive i messaggi in una tabella BigQuery esistente alla ricezione. In alternativa, puoi creare la tabella quando crei l'abbonamento BigQuery.

4. Crea una pipeline e una registrazione che indirizza ogni messaggio ricevuto dal bus (utilizzando --cel-match="true") all'argomento Pub/Sub. Configura un criterio di ripetizione per la pipeline.

   Ad esempio, i seguenti comandi creano una pipeline e una registrazione:

   gcloud beta eventarc pipelines create my-archive-pipeline \
       --destinations=pubsub_topic='my-archive-topic',network_attachment='my-network-attachment' \
       --min-retry-delay=1 \
       --max-retry-delay=20 \
       --max-retry-attempts=6 \
       --location=us-central1
   

   gcloud beta eventarc enrollments create my-archive-enrollment \
       --cel-match="true" \
       --destination-pipeline=my-archive-pipeline \
       --message-bus=my-message-bus \
       --message-bus-project=my-google-cloud-project \
       --location=us-central1
   

5. Instrada i log della pipeline a un altro set di dati BigQuery.

   Ora dovresti avere due set di dati BigQuery separati: uno che memorizza ogni messaggio ricevuto dal bus Eventarc Advanced e uno che memorizza i log della pipeline.

6. Per identificare i messaggi non riusciti, utilizza un'istruzione di query per unire entrambi i set di dati BigQuery nel campo message_uid.

7. Dopo aver identificato i messaggi non riusciti, puoi pubblicarli di nuovo nel bus utilizzando l'API Eventarc Publishing. Ad esempio, puoi eseguire il deployment di un servizio o di un job Cloud Run per leggere i messaggi da BigQuery e pubblicarli direttamente nel bus avanzato di Eventarc.

Rendi idempotenti i gestori di eventi

I gestori di eventi che possono essere riprovati devono essere idempotenti e seguire le seguenti linee guida generali:

• Molte API esterne ti consentono di fornire una chiave di idempotenza come parametro. Se utilizzi un'API di questo tipo, devi utilizzare l'origine e l'ID evento come chiave di idempotenza. (I produttori devono assicurarsi che source + id sia univoco per ogni evento distinto.)
• Inoltre, puoi utilizzare un attributo CloudEvents, xgooglemessageuid, per fornire l'idempotenza. Il valore di questo attributo è uguale al campo message_uid nei messaggi Eventarc Advanced. Identifica in modo univoco l'azione di pubblicazione di un evento. Ad esempio, se lo stesso evento viene pubblicato due volte in un bus, ogni evento avrà un valore xgooglemessageuid diverso quando viene inviato a un gestore di eventi.
• L'idempotenza funziona bene con la consegna "at-least-once", perché rende sicuro il nuovo tentativo. Pertanto, una best practice generale per scrivere codice affidabile è combinare l'idempotenza con i tentativi.
• Assicurati che il codice sia idempotente internamente. Ad esempio:
  • Assicurati che le mutazioni possano verificarsi più di una volta senza modificare il risultato.
  • Esegui query sullo stato del database in una transazione prima di modificarlo.
  • Assicurati che tutti gli effetti collaterali siano idempotenti.
• Imponi un controllo transazionale al di fuori del tuo servizio, indipendentemente dal codice. Ad esempio, mantieni lo stato in un punto in cui viene registrato che un determinato ID evento è già stato elaborato.
• Gestisci le chiamate duplicate fuori banda. Ad esempio, esegui un processo di pulizia separato che pulisce dopo le chiamate duplicate.

Passaggi successivi

• Risolvere i problemi
• Visualizzare i log di controllo