Le raté, ce n'est pas l'alerte manquée
On juge le monitoring à sa vitesse de détection. C'est le mauvais critère, et il fabrique le mauvais système : intervalles plus courts, seuils plus serrés, une sonde de plus par service, et en un trimestre le canal d'astreinte est devenu de la météo. On y jette encore un œil. On ne le lit plus.
La grandeur intéressante n'est pas le délai de détection, c'est le nombre de notifications qu'un humain peut encore prendre au sérieux. Ce budget est petit, il est individuel, et chaque alerte y puise — y compris celles qui se révèlent n'être rien, surtout celles-là. D'où la thèse de cet article : un système d'alerte doit être lent à crier. Délibérément, mesurablement lent. Les trois minutes passées à confirmer une panne ne sont pas de la détection perdue : c'est ce qui garde au message son sens le jour où il arrive.
Tout ce qui suit vaut pour n'importe quel outil de supervision. La dernière section dit ce que Servor en fait, y compris ce qu'il ne fait pas.
Le délai de détection est une décision, pas une mesure
L'arithmétique est triviale et presque jamais écrite : votre délai de détection vaut l'intervalle multiplié par le nombre d'échecs consécutifs exigés avant la bascule. Une vérification toutes les 60 secondes qui bascule au troisième échec détecte en trois minutes, pas en une. Ajoutez le chemin de notification et vous êtes à trois minutes et demie.
Décidez donc du nombre d'abord. Pour chaque service, demandez-vous quel délai il peut absorber avant que quelqu'un doive savoir, et déduisez-en le couple. Faire l'inverse — choisir 30 secondes parce que ça fait réactif, puis découvrir le battement — c'est la naissance de la plupart des installations bruyantes.
Deux conséquences à garder en tête :
- Échantillonner plus vite ne détecte pas proportionnellement plus vite. Cela multiplie le nombre d'échantillons susceptibles d'échouer pour rien. Sur un réseau normal, la majorité des échecs isolés se sont résorbés avant la vérification suivante : personne n'aurait jamais dû en entendre parler.
- Le plancher n'est pas l'intervalle, c'est la propagation. Un changement de configuration, un TTL DNS, un répartiteur qui vide un nœud : plusieurs des choses que vous surveillez ne peuvent honnêtement pas rapporter un état stable en moins d'une minute.
Hystérésis asymétrique : lent à crier, plus lent encore à rassurer
L'hystérésis, ce sont deux nombres distincts : combien d'échecs consécutifs déclarent la panne, et combien de succès consécutifs déclarent le retour. Les régler à l'identique est le réglage par défaut, et c'est une erreur.
Rendez-les asymétriques, le retour étant le plus exigeant des deux. Un service qui répond une fois puis retombe n'est pas rétabli, il oscille — et chaque oscillation, en réglage symétrique, coûte deux notifications. Trois échecs pour ouvrir et quatre succès pour fermer absorbent l'oscillation entièrement, au prix d'une minute ou deux sur la fermeture, que personne n'attend à ce stade.
Le même scrupule vaut un cran au-dessus. Clore un incident public à la seconde où la vérification repasse au vert, c'est la meilleure façon de le rouvrir vingt minutes plus tard — et un incident rouvert coûte bien plus de confiance que dix minutes d'un honnête « nous observons ». Être lent à annoncer une bonne nouvelle est la crédibilité la moins chère du marché.
Un battement qui survit à une hystérésis raisonnable n'est plus un problème de réglage. C'est un vrai signal : quelque chose est réellement instable, et la réponse est un ticket sur cette instabilité, pas un nombre plus grand dans le compteur d'échecs.
Des seuils qui veulent dire quelque chose
C'est dans les alertes de ressources que niche l'essentiel du bruit, parce qu'une métrique de ressource est un indice de symptôme et qu'on alerte sur l'indice.
- Processeur. Une mesure instantanée ne veut rien dire : 100 % pendant vingt secondes au milieu d'une compilation, c'est la machine qui fait son travail. Alertez sur un dépassement soutenu, avec une durée minimale explicite, et préférez la saturation à l'utilisation : la charge rapportée au nombre de cœurs en dit plus long sur la file d'attente qu'un pourcentage.
- Mémoire. Alerter sur la mémoire libre garantit du bruit, puisqu'un Linux en bonne santé occupe tout ce qu'il peut en cache de pages. Ce qui compte, c'est la mémoire disponible, et surtout l'activité de swap et l'apparition du tueur de processus dans le journal : ce sont des événements, pas des dégradés.
- Disque.Le pourcentage ment aux deux bouts : 90 % d'un volume de 2 To, c'est peut-être des semaines ; 90 % d'un volume de 20 Go, c'est cette nuit. Raisonnez en jours restants au rythme de croissance observé, et gardez un second seuil, haut et non négociable, comme filet pour le jour où un service écrit son journal en boucle.
- Certificats. La panne la plus prévisible du métier, et toujours l'une des plus fréquentes. Elle mérite un avertissement des semaines à l'avance — et elle mérite de ne pas réveiller : il n'y a rien à faire à trois heures du matin d'une expiration dans vingt jours.
Et une sonde qui renvoie 200 alors que sa base est injoignable est pire qu'une absence de sonde : elle fabrique de la confiance. Une page de santé doit échouer quand ses dépendances échouent, sinon ce n'est pas sur elle qu'il faut alerter.
Ce qui mérite de réveiller quelqu'un
Un seul test, appliqué sans sentiment : existe-t-il une action, maintenant, que seul un humain peut faire, et le coût d'attendre demain matin dépasse-t-il celui de l'interruption ? Si la réponse est non, ce n'est pas une alerte d'astreinte. Cela peut rester digne d'être consigné : c'est un autre canal.
Trois niveaux, et chaque chose appartient à exactement un :
- Réveiller. Indisponibilité visible par les clients, données en danger, ressource qui sera épuisée avant l'ouverture des bureaux. Liste courte, et elle doit le rester.
- Prévenir l'équipe. Une dégradation, un échec qui s'est résorbé seul, une file qui grossit à un rythme qui comptera demain. Cela va dans un salon aux heures ouvrées, pas sur un téléphone la nuit.
- Consigner. Tendances, capacité, certificats à trente jours. Cela vit sur un écran que personne n'est obligé de lire dans le noir.
Une contrainte utile : chaque message d'alerte doit contenir ce qu'il faut faire, pas seulement ce qui est cassé. Si personne ne sait écrire cette phrase, l'alerte n'a ni propriétaire ni procédure, et elle redescend au troisième niveau jusqu'à ce qu'elle ait les deux. Les alertes sans action associée sont la première source de bruit de la plupart des installations, et la plus facile à supprimer, puisque les supprimer ne coûte rien.
Regrouper les conséquences sous leur cause
La deuxième grande source de bruit est structurelle et non statistique. Un hôte tombe, et ses huit vérifications tombent avec lui : HTTP, TCP, ping, la sonde SSH, l'espace disque, deux processus et le certificat. Un événement, huit messages, envoyés dans la même minute — moment précis où le destinataire cesse de lire et se met à faire défiler.
La discipline consiste à séparer deux natures de signal et à les traiter différemment :
- Les signaux de cause — l'hôte est injoignable, l'agent ne donne plus signe de vie. Ils sont peu nombreux, et ce sont eux qui doivent notifier.
- Les signaux de conséquence — tout ce qui échoue nécessairement quand la cause est vraie. Ils doivent être enregistrés et affichés, et rester muets tant que la cause est active.
Un agent qui cesse de rapporter est en général la première indication fiable d'une panne d'hôte, parce qu'il s'arrête à la seconde où la machine s'arrête, là où une sonde externe doit encore purger ses échecs consécutifs. Traitez-le pour ce qu'il est : le signal de cause.
Le même raisonnement couvre les travaux planifiés : une fenêtre de maintenance qui ne fait pas taire les vérifications concernées apprend à l'équipe qu'on peut ignorer les alertes pendant les heures de travail — et cette leçon ne reste pas dans la fenêtre.
La répétition n'est pas de l'urgence
Renotifier toutes les cinq minutes sur une panne que tout le monde connaît n'apporte rien, sinon l'habitude de couper le canal. Tant qu'un état n'a pas changé, il n'y a pas d'information nouvelle, et une absence d'information ne devrait pas produire de message. Notifiez sur les transitions — vers la panne, vers le retour — et tenez tout le reste derrière une temporisation.
Il existe un cas légitime de répétition, et c'est un autre mécanisme : personne n'a accusé réception. C'est un problème d'escalade, qu'on règle avec un processus humain et un tour d'astreinte, pas avec un moniteur plus bruyant. Confondre les deux transforme un téléphone en métronome et vous coûte précisément l'accusé de réception que vous cherchiez.
La limite qu'aucun réglage ne franchit : un seul point d'observation
Une vérification mesure un chemin, pas un état. Depuis un point unique, une coupure de transit entre ce point et votre serveur est identique, octet pour octet, à une panne de votre serveur : dans les deux cas, la requête expire. Aucun travail sur les seuils ne lève cette ambiguïté, parce que l'information qui la lèverait n'est pas dans la mesure.
On peut malgré tout la réduire, en faisant se contredire utilement deux signaux :
- la sonde externe échoue et l'agent de la machine s'est tu : la machine est très probablement à terre ;
- la sonde externe échoue alors que l'agent continue de pousser des métriques normales : c'est le chemin qui est suspect, ou le service qui échoue d'une manière que l'hôte ne voit pas ;
- plusieurs cibles sans rapport échouent en même temps depuis le même point : soupçonnez le point d'observation avant de soupçonner tous vos serveurs.
Cela a une conséquence directe sur ce qu'on écrit publiquement. Pendant la fenêtre ambiguë, la formulation honnête décrit ce que l'on observe — « nous constatons des échecs à joindre l'API » — et non une cause non confirmée. Annoncer une cause qu'il faudra retirer coûte plus cher que d'en dire moins. Notre article sur la communication d'incident couvre le reste de ce vocabulaire.
Servor est explicite sur cette limite : ses vérifications partent d'un seul point. S'il faut distinguer formellement une panne de transit d'une panne de service, ou mesurer la disponibilité depuis plusieurs continents, cela demande un service conçu pour ça, à côté et non à la place.
Relire les alertes réellement reçues
Le réglage n'est pas une opération unique. Une fois par mois, reprenez les alertes de la période et rangez-les en trois tas : traitées, résolues avant toute intervention, ignorées. Le deuxième tas est votre arriéré d'hystérésis : chacune de ces alertes est une notification que le système aurait pu absorber. Le troisième est pire : une alerte régulièrement ignorée est un apprentissage, et elle apprend à ignorer la suivante. Supprimez-la ou corrigez-la ; la laisser est la seule option sans bénéfice.
Deux remarques pratiques. Comptez les notifications par personne et par semaine, pas au total : le total est un chiffre de pilotage, le chiffre individuel est celui qui prédit si la prochaine alerte sera lue. Et faites la relecture pendant que les données existent encore : les mesures fines coûtent cher à conserver, si bien que la plupart des outils gardent le détail quelques jours et seulement un agrégat horaire pendant des mois. Un pic de trente secondes est invisible dans une moyenne horaire, et beaucoup de conclusions fausses mais assurées viennent de là. Chez Servor, la frontière est de 7 jours de mesures brutes et 90 jours d'agrégats horaires : prenez les captures pendant l'incident, pas trois semaines après.
Le produit d'un post-mortem doit inclure au moins un réglage modifié : un seuil qui a alerté trop tard, une hystérésis trop nerveuse, une notification qui a réveillé quelqu'un sans qu'aucune action ne soit possible, un message public qui a mal vieilli. Sans cette boucle, la supervision se dégrade discrètement pendant que le parc grossit, et l'équipe finit par se fier à son instinct plutôt qu'à ses sondes.
Ce que le réglage ne répare pas
Si un service tombe réellement plusieurs fois par semaine, aucune hystérésis ne rendra cela agréable — elle le rendra seulement plus discret, ce qui est pire. Une alerte bruyante est souvent le rapport exact d'un système instable, et la correction appartient au système. De même, aucun seuil ne remplace un propriétaire : une alerte dont personne n'est responsable sera ignorée quelle que soit sa calibration. Et rien de tout cela ne sert si l'alerte ne peut pas sortir : un chemin de notification qui dépend de l'infrastructure qu'il surveille n'est pas un chemin de notification.
Ce que Servor met à disposition
Neuf types de vérifications — HTTP, TCP, ping, SSH, DNS, certificat SSL, espace disque, présence de processus, script personnalisé — avec un intervalle réglable de 30 secondes à 1 heure et une hystérésis configurée dans les deux sens : nombre d'échecs avant la bascule, nombre de succès avant le retour. C'est le réglage central décrit dans cet article, et il est propre à chaque monitor, pas global.
Les vérifications peuvent s'exécuter depuis l'agent installé sur la machine, ce qui les rend indépendantes d'une session ouverte dans un navigateur. Le même agent pousse ses métriques toutes les 15 à 300 secondes (60 par défaut), et une alerte distincte signale un agent devenu injoignable — le signal de cause de la section précédente. Les alertes de seuil processeur, mémoire et disque se déclenchent sur dépassement soutenu et ne se répètent pas tant que l'alerte reste active. Les notifications partent vers le courriel, Slack, Discord ou un webhook signé, avec des règles de filtrage et une temporisation anti-répétition ; la discipline cause/conséquence, c'est vous qui l'exprimez à travers ces règles, ce n'est pas le produit qui la devine.
Un incident s'ouvre à la main ou automatiquement à la bascule d'un monitor, et il porte son journal de mises à jour jusqu'à la status page publique. Monitors et status pages sont inclus à partir du plan Operations (100 monitors, 5 pages) et illimités sur le plan AI ; le plan Free n'en propose ni l'un ni l'autre.
Pour le cadre général — choisir quoi surveiller, écrire pendant la panne, tenir un post-mortem qui change quelque chose — voir le guide du monitoring. Et si la vérification que vous vous apprêtez à ajouter est une sonde SSH, l'article sur le durcissement de SSH explique ce qu'elle vous dit réellement.