Comment empêcher les journaux de Home Assistant de remplir le disque système

Empêchez les journaux de Home Assistant de remplir le disque en identifiant d’abord précisément le fichier qui grossit, en corrigeant l’événement répétitif, puis en appliquant la rétention au niveau qui gère ce journal.

Sur un petit serveur domestique, les journaux de Home Assistant Core, de Docker, du Supervisor ou des modules complémentaires, ainsi que le journal de l’hôte, peuvent tous consommer le même disque système, tout en nécessitant des corrections différentes. Mesurez la croissance sur une courte période contrôlée, conservez suffisamment d’éléments pour identifier le processus qui écrit, utilisez des limites réversibles et interrompez les écritures non essentielles si l’espace restant est trop faible pour permettre un redémarrage ou une sauvegarde sûrs.

Identifiez le journal qui consomme l’espace

Notez l’espace libre total, puis répertoriez les fichiers et répertoires les plus volumineux du système de fichiers concerné sans rien supprimer. Comparez de nouveau leurs tailles après cinq à dix minutes, pendant que Home Assistant fonctionne normalement. Le fichier dont la taille change est plus utile qu’une simple liste statique d’anciens fichiers volumineux.

Les cas liés à Home Assistant montrent que l’épuisement de l’espace disque peut provenir de différentes couches, notamment des journaux système plutôt que de la base de données Recorder. Une discussion résolue a identifié le journal systemd comme source de la croissance ; la première distinction à faire est donc quel répertoire continue de grossir, et non de déterminer si Home Assistant semble occupé.

Si un journal Core grossit, examinez son composant et son message répétitifs. Si les journaux JSON de Docker grossissent, examinez le pilote de journalisation du conteneur. Si le journal systemd grossit, examinez le service émetteur. Si l’espace libre est déjà dangereusement faible, arrêtez le conteneur non essentiel le plus bavard, ou Home Assistant lui-même, avant que de nouvelles écritures ne compliquent la récupération.

Corrigez les erreurs répétées avant de réduire la visibilité

Comptez le message dominant et faites correspondre ses horodatages à un appareil, une intégration, une automatisation, un module complémentaire ou un événement réseau. Un avertissement répété des milliers de fois a généralement davantage de valeur préventive que des dizaines d’entrées ponctuelles sans rapport. Enregistrez un court échantillon avec la version et le déclencheur avant de modifier les paramètres.

Un problème de Home Assistant Core a documenté une erreur Tradfri qui a fait dépasser 10 Go à un journal et épuisé le disque système. Il s’agit d’un exemple spécifique à une version d’intégration saturant un journal ; cela justifie d’isoler l’émetteur, et non de supposer que Tradfri ou la rotation est toujours en cause.

Désactivez la journalisation de débogage une fois la capture terminée, puis rechargez ou désactivez uniquement l’intégration bruyante confirmée et répétez le déclencheur d’origine. Si le débit de messages chute, corrigez cette intégration ou sa dépendance. Dans le cas contraire, rétablissez le paramètre et passez à l’émetteur vérifié suivant au lieu de supprimer tous les avertissements.

Définissez la rétention au niveau qui gère le journal

Définissez séparément une politique limitée pour le journal de l’hôte, le pilote de journalisation Docker, le proxy inverse et les autres modules complémentaires. Le niveau de journalisation de Core ne limite pas le stockage du journal systemd, et une option de taille Docker ne fait pas tourner un fichier écrit directement dans un répertoire de configuration monté.

Choisissez des limites qui conservent suffisamment d’historique pour couvrir l’intervalle entre les vérifications, tout en préservant de l’espace pour les sauvegardes, les mises à jour, les opérations sur la base de données et la récupération. L’article ZimaSpace associé sur l’espace libre de Home Assistant explique pourquoi consommer la dernière marge disponible peut interrompre des opérations qui nécessitent temporairement davantage d’espace disque.

Documentez chaque politique dans la configuration qui subsiste après une recréation. Redémarrez ou recréez uniquement le service concerné, vérifiez que le paramètre est actif et conservez l’ancienne valeur pour pouvoir revenir en arrière. N’utilisez pas une suppression générale planifiée pour remplacer la recherche d’un processus d’écriture anormal.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifiez que la croissance reste limitée avec le déclencheur d’origine

Reproduisez l’événement à l’origine de la saturation, par exemple la mise hors ligne d’un appareil, une nouvelle tentative d’une intégration, une sauvegarde ou une panne réseau. Suivez la taille du même fichier, le débit de messages, l’espace libre, l’état du service et la réponse des automatisations pendant une durée supérieure à la précédente période de croissance.

Un résultat satisfaisant se caractérise par une empreinte de journal stable ou soumise à une rotation, l’absence de perte des informations de diagnostic nécessaires, des écritures d’historique normales et suffisamment d’espace libre pour la prochaine sauvegarde et mise à jour. Redémarrez une fois l’hôte et répétez le déclencheur afin de vérifier que les limites restent appliquées après la recréation du service.

Annulez une modification de rétention si elle supprime les éléments nécessaires au diagnostic d’un problème persistant. Si le journal continue de grossir après l’isolement de la source confirmée, transmettez le message répété, le composant émetteur, la version, le taux de croissance et le chemin de stockage ; interrompez de nouveau les écritures si le disque approche de la saturation.