Comprendre les alertes

Une alerte est un message envoyé parce qu'un incident s'est ouvert, ou parce qu'il s'est terminé. Ce n'est pas la supervision qui pense à voix haute : tout ce qui vous parvient a d'abord été confirmé.

Ce qui en déclenche une#

Un check — une des observations que Webmonit relance sans cesse : aller chercher une page, résoudre un nom, envoyer un ping — échoue. Cela seul ne déclenche rien : un paquet perdu n'est pas une panne. Le check est relancé quelques secondes plus tard, puis encore une fois ; par défaut les re-tests ont lieu 15 et 45 secondes après le premier échec, et il faut deux échecs de suite pour qu'un incident s'ouvre. L'administrateur peut régler ces valeurs autrement.

Quand l'échec tient, l'incident est confirmé, et c'est à ce moment que l'alerte part.

Un incident porte l'un de deux niveaux d'attention :

• critical, critique — un service vital d'un host (la machine surveillée) s'est arrêté : la machine elle-même, ou quelque chose sur quoi repose le reste de son travail. C'est le niveau fait pour réveiller quelqu'un.
• warning, avertissement — un site est tombé, ou un check secondaire a trouvé quelque chose. De l'attention, pas un incendie.

Ce second point surprend, alors autant le dire nettement : un de vos sites en panne est un warning, pas un critical. Sur la vue d'ensemble, il est compté sous Open warnings et non sous Open alerts. Ce n'est pas un jugement sur votre site. C'est un jugement sur la différence entre un site injoignable et la machine qui en porte deux cents devenue injoignable.

Pourquoi une alerte peut arriver après la panne#

Quatre raisons, toutes délibérées.

Une panne est confirmée avant d'être annoncée. C'est le délai décrit plus haut : des secondes, pas des minutes, et c'est ce qui empêche un paquet perdu ou une mauvaise seconde de devenir un message sur votre téléphone.

Un check tourne à intervalle. Rien n'est surveillé en continu — ce serait marteler les machines mêmes qu'on surveille. Par défaut, la page d'un site est récupérée toutes les cinq minutes, un host reçoit un ping toutes les dix secondes, le DNS est lu tous les quarts d'heure, un certificat toutes les six heures, et l'enregistrement d'un domaine une fois par jour. Le pire cas pour la panne d'un site est donc à peu près un intervalle plus la confirmation. Pour un certificat cela n'a aucune importance : ce qui est surveillé là est une date, à des semaines de distance.

Une alerte par cause. Quand un host ne répond plus à son ping — plus rien ne revient, ce qui n'est pas la même chose que quelques paquets perdus —, tous les sites qu'il porte, et chacun de ses propres services (serveur web, base de données, ports), échouent à la même seconde. Vous recevez un seul message, qui nomme le host et combien de sites il porte ; les autres incidents s'ouvrent quand même et sont bien enregistrés, rangés sous celui du host, et ils n'envoient rien. Avant qu'un check sur une machine soit confirmé, la machine reçoit d'abord un ping si elle n'a pas répondu depuis une demi-minute : quelques secondes, pour que la cause soit connue avant que ses conséquences soient annoncées. Quand le host répond de nouveau, tout ce qui était rangé sous lui est revérifié aussitôt : ce qui est revenu se ferme sans message, comme il s'était rangé ; ce qui échoue encore est annoncé à ce moment-là, comme une panne à part entière. Dans l'historique, l'incident du host porte le nombre d'incidents rangés sous lui ; with folded les liste chacun sur sa ligne. Il en va de même à l'intérieur d'un site : un nom doit résoudre avant qu'une page puisse répondre, et une page doit répondre avant que son certificat veuille dire quelque chose, de sorte qu'un site qui tombe envoie une alerte et non cinq. Si vous ne recevez rien alors que votre site est manifestement en panne, regardez le host : le message est parti à son sujet.

Rien n'est envoyé pendant que la supervision est aveugle. Si la machine sur laquelle tourne Webmonit perd son propre réseau, tout paraît en panne depuis l'endroit où elle se trouve. Elle le dit, une fois, sur ses propres pages, et n'envoie plus aucune alerte tant qu'elle ne voit pas de nouveau.

Ce que dit le message#

Le premier mot du titre est la nouvelle :

