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.

Les tentatives sont disponibles pour les vérifications API, multi-étapes, TCP et DNS. Les vérifications navigateur ne réessaient pas ; elles alertent à la place après N échecs consécutifs, comme décrit plus bas.

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.

Les nouvelles vérifications démarrent avec 2 tentatives, ce qui filtre les incidents passagers sans trop retarder une vraie alerte. Réglez Nouvelles tentatives sur 0 pour désactiver la fonction. Les vérifications existantes conservent la valeur enregistrée.

Les réglages

Les réglages se trouvent dans la section Nouvelles tentatives avant alerte du formulaire de la vérification, sur la page de nouvelle vérification API.

Réglage	Plage	Par défaut	Rôle
Nouvelles tentatives	0 à 5	2	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
Temps maximal de tentatives (s)	1 à 300	60	Un budget de temps total pour toute la séquence

Une nouvelle tentative s'exécute toujours depuis le même emplacement que la tentative échouée.

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.

Vérifications navigateur : alerter après N échecs consécutifs

Les vérifications navigateur ne réessaient pas. Dans la même section, le champ devient Alert after N consecutive failures, et la fréquence de votre vérification est l'espacement entre les exécutions. LoadFocus alerte quand N exécutions échouées se produisent d'affilée, de 0 à 5. Une valeur de 0 ou 1 alerte dès la première exécution échouée.

Une notification de rétablissement n'est envoyée que si une alerte a été envoyée : une brève coupure qui n'a jamais atteint N ne produit donc pas de message « rétabli ».

Alerter à chaque échec

Sous Advanced notification options, l'interrupteur chaque fois qu'une vérification échoue envoie une alerte pour chaque exécution en échec, au lieu de seulement quand la vérification commence à échouer. Pour une vérification navigateur avec N supérieur à 1, il commence à alerter quand N exécutions échouées d'affilée sont atteintes, puis alerte à chaque exécution échouée suivante. continuer à me rappeler tant qu'un contrôle reste en panne envoie des rappels répétés selon un calendrier que vous choisissez.

Alerter seulement quand plusieurs emplacements échouent

Par défaut, un seul emplacement en échec marque toute l'exécution comme échouée. Une vérification définie dans un fichier YAML avec Monitoring as Code peut régler locationFailureThreshold sur un nombre N supérieur à 1 : elle n'alerte alors que si au moins N emplacements échouent pendant la même exécution.

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 : réglez Nouvelles tentatives sur 0 pour 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 la vérification. Si une vérification s'exécute chaque minute et que ses tentatives peuvent durer plus d'une minute, une vérification en échec serait encore en train de réessayer quand son exécution suivante est due.

Guides associés

Comment créer une nouvelle vérification API pour les réglages communs des vérifications
Canaux d'alerte pour choisir où les alertes sont envoyées
Surveillance de disponibilité