Surveiller l'espace disque d'un serveur : seuils, tendances et alertes

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.

Pourquoi un disque plein casse tout

Quand un système de fichiers atteint 100 %, les conséquences dépassent largement l'impossibilité d'écrire un fichier :

• La base de données s'arrête ou passe en lecture seule. PostgreSQL, MySQL et SQL Server refusent d'écrire dès qu'ils ne peuvent plus garantir leurs journaux de transaction.
• Les journaux système cessent d'être écrits, ce qui supprime précisément les traces dont vous auriez besoin pour diagnostiquer l'incident.
• Les sessions utilisateur échouent : sur Windows, un profil ne peut plus se charger ; sur Linux, les fichiers temporaires ne peuvent plus être créés.
• Le système peut devenir impossible à réparer à distance si /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.

Les seuils à retenir

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 %.

La tendance compte plus que le seuil

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.

Ne pas oublier les inodes

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 -i

Surveillez 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.

Ce qu'il faut surveiller exactement

Une supervision disque complète couvre quatre métriques :

1. Pourcentage d'espace libre, par système de fichiers — pas seulement la racine
2. Espace libre absolu, pour éviter les faux positifs sur les grands volumes
3. Pourcentage d'inodes libres, sur les systèmes de fichiers Linux
4. Temps estimé avant saturation, calculé sur la tendance récente

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.

Les causes récurrentes de saturation

Dans la pratique, quelques coupables reviennent systématiquement :

• Les journaux applicatifs sans rotation. Un service qui écrit sans logrotate ou avec une configuration défaillante remplit un volume en quelques semaines.
• Les sauvegardes locales qui s'accumulent. Un script de sauvegarde sans purge conserve indéfiniment ses archives.
• Les journaux de transaction de base de données. Sous SQL Server, un journal en mode de récupération complet sans sauvegarde régulière grossit sans limite.
• Les fichiers temporaires jamais nettoyés. Uploads interrompus, décompressions partielles, caches applicatifs.
• Les instantanés de machines virtuelles oubliés. Un instantané conservé plusieurs mois peut dépasser la taille du disque d'origine.
• 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.

Éviter le bruit

L'erreur classique consiste à alerter sur tous les systèmes de fichiers avec le même seuil. Cela produit rapidement du bruit :

• les volumes de sauvegarde sont normalement remplis à 90 %, c'est leur rôle
• les points de montage en lecture seule ou les images système sont à 100 % en permanence
• les volumes temporaires fluctuent fortement et déclenchent des alertes qui se résolvent seules

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.

Avec Logiserv

Les templates appliqués automatiquement à chaque système supervisé 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 système par système.

Découverte des volumes

Automatique

Chaque système de fichiers est détecté et surveillé séparément, sans déclaration manuelle.

Métriques disque

Espace et inodes

Pourcentage libre, espace absolu et occupation des inodes sur les volumes Linux.

Historique

Conservé pour la tendance

L'évolution sur plusieurs jours permet d'anticiper la saturation plutôt que de la constater.

Les graphiques d'évolution par système sont consultables dans les statistiques du parc.

Pour aller plus loin

• Quelles métriques surveiller sur un serveur — le plan de supervision complet
• Éviter les faux positifs Zabbix — régler les seuils pour que les alertes restent lues
• Pourquoi superviser un serveur Linux — les incidents que la supervision détecte à l'avance
• Supervision serveur Windows et Linux : le guide — la démarche complète
• Installer Zabbix Agent 2 — collecter ces métriques sur vos systèmes