• DOWN — un site ou un check est tombé, et c'est confirmé.
• HOST DOWN — une machine ne répond plus du tout : son ping ne reçoit aucune réponse. Un de ses services qui tombe — un port mail, son serveur web — est un DOWN qui nomme ce service, critique tout autant.
• WARNING — quelque chose qui n'est pas une panne demande de l'attention : un certificat qui approche de son expiration, un disque qui vieillit, une grappe RAID en reconstruction. Rien n'a cessé de répondre.
• UP — c'est revenu. Le message dit combien de temps c'était parti.
• RESOLVED — l'avertissement est levé. Rien ne s'était arrêté, donc rien n'est « remonté ».
• STILL DOWN — un rappel au sujet d'une panne que personne n'a encore acquittée, quand les rappels sont activés.
• CHANGED — une panne que quelqu'un avait acquittée s'est transformée en une autre panne ; l'acquittement a donc été levé et il faut regarder de nouveau.
• CLOSED — et celui-là n'est pas une bonne nouvelle. Il signifie que le check a cessé d'être exécuté — remplacé, mis en pause ou supprimé — et que son incident a donc été fermé. Rien n'est rétabli ; c'est la question qui a cessé d'être posée.

Sous le titre, un fait par ligne : quel check, ce qu'il fait, le site, le host, le compte, l'erreur dans les mots du check, combien de sites porte la machine quand c'est une machine entière qui est tombée, et depuis quand. Quand l'administrateur a renseigné une adresse publique pour l'interface, le message porte en plus un lien direct vers l'incident.

Répéter une alerte#

Par défaut, une panne est dite une fois, quand elle arrive, et une fois encore quand elle se termine. Un administrateur qui veut qu'un critical non acquitté soit répété peut l'activer dans Channels — toutes les trente minutes, toutes les heures ou toutes les quatre heures — et il est alors répété aussi longtemps qu'il n'est ni acquitté ni résolu. Ce sont les messages STILL DOWN, et ils portent depuis combien de temps la panne dure et que personne ne s'en est chargé : utile quand un message unique à trois heures du matin risque de passer inaperçu, du bruit quand la personne qui lit est déjà dessus.

Un warning ne se répète pas. Il envoie un message quand il s'ouvre et un quand il se termine.

Acquitter#

Acquitter un incident, c'est écrire : j'ai vu, je m'en occupe. Cela enregistre qui, quand, et une note — ce qui a été constaté, ce qui est en train d'être fait.

Cela fait trois choses et pas une de plus. Cela arrête les rappels, quand ils sont activés. Cela déplace la panne du compte « en attente d'être remarquée » vers le compte « prise en main ». Et cela laisse la note là où la prochaine personne qui regardera la trouvera.

Cela ne résout pas l'incident. L'incident reste ouvert jusqu'à ce que la chose se rétablisse réellement, et le site reste en panne jusqu'à ce qu'il soit revenu. Et si ce qui est cassé se transforme en une autre panne, l'acquittement est levé tout seul et un message CHANGED part — parce que ce qui a été acquitté n'est pas ce qui se passe maintenant.

Acquitter demande un compte autorisé à écrire. Un compte en lecture seule ne peut pas acquitter, mais il voit sur chaque incident ouvert qui l'a acquitté, à quelle heure, et ce qui a été écrit. C'est en général la réponse à la question « est-ce que quelqu'un est déjà au courant ».

Les fenêtres de maintenance#

Une fenêtre de maintenance est une période déclarée à l'avance pendant laquelle les pannes sont attendues : une migration, une sauvegarde nocturne qui ralentit une machine, une montée de version.

Pendant qu'une fenêtre est ouverte, les checks continuent de tourner et les résultats continuent d'être enregistrés — l'historique n'est pas falsifié — mais les cibles couvertes se lisent maintenance et non down, et aucune alerte ne part. Une fenêtre peut couvrir un site, un host entier et ses sites, tout l'arbre d'un client, ou tout. Elle peut être ponctuelle ou revenir chaque jour à une heure donnée, ce qui est la bonne réponse pour une sauvegarde qui charge une machine toutes les nuits.

