Monitoring serveur : moins de bruit, des alertes qui comptent

L'erreur la plus courante consiste à empiler des sondes d'infrastructure sans jamais interroger le service lui-même. Un hôte qui répond au ping ne dit rien d'un pool de connexions saturé ni d'un worker bloqué. L'erreur inverse existe aussi : une seule vérification sur la page d'accueil ne suffit plus dès que le produit dépend de plusieurs services. Donnez un point de contrôle à chaque chemin critique, et faites en sorte qu'une page de santé signale l'échec quand ses dépendances vont mal. Une sonde qui renvoie 200 alors que la base est injoignable est pire que pas de sonde du tout.

Les contrôles de fond, ceux qui n'observent pas la disponibilité mais achètent du temps, méritent un traitement séparé. Un certificat qui expire dans dix jours, un volume à 88 %, un démon arrêté sans bruit : rien ne casse aujourd'hui, tout casse un dimanche matin. Ces vérifications s'exécutent lentement, une à quatre fois par heure, et sortent par un canal qui n'a rien à voir avec l'astreinte.

Trente secondes est un plancher raisonnable pour une vérification HTTP sur un service exposé ; une heure suffit largement pour un certificat ou un volume disque. Échantillonner plus vite coûte en charge sur la cible et, surtout, en faux positifs : plus la fréquence monte, plus vous capturez de micro-coupures réseau dont aucun utilisateur ne s'est aperçu. Sur un lien correct, la majorité des échecs isolés se résorbent avant la vérification suivante, et personne n'aurait dû en entendre parler.

Les seuils de ressources obéissent à une autre logique. Un CPU à 100 % pendant vingt secondes au milieu d'une compilation n'est pas un incident ; une charge au-dessus de la capacité pendant dix minutes en est un. Réglez donc processeur et mémoire sur un dépassement soutenu, avec une durée minimale explicite. Pour le disque, le pourcentage seul ment : 90 % d'un volume de 2 To laissent des semaines, 90 % de 20 Go laissent une nuit. Raisonnez en jours restants au rythme de croissance observé, et gardez un second seuil, haut et non négociable, comme filet.

L'hystérésis traite le flapping, ce va-et-vient d'un monitor qui oscille entre les deux états et produit deux notifications par minute. Exiger trois échecs consécutifs pour déclarer la panne et deux succès pour déclarer le retour absorbe les creux courts sans retarder sérieusement la détection. L'asymétrie est délibérée : on veut être lent à crier, et plus lent encore à annoncer que tout va bien, parce qu'un service qui remonte une fois puis retombe n'est pas rétabli. Le même scrupule vaut avant de clore un incident public.

Le deuxième gisement de bruit est structurel. Quand une machine tombe, ses huit vérifications tombent avec elle et l'astreinte reçoit huit messages pour un seul événement. Séparez le signal de cause, l'hôte muet ou l'agent injoignable, des signaux de conséquence, et faites taire les seconds tant que le premier est actif. Séparez aussi les canaux : l'astreinte reçoit ce qui exige des mains sur un clavier tout de suite, un salon d'équipe reçoit le reste, et les tendances lentes vivent sur un écran que personne n'est obligé de lire en pleine nuit.

Deux familles de sondes coexistent et ne racontent pas la même histoire. Une sonde externe interroge le service comme le ferait un utilisateur : elle voit la disponibilité perçue et ne sait rien de la cause. Une sonde locale, exécutée par un agent installé sur la machine, voit les disques, les processus et la mémoire, mais disparaît en même temps que la machine. D'où l'intérêt d'un signal explicite lorsque l'agent cesse de donner signe de vie : c'est souvent la première information fiable sur une panne d'hôte, et elle arrive avant que les sondes de surface ne réagissent.

Servor exécute ses vérifications depuis un seul point. Elles peuvent aussi tourner directement sur l'agent installé sur la machine, ce qui les rend indépendantes d'une session ouverte dans le navigateur. Il n'y a pas de sondes réparties sur plusieurs continents. Si votre besoin est de distinguer formellement une panne de transit d'une panne de service, ou de mesurer la disponibilité depuis plusieurs pays, il faut compléter par un service conçu pour cela. Le dire tout de suite évite une mauvaise découverte le jour du premier litige.

Le vocabulaire fixe les attentes. Quatre états sont d'usage courant : on cherche, on a identifié, on a corrigé et on observe, c'est clos. Chacun dit quelque chose de différent, et passer trop tôt au dernier oblige à rouvrir, ce qui coûte bien plus en confiance que dix minutes de patience. Écrivez dans la langue du client plutôt que dans celle de votre infrastructure : les envois de courriels sont retardés, plutôt que le consommateur de la file d'attente n'acquitte plus les messages.

Deux contraintes techniques cadrent l'exercice. La page doit vivre en dehors de l'infrastructure qu'elle décrit, sinon elle disparaît au moment précis où elle devient utile, et elle doit se trouver à une adresse que vos clients connaissent déjà, donc sur votre domaine, avec un certificat valide. Prévoyez aussi un canal poussé, courriel avec double consentement ou webhook vers les outils de vos clients, parce que personne ne pense à ouvrir une page de statut avant d'avoir déjà perdu vingt minutes.

Encore faut-il que les données existent au moment où vous les cherchez. Les mesures fines coûtent cher à conserver : la plupart des outils gardent le détail quelques jours, puis n'en conservent qu'un agrégat horaire sur plusieurs mois. Sachez lequel des deux vous lisez, parce qu'un pic de trente secondes est invisible dans une moyenne horaire et que beaucoup de conclusions fausses viennent de là. Prenez pendant l'incident les captures qui comptent, pas trois semaines après.

Le livrable n'est pas le récit, ce sont les décisions. Chaque incident devrait produire 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.

Les vérifications peuvent s'exécuter depuis l'agent installé sur la machine. Cet agent est un binaire compilé unique qui n'ouvre aucun port entrant : il initie une connexion sortante, donc il fonctionne derrière un NAT, un pare-feu d'entreprise ou un réseau accessible uniquement par VPN. Il pousse ses métriques toutes les 15 à 300 secondes, 60 par défaut : processeur global et par cœur, charge, mémoire détaillée et swap, disques par point de montage, réseau, uptime, processus. Les mesures brutes sont conservées 7 jours, les agrégats horaires 90 jours. 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 ; une alerte distincte signale un agent devenu injoignable.

La communication vit au même endroit. Un incident se crée à la main ou automatiquement à la bascule d'un monitor, avance entre quatre statuts, conserve son journal de mises à jour et notifie les abonnés. Les status pages publiques disposent d'un hostname unique et immuable, d'une URL personnalisée, d'un domaine sur mesure avec certificat automatique, d'une personnalisation graphique, d'un historique de 90 jours et d'abonnés par courriel en double consentement ou par webhook signé. 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.