Pourquoi superviser un serveur Linux ? Les pannes évitables

Service

Ce que la supervision d'un serveur Linux détecte avant l'incident : saturation disque, fuite mémoire, processus zombie, échec de sauvegarde, certificat expiré. Avec les commandes de diagnostic.

Un serveur Linux tombe rarement sans prévenir. Les six signaux qui précèdent la panne, comment les mesurer, et pourquoi un contrôle ponctuel ne suffit pas.

Pourquoi superviser un serveur Linux ? Les pannes évitables

Protégez votre infrastructure dès aujourd'hui

Démarrez gratuitement, sans carte bancaire requise

Démarrer mon essai sans frais Voir les démos

Un serveur Linux bien administré tombe rarement sans prévenir. Dans la grande majorité des cas, l'incident est précédé de plusieurs jours de signaux mesurables — et parfaitement invisibles tant que personne ne les mesure.

La question n'est donc pas « mon serveur est-il fiable » mais « saurais-je qu'il ne va pas bien avant qu'il ne s'arrête ».

Ce qu'une connexion SSH occasionnelle ne montre pas

L'approche la plus répandue consiste à se connecter quand un utilisateur signale un problème, puis à lancer df -h, free -m et top. Cette méthode a deux limites structurelles :

Elle est ponctuelle. Vous voyez l'état à l'instant de la connexion, pas la tendance des trois dernières semaines. Un disque à 78 % ne dit rien ; un disque passé de 40 % à 78 % en dix jours dit tout.
Elle est déclenchée par l'incident. Au moment où vous vous connectez, le problème est déjà visible des utilisateurs.

La supervision continue transforme ces deux points : elle enregistre l'évolution, et elle alerte avant que le seuil critique ne soit atteint.

Les six pannes que la supervision anticipe

1. La saturation du disque

La plus fréquente et la plus évitable. Un journal applicatif sans rotation, une sauvegarde qui s'accumule ou des instantanés oubliés remplissent un volume en quelques semaines. Quand / ou /var atteignent 100 %, la base de données s'arrête, les journaux cessent d'être écrits, et parfois SSH lui-même ne fonctionne plus — ce qui transforme un incident bénin en déplacement sur site.

df -h
df -i    # les inodes : un volume peut être plein en affichant 40 %

Le sujet est détaillé dans surveiller l'espace disque d'un serveur.

2. La fuite mémoire

Un processus qui consomme progressivement de la mémoire finit par déclencher le tueur de processus du noyau, l'OOM killer. Celui-ci arrête le processus le plus gourmand — souvent la base de données, précisément le service que vous vouliez protéger.

Le signal précurseur est une croissance lente et régulière de la mémoire utilisée sur plusieurs jours, invisible sur un free -m ponctuel.

free -m
grep -i "killed process" /var/log/syslog
journalctl -k | grep -i "out of memory"

Sur Linux, ne surveillez jamais la mémoire « libre ». Le noyau utilise délibérément toute la mémoire inoccupée comme cache disque : un système sain affiche presque toujours très peu de mémoire libre. La métrique pertinente est la mémoire disponible.

3. Le swap qui s'emballe

Quand la mémoire physique manque, le système déporte des pages sur le disque. Les temps de réponse s'effondrent d'un facteur considérable, sans qu'aucun service ne soit techniquement arrêté. Les utilisateurs signalent « c'est lent », et rien dans les journaux n'indique d'erreur.

vmstat 1 5    # colonnes si/so : échanges avec le swap

Une activité de swap soutenue est un incident, même si tout répond encore.

4. Les sauvegardes qui échouent en silence

Un script de sauvegarde qui échoue chaque nuit depuis trois mois ne se découvre qu'au moment de la restauration. C'est le pire scénario possible : le problème est ancien, et on l'apprend quand on en a le plus besoin.

Trois éléments à surveiller : le service tourne, la date du dernier succès est récente, et la destination a de l'espace disponible.

5. Les certificats TLS expirés

Une panne complète, parfaitement datée à l'avance, et pourtant régulièrement subie. Une alerte trente jours avant l'échéance coûte quasiment rien.

openssl x509 -enddate -noout -in /etc/ssl/certs/monsite.crt

6. Les redémarrages inattendus

Un serveur qui redémarre seul signale un problème matériel, une mise à jour automatique non maîtrisée ou un plantage noyau. Sans supervision de la durée de fonctionnement, un redémarrage nocturne passe complètement inaperçu.

uptime
last reboot | head -5

Le cas particulier des machines virtuelles

Sur une machine virtuelle, certaines métriques matérielles n'ont pas de sens : température, état des ventilateurs, SMART des disques appartiennent à l'hyperviseur, pas à l'invité.

En revanche, une métrique spécifique mérite l'attention : le temps de vol (steal time), qui mesure le temps pendant lequel le processeur virtuel était prêt mais n'a pas obtenu de temps système. Une valeur élevée signale un hyperviseur surchargé — le problème n'est pas sur votre système, mais elle en subit les conséquences.

top    # colonne "st" dans la ligne %Cpu

Superviser n'est pas seulement alerter

Un bénéfice moins évident de la supervision continue est le diagnostic après incident. Quand un service a été lent mardi entre 14h et 16h, disposer des courbes de charge, de mémoire et d'entrées-sorties sur cette fenêtre transforme une enquête approfondie en lecture de graphique.

Sans historique, la seule réponse possible à « pourquoi c'était lent hier » est une hypothèse.

Le second bénéfice est la planification de capacité : savoir qu'un volume gagne 2 % par mois permet de planifier son extension à froid, pendant une fenêtre de maintenance choisie, plutôt qu'en urgence un vendredi soir.

Ce qu'il faut pour s'y mettre

Trois éléments : un agent installé sur le système, un serveur qui collecte et conserve l'historique, et des seuils calibrés sur votre parc.

Les deux premiers sont des questions techniques bien documentées — voir les guides d'installation Ubuntu, Debian, Rocky Linux, AlmaLinux, Amazon Linux, SLES et openSUSE et Raspberry Pi.

Le troisième est celui qui décide de la réussite : des seuils trop sensibles produisent des alertes que plus personne ne lit, ce qui ramène à la situation de départ. Voir comment éviter les faux positifs.

Avec Logiserv

L'agent s'installe en une commande, les templates Linux sont appliqués automatiquement et les seuils sont préréglés sur des valeurs éprouvées plutôt que sur les valeurs par défaut.

Distributions supportées: Debian, Ubuntu, RHEL, Rocky, AlmaLinux, Amazon Linux, SLES
Métriques Linux: Disque, mémoire, charge, services
Empreinte de l'agent: Quelques dizaines de Mo

Pour aller plus loin

Quelles métriques surveiller sur un serveur — le plan de supervision complet
Surveiller l'espace disque d'un serveur — la panne la plus fréquente, en détail
Éviter les faux positifs Zabbix — pour que les alertes restent lues
Installer Zabbix Agent sur Ubuntu — la mise en œuvre
Supervision serveur Windows et Linux : le guide — la démarche complète

Partagez ce lien