Nouvelles tentatives et seuils d'alerte

Pourquoi les faux positifs se produisent

Une seule exécution en échec ne signifie pas toujours que votre service est down. Une microcoupure réseau, un handshake lent ou une région de monitoring instable peuvent faire passer un endpoint sain pour cassé pendant un instant. LoadFocus vous offre trois couches qui empêchent ces faux positifs de vous réveiller : les nouvelles tentatives (retries), un seuil d'échecs consécutifs et un seuil multi-emplacements.

Ces trois réglages se trouvent sur le check lui-même, sur la page New API Check, et fonctionnent pour les checks API, TCP, DNS et navigateur.

Nouvelles tentatives (retries)

Quand un check échoue, LoadFocus peut le retenter avant de marquer l'exécution comme échouée. Une microcoupure transitoire qui réussit à la nouvelle tentative ne devient jamais un échec. Vous pouvez configurer :

• Nombre de tentatives : combien de fois retenter, de 0 à 5.
• Intervalle entre les tentatives : le délai d'attente entre chaque tentative, de 1 à 60 secondes.
• Stratégie de backoff : espacement fixed, linear ou exponential entre les tentatives.
• Région de la nouvelle tentative : retenter depuis la même région ou depuis une région différente, pour écarter le bruit local d'une région.
• Durée totale maximale des tentatives : un plafond sur la durée cumulée de toutes les tentatives.

Seuil d'échecs consécutifs

Les nouvelles tentatives absorbent les microcoupures au sein d'une exécution, mais un check peut encore produire une mauvaise exécution isolée. Au lieu d'alerter dès le premier échec, vous pouvez n'être alerté qu'après N exécutions échouées consécutives. Si vous préférez une sensibilité maximale, vous pouvez aussi choisir d'être alerté à chaque échec.

Les notifications de rétablissement sont envoyées quand le check repasse au vert, vous savez donc toujours quand l'incident est terminé.

Seuil multi-emplacements

Quand un check s'exécute depuis plusieurs régions, vous pouvez définir combien d'emplacements doivent échouer pour que le check compte comme échoué. Cela agit comme un quorum : une seule région instable ne peut pas vous alerter à elle seule, tandis qu'une vraie panne visible depuis plusieurs régions le fait toujours.

Comment les trois couches se combinent

Chaque couche absorbe un type de bruit différent :

• Les nouvelles tentatives absorbent les microcoupures au sein d'une même exécution.
• Le seuil d'échecs consécutifs absorbe les mauvaises exécutions isolées.
• Le seuil multi-emplacements absorbe le bruit d'une seule région.

Ensemble, elles font qu'une alerte reflète presque toujours un problème réel, durable et visible depuis plusieurs régions. Pour les réglages communs des checks, consultez Comment créer un nouveau check API. Pour choisir où vos alertes sont envoyées, consultez les canaux d'alerte, et découvrez l'Uptime Monitoring.