Réduire le bruit des alertes de monitoring

Une supervision qui alerte trop finit par ne plus alerter du tout : au dixième message sans conséquence, plus personne ne lit le onzième, et c’est celui-là qui annonçait la vraie panne. Réduire le bruit n’est pas un confort, c’est ce qui garde les alertes utiles. Ce guide passe en revue les sources de bruit les plus courantes, et les réglages qui les traitent.

D’où vient le bruit

Quatre causes reviennent presque toujours :

• les micro-coupures — un redémarrage de quelques secondes, une requête perdue sur le réseau ;
• les interventions prévues — un déploiement ou une maintenance qui fait tomber un service, comme prévu, et alerte quand même ;
• les pannes en cascade — une dépendance commune tombe, et dix moniteurs envoient dix alertes pour une seule cause ;
• les mauvais destinataires — toute l’équipe reçoit tout, y compris ce qui ne la concerne pas, et les rappels continuent pendant que quelqu’un corrige déjà.

1. Ne pas alerter sur une micro-coupure

Une seule requête en échec ne prouve pas grand-chose. Avant de conclure à une panne, Uptally refait la vérification deux secondes plus tard, depuis le même lieu : un redémarrage éclair ou un paquet perdu ne déclenche pas d’alerte. Si la seconde tentative échoue aussi, l’incident est ouvert et l’alerte part.

Deux réglages évitent aussi les fausses pannes :

• les codes de réponse acceptés — par défaut, tout code de 200 à 299 est un succès. Une API qui répond volontairement 401 sans jeton, ou une page qui redirige, se règle en conséquence ; les redirections sont suivies, jusqu’à cinq ;
• le délai de réponse — une page HTTP qui met plus de 10 secondes à répondre compte comme un échec. Une page qui approche régulièrement ce délai a un problème de performance, qu’il vaut mieux traiter comme tel.

2. Taire les interventions prévues

Un déploiement annoncé ne devrait réveiller personne. Une fenêtre de maintenance déclare à l’avance une plage horaire pendant laquelle les moniteurs concernés n’ouvrent pas d’incident : ni les membres de l’équipe ni les abonnés de la page de statut ne sont alertés.

Dans Uptally, les vérifications continuent pendant la fenêtre et leurs résultats sont enregistrés : l’historique reste complet, le moniteur affiche simplement l’état « maintenance ». Une fenêtre peut être ponctuelle, quotidienne ou hebdomadaire sur les jours choisis, à l’heure locale de l’organisation. Chaque moniteur peut aussi s’en exclure, pour un service qui doit rester sous surveillance pendant une intervention voisine.

Si un service est toujours en panne à la fin de la fenêtre, un réglage de l’organisation décide s’il faut alerter à ce moment-là.

3. Une panne, un message

Quand un hébergeur, une base de données ou un enregistrement DNS commun tombe, tous les services qui en dépendent tombent avec lui. Recevoir une alerte par moniteur noie la seule information utile : c’est une seule panne.

Le regroupement retient les alertes pendant une minute environ et réunit celles qui vont ensemble en un seul e-mail, qui liste les moniteurs touchés et la raison de chaque échec. Uptally regroupe par le premier tag du moniteur, à défaut par son domaine racine : taguer les moniteurs par dépendance commune — api-paiement, hebergeur-principal — fait coïncider les groupes avec les vraies causes de panne.

La contrepartie est un délai : avec le regroupement, l’alerte arrive une à deux minutes plus tard. Les abonnés de la page de statut, eux, restent prévenus immédiatement. Le regroupement s’active pour toute l’organisation, à partir du plan Growth.

4. Prévenir les bonnes personnes

Une alerte envoyée à tout le monde n’est la responsabilité de personne. Mieux vaut une règle claire : qui reçoit quoi, et par quel canal.

Uptally applique une règle par défaut à toute l’organisation : tous les membres, un rôle, ou une liste de personnes nommées. Sur le plan Scale, un moniteur peut avoir sa propre règle — le moniteur du paiement prévient l’équipe qui en a la charge, sans déranger les autres.

5. Arrêter les rappels une fois l’incident pris en charge

Les rappels servent à ne pas laisser une panne ouverte sans que personne ne s’en occupe. Ils deviennent du bruit dès que quelqu’un s’en occupe.

Dans Uptally, chaque membre choisit s’il veut des rappels par e-mail tant qu’un incident reste ouvert, et à quel rythme : toutes les 15, 30, 60 ou 180 minutes. Deux gestes les arrêtent :

• l’acquittement indique qui a pris l’incident en charge, et arrête les rappels jusqu’à ce qu’il soit relâché ;
• la mise en pause suspend les rappels pendant 30, 60 ou 180 minutes, le temps d’une intervention.

Ni l’un ni l’autre ne touche aux alertes d’ouverture et de résolution : tout le monde saura quand le service est rétabli.

Le problème inverse : la panne qui répond 200

Réduire le bruit ne doit pas rendre aveugle. Une page d’erreur applicative, un site vide après un déploiement raté ou une API qui renvoie une erreur dans un corps JSON peuvent très bien répondre 200 : un contrôle du code de statut les juge en bonne santé.

Le moniteur à mot-clé cherche un texte attendu dans la réponse — ou vérifie qu’un texte n’y figure pas, comme « Erreur interne » — avec une recherche simple ou une expression régulière. L’assertion JSON vérifie qu’un champ existe et, si besoin, qu’il a la valeur attendue. Les deux sont disponibles à partir du plan Growth.

En résumé

• Une alerte ne doit partir que pour une panne réelle, qui dure plus qu’une requête.
• Déclarez les interventions prévues en fenêtres de maintenance.
• Taguez les moniteurs par dépendance commune, et regroupez les alertes.
• Donnez à chaque alerte un destinataire responsable.
• Acquittez un incident dès que quelqu’un le prend en charge.
• Vérifiez le contenu des réponses, pas seulement leur code de statut.

Pour régler la fréquence des vérifications elles-mêmes, voir aussi Bien choisir ses intervalles de monitoring.