Les flux d'événements dans EventBridge utilisent des politiques de nouvelle tentative, des politiques de tolérance aux pannes et des files d'attente de lettres mortes (DLQ) pour gérer les échecs de livraison des événements. Lorsqu'une livraison vers une cible échoue, EventBridge tente de nouveau la livraison selon la politique configurée. Si toutes les tentatives sont épuisées, la politique de tolérance aux pannes détermine s'il faut ignorer l'événement ayant échoué ou bloquer le flux. Acheminez les événements non livrables vers une DLQ afin de les conserver pour inspection ultérieure.
Le schéma suivant illustre l'interaction entre ces trois politiques :
Event delivery fails
|
v
Retry policy
(backoff or exponential decay)
|
All retries exhausted?
/ \
No Yes
| |
Retry Fault tolerance policy
again / \
Allowed Prohibited
| |
DLQ configured? Stream blocked,
/ \ task status -> Ready
Yes No
| |
Send to Discard
DLQ eventPolitiques de nouvelle tentative
Une politique de nouvelle tentative contrôle la manière dont EventBridge retente la livraison après un échec. Chaque flux d'événements prend en charge deux politiques de nouvelle tentative :
| Politique | Nombre maximal de tentatives | Intervalle de nouvelle tentative | Durée maximale | Par défaut |
|---|---|---|---|---|
| Nouvelle tentative avec temporisation | 3 | Aléatoire, 10 à 20 secondes entre les tentatives | -- | Oui |
| Nouvelle tentative à décroissance exponentielle | 176 | Commence à 1 s, double jusqu'à 512 s | 1 jour | Non |
Nouvelle tentative avec temporisation
La nouvelle tentative avec temporisation est la politique par défaut. EventBridge retente la livraison d'un événement ayant échoué jusqu'à 3 fois, avec un intervalle aléatoire de 10 à 20 secondes entre les tentatives consécutives. Utilisez cette politique lorsque vous prévoyez des défaillances transitoires qui se résolvent rapidement.
Nouvelle tentative à décroissance exponentielle
La nouvelle tentative à décroissance exponentielle offre une fenêtre de nouvelle tentative plus longue pour les cibles susceptibles de mettre plus de temps à récupérer. EventBridge retente la livraison d'un événement ayant échoué jusqu'à 176 fois sur une période maximale de 1 jour. L'intervalle double à chaque tentative, jusqu'à un plafond de 512 secondes :
1 s, 2 s, 4 s, 8 s, 16 s, 32 s, 64 s, 128 s, 256 s, 512 sUne fois que l'intervalle atteint 512 secondes, les 167 tentatives restantes se poursuivent à des intervalles de 512 secondes.
Erreurs non réessayables
Si les nouvelles tentatives ne peuvent pas être effectuées en raison d'erreurs telles que des configurations de ressources invalides, l'état de la tâche passe à Start Failed quelle que soit la politique de nouvelle tentative ou de tolérance aux pannes. EventBridge ne retente pas ces erreurs car le problème sous-jacent nécessite une intervention manuelle.
Politiques de tolérance aux pannes
Une politique de tolérance aux pannes contrôle la manière dont EventBridge gère un événement qui échoue toujours après l'épuisement de toutes les tentatives. Chaque flux d'événements prend en charge deux politiques de tolérance aux pannes :
| Politique | Comportement après épuisement des tentatives | Effet sur les événements suivants |
|---|---|---|
| Tolérance aux pannes autorisée | L'événement est envoyé à la DLQ (si configurée) ou ignoré | Le traitement continue |
| Tolérance aux pannes interdite | L'état de la tâche passe à Ready | Traitement bloqué jusqu'à ce que vous résolviez le problème |
Tolérance aux pannes autorisée
Lorsque la tolérance aux pannes est autorisée, les échecs de livraison ne bloquent pas le traitement des événements. Après l'épuisement de toutes les tentatives, EventBridge livre l'événement à la DLQ ou l'ignore, puis poursuit le traitement.
Choisissez cette politique lorsque la perte d'événements est acceptable ou lorsque vous avez configuré une DLQ pour capturer les événements ayant échoué.
Tolérance aux pannes interdite
Lorsque la tolérance aux pannes est interdite, les échecs de livraison bloquent le traitement des événements après l'épuisement de toutes les tentatives. L'état de la tâche passe à Ready et aucun autre événement n'est traité tant que vous n'avez pas résolu le problème.
Optez pour cette politique lorsque chaque événement doit être livré et que vous préférez interrompre le traitement plutôt que de perdre des événements.
Files d'attente de lettres mortes
Une file d'attente de lettres mortes (DLQ) capture les événements dont la livraison échoue après l'épuisement de toutes les tentatives. Lorsque vous activez une DLQ sur une tâche, EventBridge envoie les données brutes de l'événement à la DLQ au lieu de les ignorer. La fonctionnalité DLQ est désactivée par défaut.
Cibles DLQ prises en charge
Les services suivants sont pris en charge en tant que cibles DLQ :
| Service | Description |
|---|---|
| ApsaraMQ for RocketMQ | Service de file d'attente de messages |
| Simple Message Queue (anciennement MNS) | Service de file d'attente de messages léger |
| ApsaraMQ for Kafka | Service de file d'attente de messages compatible avec Kafka |
| Bus d'événements EventBridge | Acheminez les événements ayant échoué vers un autre bus d'événements pour un traitement ultérieur |
Quand activer une DLQ
Activez une DLQ lorsque vous devez :
Inspecter et déboguer les événements dont la livraison a échoué
Retraiter les événements ayant échoué après avoir corrigé la cause racine
Conserver un registre de tous les échecs de livraison à des fins d'audit
Si vous utilisez la politique Fault tolerance allowed sans DLQ, les événements ayant échoué sont définitivement ignorés après l'épuisement des tentatives. Pour éviter la perte de données, configurez une DLQ avant d'activer la tolérance aux pannes.