Éviter les faux positifs d'alerte : le guide multi-régions

Il est 3 h du matin, le téléphone vibre : votre site est « en panne ». Vous ouvrez l'ordinateur, le site répond parfaitement, et personne n'a rien remarqué. Ce scénario coûte plus cher qu'il n'y paraît : une nuit écourtée, mais surtout un peu de confiance en moins dans chaque alerte suivante.

Ce guide explique d'où viennent les faux positifs, comment fonctionne la confirmation depuis plusieurs régions et quels réglages vérifier. Il vaut pour n'importe quel outil ; nous indiquons au passage ce que fait LucidStack.

Qu'est-ce qu'un faux positif, et pourquoi c'est grave

Un faux positif est une alerte déclenchée alors que le service fonctionne pour ses utilisateurs. La sonde a bien constaté un échec, mais celui-ci vient du chemin réseau, de la sonde elle-même ou d'un réglage trop strict.

Le problème, c'est l'accumulation. Après quelques réveils pour rien, on ignore les notifications, on coupe le son du canal. C'est la fatigue d'alerte. Le jour où la panne est réelle, l'alerte arrive dans un canal que plus personne ne lit. Le chapitre consacré à la surveillance dans le livre SRE de Google le résume bien : une alerte qui réveille quelqu'un doit être urgente, exploitable et réelle.

Les causes les plus fréquentes

Avant de régler quoi que ce soit, il faut comprendre ce qui fait échouer une vérification alors que tout va bien.

Côté sonde et réseau

• Un incident réseau passager côté sonde : congestion chez l'hébergeur de la sonde, perte de paquets sur un lien de transit, redémarrage d'un équipement. Le serveur surveillé n'y est pour rien.
• Un hoquet du résolveur DNS : le résolveur utilisé par la sonde met trop de temps à répondre ou renvoie une erreur temporaire. La requête échoue avant même d'avoir atteint votre serveur.

Côté serveur surveillé

• Limitation de débit ou pare-feu applicatif (WAF) : une protection anti-bot voit des requêtes régulières venant toujours des mêmes adresses et finit par les bloquer ou leur servir un défi (403, 429, page de vérification).
• Un délai d'expiration trop court : la page répond en 4 secondes lors d'un pic de charge, la sonde abandonne à 3. Le site est lent, pas en panne.
• Une page lourde : une page d'accueil qui agrège dix appels internes dépend à chaque vérification du maillon le plus lent.
• Les redirections : une redirection HTTP vers HTTPS, vers une langue ou vers une page de connexion change le code de statut et parfois le contenu. Si l'outil ne la suit pas ou si le code renvoyé n'est pas accepté, chaque vérification échoue.
• La maintenance : un déploiement, une mise à jour de base de données ou un redémarrage planifié produisent de vrais échecs, mais attendus. Ce n'est pas une panne au sens de l'astreinte.

Les deux premières causes se règlent par la confirmation multi-régions ; les suivantes par des réglages adaptés.

Le principe de la confirmation, étape par étape

L'idée est simple : un seul point de vue ne suffit pas pour déclarer une panne. Voici comment LucidStack applique la surveillance multi-régions, avec des sondes à Paris, Amsterdam et Varsovie.

1. Une région échoue. Par exemple, la vérification depuis Amsterdam dépasse le délai d'expiration.
2. Les autres régions revérifient immédiatement. Paris et Varsovie lancent aussitôt la même vérification, sans attendre le prochain intervalle.
3. La majorité décide. Si au moins deux régions sur trois échouent, la panne est confirmée : un incident est ouvert et les alertes partent.
4. Sinon, le moniteur passe en « dégradé ». Si les autres régions réussissent, la majorité d'échecs devient impossible : aucune alerte de panne n'est envoyée, mais l'anomalie reste visible.

Concrètement, une confirmation ressemble à ceci :

03:12:04  Amsterdam  échec   délai d'expiration dépassé (30 s)
03:12:05  Paris      succès  200 OK en 310 ms
03:12:05  Varsovie   succès  200 OK en 420 ms
→ 1 échec sur 3 : moniteur « dégradé », pas d'alerte de panne

