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.
Les autres services
Les métriques indispensables à surveiller sur un serveur Windows ou Linux : disque, mémoire, processeur, services, réseau. Seuils recommandés, pièges de lecture et ordre de priorité.
Comment surveiller l'espace disque d'un serveur Windows ou Linux : quels seuils choisir, pourquoi la tendance compte plus que le pourcentage, et comment éviter la saturation avant l'incident.
Installer Zabbix Agent 2 sur Ubuntu Server 20.04, 22.04 et 24.04 : dépôt officiel, apt, configuration de zabbix_agent2.conf, clé PSK, port 10050 et vérification systemd.
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 ».
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 :
La supervision continue transforme ces deux points : elle enregistre l'évolution, et elle alerte avant que le seuil critique ne soit atteint.
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.
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 : une machine saine affiche presque toujours très peu de mémoire libre. La métrique pertinente est la mémoire disponible.
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 swapUne activité de swap soutenue est un incident, même si tout répond encore.
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.
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.crtUn 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 -5Sur 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 machine. Une valeur élevée signale un hyperviseur surchargé — le problème n'est pas sur votre machine, mais elle en subit les conséquences.
top # colonne "st" dans la ligne %CpuUn 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.
Trois éléments : un agent installé sur la machine, 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 et AlmaLinux.
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.
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.
Détection automatique via /etc/os-release, sans paramètre à fournir.
Découverte automatique des systèmes de fichiers et des interfaces réseau.
Installation sans redémarrage ni interruption des services hébergés.
Logiserv supervise votre parc à partir de cet article : essai gratuit sans carte bancaire.