Nouvelles Tentatives Avant Alerte
Nouvelles Tentatives Avant Alerte
Que sont les nouvelles tentatives ?
Les nouvelles tentatives réexécutent une vérification en échec avant que nous vous envoyions une alerte. Une seule requête en échec n'est pas toujours une vraie panne : une coupure réseau brève, un démarrage à froid lent ou un délai d'attente ponctuel peuvent faire échouer une vérification alors que votre API se porte bien. Les nouvelles tentatives vous permettent de confirmer qu'une panne est réelle avant d'alerter qui que ce soit.
Les nouvelles tentatives n'ont lieu que lorsqu'une vérification échoue. Une vérification réussie n'est jamais réessayée, ce réglage ne vous coûte donc rien tant que tout va bien.
Pourquoi les utiliser ?
La raison principale est le bruit des alertes. Sans nouvelles tentatives, chaque incident passager devient une alerte, et des alertes le plus souvent fausses finissent par être ignorées. Avec elles, vous n'entendez parler que des échecs qui ont survécu à plusieurs tentatives.
Réglez Nouvelles tentatives sur 0 pour désactiver la fonction. Elle est désactivée par défaut.
Les réglages
| Réglage | Plage | Par défaut | Rôle |
|---|---|---|---|
| Nouvelles tentatives | 0 à 5 | 0 (désactivé) | Combien de tentatives supplémentaires après le premier échec |
| Intervalle (s) | 1 à 60 | 10 | L'attente de base entre les tentatives |
| Backoff | Fixe, Linéaire, Exponentiel | Fixe | Comment l'attente augmente à chaque tentative |
| Région | Même région, Autre région | Même région | Où la nouvelle tentative s'exécute |
| Temps maximal de tentatives (s) | 1 à 300 | 60 | Un budget de temps total pour toute la séquence |
Fonctionnement du backoff
Le backoff détermine combien de temps nous attendons avant chaque tentative, à partir de votre Intervalle. Pour un intervalle de 10 secondes :
| Tentative | Fixe | Linéaire | Exponentiel |
|---|---|---|---|
| 1re tentative | 10s | 10s | 10s |
| 2e tentative | 10s | 20s | 20s |
| 3e tentative | 10s | 30s | 40s |
- Fixe attend le même intervalle à chaque fois. À utiliser lorsque vous prévoyez qu'un échec se résorbe vite.
- Linéaire fait croître l'attente régulièrement. Un compromis raisonnable.
- Exponentiel double l'attente à chaque fois. À utiliser lorsqu'un service en difficulté a besoin de répit et que vous ne voulez pas que vos tentatives alourdissent la charge.
Temps maximal de tentatives
Le temps maximal de tentatives est un budget pour toute la séquence, mesuré depuis le début de la première tentative. Avant chaque attente, nous vérifions si cette attente ferait dépasser le budget à la séquence. Si c'est le cas, nous arrêtons et signalons le dernier échec.
Cela signifie que le budget peut mettre fin à vos tentatives avant que vous les ayez toutes utilisées, et c'est voulu. Par exemple, avec un intervalle de 10 secondes, un backoff Exponentiel, 3 tentatives et un budget de 60 secondes, la troisième tentative demanderait une attente de 40 secondes en plus des quelque 30 secondes déjà écoulées. Cela dépasse le budget, la vérification s'arrête donc après la deuxième tentative.
Si vous voulez que toutes vos tentatives s'exécutent, veillez à ce que le budget soit supérieur au total des attentes ci-dessus.
Ce qui est enregistré
Seule la dernière tentative est enregistrée comme résultat de la vérification. C'est ce qui rend les nouvelles tentatives utiles :
- Échoue, puis réussit lors d'une tentative : la vérification est enregistrée comme réussie et aucune alerte n'est envoyée. L'incident passager ne vous parvient jamais.
- Échoue à chaque tentative : la vérification est enregistrée comme en échec et vos canaux d'alerte se déclenchent normalement.
Comme seul le résultat final est stocké, les nouvelles tentatives ne faussent pas vos chiffres de disponibilité avec des incidents passagers.
Région
Même région réessaie depuis l'emplacement qui a constaté l'échec. Autre région est prévu pour confirmer un échec depuis un second emplacement. Dans la version actuelle, « Autre région » réessaie toujours dans la même région.
Cas d'usage pratiques
- API publiques sur internet : 1 à 2 tentatives avec un backoff Fixe et un intervalle court filtrent le bruit réseau habituel.
- Services à démarrage à froid : utilisez un backoff Linéaire ou Exponentiel pour laisser à une première réponse lente le temps de se réchauffer.
- Un service sous charge : utilisez un backoff Exponentiel pour que vos tentatives lui laissent de la marge au lieu d'ajouter de la pression.
- Vérifications critiques devant alerter immédiatement : laissez Nouvelles tentatives sur
0pour qu'un seul échec alerte tout de suite.
Une note sur la fréquence
Gardez votre budget de tentatives en dessous de la fréquence de votre vérification. Si une vérification s'exécute chaque minute et que vos tentatives peuvent durer jusqu'à 300 secondes, une vérification en échec serait encore en train de réessayer à l'heure de son exécution suivante.