Cette page a été traduite par l'API Cloud Translation.

Événements de nouvelle tentative

Avancé

Un événement peut être refusé pour plusieurs raisons. Par exemple, le service de récepteur d'événements peut être temporairement indisponible en raison d'une panne, le service peut rencontrer une erreur lors du traitement d'un événement ou les ressources du service peuvent être épuisées. Les erreurs temporaires comme celle-ci peuvent être réessayées.

Il est également possible qu'un événement ne soit pas distribué au destinataire des événements. Par exemple, l'événement peut ne pas correspondre au schéma attendu configuré, ou la médiation de l'événement peut échouer avant que le message de l'événement ne puisse être acheminé vers sa destination finale. Dans ce cas, des erreurs persistantes se produisent.

Erreurs temporaires

Eventarc Advanced vous permet de gérer les erreurs temporaires. Ces erreurs temporaires peuvent être réessayées et incluent celles associées aux codes d'erreur suivants:

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

Erreurs persistantes

Contrairement aux erreurs temporaires, les erreurs persistantes incluent les suivantes:

Erreurs qui se produisent lorsque le nombre de tentatives de nouvelle connexion configurées est épuisé
Erreurs qui se produisent lorsqu'un événement échoue avant de pouvoir être acheminé vers sa destination
Erreurs qui génèrent un code d'erreur considéré comme non récupérable (par exemple, codes d'erreur autres que ceux listés pour les erreurs temporaires)

Vous pouvez identifier manuellement les erreurs persistantes et les gérer de manière appropriée.

Réessayer les erreurs temporaires

Eventarc Advanced utilise un intervalle exponentiel entre les tentatives pour gérer les erreurs pouvant faire l'objet d'une nouvelle tentative. La stratégie de nouvelle tentative par défaut commence avec un délai d'une seconde, et le délai est doublé après chaque tentative infructueuse (jusqu'à un maximum de 60 secondes et cinq tentatives).

Vous pouvez modifier la stratégie de nouvelle tentative par défaut à l'aide de la console Google Cloud ou de la commande gcloud beta eventarc pipelines update.

Notez que vous ne pouvez pas modifier le facteur de délai par défaut de 2.

Console

Dans la console Google Cloud, accédez à la page Eventarc > Pipelines.

Accéder à la page Pipelines
Cliquez sur le nom du pipeline.
Sur la page Détails du pipeline, cliquez sur Modifier.
Sur la page Modifier le pipeline, dans la section Règle de nouvelle tentative, modifiez les champs suivants:
- Nombre maximal de tentatives: nombre de nouvelles tentatives. La valeur par défaut est de 5 tentatives. Peut être n'importe quel nombre réel positif. Si ce champ est défini sur 1, aucune règle de nouvelle tentative n'est appliquée. Une seule tentative de distribution du message est donc effectuée.
- Délai minimum (en secondes): délai initial en secondes. La valeur par défaut est de 1 seconde. Doit être compris entre 1 et 600.
- Délai maximal (en secondes): délai maximal en secondes. La valeur par défaut est de 60 secondes. Doit être compris entre 1 et 600.
Vous pouvez configurer un délai avant expiration linéaire en définissant les délais minimal et maximal sur la même valeur.
Cliquez sur Enregistrer.

gcloud

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

Remplacez les éléments suivants :

PIPELINE_NAME: ID ou identifiant complet du pipeline.
MIN_DELAY: délai initial en secondes. La valeur par défaut est 1 seconde. Doit être compris entre 1 et 600.
MAX_DELAY: délai maximal en secondes. La valeur par défaut est 60 secondes. Doit être compris entre 1 et 600.
MAX_ATTEMPTS: nombre de nouvelles tentatives. La valeur par défaut est 5. Il peut s'agir de n'importe quel nombre réel positif. Si la valeur est 1, aucune règle de nouvelle tentative n'est appliquée et une seule tentative de distribution du message est effectuée.

