Comment empêcher les journaux Docker de remplir le disque de démarrage de l’hôte ?

Arrêtez immédiatement le producteur de journaux, identifiez la destination de journalisation active, puis appliquez une rotation limitée et corrigez l’erreur ou la boucle de redémarrage à l’origine de l’afflux.

Sur un NAS ou un serveur domestique basé sur Docker, le disque de démarrage peut se remplir même lorsque les médias et les bases de données résident sur un autre pool, car les sorties standard et d’erreur des conteneurs, les données du journal systemd et les fichiers natifs des applications peuvent toujours rester sous le système de fichiers système. La séquence sûre consiste à préserver suffisamment d’éléments récents, à arrêter la croissance incontrôlée, à déterminer quelle couche de journalisation occupe l’espace, à configurer la conservation pour les services existants et futurs, puis à vérifier que l’application sous-jacente n’émet plus le même volume de journaux.

Localiser le stockage des journaux qui augmente réellement

Vérifiez l’espace libre sur le système de fichiers de démarrage, puis comparez la taille de la racine de données Docker, des fichiers journaux propres à chaque conteneur, du journal système et des répertoires de journaux des applications montés depuis l’hôte. Notez les chemins les plus volumineux avant de supprimer ou de tronquer quoi que ce soit.

Une analyse d’un problème d’espace disque Docker a montré que les résumés Docker habituels ne révélaient pas le principal consommateur, car le fichier journal par défaut augmentait séparément. L’élément décisif était un journal de conteneur en croissance constante situé sous le chemin de stockage Docker local.

Inspectez le pilote de journalisation et le chemin des journaux configurés pour chaque conteneur en cours d’exécution, puis faites correspondre le fichier le plus volumineux avec le nom du conteneur et les messages récents. Si aucun journal de conteneur n’explique l’utilisation, poursuivez avec journald et les répertoires natifs des applications au lieu de supposer que tout problème de disque lié à Docker concerne json-file.

Arrêter le conteneur bruyant avant le nettoyage d’urgence

Lorsque le disque de démarrage est presque plein, mettez en pause ou arrêtez le conteneur dont la croissance est la plus rapide. Enregistrez une portion limitée de la fin du journal, son nombre de redémarrages, son état de sortie, la version de l’image, son environnement, ses montages et la première erreur répétée avant de récupérer de l’espace.

Les administrateurs découvrent souvent que les journaux JSON des conteneurs peuvent consommer l’espace disque restant lorsqu’aucune limite de taille n’est configurée. Une longue discussion sur Stack Overflow identifie la croissance illimitée des journaux JSON comme un risque de capacité distinct des données d’images et de volumes.

Ne supprimez pas aveuglément un fichier journal actif tant que Docker le garde ouvert, et ne supprimez jamais de répertoires arbitraires dans l’arborescence des métadonnées Docker. Utilisez uniquement la procédure de rotation ou de troncature prise en charge par la plateforme après avoir arrêté le producteur, puis vérifiez que les blocs récupérés sont visibles avant de redémarrer un service concerné.

Appliquer une rotation limitée à chaque service de longue durée

Définissez un pilote de journalisation explicite et des limites de rotation finies dans le service Compose ou la configuration du conteneur. Pour le pilote JSON courant, les contrôles importants sont une taille maximale de fichier et un nombre limité de fichiers conservés.

Une discussion sur la rotation dans la communauté Docker explique que des options telles que max-size et max-file limitent la quantité d’historique local conservée par un conteneur. L’exigence opérationnelle est une politique de rotation finie, et non un fichier qui augmente indéfiniment.

Choisissez les limites en fonction de la rapidité avec laquelle un incident doit être diagnostiqué et de la quantité d’espace du disque de démarrage que l’hôte peut réserver en toute sécurité. Recréez le service afin que le conteneur en cours d’exécution reçoive la nouvelle configuration de journalisation, puis inspectez ses paramètres effectifs et effectuez un petit test contrôlé pour confirmer que les fichiers pivotent comme prévu.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Définir des valeurs par défaut pour les futurs conteneurs sans supposer qu’elles modifieront les conteneurs existants

Configurez une valeur par défaut au niveau du démon ou de la plateforme pour les conteneurs nouvellement créés, afin qu’un paramètre de service omis ne rétablisse pas silencieusement une journalisation locale illimitée. Laissez aux services critiques la possibilité d’utiliser une surcharge plus restrictive lorsque leurs besoins de diagnostic diffèrent.

La modification d’une valeur par défaut de journalisation Docker ne réécrit pas rétroactivement la configuration de chaque conteneur existant sur l’hôte. Les mêmes recommandations de la communauté distinguent les valeurs par défaut du démon des paramètres définis à la création de chaque conteneur ; les anciens services doivent donc être inspectés et recréés volontairement.

Déployez d’abord la modification sur un service non critique. Vérifiez que la récupération des journaux, la supervision, les alertes et les procédures d’assistance fonctionnent toujours, puis recréez les autres services par lots contrôlés sans supprimer leurs volumes persistants.

Corriger l’événement à l’origine de l’afflux de journaux

Les limites de rotation réduisent les dégâts, mais elles ne réparent pas un conteneur qui redémarre toutes les quelques secondes, réessaie de joindre une base de données inaccessible, journalise chaque contrôle d’intégrité, subit une attaque ou un afflux de requêtes, ou a été laissé en mode débogage après un dépannage.

Un utilisateur Docker a attribué un journal JSON d’environ 80 Go à une sortie de débogage excessive, illustrant comment une sortie au niveau débogage peut saturer un disque de démarrage, même lorsque la rotation constitue la mesure de protection immédiate.

Regroupez les messages répétés par fréquence et par premier horodatage, puis corrigez l’erreur racine la plus ancienne. Le guide ZimaSpace consacré à l’identification d’une dépendance à l’origine d’une boucle de redémarrage constitue l’étape de diagnostic suivante lorsque des échecs de connexion, de montage, de secret ou de disponibilité génèrent la tempête de journaux.

Suivre séparément les journaux Docker, journald et ceux des applications

Un conteneur peut envoyer sa sortie standard à Docker tout en écrivant ses propres fichiers dans un montage lié, tandis que le service Docker lui-même peut envoyer des événements du démon à journald. Chaque destination possède son propre responsable de la conservation et peut remplir indépendamment le même système de fichiers de démarrage.

Des opérateurs de serveurs domestiques ont signalé que les répertoires de journaux des applications augmentaient malgré l’idée que la rotation au niveau Docker les contiendrait. Un cas rapporté dans la communauté TrueNAS souligne la nécessité d’identifier quelle couche de journalisation gère la conservation avant d’ajuster les limites.

Établissez après la correction une référence pour l’utilisation du disque de démarrage, les fichiers journaux les plus volumineux, la taille du journal, le nombre de redémarrages des conteneurs et la croissance quotidienne. La réparation n’est terminée que lorsque chaque destination active dispose d’une politique limitée, que le service bruyant reste stable dans sa charge de travail normale et qu’un redémarrage volontaire ne recrée pas de fichiers illimités.