La synthèse mensuelle de monitoring est un texte court, produit après la fin du mois, à partir des contrôles enregistrés. Elle dit ce qui a été indisponible, combien de temps, et ce qui a changé. Elle n’est pas l’écran que l’astreinte regarde pendant la panne, ni la liste brute des essais. Son lecteur n’a pas vécu les incidents : il doit pouvoir les comprendre sans ouvrir l’outil.
Les rubriques, dans cet ordre
Tenez-vous à une page. Les rubriques suivantes suffisent.
- La période en dates, fuseau indiqué, et la liste des URL incluses. Une URL ajoutée le 20 ne doit pas afficher un taux sur trente jours.
- Le taux par URL, avec la règle de calcul : un contrôle représente l’intervalle qui le sépare du suivant. Renvoyez au mode de calcul plutôt qu’à un chiffre isolé. Le détail des minutes, pour un objectif du type 99,9 %, est dans l’article sur l’objectif de disponibilité.
- Les incidents, un paragraphe ou une ligne chacun : début, fin, durée, URL, symptôme (code 503, échec TLS, contenu absent, délai). Le plus long incident est cité même si le taux du mois reste élevé : quarante minutes d’affilée ne se lisent pas comme quarante minutes éparpillées.
- Le temps de réponse des essais réussis, en médiane du mois, comparée au mois précédent si vous l’avez. Pas un graphique de chaque point.
- Le certificat : date d’expiration la plus proche parmi les noms surveillés.
- Les actions : déploiement, changement DNS, extension de la liste d’URL. Si rien n’a été fait après un incident, écrivez-le. Un mois sans phrase d’action et sans incident est une synthèse valide.
Le temps réel n’apparaît pas dans ce document, sauf pour dire quel intervalle de contrôle était en vigueur. Le lecteur n’a pas à savoir quelle était la couleur du voyant le 12 à 8 h. Il a besoin de la durée.
La calculer depuis les relevés
Ouvrez l’historique, filtrez le mois, groupez les échecs contigus en incidents. Deux échecs séparés par un succès sont deux incidents. Un succès isolé au milieu d’une panne, s’il tient à un seul essai, se note : soit vous le comptez comme une reprise, soit vous documentez pourquoi vous le rattachez au même incident. Choisissez une règle et gardez-la d’un mois à l’autre, sinon les taux ne se comparent pas.
N’importez pas les pages secondaires pour « faire du volume ». Le taux d’un blog statique, contrôlé en même temps que la page de paiement, tire la moyenne vers le haut. La synthèse d’un site vitrine parle de l’accueil et du contact. Celle d’une boutique parle du catalogue seulement si vous le surveillez vraiment.
Les contrôles pendant une maintenance annoncée se traitent selon le contrat : exclus du taux, ou inclus mais listés à part. Si vous les excluez sans le dire, le mois est incomparable au suivant. Une ligne « maintenance le 4, 25 minutes, exclue du taux » suffit.
Ce qu’on ne met pas
Le corps HTML des erreurs, les captures, la liste des cent essais verts, les hypothèses non vérifiées (« sans doute l’hébergeur »). Si la cause est confirmée, une phrase. Si elle ne l’est pas, « cause non identifiée » vaut mieux qu’un roman.
Le lecteur qui veut le détail ouvre l’historique. Celui qui veut agir maintenant n’attend pas ce document : l’incident du mois en cours est déjà passé par l’alerte. SiteGarde fournit les relevés ; la synthèse reste un texte que quelqu’un relit avant envoi, ne serait-ce que pour vérifier qu’une URL retirée en cours de mois n’y figure plus avec un taux absurde.