Come evitare che i log di Home Assistant riempiano il disco di sistema

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Prevent Home Assistant Logs From Filling the System Disk

Impedisci che i log di Home Assistant riempiano il disco identificando prima il file in crescita esatta, correggendo l’evento ripetuto e applicando la conservazione al livello che gestisce quel log.

Su un piccolo server domestico, i log di Home Assistant Core, i log di Docker, i log del Supervisor o degli add-on e il journal dell’host possono consumare tutti lo stesso disco di sistema, richiedendo però interventi diversi. Misura la crescita in una breve finestra controllata, conserva prove sufficienti per identificare il processo che scrive, usa limiti reversibili e interrompi le scritture non essenziali se lo spazio residuo è troppo ridotto per un riavvio o un backup sicuro.

Identifica quale log sta consumando spazio

Registra lo spazio libero totale, quindi elenca i file e le directory più grandi nel filesystem interessato senza eliminare nulla. Confronta nuovamente le dimensioni dopo cinque-dieci minuti mentre Home Assistant funziona normalmente. Il file la cui dimensione cambia è più utile di un elenco statico di vecchi file grandi.

I casi di Home Assistant mostrano che l’esaurimento dello spazio può dipendere da livelli diversi, inclusi i log di sistema anziché il database Recorder. Una discussione risolta ha ricondotto la crescita al journal di systemd, quindi la prima distinzione riguarda quale directory continua a crescere, non se Home Assistant sembra occupato.

Se cresce un log di Core, esamina il componente e il messaggio ripetuti. Se crescono i log JSON di Docker, esamina il driver di log del container. Se cresce il journal, esamina il servizio che emette i messaggi. Se lo spazio libero è già a un livello critico, arresta il container non essenziale più rumoroso o Home Assistant stesso prima che ulteriori scritture rendano più difficile il ripristino.

Correggi gli errori ripetuti prima di ridurre la visibilità

Conta il messaggio prevalente e confronta i relativi timestamp con un dispositivo, un’integrazione, un’automazione, un add-on o un evento di rete. Un avviso ripetuto migliaia di volte ha solitamente un valore preventivo maggiore rispetto a decine di voci isolate e non correlate. Salva un breve campione con la versione e il trigger prima di modificare le impostazioni.

Un problema di Home Assistant Core ha documentato un errore di Tradfri che ha portato un log oltre 10 GB, esaurendo il disco di sistema. È un esempio circoscritto a una determinata versione di un’integrazione che inonda un log; dimostra l’importanza di isolare il responsabile, non di presumere che Tradfri o la rotazione siano sempre la causa.

Disattiva la registrazione di debug quando hai completato la raccolta, quindi ricarica o disattiva solo l’integrazione rumorosa confermata e ripeti il trigger originale. Se la frequenza dei messaggi crolla, ripara quell’integrazione o la relativa dipendenza. Se non cambia, ripristina l’impostazione e passa al successivo responsabile verificato invece di sopprimere tutti gli avvisi.

Imposta la conservazione al livello che gestisce il log

Imposta separatamente una politica con limiti per il journal dell’host, il driver di log di Docker, il proxy inverso e gli altri add-on. Il livello di log di Core non limita lo spazio del journal di systemd e un’opzione sulle dimensioni di Docker non esegue la rotazione di un file scritto direttamente all’interno di una directory di configurazione montata.

Scegli limiti che conservino una cronologia sufficiente a coprire l’intervallo tra i controlli, mantenendo al contempo spazio per backup, aggiornamenti, operazioni sul database e ripristino. L’articolo correlato di ZimaSpace sulla quantità di spazio libero di Home Assistant spiega perché consumare l’ultimo margine disponibile può interrompere operazioni che richiedono temporaneamente ulteriore spazio su disco.

Documenta ogni politica nella configurazione che sopravvive alla ricreazione. Riavvia o ricrea solo il servizio interessato, verifica che l’impostazione sia attiva e conserva il valore precedente per un eventuale ripristino. Non usare un’eliminazione generalizzata pianificata come sostituto dell’identificazione di un processo di scrittura anomalo.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Verifica che la crescita rimanga limitata con il trigger originale

Riproduci l’evento che ha causato l’inondazione, ad esempio un dispositivo che va offline, un tentativo ripetuto di un’integrazione, un backup o un’interruzione di rete. Monitora le dimensioni dello stesso file, la frequenza dei messaggi, lo spazio libero, lo stato del servizio e la risposta delle automazioni per un periodo più lungo rispetto alla precedente finestra di crescita.

Un risultato positivo presenta un ingombro dei log stabile o sottoposto a rotazione, nessuna perdita delle informazioni diagnostiche necessarie, normali scritture nella cronologia e spazio libero sufficiente per il backup e l’aggiornamento successivi. Riavvia l’host una volta e ripeti il trigger, così da verificare i limiti anche dopo la ricreazione del servizio.

Ripristina una modifica alla conservazione se elimina le prove necessarie per diagnosticare un problema ancora in corso. Se il log continua a espandersi dopo aver isolato la fonte confermata, segnala il problema includendo il messaggio ripetuto, il componente che lo emette, la versione, la velocità di crescita e il percorso di archiviazione; interrompi nuovamente le scritture se il disco si avvicina all’esaurimento.