Hur förhindrar man att Docker-loggar fyller upp värdens startenhet?
Stoppa den omedelbara loggproducenten, identifiera den aktiva loggmottagaren och tillämpa sedan begränsad rotation samt åtgärda felet eller omstartsloopen som skapar översvämningen.
På en Docker-baserad NAS eller hemmaserver kan startdisken fyllas även när media och databaser finns på en annan pool, eftersom containrarnas stdout och stderr, systemd-journaldata och programmens egna filer fortfarande kan ligga under systemfilsystemet. Den säkra ordningen är att bevara tillräckligt med aktuell information, stoppa okontrollerad tillväxt, fastställa vilket logglager som använder utrymmet, konfigurera lagringstid för befintliga och framtida tjänster samt verifiera att det underliggande programmet inte längre genererar samma mängd loggar.
Hitta det logglager som faktiskt växer
Kontrollera ledigt utrymme på startfilsystemet och jämför sedan storleken på Dockers datarot, loggfiler per container, systemjournalen och programmens loggkataloger som är monterade från värden. Dokumentera de största sökvägarna innan du tar bort eller tömmer något.
I ett fall med diskutrymmesproblem i Docker visade Dockers vanliga sammanfattningar inte den största användaren, eftersom standardloggfilen växte separat. Det avgörande beviset var en ständigt växande containerlogg under den lokala Docker-lagringssökvägen.
Kontrollera vilken konfigurerad loggdrivrutin och loggsökväg varje körande container använder och matcha den största filen mot containerns namn och senaste meddelanden. Om ingen containerlogg förklarar användningen, fortsätt med journald och programmets egna kataloger i stället för att anta att alla Docker-relaterade diskproblem beror på json-file.
Stoppa den högljudda containern före akut rensning
När startdisken nästan är full bör du pausa eller stoppa containern som växer snabbast. Spara en begränsad loggsvans, dess omstartsantal, avslutningsstatus, image-version, miljö, monteringar och det första upprepade felet innan du frigör utrymme.
Administratörer upptäcker ofta att JSON-loggar för containrar kan förbruka det återstående diskutrymmet när ingen storleksgräns är konfigurerad. En långvarig Stack Overflow-diskussion identifierar obegränsad JSON-loggtillväxt som en separat kapacitetsrisk, skild från image- och volymdata.
Ta inte bort en aktiv loggfil på måfå medan Docker fortfarande har den öppen, och ta aldrig bort godtyckliga kataloger från Dockers metadataträd. Använd endast plattformens stödda procedur för rotation eller tömning efter att producenten har stoppats och bekräfta sedan att det frigjorda utrymmet verkligen syns innan du startar om den berörda tjänsten.
Tillämpa begränsad rotation på varje långvarig tjänst
Ange en uttrycklig loggdrivrutin och ändliga rotationsgränser i Compose-tjänsten eller containerkonfigurationen. För den vanliga JSON-drivrutinen är de viktigaste inställningarna en maximal filstorlek och ett begränsat antal sparade filer.
En rotationsdiskussion i Docker-communityt förklarar att alternativ som max-size och max-file begränsar hur mycket lokal historik en container behåller. Det operativa kravet är en ändlig rotationspolicy, inte en enda fil som växer obegränsat.
Välj gränser utifrån hur snabbt en incident måste kunna felsökas och hur mycket utrymme på startdisken värden säkert kan reservera. Skapa om tjänsten så att den körande containern får den nya loggkonfigurationen och kontrollera sedan dess effektiva inställningar. Genomför även ett litet kontrollerat test för att bevisa att filerna roterar som förväntat.
Ange standardvärden för framtida containrar utan att anta att befintliga ändras
Konfigurera en standardinställning på daemon- eller plattformsnivå för nyskapade containrar, så att en tjänst utan egen inställning inte i tysthet återgår till obegränsad lokal loggning. Låt kritiska tjänster använda en snävare åsidosättning när deras diagnostikbehov skiljer sig.
Att ändra en standardinställning för Docker-loggning skriver inte retroaktivt om värdkonfigurationen för alla befintliga containrar. Samma vägledning från communityt skiljer mellan daemon-standardvärden och inställningar per container vid skapandet, så gamla tjänster måste granskas och skapas om medvetet.
Rulla först ut ändringen till en icke-kritisk tjänst. Bekräfta att logghämtning, övervakning, aviseringar och supportarbetsflöden fortfarande fungerar och skapa sedan om återstående tjänster i kontrollerade grupper utan att ta bort deras beständiga volymer.
Åtgärda händelsen som producerar loggöversvämningen
Rotationsgränser begränsar skadan, men reparerar inte en container som startar om varannan sekund, försöker nå en otillgänglig databas, loggar varje hälsokontroll, utsätts för en attack eller stor mängd förfrågningar eller lämnades i felsökningsläge efter felsökning.
En Docker-användare spårade en JSON-logg på cirka 80 GB till omfattande felsökningsutdata, vilket visar hur utdata på felsökningsnivå kan överbelasta en startdisk även när rotation är den omedelbara skyddsåtgärden.
Gruppera upprepade meddelanden efter frekvens och första tidsstämpel och åtgärda sedan det tidigaste grundfelet. ZimaSpaces guide om att hitta ett beroende som orsakar en omstartsloop är nästa diagnostiska steg när anslutnings-, monterings-, hemlighets- eller beredskapsfel genererar loggstormen.
Håll isär Docker-, journald- och programloggar
En container kan skicka stdout till Docker och samtidigt skriva egna filer till en bind-montering, medan själva Docker-tjänsten kan skicka daemonhändelser till journald. Varje mottagare har en separat ansvarig för lagringstid och kan fylla samma startfilsystem oberoende av de andra.
Operatörer av hemmaservrar har rapporterat att programmets loggkataloger växer trots förväntningen att rotation på Docker-nivå skulle hålla dem under kontroll. Ett TrueNAS-communityfall visar att man måste fastställa vilket logglager som ansvarar för lagringstiden innan gränserna justeras.
Dokumentera en baslinje efter åtgärden för användningen av startdisken, de största loggfilerna, journalens storlek, containrarnas omstartsantal och den dagliga tillväxten. Reparationen är klar först när varje aktiv mottagare har en begränsad policy, den högljudda tjänsten förblir stabil under normal belastning och en avsiktlig omstart inte återskapar obegränsade filer.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
