Être prévenu avant vos clients : superviser un serveur sans rien payer

Un lundi matin, un client appelle : « votre site ne répond plus ». Vous découvrez la panne en même temps que lui, sauf qu'elle a commencé la veille à 22 h. Vous avez perdu la nuit, et lui a perdu confiance.

Ce guide règle exactement ce problème. À la fin, une machine vérifie votre serveur toutes les minutes, vous envoie une alerte quand il tombe, et vous aurez vu cette alerte arriver pour de vrai, parce que vous aurez cassé quelque chose exprès pour la déclencher. Coût du logiciel : zéro, sans palier payant ni limite de nombre de surveillances. Coût de l'hébergement : entre zéro et six euros par mois, et ce guide dit lesquels.

En clair

Un petit logiciel, installé sur une autre machine que celle qu'il surveille, interroge votre serveur en boucle. Tant qu'il obtient une réponse, il se tait. Dès qu'il n'en obtient plus, il fait sonner votre téléphone. C'est tout. Le reste de ce guide sert à ce que cette alerte arrive vraiment le jour où elle compte.

Avant tout outil : surveiller quoi, prévenir qui

C'est la question que presque personne ne se pose, et c'est elle qui décide si votre supervision servira à quelque chose dans six mois.

Une supervision qui alerte tout le monde sur tout ne survit pas trois semaines. Le schéma est toujours le même : les alertes arrivent en rafale, la plupart pour des broutilles, quelqu'un crée une règle de messagerie pour les classer automatiquement, et le jour de la vraie panne l'alerte part directement à la corbeille. Une alerte qu'on ignore est pire que pas d'alerte du tout, parce qu'elle donne le sentiment d'être couvert.

La règle de départ : n'alertez que sur ce pour quoi vous vous lèveriez la nuit. Trois choses le méritent quand on démarre.

Ce qui ne mérite pas d'alerte au début : un pic de CPU (le processeur), une montée de mémoire, un temps de réponse un peu long. Ce sont des indicateurs, utiles à regarder quand vous enquêtez, inutiles à recevoir sur votre téléphone à trois heures du matin. Pour comprendre pourquoi cette distinction entre mesurer et alerter est la colonne vertébrale du sujet, le cours Monitoring et supervision : les bases déroule le raisonnement complet.

Prévenir qui, ensuite : une seule personne par alerte. Une alerte envoyée à quatre personnes est une alerte que personne ne traite, chacun supposant qu'un autre s'en occupe. Si vous êtes seul, la question est réglée. Si vous êtes deux, nommez qui reçoit quoi, par écrit, même en une ligne.

La question qui annule tout le reste : où tourne l'outil

Voici l'erreur de conception la plus fréquente, et elle réduit à néant l'ensemble du travail.

Vous installez l'outil de supervision sur le serveur à surveiller. C'est pratique, tout est au même endroit. Le jour où ce serveur tombe, l'outil tombe avec lui. Il n'envoie aucune alerte, puisqu'il n'existe plus. Vous avez construit un détecteur de fumée alimenté par la pièce qui brûle.

L'outil doit tourner ailleurs que sur la machine qu'il surveille, et si possible sur un autre réseau et une autre alimentation électrique. Voici les options réalistes pour une petite structure, avec leur coût réel.

Le critère à retenir tient en une phrase : l'observateur doit survivre à la panne qu'il doit détecter. Si une seule coupure peut abattre les deux machines, l'installation ne vaut rien.

L'outil retenu : Uptime Kuma, et pourquoi celui-là

Uptime Kuma est un logiciel libre, gratuit, qui s'installe en une commande et se pilote depuis une page web. J'ai tranché pour lui plutôt que d'en survoler trois, pour quatre raisons.

Il est gratuit sans piège. Pas de version limitée à dix surveillances, pas de palier qui devient payant quand vous grossissez, pas de fonction d'alerte réservée à une offre supérieure. Vous l'hébergez, il vous appartient. C'est très rare dans ce domaine : la plupart des services de supervision « gratuits » le sont jusqu'à cinquante surveillances ou cinq minutes d'intervalle, et facturent la notification par SMS (message texte) à l'unité.

