Questa pagina è stata tradotta dall'API Cloud Translation.

Eventi di ripetizione

Avanzate

Un evento può essere rifiutato per diversi motivi. Ad esempio, il servizio di ricezione degli eventi potrebbe essere temporaneamente non disponibile a causa di un'interruzione; il servizio potrebbe riscontrare un errore durante l'elaborazione di un evento oppure le risorse del servizio potrebbero essere esaurite. Per gli errori temporanei come questo è possibile riprovare.

Inoltre, un evento può 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 dell'evento possa essere inoltrato alla destinazione finale. In questi casi si verificano errori persistenti.

Errori temporanei

Eventarc Advanced ti offre la possibilità di gestire gli errori temporanei. Per questi errori temporanei è possibile riprovare e sono inclusi 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 inoltrato alla destinazione
Errori che generano un codice di errore considerato non ripetibile, ad esempio codici di errore diversi da quelli elencati per gli errori temporanei

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

Riprovare in caso di 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 nuovo tentativo 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.

Console

Nella console Google Cloud, vai alla pagina Eventarc > Pipeline.

Vai a Pipeline
Fai clic sul nome della pipeline.
Nella pagina Dettagli pipeline, fai clic su Modifica.
Nella pagina Modifica pipeline, nella sezione Criterio di ripetizione, modifica i seguenti campi:
- Numero tentativi massimi: il numero di tentativi; il valore predefinito è 5 tentativi. Può essere qualsiasi numero reale positivo. Se impostato su 1, non viene applicato alcun criterio per i nuovi tentativi e viene eseguito un solo tentativo di invio di un messaggio.
- Ritardo minimo (secondi): il ritardo iniziale in secondi. Il valore predefinito è 1 secondo. Il valore deve essere compreso tra 1 e 600.
- Ritardo massimo (secondi): il ritardo massimo in secondi. Il valore predefinito è 60 secondi. Il valore deve essere compreso tra 1 e 600.
Puoi configurare un backoff lineare impostando gli intervalli minimo e massimo sullo stesso valore.
Fai clic su Salva.

gcloud

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

Sostituisci quanto segue:

PIPELINE_NAME: l'ID o l'identificatore completamente qualificato della pipeline.
MIN_DELAY: il ritardo iniziale in secondi. Il valore predefinito è 1 secondo. Il valore deve essere compreso tra 1 e 600.
MAX_DELAY: il ritardo massimo in secondi. Il valore predefinito è 60 secondi. Il valore deve essere compreso tra 1 e 600.
MAX_ATTEMPTS: il numero di nuovi tentativi. Il valore predefinito è 5 tentativi. Può essere qualsiasi numero reale positivo. Se impostato su 1, non viene applicato alcun criterio per i nuovi tentativi e viene eseguito un solo tentativo di invio di un messaggio.

L'esempio seguente configura un backoff lineare impostando i ritardi minimo e massimo sullo stesso valore:

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 di conseguenza.

Di seguito viene fornita una panoramica dei passaggi necessari per archiviare i messaggi degli eventi, identificare gli errori persistenti e riprovare gli eventi interessati.

Crea un bus. Configura adeguatamente il bus, ad esempio per pubblicare eventi da origini Google.
Crea un argomento Pub/Sub. Questo argomento Pub/Sub sarà la destinazione target della pipeline.
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 non appena vengono ricevuti. In alternativa, puoi creare la tabella quando crei l'abbonamento BigQuery.

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

Ad esempio, i comandi seguenti 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

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

Ora dovresti avere due set di dati BigQuery distinti: uno che immagazzina ogni messaggio ricevuto dal bus Eventarc Advanced e uno che memorizza i log della pipeline.
Per identificare i messaggi che non sono andati a buon fine, utilizza un istruzione di query per unire entrambi i set di dati BigQuery sul campo message_uid.
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 Eventarc Advanced.

Rendi idempotenti i gestori di eventi

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

Molte API esterne ti consentono di fornire una chiave di iride come parametro. Se utilizzi un'API di questo tipo, devi utilizzare l'origine e l'ID evento come chiave di idempotency. 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 corrisponde al message_uid campo 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 eventi.
L'idempotenza funziona bene con la consegna "almeno una volta", perché consente di ritentare in sicurezza. Pertanto, una best practice generale per scrivere codice affidabile è combinare l'idempotenza con i tentativi di nuovo.
Assicurati che il codice sia internamente idempotente. 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.
Imposta un controllo transazionale esterno al tuo servizio, indipendentemente dal codice. Ad esempio, mantieni lo stato da qualche parte registrando che un determinato ID evento è stato già elaborato.
Gestire le chiamate duplicate out-of-band. Ad esempio, puoi avere un processo di pulizia distinto per le chiamate duplicate.