Un moniteur qui crie au loup est pire que pas de moniteur du tout. Après quelques fausses alertes, plus personne ne lit les alertes, et la vraie reçoit le même haussement d’épaules. Ce guide explique d’où viennent les fausses alertes et ce que vous pouvez faire.

D’abord, une définition. Une fausse alerte est une alerte sur un problème que vos visiteurs n’ont pas eu. Ce n’est pas la même chose qu’une brève panne réelle : un site inaccessible pendant deux minutes était réellement en panne, et l’alerte avait raison.

D’où viennent les fausses alertes

Une micro-coupure entre le moniteur et le site

La vérification voyage sur l’internet public. Un paquet perdu en route, une liaison saturée ou un court problème de routage peuvent faire échouer une vérification alors que le site est parfaitement sain pour ses visiteurs. C’est la cause la plus courante, et elle passe toute seule.

Le moniteur est bloqué

Les pare-feu, les protections contre les robots et les limites de débit sont conçus pour arrêter les requêtes automatisées, et un moniteur envoie des requêtes automatisées. Si votre protection répond à une vérification par une page de défi ou un 403 Forbidden, le moniteur voit un échec alors que les vraies personnes passent.

UptimeWire considère toute réponse finale hors de la plage 200 à 399 comme une vérification échouée. Cela inclut 401 et 403. Si votre site montre cette réponse aux visiteurs automatisés, autorisez le moniteur. À la date de rédaction, les requêtes d’UptimeWire s’identifient comme UptimeWireBot/1.0.

Une page lente

Une vérification attend une réponse pendant un temps limité. Dans UptimeWire, une vérification abandonne au bout de 15 secondes. Une page qui prend parfois plus de temps, par exemple pendant le préchauffage d’un cache, fera échouer ces vérifications même si un visiteur patient obtiendrait une page.

Surveillez une adresse qui répond rapidement, comme une page simple ou une page de santé, plutôt qu’une page lourde de recherche ou de rapport.

Trop de redirections

UptimeWire suit jusqu’à cinq redirections. Une chaîne plus longue, ou une boucle entre deux adresses, compte comme un échec, avec le motif « plus de 5 redirections ». Les navigateurs sont eux aussi limités ; une chaîne aussi longue est donc un vrai défaut, mais il se peut qu’il n’apparaisse que dans un moniteur.

Une règle de texte de page trop stricte

Une règle de texte de page fait échouer la vérification quand le texte attendu est absent, ou quand un texte interdit apparaît. UptimeWire lit le HTML brut de la page, jusqu’à 1 Mo, et compare le texte sans tenir compte de la casse. Il n’exécute pas de scripts. Le texte que le navigateur ajoute avec JavaScript ne figure pas dans ce HTML ; une règle fondée dessus échouera donc sur une page saine.

Travaux planifiés

Un déploiement, une migration de base de données ou un redémarrage de serveur fait échouer le site volontairement. Si le moniteur n’est pas au courant, il signale une vraie panne que vous avez provoquée. Ce n’est pas faux au sens d’inexact, mais c’est du bruit, et les fenêtres de maintenance planifiées existent pour le supprimer.

Comment les vérifications répétées réduisent le bruit

La défense la plus simple est de ne pas croire un échec isolé. Quand une vérification échoue, UptimeWire vérifie de nouveau. Un incident ne s’ouvre qu’après trois vérifications échouées d’affilée, espacées d’environ 20 secondes. Il se ferme après deux vérifications réussies.

Quand plusieurs emplacements de vérification sont disponibles, un échec doit en outre être constaté par plus de la moitié des emplacements qui ont répondu. Quand un seul emplacement est disponible, un second serveur peut être consulté avant l’ouverture de l’incident, si l’un est configuré. Sans second avis, un incident peut s’ouvrir sur les trois échecs d’un seul endroit.

Le compromis est simple. Répéter une vérification coûte un peu de temps, environ 40 secondes en plus de l’intervalle de vérification. En échange, les fausses alertes baissent fortement. Cela ne donne pas une détection instantanée, et aucun réglage ne le fait.

Fenêtres de maintenance planifiées

Pour les travaux prévisibles, prévenez le moniteur à l’avance. Dans UptimeWire, vous planifiez une fenêtre de maintenance pour un site web. Les vérifications continuent et l’historique montre les échecs, mais :

  • Les alertes d’incident qui commencent dans la fenêtre sont retenues. Si la panne se termine dans la fenêtre, les alertes sont annulées. Si elle dépasse la fin, elles sont envoyées à la fin de la fenêtre.
  • Le temps passé dans la fenêtre est exclu du calcul de disponibilité.
  • Les avertissements sur le certificat, le domaine et le DNS ne sont pas retenus par la fenêtre.

Une fenêtre doit être configurée à l’avance, et des limites s’appliquent à sa durée et à leur nombre. C’est un outil pour les travaux que vous annoncez, pas un moyen de cacher une panne.

Quoi régler, dans l’ordre

  1. Lisez les motifs d’échec. L’historique des incidents montre pourquoi chaque vérification a échoué : délai dépassé, connexion refusée, nom non résolu, erreur de certificat ou code d’état. Une régularité dans les motifs désigne généralement la cause.
  2. Autorisez le passage du moniteur à travers votre protection si le motif est 403 ou un défi.
  3. Choisissez une adresse plus légère si le motif est un délai dépassé.
  4. Revoyez les règles de texte de page. Assurez-vous que le texte figure dans le HTML brut.
  5. Utilisez des fenêtres de maintenance pour les travaux planifiés.
  6. Choisissez où vont les alertes. Envoyez la première alerte à un endroit où une personne la verra, et gardez les canaux bruyants pour l’essentiel.
  7. Envoyez une notification de test pour confirmer que le chemin fonctionne. Elle montre aussi à quoi ressemble l’alerte à 3 h du matin.

Ce qu’il ne faut pas faire

  • N’allongez pas l’intervalle de vérification pour réduire les alertes. Cela ne fait que retarder la détection des vraies pannes.
  • N’ignorez pas une régularité répétée. Si un moniteur échoue à la même heure chaque nuit, il se passe quelque chose à ce moment-là. Ce pourrait être une sauvegarde qui ralentit le serveur.
  • Ne désactivez pas un moniteur pour arrêter le bruit. Corrigez la cause.

Quand l’alerte est réelle mais brève

Une brève panne peut être réelle et pourtant ressembler à du bruit, par exemple un redémarrage qui dure une minute. Si elle se répète, c’est un vrai problème de faible ampleur. Comptez-la. L’historique des incidents enregistre les heures de début et de fin, ce qui vous permet de voir à quelle fréquence et pendant combien de temps cela se produit.

Une vérification HTTP ne peut pas non plus voir tous les types de défaillance. Une réponse 200 ne prouve pas que le paiement fonctionne, et le silence d’un moniteur n’est pas la preuve que tout va bien. Surveillance de la disponibilité d’un site web explique ce qu’une vérification mesure et ce qu’elle manque.

Liste de contrôle

  • Les alertes comportent-elles un motif ? Lisez-le.
  • Le moniteur est-il autorisé à passer à travers la protection contre les robots et les limites de débit ?
  • L’adresse surveillée répond-elle bien en moins de 15 secondes ?
  • Les règles de texte de page reposent-elles sur le HTML brut ?
  • Les changements planifiés sont-ils couverts par une fenêtre de maintenance ?
  • La première alerte va-t-elle à quelqu’un qui agira ?