Hoe voorkom je dat Docker-logs de opstartschijf van een host vullen?
Stop de directe producent van de logbestanden, identificeer de actieve logbestemming en pas vervolgens begrensde rotatie toe. Verhelp ook de fout of de herstartlus die de overvloed veroorzaakt.
Op een op Docker gebaseerde NAS of homeserver kan de opstartschijf vollopen, zelfs wanneer media en databases op een andere pool staan, omdat de stdout- en stderr-uitvoer van containers, systemd-journalgegevens en systeemeigen applicatiebestanden nog steeds onder het systeembestandssysteem kunnen staan. De veilige volgorde is: voldoende recent bewijs bewaren, ongecontroleerde groei stoppen, bepalen welke logginglaag de ruimte gebruikt, bewaarbeleid configureren voor bestaande en toekomstige services en controleren of de onderliggende applicatie niet langer dezelfde hoeveelheid logbestanden produceert.
Vind de logopslag die daadwerkelijk groeit
Controleer de vrije ruimte op het bestandssysteem van de opstartschijf en vergelijk vervolgens de omvang van Docker’s gegevensrootmap, logbestanden per container, het systeemjournal en applicatielogmappen die vanaf de host zijn aangekoppeld. Noteer de grootste paden voordat je iets verwijdert of afkapt.
In een Docker-geval met schijfruimteproblemen lieten normale Docker-overzichten niet zien wat de grootste verbruiker was, omdat het standaardlogbestand afzonderlijk bleef groeien. Het doorslaggevende bewijs was een voortdurend groeiend containerlogbestand onder het lokale Docker-opslagpad.
Inspecteer de geconfigureerde logdriver en het logpad van elke actieve container en koppel het grootste bestand aan de containernaam en recente berichten. Als geen containerlogbestand het gebruik verklaart, ga dan verder met journald en systeemeigen applicatiemappen in plaats van ervan uit te gaan dat elk Docker-gerelateerd schijfruimteprobleem bij json-file hoort.
Stop de luidruchtige container vóór noodopruiming
Wanneer de opstartschijf bijna vol is, pauzeer of stop je de container die het snelst groeit. Sla een begrensd uiteinde van het logbestand op, evenals het aantal herstarts, de afsluitstatus, de imageversie, omgeving, aankoppelingen en de eerste zich herhalende fout, voordat je ruimte vrijmaakt.
Beheerders ontdekken vaak dat JSON-logbestanden van containers de resterende schijfruimte kunnen verbruiken wanneer er geen maximale grootte is ingesteld. Een langdurige Stack Overflow-discussie beschrijft onbeperkte groei van JSON-logs als een afzonderlijk capaciteitsrisico naast image- en volum gegevens.
Verwijder een actief logbestand niet blindelings terwijl Docker het nog open heeft en verwijder nooit willekeurige mappen uit de metadataboom van Docker. Gebruik de door het platform ondersteunde rotatie- of afkapprocedure pas nadat je de producent hebt gestopt en controleer vervolgens of de vrijgemaakte blokken zichtbaar zijn voordat je een getroffen service opnieuw start.
Pas begrensde rotatie toe op elke langlopende service
Stel een expliciete logdriver en eindige rotatielimieten in de Compose-service of containerconfiguratie in. Voor de gebruikelijke JSON-driver zijn een maximale bestandsgrootte en een beperkt aantal bewaarde bestanden de belangrijkste instellingen.
Een rotatiediscussie in de Docker-community legt uit dat opties zoals max-size en max-file begrenzen hoeveel lokale geschiedenis één container bewaart. De operationele vereiste is een eindig rotatiebeleid, niet één bestand dat onbeperkt blijft groeien.
Kies limieten op basis van hoe snel een incident moet kunnen worden onderzocht en hoeveel ruimte op de opstartschijf de host veilig kan reserveren. Maak de service opnieuw aan zodat de actieve container de nieuwe loggingconfiguratie ontvangt, inspecteer vervolgens de effectieve instellingen en voer een kleine, gecontroleerde test uit om te bevestigen dat bestanden naar verwachting roteren.
Stel standaardwaarden in voor toekomstige containers zonder aan te nemen dat bestaande containers veranderen
Configureer een standaardwaarde op daemon- of platformniveau voor nieuw aangemaakte containers, zodat een service-instelling die ontbreekt niet stilletjes terugvalt op onbeperkte lokale logging. Laat ruimte voor een smallere override bij kritieke services wanneer hun diagnostische behoeften anders zijn.
Het wijzigen van een standaard Docker-logginginstelling herschrijft niet automatisch de hostconfiguratie van elke bestaande container. Dezelfde richtlijnen uit de community maken onderscheid tussen daemonstandaardwaarden en instellingen per container bij het aanmaken. Daarom moeten oude services worden gecontroleerd en bewust opnieuw worden aangemaakt.
Voer de wijziging eerst door voor één niet-kritieke service. Controleer of het ophalen van logs, monitoring, waarschuwingen en supportprocessen nog werken en maak daarna de overige services in gecontroleerde batches opnieuw aan, zonder hun permanente volumes te verwijderen.
Verhelp de gebeurtenis die de logstroom veroorzaakt
Rotatielimieten beperken de schade, maar repareren geen container die elke paar seconden opnieuw start, een onbereikbare database blijft proberen te bereiken, elke healthcheck logt, door een aanval of verzoekenstroom wordt overspoeld of na het oplossen van problemen in de foutopsporingsmodus is blijven staan.
Een Docker-gebruiker herleidde een JSON-logbestand van ongeveer 80 GB tot buitensporige foutopsporingsuitvoer. Dit illustreert hoe uitvoer op foutopsporingsniveau een opstartschijf kan overspoelen, zelfs wanneer rotatie de directe beveiligingsmaatregel is.
Groepeer herhaalde berichten op frequentie en eerste tijdstip en herstel vervolgens de vroegste hoofdfout. De ZimaSpace-gids voor het vinden van een afhankelijkheid die een herstartlus veroorzaakt is de volgende diagnostische stap wanneer verbindings-, aankoppelings-, geheim- of gereedheidsfouten de logstorm veroorzaken.
Houd Docker-, journald- en systeemeigen applicatielogs afzonderlijk bij
Een container kan stdout naar Docker sturen en tegelijkertijd eigen bestanden naar een bind mount schrijven. Ook kan de Docker-service zelf daemon-gebeurtenissen naar journald sturen. Elke bestemming heeft een andere verantwoordelijke voor bewaarbeleid en kan onafhankelijk hetzelfde bestandssysteem van de opstartschijf vullen.
Beheerders van homeservers hebben gemeld dat logmappen van applicaties blijven groeien, ondanks de verwachting dat rotatie op Docker-niveau dit zou beperken. Een TrueNAS-communitygeval benadrukt dat je moet bepalen welke logginglaag verantwoordelijk is voor het bewaarbeleid voordat je limieten aanpast.
Leg na de oplossing een uitgangsmeting vast van het gebruik van de opstartschijf, de grootste logbestanden, de journalgrootte, het aantal herstarts van containers en de dagelijkse groei. De reparatie is pas voltooid wanneer elke actieve bestemming een begrensd beleid heeft, de luidruchtige service stabiel blijft onder de normale werklast en een bewuste herstart niet opnieuw onbeperkte bestanden aanmaakt.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...
Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.
Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...
