Hygiène des alertes pour la supervision d'hôtes : taux de variation plutôt que seuil fixe, unités en échec et fenêtres de durée

Ce que c'est

Le livre SRE de Google indique que « paging a human is a quite expensive use of an employee's time » (alerter un humain coûte cher en temps de travail) et qu'un alerting efficace exige « good signal and very low noise » (un bon signal et très peu de bruit) : chaque page qui ne demande finalement aucune action apprend à l'ingénieur d'astreinte à accorder moins de confiance aux pages. Le chapitre du SRE workbook consacré à l'alerting sur les SLO décrit l'alerting multifenêtre, qui ne se déclenche que si le taux de consommation du budget d'erreur (burn rate) est élevé à la fois sur une fenêtre longue (un pic bref ne déclenche donc pas de page) et sur une fenêtre courte (l'alerte se résout peu après le retour à la normale).

Appliquées à un hôte isolé plutôt qu'au SLO d'un service, ces deux idées permettent de décider lesquels des signaux traités ailleurs dans cette série relèvent d'une page d'astreinte et lesquels d'une file de tickets :

• Espace disque : un pourcentage fixe (par exemple « alerter à 90 % de remplissage ») déclenche la même page que la partition soit restée à 91 % sans changement pendant six mois ou qu'elle soit passée de 60 % à 91 % au cours de la dernière heure. Le taux de remplissage — le temps estimé avant saturation au rythme de croissance actuel — est le signal qui prédit réellement une panne imminente : un 91 % lent et stable relève du ticket, une partition qui va se remplir dans l'heure relève de la page.
• Unités systemd en échec / services Windows arrêtés : une unité en échec à l'instant présent et censée tourner se rapproche du cas « déjà en panne » que le livre SRE considère comme digne d'une page ; une unité qui a échoué une fois et a déjà été relancée par sa propre logique de nouvelle tentative relève du ticket, pas de la page.
• Synchronisation d'horloge : un hôte dont l'horloge a dérivé au point de casser la validation TLS ou la corrélation des journaux justifie une page ; un délai d'attente NTP ponctuel qui se résout à l'interrogation suivante, non.
• Santé SMART/NVMe : un auto-test en échec ou un octet de critical warning non nul justifie une page, vu le court délai avant perte de données ; un unique secteur réalloué sur un disque par ailleurs sain donne lieu à un ticket de surveillance.

Pourquoi c'est important

Alerter sur la valeur instantanée brute d'une métrique, sans exigence de durée ni de tendance, est précisément ce qui produit l'instabilité (flapping) et le bruit contre lesquels met en garde le livre SRE : un seuil qui oscille autour de sa limite se déclenche et se résout à répétition, et la fatigue d'alerte qui en résulte est le même mode de défaillance, que la métrique soit un pourcentage de disque ou un taux d'erreurs HTTP.

Comment l'appliquer

• Pour chaque alerte d'hôte, se demander si la règle réagit à un taux ou une tendance, ou bien à un niveau brut, et si elle exige que la condition persiste sur une fenêtre plutôt que sur un échantillon instantané.
• Envoyer les conditions « déjà en panne, action requise maintenant » (disque sur le point de se remplir dans la fenêtre d'astreinte, unité indispensable arrêtée, horloge désynchronisée) vers une page ; envoyer les conditions « à examiner prochainement » (lentes, stables ou déjà résolues) vers un ticket ou un tableau de bord.
• Réévaluer toute alerte qui déclenche plus de quelques pages sans correction réelle correspondante — l'étude de cas Bigtable du livre SRE décrit la désactivation d'alertes par e-mail devenues trop nombreuses pour être diagnostiquées.

Pièges

• Copier un seuil de disque en pourcentage d'un hôte à un autre dont le rythme de croissance est très différent : le même chiffre correspond alors à une marge de manœuvre différente.
• Traiter une page et un ticket comme une même sévérité avec des canaux de diffusion différents, plutôt que comme deux classes d'urgence distinctes.