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.
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é.
Réduire les fausses alertes Zabbix : hystérésis, durée de dépassement, seuils par volume, dépendances entre déclencheurs et calibrage sur données réelles plutôt que sur les valeurs par défaut.
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.
La saturation d'un disque est la panne serveur la plus fréquente, la plus prévisible, et pourtant l'une des plus courantes en production. Elle n'arrive jamais par surprise : un disque se remplit progressivement, souvent pendant des semaines, avant de provoquer un arrêt brutal.
Cet article détaille ce qu'il faut mesurer, à quels seuils alerter, et pourquoi le pourcentage d'occupation seul ne suffit pas.
Quand un système de fichiers atteint 100 %, les conséquences dépassent largement l'impossibilité d'écrire un fichier :
/var ou /tmp sont saturés, car SSH lui-même a besoin d'écrire.C'est ce dernier point qui transforme un incident bénin en déplacement sur site.
| Niveau | Seuil | Action attendue |
|---|---|---|
| Information | 75 % | Aucune action immédiate, à noter dans le suivi |
| Avertissement | 85 % | Planifier un nettoyage ou une extension |
| Critique | 95 % | Intervenir dans la journée |
| Urgence | 98 % | Intervenir immédiatement |
Ces valeurs conviennent à un disque de taille moyenne. Elles sont trompeuses sur les très grands volumes : sur un disque de 4 To, 5 % d'espace libre représentent encore 200 Go, largement suffisants. Sur un disque de 50 Go, les mêmes 5 % ne laissent que 2,5 Go, soit quelques heures de journaux applicatifs.
Pour cette raison, une bonne règle combine les deux critères : alerter quand le pourcentage libre passe sous le seuil ET que l'espace libre absolu descend sous une valeur plancher (par exemple 10 Go). Cela évite de réveiller quelqu'un pour un volume de sauvegarde de 20 To rempli à 92 %.
Un disque à 60 % qui gagne 3 % par jour est un problème plus urgent qu'un disque stable à 88 % depuis six mois. Le premier saturera dans moins de deux semaines ; le second n'a jamais bougé.
C'est le principal apport d'une supervision par rapport à une simple vérification ponctuelle : la prévision de remplissage. En analysant la pente des dernières heures, il est possible d'estimer quand le volume atteindra 100 % et d'alerter sur cette prévision plutôt que sur le seuil.
Zabbix fournit une fonction dédiée pour cela :
timeleft(/host/vfs.fs.size[/,pfree],1h,0)
Elle renvoie le temps estimé avant que la métrique n'atteigne zéro. Une alerte déclenchée quand cette valeur passe sous 24 heures prévient de la saturation imminente, quel que soit le pourcentage actuel.
La prévision demande un historique suffisant pour être fiable. Sur une machine récemment ajoutée à la supervision, comptez quelques heures avant que l'estimation ne devienne exploitable.
Sur les systèmes de fichiers Linux comme ext4, un volume peut être plein sans être plein. Chaque fichier consomme un inode, et leur nombre est fixé à la création du système de fichiers. Un répertoire contenant des millions de petits fichiers — cache applicatif, files de messages, sessions PHP — épuise les inodes bien avant l'espace disque.
Le symptôme est déroutant : df -h affiche 40 % d'occupation, et le système refuse pourtant de créer le moindre fichier avec l'erreur « No space left on device ».
Vérification :
df -iSurveillez les inodes avec les mêmes seuils que l'espace disque. C'est une métrique souvent absente des supervisions élémentaires, et la cause de longues séances de diagnostic.
Une supervision disque complète couvre quatre métriques :
Chaque système de fichiers doit être surveillé séparément. Un serveur avec /, /var, /home et un volume de données a quatre points de défaillance distincts : /var peut saturer alors que la racine est vide.
Dans la pratique, quelques coupables reviennent systématiquement :
logrotate ou avec une configuration défaillante remplit un volume en quelques semaines.journald sans limite sur les systèmes Linux récents, dont la taille par défaut peut atteindre plusieurs gigaoctets.Une supervision qui remonte la tendance permet d'identifier ces causes avant l'incident : une croissance régulière et linéaire signale presque toujours un journal ou une sauvegarde, pas une activité utilisateur.
L'erreur classique consiste à alerter sur tous les systèmes de fichiers avec le même seuil. Cela produit rapidement du bruit :
La parade consiste à définir des seuils par volume plutôt qu'un seuil global, et à exclure explicitement les points de montage dont le remplissage est attendu. Une alerte qui se déclenche puis se résout d'elle-même chaque nuit finit par être ignorée — et avec elle, celles qui comptaient.
Le sujet est développé dans comment éviter les faux positifs.
Les templates appliqués automatiquement à chaque machine supervisée couvrent la découverte des systèmes de fichiers, le pourcentage d'espace libre, l'espace absolu et les inodes sur les volumes Linux — sans configuration à faire machine par machine.
Chaque système de fichiers est détecté et surveillé séparément, sans déclaration manuelle.
Pourcentage libre, espace absolu et occupation des inodes sur les volumes Linux.
L'évolution sur plusieurs jours permet d'anticiper la saturation plutôt que de la constater.
Les graphiques d'évolution par machine sont consultables dans les statistiques du parc.
Logiserv supervise votre parc à partir de cet article : essai gratuit sans carte bancaire.