Il sait faire les trois surveillances qui comptent, y compris la troisième, la plus négligée : il peut attendre un signal au lieu d'aller le chercher. C'est ce qui permet de surveiller une sauvegarde, on y vient.

Il s'installe vraiment en une commande et son interface est en français. Un débutant en supervision obtient sa première surveillance active en dix minutes, ce qui est la condition pour que l'installation soit terminée un jour.

Il envoie ailleurs que par courrier électronique, vers une vingtaine de canaux dont plusieurs font réellement sonner un téléphone.

Sa limite, dite franchement : il ne mesure pas des métriques fines et ne trace pas les performances internes d'une application. Ce n'est pas son métier, et ce n'est pas non plus votre besoin aujourd'hui. Le jour où ce sera le cas, vous chercherez du côté des piles de métriques, et vous serez alors passé à une autre échelle.

Ce que vous allez construire

flowchart LR
    subgraph OBS["Machine d'observation, ailleurs"]
        K["Uptime Kuma"]
    end
    subgraph PROD["Serveur surveillé"]
        S["Site ou service"]
        D["Tâche disque"]
        B["Script de sauvegarde"]
    end
    K -->|"1. interroge toutes les 60 s"| S
    D -->|"2. signale que le disque va bien"| K
    B -->|"3. signale la fin de sauvegarde"| K
    K -->|"panne, ou silence anormal"| N["Notification qui fait du bruit"]
    N --> T["Votre téléphone"]

Deux sens de circulation, et c'est toute l'astuce. Pour le service web, Kuma va chercher l'information. Pour le disque et la sauvegarde, c'est le serveur qui vient dire qu'il va bien, et c'est le silence qui déclenche l'alerte. Un serveur éteint ne dit rien : le silence est donc un signal fiable, là où une vérification active sur une machine morte ne renvoie rien d'exploitable.

Installer Uptime Kuma

Sur la machine d'observation, avec Docker installé, une seule commande :

docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data --name uptime-kuma \
  louislam/uptime-kuma:1

Puis ouvrez http://adresse-de-la-machine:3001 dans un navigateur. Le premier écran vous demande de créer le compte administrateur : faites-le immédiatement, avant d'exposer quoi que ce soit.

Les écrans d'installation bougent d'une version à l'autre. Si ce qui s'affiche ne ressemble pas à ce qui est décrit ici, fiez-vous à la documentation officielle du projet plutôt qu'à ce guide : l'intention reste la même, créer un compte puis ajouter une première surveillance.

Deux précautions avant d'aller plus loin. Si cette page est accessible depuis internet, mettez-la derrière une adresse en HTTPS (la version chiffrée du protocole du web) et un mot de passe solide : elle contient la liste de vos services et de leurs adresses. Si vous préférez ne pas l'exposer du tout, laissez-la sur le réseau privé et atteignez-la par SSH (connexion sécurisée en ligne de commande), en suivant le guide SSH : authentification par clé.

Surveillance 1 : le service répond-il

