L’historique de disponibilité est la série des contrôles déjà faits, pas le voyant du moment. Chaque ligne dit : à telle heure, cette URL a renvoyé tel code, en tant de millisecondes, et le contenu attendu était là ou non. Avec cette série, on répond à « que s’est-il passé mardi à 22 h ? » et on calcule un taux sur un mois. Sans elle, il ne reste qu’un souvenir d’astreinte.
Ce qu’on enregistre à chaque essai
Gardez le minimum qui permet de reconstruire l’incident, pas la page entière à chaque fois.
- l’URL contrôlée et le lieu du contrôle, s’il y en a plusieurs ;
- l’horodatage, en UTC, pour ne pas mélanger heure d’été et heure d’hiver ;
- le code HTTP final, ou la nature de l’échec (DNS, TLS, délai dépassé) ;
- le temps jusqu’à la réponse ;
- le résultat du test de contenu : chaîne trouvée ou non ;
- un identifiant d’incident, quand plusieurs échecs d’affilée forment le même épisode.
Conserver le HTML complet de chaque essai gonfle le stockage et sert rarement. Conservez le corps seulement sur l’échec, et seulement le temps de comprendre. Le succès se résume en une ligne.
Le monitoring en temps réel affiche la dernière de ces lignes. Dès qu’elle redevient un succès, l’écran ne montre plus la panne. L’historique, si.
Retrouver un créneau
Pour une plainte « le paiement ne marchait pas vers 21 h », filtrez l’URL concernée entre 20 h et 22 h. Vous devez voir soit une suite d’échecs, soit des 200 avec un temps de réponse sorti de l’habitude, soit rien d’anormal. Les trois conclusions sont utiles. La troisième évite de chercher un bug de paiement quand le contrôle extérieur n’a rien vu : la cause est peut-être le navigateur du client, un moyen de paiement tiers, ou une URL que vous ne surveillez pas.
Le pas du contrôle limite la précision. Si vous interrogez toutes les cinq minutes, vous ne prouverez pas ce qui s’est passé à 21 h 01 et 21 h 02. Vous prouverez l’état à 21 h 00 et à 21 h 05. Écrivez cette limite dans le compte rendu, plutôt que d’inventer une durée à la seconde.
Quand plusieurs URL échouent ensemble, l’historique montre si l’accueil et le paiement sont tombés au même horodatage (cause commune : DNS, certificat, origine) ou si seul le paiement a échoué (cause applicative). C’est la différence entre appeler l’hébergeur et ouvrir le déploiement du jour.
Du relevé au taux, sans récit
Le taux de disponibilité sur une période est le temps considéré comme bon, divisé par le temps de la période. La convention habituelle : l’état lu à un contrôle est supposé tenir jusqu’au contrôle suivant. Un échec isolé sur un pas de cinq minutes pèse cinq minutes. Dix échecs de suite pèsent cinquante minutes, pas « une soirée » arrondie au feeling.
N’additionnez pas les URL en un seul pourcentage si vous voulez encore comprendre. Un taux global de 99,8 % peut cacher une page de contact à 90 % et un blog jamais en échec. Calculez par URL, puis éventuellement un taux sur le sous-ensemble des pages critiques.
Ce chiffre brut n’est pas la synthèse mensuelle. La synthèse nomme les incidents, leur durée, et ce qui a été fait. L’historique fournit les minutes. Il ne rédige pas le paragraphe.
Conservez les lignes au moins le temps de vos engagements, souvent treize mois si vous comparez un mois à l’an passé. Au-delà, un agrégat horaire peut remplacer le détail, à condition de ne plus prétendre retrouver une minute précise. SiteGarde a son utilité s’il garde cette série ; un voyant sans archive ne constitue pas un historique.