D’où vient la croissance du disque d’un serveur VPN et comment la plafonner

Le tunnel cesse d’accepter des connexions, le service redémarre deux fois, puis plus rien n’apparaît dans son journal. Ce silence est l’indice, car c’est le journal qui a rempli le disque et le démon n’a nulle part où écrire l’erreur que vous attendez. Tout service de longue durée peut atteindre cet état, et supprimer un répertoire nommé logs y remédie rarement. La solution durable consiste à savoir quel stockage a grossi, qui possède sa politique de rétention et si l’écrivain a réellement libéré l’espace.

Trouvez le stockage qui a grossi et le rythme auquel il a grossi

Commencez par deux chiffres faciles à oublier : les blocs libres et les inodes libres. Un système de fichiers peut annoncer beaucoup d’espace et refuser une écriture faute d’inodes, ce qui arrive quand un service crée un fichier par session. Demandez les deux relevés sur le même volume, car les réponses peuvent se contredire le même après-midi. Faites-le pendant que l’hôte est sain, afin que les chiffres décrivent un fonctionnement normal et non une panne.

df -h /var
df -i /var

Attribuez ensuite la croissance à un propriétaire. Le chiffre d’utilisation du journal ne couvre que le journal et ne verra jamais un démon qui écrit dans un chemin issu de son fichier de configuration.

journalctl --disk-usage

La croissance dans le temps en dit plus que n’importe quel relevé isolé. Un niveau de débogage laissé actif, une boucle de nouvelles tentatives qui journalise chaque essai ou un fichier de capture que personne n’a arrêté : chacun peut sembler ordinaire à un instant et alarmant une heure plus tard. Prenez un relevé, attendez une période chargée, prenez-en un autre et divisez par l’intervalle. Un débit que vous pouvez énoncer transforme la capacité en décision plutôt qu’en incendie.

Ce que la rotation fait à un fichier ouvert

Un fichier journal est un nom qui pointe vers un inode, et l’espace ne revient qu’à la fermeture du dernier descripteur ouvert. Renommez le fichier et l’écrivain continue de remplir le même inode ; supprimez-le et l’écrivain continue de remplir un inode sans aucun nom. C’est pourquoi « j’ai supprimé le fichier et le disque est resté plein » décrit des descripteurs de fichiers et non un système de fichiers cassé. Redémarrer l’écrivain, ou choisir un mode de rotation qui rouvre le fichier, est ce qui rend réellement les blocs.

lsof +L1 | head

La politique appartient au composant qui écrit le fichier. Le journal applique ses propres limites de stockage depuis son fichier de configuration, tandis qu’un service reposant sur des fichiers s’appuie généralement sur logrotate, soit avec une règle de création et un signal de réouverture, soit avec un mode de troncature sur place quand l’écrivain ne peut pas rouvrir. Confirmez la décision sans rien changer d’abord :

logrotate -d /etc/logrotate.conf

Où placer la limite et quelle taille lui donner

Placez le plafond là où l’écrivain est configuré, pas au point de montage. Un quota sur tout le volume protège l’hôte mais ne dit rien du service qui échouera le premier, et un script de nettoyage global tend à supprimer les preuves dont l’incident suivant aura besoin. Un plafond de journal, un nombre de rotations avec une taille maximale et la rétention applicative bornent chacun un producteur. Ensemble, ils bornent le total ; séparément, chacun est une supposition.

Dimensionnez ce plafond à partir de la rétention que vous pouvez défendre, non de l’espace libre disponible. Si une revue exige une semaine de tentatives de connexion, le journal doit tenir une semaine au débit le plus élevé attendu, et ce débit est le chiffre mesuré plus tôt.

La journalisation de débogage est un mode temporaire avec une heure de début consignée, non un plan de stockage. Gardez la question de confidentialité dans la même décision, car les journaux de connexion portent des adresses et des identifiants. Une rétention plus longue est aussi un choix de traitement des données et devrait être prise par quelqu’un qui connaît les deux contraintes.

Vérifiez le plafond après un redémarrage

Un changement de rétention qui tient jusqu’au prochain redémarrage n’est pas un changement. Redémarrez l’écrivain, confirmez que la nouvelle limite s’applique et vérifiez que la rotation fonctionne encore ensuite. Pour le journal, un redémarrage et un relevé d’utilisation répondent aux deux questions :

systemctl restart systemd-journald
journalctl --disk-usage

Pour un service reposant sur des fichiers, exécutez la tâche de rotation une fois à la main et confirmez que le fichier a été remplacé et le descripteur rouvert. Un écrivain qui conserve l’ancien descripteur passe un contrôle superficiel et échoue la fois suivante, quand le volume se remplit. Surveillez l’espace libre pendant le test, car un fichier qui a rétréci sans que l’espace revienne signifie que l’ancien inode est encore retenu.

Comparez le prochain relevé avec celui-ci

Revenez une semaine plus tard et comparez le débit de croissance avec celui qui est consigné. Un débit identique signifie que le plafond tient et que la charge est stable ; un débit doublé signifie que quelque chose a changé, et la question utile est quoi. Lisez d’abord le contenu du journal pour les échecs répétés, car une boucle de nouvelles tentatives est à la fois un symptôme et une cause de volume. Vérifiez ensuite tout ce qui a été activé récemment, y compris les niveaux de débogage allumés pendant un incident et jamais éteints.

Gardez les sauvegardes hors du même volume, ou acceptez qu’un disque plein emporte la sauvegarde avec lui. Une copie écrite sur l’hôte qu’elle protège n’est pas un plan de restauration, et sa rétention demande sa propre réponse.

Écrivez ce qui est conservé, où, pendant combien de temps et qui le supprime. Cette phrase est le livrable, et c’est la seule partie de ce travail qui survit au prochain redémarrage.