Dans l'interface, ajoutez une surveillance de type HTTP (le protocole du web) et donnez-lui l'URL (l'adresse web) de votre site.

Trois réglages méritent une décision, et non la valeur par défaut.

L'intervalle. Soixante secondes convient. En dessous, vous gagnez peu et vous multipliez les fausses alertes sur des micro-coupures réseau.

Le nombre d'échecs avant alerte. Mettez deux ou trois, jamais un. Un unique échec est très souvent un hoquet réseau côté observateur, pas une panne. Trois échecs à soixante secondes, c'est une alerte trois minutes après le début d'une vraie panne : largement assez rapide, et le bruit disparaît.

Ce qu'on considère comme une réponse valable. Une page peut répondre tout en affichant une erreur applicative. Si l'outil le permet, demandez qu'un mot précis soit présent dans la page reçue, un mot qui ne s'affiche que lorsque l'application fonctionne vraiment. Sans cela, vous surveillez le serveur web, pas le service.

Un détail qui vous évitera une panne complète et prévisible : ajoutez aussi une surveillance de l'expiration du certificat HTTPS et du nom de domaine. Ce sont deux causes d'indisponibilité totale, connues des semaines à l'avance, et pourtant subies chaque année par des milliers de structures.

Surveillance 2 : le disque se remplit

Un disque plein ne produit pas une panne franche. Il produit une base de données qui refuse d'écrire, des journaux qui s'arrêtent, une sauvegarde qui échoue en silence. C'est la panne la plus évitable qui soit, à condition d'être prévenu avant le mur, et non le jour du mur. La fiche Le disque se remplit soudainement traite le jour où c'est déjà arrivé.

Uptime Kuma ne regarde pas dans votre disque, et c'est normal : il est à l'extérieur. On inverse donc le sens. Créez une surveillance de type « push » : Kuma vous donne une adresse à appeler et attend qu'on l'appelle. Si personne ne l'appelle dans le délai imparti, il alerte.

Sur le serveur surveillé, une ligne de tâche planifiée toutes les cinq minutes, qui n'appelle Kuma que si le disque va bien :

*/5 * * * * [ "$(df --output=pcent / | tr -dc '0-9')" -lt 85 ] && curl -fsS "https://kuma.exemple.fr/api/push/AbC123" > /dev/null

Réglez le délai d'attente de la surveillance à une quinzaine de minutes, soit trois passages manqués. Ce montage a une qualité que peu de gens remarquent : il alerte aussi bien quand le disque dépasse 85 % que quand le serveur entier est éteint. Une seule surveillance, deux pannes couvertes.

Surveillance 3 : la sauvegarde a-t-elle tourné

C'est la surveillance la plus rentable du lot, et la plus rarement installée. Une sauvegarde qui échoue ne se plaint pas. Elle échoue calmement, chaque nuit, pendant huit mois, et vous l'apprenez le jour où vous en avez besoin. La fiche La sauvegarde automatique échoue en silence décrit ce scénario en détail.

Même mécanisme que pour le disque, avec une différence importante : l'appel se place à la toute fin du script de sauvegarde, et seulement en cas de succès.

#!/bin/bash
set -e

# ... vos commandes de sauvegarde ...

# Cette ligne n'est atteinte que si tout ce qui précède a réussi,
# grâce au set -e qui arrête le script à la première erreur.
curl -fsS "https://kuma.exemple.fr/api/push/XyZ789" > /dev/null

Réglez le délai d'attente sur un peu plus de vingt-quatre heures si la sauvegarde est quotidienne. Le résultat est ce qu'on appelle un interrupteur d'homme mort : le silence devient l'alerte. Sauvegarde en échec, script planté, serveur éteint, tâche planifiée supprimée par erreur : tous ces cas produisent le même silence, donc la même alerte. Aucun d'eux ne serait détecté par une supervision qui se contenterait de lire le compte rendu de la sauvegarde.

Où envoyer l'alerte, et ce que chaque canal vaut vraiment

C'est ici que la plupart des installations échouent, après avoir bien fonctionné sur le papier.

Le courrier électronique est le pire canal pour une alerte de nuit, et il faut le dire clairement. Trois raisons, chacune suffisante. Il n'émet aucun son distinct : votre téléphone traite l'alerte d'un serveur mort comme une infolettre. Il arrive avec un retard imprévisible, de quelques secondes à plusieurs minutes selon la file de traitement. Et surtout, il peut dépendre de l'infrastructure en panne : si votre serveur de courrier SMTP (le protocole d'envoi de courrier) est sur la machine qui vient de tomber, l'alerte ne partira jamais. Le courrier électronique convient pour un compte rendu du matin. Pas pour réveiller quelqu'un.

Le réglage qui compte plus que le choix du canal : ce canal doit traverser le mode silencieux de votre téléphone. Une alerte parfaite qui arrive sur un appareil muet entre 22 h et 7 h ne sert à rien. Vérifiez-le explicitement, sur votre téléphone, ce soir.

L'étape que tout le monde saute : provoquer la panne

Vous venez de construire quelque chose qui a l'air de marcher. Une supervision qu'on n'a jamais vue se déclencher n'est pas une supervision, c'est une intention. Tant que vous n'avez pas reçu une alerte pour de vrai, vous ne savez rien de ce que vous avez installé.

Cassez donc quelque chose exprès, en pleine journée, en prévenant qui de droit.

Test 1, le service. Arrêtez votre serveur web pendant trois minutes. Attendez l'alerte. Notez l'heure exacte de l'arrêt et l'heure exacte de réception. L'écart est votre délai réel de détection : c'est un chiffre, et c'est le seul qui vaille.

Test 2, le disque. Sur le serveur, créez un fichier assez gros pour franchir le seuil, ou abaissez temporairement le seuil de 85 à une valeur déjà dépassée. La tâche planifiée cesse d'appeler, et l'alerte doit tomber au bout du délai d'attente. Remettez ensuite le seuil d'origine.

Test 3, la sauvegarde. Ne lancez simplement pas la sauvegarde ce soir, ou supprimez l'appel final pendant un cycle. L'alerte de silence doit arriver le lendemain.

Test 4, celui qu'on oublie. Mettez votre téléphone en mode nuit et refaites le test 1. Beaucoup d'installations correctes échouent exactement ici.

Notez le résultat des quatre tests quelque part, avec la date. Et refaites-les deux fois par an : un canal de notification change de règles, une clé expire, un numéro change. Une supervision se vérifie comme un extincteur.

Qui surveille le surveillant

Votre machine d'observation peut tomber, elle aussi. Et quand elle tombe, tout devient silencieux, ce qui ressemble à s'y méprendre à « tout va bien ».

Deux réponses simples, gratuites l'une comme l'autre. Faites surveiller la page de Kuma par un service de vérification extérieur en offre gratuite, ou par une seconde instance installée ailleurs, par exemple chez vous. Ou activez l'envoi périodique d'un compte rendu quotidien : un courrier électronique du matin qui dit « tout va bien », dont l'absence vous alerte. C'est le seul usage où le courrier électronique est à sa place.

Erreurs fréquentes

• Installer l'outil sur la machine à surveiller. L'erreur qui annule tout le reste. Le jour de la panne, l'outil est mort avec le serveur et ne prévient personne.
• Alerter sur tout, dès le premier échec. Deux semaines de fausses alertes, puis une règle de messagerie, puis plus personne ne les lit. Trois échecs consécutifs avant d'alerter, et seulement sur ce qui justifie de se lever.
• Ne jamais tester. L'installation paraît terminée, elle ne l'est pas. Tant qu'une alerte n'est pas arrivée sur votre téléphone pour une panne provoquée, vous n'avez rien vérifié.
• Ne compter que sur le courrier électronique. Sans son distinct, avec un retard variable, et parfois hébergé sur la machine même qui est tombée.
• Surveiller que le serveur répond, sans surveiller la sauvegarde. La panne visible se répare en une heure. La sauvegarde absente depuis huit mois se répare rarement.

À retenir

• Décidez quoi surveiller et qui prévenir avant de choisir un outil. Trois surveillances suffisent pour commencer : le service répond, le disque respire, la sauvegarde a tourné.
• L'observateur doit survivre à la panne qu'il détecte. Jamais sur la machine surveillée, jamais sur la même prise électrique ni la même connexion.
• Le silence est un excellent signal d'alerte : un serveur éteint ne peut pas mentir en disant qu'il va bien.
• Le courrier électronique n'est pas un canal d'alerte nocturne. Choisissez un canal qui traverse le mode silencieux.
• Provoquez une panne et regardez l'alerte arriver. Sans ce test, vous avez une intention, pas une supervision.

Mini-exercice

Votre serveur héberge un site et sa propre sauvegarde nocturne. Vous installez Uptime Kuma sur ce même serveur, avec une surveillance du site et une alerte par courrier électronique envoyée par le serveur de messagerie qui tourne, lui aussi, sur cette machine.

Une coupure de courant frappe le bureau à 2 h du matin. Combien d'alertes recevez-vous, et quelles sont les trois erreurs de conception à corriger ?

Réponse : zéro alerte. L'outil de supervision est tombé avec le serveur, il n'a rien à interroger et rien pour interroger. Le serveur d'envoi de courrier est tombé avec lui, donc aucun message ne peut partir. Et même s'il était parti, il aurait atterri sans bruit dans une boîte de réception à côté des infolettres. Les trois corrections : déplacer Uptime Kuma sur une machine extérieure au site et à son alimentation, choisir un canal d'alerte indépendant de votre infrastructure, et vérifier que ce canal sonne quand le téléphone est en mode nuit. Ensuite, provoquez la coupure un mardi après-midi pour vérifier que les trois corrections tiennent.