Stratégies de revérification : confirmer un statut avant d'alerter

Pourquoi une seule vérification échouée n'est pas une panne

Un résultat de vérification décrit une seule requête, depuis un seul endroit, à un seul instant. Chacun de ces trois éléments peut se tromper sur l'état réel du site. Le réseau entre un seul point de contrôle et votre serveur peut être coupé alors que toutes les autres routes fonctionnent bien. Un enregistrement DNS peut encore être en cours de propagation dans une région et déjà correct dans la suivante. L'environnement propre à un point de contrôle peut être incompatible avec quelque chose que votre serveur fait.

Si un système de surveillance agissait sur chaque premier résultat, il vous alerterait pour tous ces cas et corromprait aussi vos statistiques de disponibilité, puisque la panne enregistrée ne s'est jamais réellement produite pour vos utilisateurs. Le statut détecté, UP ou DOWN, est donc conservé comme non vérifié jusqu'à confirmation, et c'est seulement à ce moment que la suite se déclenche : une alerte partant, un épisode s'ouvrant, le chiffre de disponibilité bougeant.

Ce qu'une revérification permet d'écarter

Revérifier depuis d'autres emplacements est ce qui distingue un vrai changement, valable pour tout le site, d'un artefact local. Les cas les plus souvent écartés sont :

• Une courte interruption pendant un nouveau déploiement, où le site est de nouveau en ligne avant qu'une deuxième vérification ne s'exécute
• Une indisponibilité DNS pendant qu'un changement de configuration se propage, de sorte que certains résolveurs répondent et d'autres non
• Un blacklistage local du site ou de l'adresse du point de contrôle, visible depuis un seul réseau uniquement
• Un agent de vérification dont l'environnement est incompatible avec les technologies que le serveur utilise
• Un problème de routage ou de peering sur le chemin entre un seul point de contrôle et le serveur

Les vérifications de confirmation sont tirées de la région géographique configurée pour la tâche de surveillance, de sorte que le second avis vienne de la même partie du monde que vos utilisateurs plutôt que d'un endroit choisi au hasard.

Les trois stratégies de revérification

HostTracker propose trois façons de décider si un nouveau statut est réel.

1. Vote majoritaire. Quand une vérification renvoie un nouveau statut, le système alloue jusqu'à 7 nouveaux emplacements de la région géographique de la tâche de surveillance pour le confirmer. Les résultats renvoyés sont regroupés par statut, et le groupe le plus grand l'emporte. Supposons qu'une vérification depuis Miami signale DOWN, et que les revérifications depuis New York, Boston et Chicago reviennent UP, DOWN, UP. Le DOWN n'est pas confirmé et est écarté, et Miami est pénalisée : elle ne sera plus utilisée pour vérifier ce site. Reprenez le même exemple dans l'autre sens, avec Miami signalant UP après un DOWN et New York et Chicago confirmant UP, et la transition DOWN-UP est enregistrée.

2. Un nombre fixe d'emplacements confirmant DOWN. Ici, vous configurez le nombre minimum de revérifications nécessaires pour confirmer un DOWN, tandis qu'un UP exige toujours le vote majoritaire. Avec ce nombre fixé à 1, dans le même exemple, Boston seule renvoyant DOWN suffit à confirmer le DOWN de Miami, même si New York et Chicago étaient en désaccord.

3. Aucune revérification. Le nouveau statut est toujours confirmé dès qu'il est détecté. Cela suppose une confiance totale dans le serveur et dans les environnements des emplacements de surveillance. Cela convient à quelques besoins de surveillance spécifiques, et le choix doit être fait avec prudence, car chaque problème réseau passager sur un seul point de contrôle devient une fausse alerte et une entaille dans le chiffre de disponibilité.

Choisir une stratégie

1. Commencez par le vote majoritaire. C'est le réglage par défaut équilibré : il coûte quelques secondes de confirmation supplémentaires et élimine presque tout le bruit provenant d'un seul point de contrôle.
2. Abaissez le seuil de confirmation DOWN quand une alerte rapide vaut plus qu'une boîte de réception tranquille. Une panne régionale que seuls deux emplacements peuvent voir vous atteint quand même, au prix de davantage de faux positifs.
3. Gardez le vote majoritaire pour les transitions UP, quel que soit le réglage choisi pour DOWN. Un UP prématuré clôt un incident qui est encore en cours et cache la fin de la panne dans vos statistiques.
4. Réservez l'absence de revérification aux cibles que vous maîtrisez de bout en bout, là où vous préférez enquêter sur une fausse alerte plutôt qu'attendre une confirmation.

Quelle que soit la stratégie choisie, vous pouvez reproduire un désaccord vous-même depuis deux réseaux différents et comparer ce que chacun voit :

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/

Un 503 depuis un réseau et un 200 depuis un autre correspondent exactement au schéma que la revérification est conçue pour résoudre. Si le statut en échec est un 5xx plutôt qu'un délai dépassé, le serveur a répondu, ce qui est un problème différent : voir 503 Service Unavailable.

Ce que la confirmation vous apporte

Les revérifications sont ce qui permet à un système de surveillance d'effectuer des vérifications fréquentes depuis de nombreux endroits sans transformer cette sensibilité en bruit. HostTracker vérifie depuis plus de 300 points de contrôle répartis dans 158 villes, donc des emplacements indépendants sont toujours disponibles pour le second avis, et seule une transition confirmée déclenche une alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien d'autres canaux. Les stratégies ci-dessus ne forment pas l'ensemble complet des possibilités, et le support peut en envisager une nouvelle pour une future version si votre surveillance a un besoin qu'aucune d'elles ne couvre. Voir surveillance de disponibilité distribuée pour savoir comment le réseau de points de contrôle est utilisé, et le reste de la section des concepts de surveillance pour les termes qui s'y rapportent.