Eventi di ripetizione

La configurazione dei criteri di ripetizione consente di inviare nuovamente gli eventi automaticamente dopo gli errori di recapito. Ciò contribuisce a garantire l'elaborazione affidabile dei messaggi quando i ricevitori di eventi subiscono interruzioni temporanee del servizio.

Un evento può essere rifiutato a causa di errori temporanei, ad esempio quando un ricevitore di eventi non è temporaneamente disponibile, si verifica un errore durante l'elaborazione di un evento o le risorse del servizio sono esaurite. Puoi riprovare a eseguire le operazioni che hanno generato errori temporanei in questo modo. Al contrario, gli errori permanenti si verificano quando un evento non corrisponde allo schema configurato o quando la mediazione non riesce prima che il messaggio possa essere indirizzato alla sua destinazione.

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:

  • 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 HTTP

Errori permanenti

A differenza degli errori temporanei, gli errori permanenti includono:

  • 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 nuovi tentativi 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 la policy di nuovi tentativi predefinita utilizzando la console Google Cloud o il comando gcloud eventarc pipelines update.

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

Console

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

    Vai a Pipeline

  2. Fai clic sul nome della pipeline.

  3. Nella pagina Dettagli pipeline, fai clic su Modifica.

  4. Nella pagina Modifica pipeline, nella sezione Policy di ripetizione, modifica i seguenti campi:

    • Tentativi massimi: il numero di tentativi di consegna; il valore predefinito è 5 tentativi. Può essere qualsiasi numero intero positivo. Se impostato su 1, non viene applicata alcuna policy 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 secondi. 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 i ritardi minimo e massimo sullo stesso valore.

  5. Fai clic su Salva.

gcloud 

gcloud 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 completo della pipeline.
  • MIN_DELAY: il ritardo iniziale in secondi; il valore predefinito è 1 secondi. 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 tentativi di consegna; il valore predefinito è 5 tentativi. Può essere qualsiasi numero intero positivo. Se impostato su 1, non viene applicata alcuna policy 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 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 una policy di ripetizione dei tentativi per la pipeline.

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

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

    gcloud 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 fare il deployment di un servizio o 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 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 avanzati di Eventarc. 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 l'esecuzione di un nuovo tentativo. Pertanto, una best practice generale per scrivere codice affidabile è combinare l'idempotenza con la ripetizione dei tentativi.
  • Assicurati che il codice sia idempotente internamente. Ad esempio:
    • Assicurati che le mutazioni possano verificarsi più di una volta senza modificare il risultato.
    • Fai query sullo stato del database in una transazione prima di mutarlo.
    • Assicurati che tutti gli effetti collaterali siano a loro volta idempotenti.
  • Imponi un controllo transazionale all'esterno del servizio, indipendente dal codice. Ad esempio, rendere persistente lo stato da qualche parte registrando che un determinato ID evento è già stato elaborato.
  • Gestisci le chiamate duplicate fuori banda. Ad esempio, esegui un processo separato per liberare spazio dopo le chiamate duplicate.

Passaggi successivi