Une fenêtre déclarée après coup fonctionne de la même façon : un hôte tombé trois minutes avant que vous déclariez la fenêtre se lit maintenance à partir de là, plus rien ne sonne pour lui tant que la fenêtre est ouverte, et si sa panne avait été annoncée, son retour l'est aussi — un canal qui a entendu « down » entend « up ». Deux détails valent d'être connus. Si une panne survit à sa fenêtre, l'alerte retenue est délivrée à la fermeture de celle-ci : un site tombé pendant la maintenance et jamais revenu est une panne dont personne n'a été prévenu, et Webmonit ne la laisse pas dans cet état. Et une fenêtre peut être marquée publique, auquel cas son titre et sa note sont annoncés sur les pages de statut publiques, avant qu'elle commence et pendant qu'elle dure.

Déclarer une fenêtre demande un compte autorisé à écrire. Les fenêtres sont visibles dans l'interface dans tous les cas, et un site couvert par l'une d'elles s'affiche en bleu et le dit.

Ce qu'une fenêtre a couvert compte comme de la maintenance, pas comme une panne : sur les pages de statut, ses heures s'affichent en bleu et restent hors du chiffre de disponibilité, de même que les jours agrégés. C'est décidé à la lecture de l'historique : une fenêtre déclarée après coup — l'intervention du fournisseur apprise au moment où elle commence — ou remise au bon jour ensuite compte exactement pareil. Les dates d'une fenêtre, son titre, sa description et le fait qu'elle soit publique se modifient à tout moment depuis la page des fenêtres ; ce qu'elle couvre, non : une fenêtre sur une autre machine est une autre fenêtre. Les alertes déjà parties avant que la fenêtre soit déclarée ou corrigée ne peuvent pas être rappelées.

Choisir ce dont on vous parle#

Sous My alerts (« mes alertes »), un compte décide de ce qui lui parvient et où. Deux pièces :

Un canal (channel) est un endroit où un message peut être envoyé — une adresse e-mail, un téléphone via ntfy, un salon Discord ou Matrix, un webhook vers quelque chose à vous. Vos canaux vous appartiennent quel que soit votre accès : un compte en lecture seule peut en ajouter, les tester et les retirer, parce qu'ils ne changent rien à la supervision elle-même. Si votre compte porte une adresse e-mail, elle fonctionne sans aucun canal.

Un abonnement (subscription) dit quel sujet part vers quel canal, et à partir de quel niveau : tout ce que vous voyez, un host, ou un site ; et warnings and worse (les avertissements et pire), outages only (les pannes seulement), critical only (les critiques seulement), ou everything (tout, remarques comprises). Sans abonnement, on ne vous dit rien — la page l'écrit noir sur blanc.

Rien de tout cela ne touche aux alertes de l'administrateur. Ce à quoi vous vous abonnez s'ajoute à ce qu'il reçoit déjà.

Quoi faire quand une alerte arrive#

Lisez le premier mot. Il vous dit si quelque chose est cassé (DOWN, HOST DOWN), si quelque chose demande de l'attention avant de casser (WARNING), ou si la nouvelle est bonne (UP, RESOLVED).

Ouvrez le lien. La page de l'incident porte la cause dans les mots du check, les résultats qui entourent la panne, et les preuves (evidence) : ce que le site a réellement répondu pendant qu'il échouait — la ligne de statut, les en-têtes, les premiers kilo-octets de la page. C'est là que vit le « pourquoi ».

Regardez si l'incident est rangé sous un autre. Si la page indique qu'il est rangé sous celui d'un host, c'est la machine qui est cassée, l'administrateur a déjà un message à son sujet qui nomme tous les sites touchés, et ce qu'il y a à faire est d'attendre le host.

Regardez si quelqu'un l'a acquitté, et lisez sa note.

S'il s'agit d'un WARNING au sujet d'une date — un certificat qui arrive à terme, un domaine dont l'enregistrement approche de son échéance — rien n'est cassé pour l'instant et il reste du temps. C'est exactement à cela que sert l'avertissement. Mais cela deviendra une panne au jour dit si personne n'agit, et la personne qui peut agir, c'est parfois vous plutôt que l'administrateur.

Si vous ne pouvez rien y faire vous-même, prévenez l'administrateur, et donnez-lui le numéro de l'incident. Chaque incident en a un, il est dans le message et en haut de sa page, et il vous épargne à tous les deux la recherche.