L'exemple suivant configure un délai de latence linéaire en définissant les délais minimal et maximal sur la même valeur:

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

Archiver les messages pour gérer les erreurs persistantes

Vous pouvez écrire des messages dans une table BigQuery à mesure qu'ils sont reçus. Vous pouvez ainsi identifier manuellement les erreurs persistantes et les gérer de manière appropriée.

Vous trouverez ci-dessous un aperçu des étapes requises pour archiver vos messages d'événement, identifier les erreurs persistantes et réessayer les événements concernés.

Créez un bus. Configurez le bus de manière appropriée, par exemple pour publier des événements à partir de sources Google.
Créez un sujet Pub/Sub. Ce sujet Pub/Sub sera la destination cible de votre pipeline.
Créez un abonnement BigQuery pour le sujet Pub/Sub. Un abonnement BigQuery est un type d'abonnement d'exportation qui écrit les messages dans une table BigQuery existante à mesure qu'ils sont reçus. Vous pouvez également créer la table lorsque vous créez l'abonnement BigQuery.

Créez un pipeline et un enregistrement qui acheminent chaque message reçu par le bus (à l'aide de --cel-match="true") vers le sujet Pub/Sub. Configurez une stratégie de nouvelle tentative pour le pipeline.

Par exemple, les commandes suivantes créent un pipeline et une inscription:

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

Acheminez les journaux de votre pipeline vers un autre ensemble de données BigQuery.

Vous devriez maintenant avoir deux ensembles de données BigQuery distincts: l'un stockant chaque message reçu par votre bus Eventarc Advanced et l'autre stockant vos journaux de pipeline.
Pour identifier les messages ayant échoué, utilisez une instruction de requête pour joindre les deux ensembles de données BigQuery sur le champ message_uid.
Après avoir identifié les messages ayant échoué, vous pouvez les publier à nouveau sur votre bus à l'aide de l'API Eventarc Publishing. Par exemple, vous pouvez déployer un service ou un job Cloud Run pour lire les messages de BigQuery et les publier directement sur le bus Eventarc Advanced.

Rendre les gestionnaires d'événements idempotents

Les gestionnaires d'événements qui peuvent être relancés doivent être idempotents, en suivant les consignes générales suivantes :

De nombreuses API externes vous permettent de fournir une clé d'idempotence en tant que paramètre. Si vous utilisez une telle API, vous devez utiliser la source et l'ID de l'événement comme clé d'idempotence. (Les producteurs doivent s'assurer que source + id est unique pour chaque événement distinct.)
Vous pouvez également utiliser un attribut CloudEvents, xgooglemessageuid, pour fournir une idempotency. La valeur de cet attribut est identique au champ message_uid dans les messages Eventarc Advanced. Il identifie de manière unique l'action de publication d'un événement. Par exemple, si le même événement est publié deux fois sur un bus, chaque événement aura une valeur xgooglemessageuid différente lorsqu'il sera envoyé à un gestionnaire d'événements.
L'idempotence fonctionne bien avec une livraison de type "au moins une fois", car elle permet de répéter la tentative en toute sécurité. Une bonne pratique pour écrire du code fiable consiste donc à combiner l'idempotence à la répétition des tentatives.
Assurez-vous que votre code est idempotent en interne. Exemple :
- Assurez-vous que les mutations peuvent se produire plus d'une fois sans en changer le résultat.
- Interrogez l'état de la base de données dans une transaction avant de muter l'état.
- Assurez-vous que tous les effets secondaires sont eux-mêmes idempotents.
Imposez un contrôle transactionnel en dehors de votre service, indépendamment du code. Par exemple, conservez l'état quelque part en notant qu'un ID d'événement donné a déjà été traité.
Gérez les appels de doublons hors bande. Par exemple, mettez en place un processus de nettoyage distinct qui se lance après les appels de doublons.