Et si les régions de confirmation ne répondent pas ? LucidStack déclare alors la panne seulement si la première région a échoué plusieurs fois d'affilée : une sonde injoignable ne masque pas une vraie panne, et un échec isolé n'alerte pas.

La reprise : éviter l'effet yo-yo

Les faux positifs n'arrivent pas qu'au début d'un incident. Un service instable peut alterner échecs et succès, et produire une rafale de notifications « panne » puis « rétabli » : c'est l'effet yo-yo (flapping).

La parade consiste à exiger plusieurs succès consécutifs avant de déclarer le retour à la normale. Dans LucidStack, un service n'est marqué rétabli qu'après plusieurs vérifications réussies d'affilée, deux par défaut. Un succès isolé ne ferme donc pas l'incident.

Régler finement vos moniteurs

La confirmation élimine les incidents réseau. Le reste dépend de vos réglages.

Délai d'expiration

Le délai d'expiration doit refléter ce qui est inacceptable pour vos utilisateurs, pas le temps de réponse habituel. LucidStack utilise 30 secondes par défaut ; le réduire à 5 secondes transforme chaque pic de charge en panne. La lenteur se traite à part.

Codes de statut acceptés

Une API qui renvoie 204, une page derrière authentification qui répond 401, une redirection volontaire en 301 : ce ne sont pas des pannes. Déclarez explicitement les codes attendus plutôt que de vous contenter de « 2xx ». À l'inverse, pointez le moniteur sur l'URL finale quand c'est possible, pour ne pas dépendre d'une redirection.

Seuil de lenteur plutôt que panne

Un site lent mérite d'être suivi, mais il n'a rien à faire dans une alerte de panne. Avec un seuil de lenteur, le service passe en « dégradé » au-delà d'un temps de réponse donné, sans alerte d'indisponibilité. Le suivi du temps de réponse par région, le 95e centile et la détection d'anomalies vous donnent la tendance sans réveiller l'astreinte.

Vérifications par mot-clé

La surveillance par mot-clé attrape les pages qui répondent 200 mais affichent une erreur. Choisissez un texte stable : un élément du pied de page ou un titre structurel, pas une promotion du moment, une phrase traduite selon la langue du visiteur ou un bloc soumis à un test A/B. Pour les textes interdits (« Fatal error », « Database connection »), restez précis afin de ne pas tomber sur un article de blog qui contient ces mots.

Autoriser les sondes

Si un pare-feu, un WAF ou un CDN filtre le trafic, ajoutez les sondes à la liste d'autorisation. Les adresses IP de LucidStack sont publiées sur la page LucidStackBot, et les requêtes portent l'agent utilisateur LucidStackBot. Pour vérifier si les sondes sont bloquées, cherchez-les dans vos journaux :

grep "LucidStackBot" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c

Une série de 403 ou de 429 indique un blocage côté protection, pas une panne.

Fenêtres de maintenance

Planifiez vos opérations dans une fenêtre de maintenance. Pendant cette fenêtre, les vérifications qui échouent ne déclenchent pas d'alerte, et la période est exclue du calcul de disponibilité.

Heures calmes pour ce qui peut attendre

Tout n'a pas besoin d'arriver à 3 h du matin. Avec les heures calmes de LucidStack, les avertissements non urgents (rappel de certificat, service dégradé) attendent la fin de la plage définie, tandis que les pannes et les rétablissements passent toujours. Vous pouvez ainsi garder une stratégie d'alerte exigeante sans sacrifier les nuits de l'équipe.

Checklist : symptôme et correction

En résumé

Un faux positif n'est presque jamais une fatalité. La confirmation multi-régions règle les problèmes de réseau et de sonde ; des réglages réalistes, des sondes autorisées, les fenêtres de maintenance et les heures calmes règlent le reste.

LucidStack applique ces principes par défaut : trois régions incluses dans toutes les offres, y compris l'offre gratuite, une panne déclarée seulement à la majorité, et une reprise confirmée par plusieurs succès. Si vous voulez des alertes que l'on peut croire, c'est un bon point de départ.