Så förhindrar du att Home Assistant-loggar fyller systemdisken

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Förhindra att Home Assistant-loggar fyller disken genom att först identifiera den exakta filen som växer, åtgärda den återkommande händelsen och tillämpa lagringstiden på det lager som äger loggen.

På en liten hemmaserver kan loggar från Home Assistant Core, Docker, Supervisor eller tillägg samt värddatorns journal alla förbruka samma systemdisk, samtidigt som de kräver olika åtgärder. Mät tillväxten under ett kort, kontrollerat tidsintervall, bevara tillräckligt med bevis för att identifiera den komponent som skriver, använd reversibla begränsningar och stoppa icke nödvändiga skrivningar om det återstående utrymmet är för litet för en säker omstart eller säkerhetskopia.

Identifiera vilken logg som förbrukar utrymme

Notera först det totala lediga utrymmet och lista sedan de största filerna och katalogerna på det berörda filsystemet utan att radera något. Jämför storlekarna igen efter fem till tio minuter medan Home Assistant körs normalt. Filen vars storlek förändras är mer användbar än en statisk lista över gamla stora filer.

Fall med Home Assistant visar att slut på diskutrymme kan bero på olika lager, inklusive systemloggar snarare än Recorder-databasen. I en löst diskussion spårades tillväxten till systemd-journalen, så den första frågan är vilken katalog som fortsätter att växa, inte om Home Assistant verkar vara upptaget.

Om en Core-logg växer granskar du dess återkommande komponent och meddelande. Om Docker JSON-loggar växer granskar du containerns loggdrivrutin. Om journalen växer granskar du tjänsten som genererar meddelandena. Om det lediga utrymmet redan är kritiskt lågt stoppar du den mest högljudda icke nödvändiga containern eller själva Home Assistant innan ytterligare skrivningar gör återställningen svårare.

Åtgärda återkommande fel innan du minskar synligheten

Räkna det vanligaste meddelandet och matcha tidsstämplarna mot en enhet, integration, automatisering, ett tillägg eller en nätverkshändelse. En varning som upprepas tusentals gånger har vanligtvis större förebyggande värde än dussintals orelaterade engångsposter. Spara ett kort exempel med version och utlösare innan du ändrar inställningarna.

Ett problem i Home Assistant Core dokumenterade ett Tradfri-fel som drev en logg över 10 GB och fyllde systemdisken. Det är ett versionsspecifikt exempel på en integration som översvämmar en logg; det stöder att isolera den komponent som genererar meddelandena, inte att anta att Tradfri eller loggrotation alltid är orsaken.

Inaktivera felsökningsloggning när insamlingen är klar och ladda sedan om eller inaktivera endast den bekräftat högljudda integrationen och upprepa den ursprungliga utlösaren. Om meddelandefrekvensen sjunker kraftigt åtgärdar du integrationen eller dess beroende. Om den inte gör det återställer du inställningen och går vidare till nästa verifierade komponent i stället för att undertrycka alla varningar.

Ställ in lagringstid på det lager som äger loggen

Ställ in en begränsad policy separat för värddatorns journal, Dockers loggdrivrutin, reverse proxy och andra tillägg. En loggnivå i Core begränsar inte lagringen i systemd-journalen, och ett storleksalternativ i Docker roterar inte en fil som skrivs direkt i en monterad konfigurationskatalog.

Välj gränser som bevarar tillräckligt med historik för att täcka intervallet mellan kontrollerna, samtidigt som utrymme lämnas för säkerhetskopior, uppdateringar, databasarbete och återställning. Den relaterade ZimaSpace-artikeln om ledigt lagringsutrymme i Home Assistant förklarar varför det kan leda till problem att förbruka den sista marginalen när en åtgärd tillfälligt behöver ytterligare diskutrymme.

Dokumentera varje policy i den konfiguration som överlever återskapande. Starta om eller återskapa endast den berörda tjänsten, bekräfta att inställningen är aktiv och behåll det tidigare värdet tillgängligt för återställning. Använd inte schemalagd massradering som ersättning för att hitta en onormal skrivande komponent.

-15% OFF
Single board computer zimaboard2

Verifiera att tillväxten förblir begränsad under den ursprungliga utlösaren

Återskapa händelsen som orsakade översvämningen, till exempel att en enhet går offline, en integration försöker igen, en säkerhetskopia körs eller ett nätverksavbrott inträffar. Följ samma filstorlek, meddelandefrekvens, lediga utrymme, tjänstehälsa och automatiseringsrespons under längre tid än den tidigare tillväxtperioden.

Ett godkänt resultat innebär ett stabilt eller roterande loggutrymme, ingen förlust av nödvändig diagnostik, normala historikskrivningar och tillräckligt med ledigt utrymme för nästa säkerhetskopia och uppdatering. Starta om värddatorn en gång och upprepa utlösaren så att begränsningarna bevisas även efter att tjänsten har återskapats.

Återställ en ändring av lagringstiden om den tar bort bevis som behövs för att diagnostisera ett pågående fel. Eskalera med det återkommande meddelandet, den komponent som genererar det, versionen, tillväxthastigheten och lagringssökvägen om loggen fortfarande växer efter att den bekräftade källan har isolerats. Stoppa skrivningarna igen om disken närmar sig full kapacitet.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.