Les inscriptions du conservatoire de Besançon ont échoué pendant 51 minutes un samedi matin de septembre, au moment précis où trois cents familles s'y prenaient toutes en même temps. La réparation a pris cinq minutes. Le reste du temps a servi à s'apercevoir qu'il se passait quelque chose.
Le disque du serveur dépassait 90 % depuis neuf jours. Rien ne le regardait. C'est la forme ordinaire d'une panne de serveur et c'est le sujet de cette page : les machines qui tombent préviennent presque toujours, dans une unité que personne n'a pensé à mesurer.
Une limite de système est une pente et non une falaise
Un disque à 90 % est une alerte, un disque à 100 % est une panne, et entre les deux il y a eu neuf jours pendant lesquels une commande de cinq minutes aurait suffi. C'est ce qui rend le seuil intéressant : il ne marque pas le moment où la machine casse, il marque le dernier moment où la réparation est encore ennuyeuse plutôt qu'urgente. Presque aucune limite de système n'est une falaise, et régler une alerte sur la valeur qui casse revient à installer un détecteur de fumée dans les cendres.
Le second piège est l'unité. df -h rend le taux par système de fichiers, donc un disque plein peut n'être qu'un répertoire. À Besançon la machine affichait un taux d'occupation général confortable pendant toute la semaine, parce que le volume des journaux était séparé du volume principal et que le tableau de bord ne montrait que le second. Rien n'était faux. La mesure portait sur autre chose que sur ce qui allait céder.
De là vient la règle qui vaut pour tout le reste de ce sujet. Surveillez ce qu'un usager fait, pas ce que la machine déclare. Un serveur qui répond, un processeur à 12 % et une base démarrée sont trois affirmations vraies pendant que personne ne parvient à s'inscrire. Une seule vérification aurait attrapé la panne : remplir un formulaire d'inscription de bout en bout, toutes les cinq minutes, depuis une machine qui n'est pas celle-là.
Les 34 minutes qui séparent la panne de la réparation
Reconstituée après coup, la matinée tient en cinq moments et seuls les deux derniers comportent quelqu'un devant la machine. Le disque se remplit à 9 h 12 et la base cesse d'accepter les écritures. Une mère de famille téléphone à 9 h 46. Le volume est nommé à 9 h 58, les journaux sont archivés et les écritures reprennent à 10 h 03.
Le détail qui compte est celui de 9 h 46 : pendant 34 minutes, le seul système de surveillance qui a fonctionné a été le téléphone. Ce n'est pas une anecdote, c'est la mesure de ce que valait le dispositif en place, et elle se lit sans matériel : prenez votre dernière panne, écrivez l'heure où elle a commencé et l'heure où vous l'avez apprise, et l'écart est la seule note de surveillance qui vaille.
Une fois sur place, la question se referme vite si l'on interroge le service plutôt que la machine. journalctl -p err -S -1h n'imprime que les erreurs de la dernière heure, ce qui est la différence entre lire un journal et lire tout ce que la machine a jamais dit. Deux commandes ont suffi ici, et aucune des deux n'était un redémarrage.
df -hdonne le taux par volume, et c'est le volume et non la machine qu'il faut lirejournalctl -p err -S -1hréduit le journal aux erreurs de l'heure écoulée, tous services confondusdu -xh --max-depth=1 /var | sort -hnomme le répertoire responsable sans quitter le volume
Le contrat décide des 34 minutes, pas la technique
Dans une structure française de cette taille, le serveur est rarement tenu par la personne qui s'en sert. Il est confié à un prestataire, et ce qui décide du délai n'est alors pas un outil mais deux sigles que peu de clients lisent avant d'en avoir besoin. La GTI est la garantie de temps d'intervention, c'est-à-dire le délai au bout duquel quelqu'un commence à regarder. La GTR est la garantie de temps de rétablissement, c'est-à-dire le délai au bout duquel le service refonctionne. Les deux ne se ressemblent pas, et un contrat qui ne porte qu'une GTI ne promet rien sur le retour du service.
Le piège est dans l'unité, une fois de plus. Une GTR de 4 heures ouvrées démarrée un vendredi à 17 h expire le lundi, et c'est parfaitement conforme au contrat signé. Un conservatoire dont les inscriptions ouvrent le samedi a donc besoin d'heures calendaires ou d'une astreinte nommée, ce qui se négocie et se paie, et se lit avant l'incident. C'est le blocage français de ce sujet : la personne qui découvre la panne croit que la question est de savoir quoi faire, alors que la question est de savoir qui a le droit d'intervenir et dans quel délai il s'y est engagé.
Un samedi
La panne a duré une seconde et le fait de s'en apercevoir en a duré 34 minutes
Cinq moments d'une seule interruption. Seuls les deux derniers comportent quelqu'un devant le serveur.
- Neuf jours avantLe disque passe 90 %Aucune alerte réglée sur ce volume, et le taux général de la machine reste confortable
- 9 h 12Le disque est pleinLa base cesse d'accepter les écritures et le formulaire rend une erreur d'inscription
- 9 h 46Une mère de famille téléphone34 minutes après, et c'est le dispositif de surveillance qui a réellement fonctionné
- 9 h 58df -h nomme le volumeDouze minutes pour le trouver, parce que les courbes de la machine portaient sur un autre nombre
- 10 h 03Journaux archivés, écritures reprisesCinq minutes, ce qu'aurait coûté la réparation n'importe lequel des neuf jours précédents
L'espacement n'est pas proportionnel et la forme est l'affirmation : la réparation a duré cinq minutes, l'interruption 51, et tout ce qu'il y a entre les deux a servi à l'apprendre.
Par où entrer, et les clusters qui portent la suite
Le rôle d'un serveur vient en premier parce qu'il installe la seule différence qui compte avec un poste de bureau : personne ne le regarde. Vient ensuite la surveillance, qui est la matière de cette page et qui se met en place avant le reste plutôt qu'après la première nuit blanche. Les serveurs web sont ce que la plupart des lecteurs venaient chercher, et se lisent une fois que l'on sait ce que l'on surveillera.
Les trois autres se prennent selon le parc que l'on a devant soi. L'hébergement décide de ce dont on est responsable avant même de configurer quoi que ce soit. Windows Server tient une grande part du parc français, annuaire et stratégies comprises, et il ne se déduit pas de Linux. La messagerie et la collaboration sont les services dont l'arrêt se remarque en trois minutes, ce qui en fait le meilleur endroit pour éprouver une surveillance sur quelque chose que tout le monde regarde.
Ce qu'il faut ouvrir en 2026
Prometheus et Grafana sont libres et gratuits, et ils ont remplacé Nagios et sa génération, qui enregistraient si une chose répondait plutôt que la façon dont elle se comportait. La différence est exactement celle de cette page : une valeur suivie dans le temps montre une pente de neuf jours, un état ne montre rien avant le dernier jour. journalctl est déjà sur la machine et ne coûte rien ; sur un parc trop petit pour justifier un journal centralisé, il en tient lieu, à condition de lui poser une question bornée plutôt que de le lancer nu.
La pièce qui manque aux deux est qu'elles tournent sur la machine surveillée. Une sonde extérieure qui remplit un formulaire depuis un autre réseau, du type d'updown.io, coûte quelques euros par mois et remplace le téléphone d'une mère de famille : elle a l'avantage de continuer à répondre quand la machine, elle, ne répond plus. C'est le seul achat de cette page, et c'est le moins cher.
La machine tient, et quelqu'un d'autre s'y intéresse
Une surveillance qui fonctionne dit qu'une chose a changé. Elle ne dit pas si le changement vient d'un usage ou de quelqu'un qui essaie, et cette question appartient à la cybersécurité, où les mêmes journaux servent de preuve. À côté, le cloud déplace la ligne de ce dont on répond sans supprimer une seule des questions de cette page, et les systèmes d'exploitation restent l'endroit où l'on apprend à lire ce que journalctl rend. L'ensemble est rangé sous les systèmes et les réseaux.