Come impedire che i log di Docker riempiano il disco di avvio dell’host?

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 Do You Stop Docker Logs From Filling a Host Boot Drive? - Zima Store Online

Interrompi la sorgente che produce immediatamente i log, individua il sistema di destinazione attivo, quindi applica una rotazione con limiti e risolvi l’errore o il ciclo di riavvio che sta causando il flusso eccessivo.

Su un NAS o un home server basato su Docker, il disco di avvio può riempirsi anche quando i file multimediali e i database risiedono su un altro pool, perché l’output stdout e stderr dei container, i dati del journal di systemd e i file nativi delle applicazioni possono comunque rimanere nel filesystem di sistema. La sequenza sicura consiste nel preservare una quantità sufficiente di prove recenti, arrestare la crescita incontrollata, determinare quale livello di logging occupa lo spazio, configurare la conservazione per i servizi esistenti e futuri e verificare che l’applicazione sottostante non generi più lo stesso volume di log.

Individua l’archivio dei log che sta realmente crescendo

Controlla lo spazio libero sul filesystem di avvio, quindi confronta le dimensioni della directory dati di Docker, dei file di log dei singoli container, del journal di sistema e delle directory dei log delle applicazioni montate dall’host. Registra i percorsi più grandi prima di eliminare o troncare qualsiasi file.

In un caso di utilizzo eccessivo dello spazio su Docker, i normali riepiloghi di Docker non mostravano il principale responsabile perché il file di log predefinito cresceva separatamente. La prova decisiva era un log del container in continua crescita nel percorso di archiviazione locale di Docker.

Esamina il driver di log configurato e il percorso dei log di ogni container in esecuzione, quindi associa il file più grande al nome del container e ai messaggi recenti. Se nessun log dei container spiega l’utilizzo, continua con journald e con le directory native delle applicazioni, invece di presumere che ogni problema di spazio relativo a Docker dipenda da json-file.

Arresta il container rumoroso prima della pulizia d’emergenza

Quando il disco di avvio è quasi pieno, metti in pausa o arresta il container che sta crescendo più rapidamente. Salva una quantità limitata delle ultime righe del log, il numero di riavvii, lo stato di uscita, la versione dell’immagine, l’ambiente, i mount e il primo errore ripetuto prima di recuperare spazio.

Gli amministratori scoprono spesso che i log JSON dei container possono consumare lo spazio residuo quando non è configurato alcun limite dimensionale. Una lunga discussione su Stack Overflow identifica la crescita illimitata dei log JSON come un rischio di capacità distinto dai dati delle immagini e dei volumi.

Non eliminare alla cieca un file di log attivo mentre Docker lo mantiene aperto e non rimuovere mai directory arbitrarie dall’albero dei metadati di Docker. Usa la procedura di rotazione o troncamento supportata dalla piattaforma solo dopo aver arrestato la sorgente, quindi verifica che i blocchi recuperati siano visibili prima di riavviare qualsiasi servizio interessato.

Applica una rotazione con limiti a ogni servizio a esecuzione prolungata

Imposta un driver di log esplicito e limiti di rotazione finiti nella configurazione del servizio Compose o del container. Per il comune driver JSON, i controlli importanti sono la dimensione massima del file e il numero limitato di file conservati.

Una discussione della community Docker sulla rotazione spiega che opzioni come max-size e max-file limitano la quantità di cronologia locale conservata da un container. Il requisito operativo è una politica di rotazione finita, non un unico file in crescita indefinita.

Scegli i limiti in base alla rapidità con cui deve essere diagnosticato un incidente e alla quantità di spazio sul disco di avvio che l’host può riservare in sicurezza. Ricrea il servizio affinché il container in esecuzione riceva la nuova configurazione di logging, quindi controlla le impostazioni effettive ed esegui un piccolo test controllato per verificare che i file vengano ruotati come previsto.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Imposta i valori predefiniti per i container futuri senza presumere che modifichino quelli esistenti

Configura un valore predefinito a livello di demone o piattaforma per i container creati in futuro, in modo che un’impostazione omessa del servizio non ripristini silenziosamente il logging locale illimitato. Lascia ai servizi critici la possibilità di usare un override più restrittivo quando le loro esigenze diagnostiche sono diverse.

La modifica di un valore predefinito di logging Docker non riscrive retroattivamente la configurazione sull’host di ogni container esistente. Le stesse indicazioni della community distinguono i valori predefiniti del demone dalle impostazioni applicate alla creazione dei singoli container, quindi i vecchi servizi devono essere controllati e ricreati intenzionalmente.

Applica la modifica prima a un servizio non critico. Verifica che il recupero dei log, il monitoraggio, gli avvisi e i flussi di supporto continuino a funzionare, quindi ricrea i servizi rimanenti in gruppi controllati senza rimuovere i relativi volumi persistenti.

Risolvi l’evento che produce il flusso eccessivo di log

I limiti di rotazione riducono i danni, ma non risolvono un container che si riavvia ogni pochi secondi, ritenta la connessione a un database irraggiungibile, registra ogni controllo di integrità, riceve un attacco o un flusso eccessivo di richieste oppure è rimasto in modalità di debug dopo la risoluzione dei problemi.

Un utente Docker ha ricondotto un log JSON di circa 80 GB a un output di debug eccessivo, dimostrando come l’output a livello di debug possa saturare un disco di avvio anche quando la rotazione è la misura di sicurezza immediata.

Raggruppa i messaggi ripetuti in base alla frequenza e al primo timestamp, quindi risolvi l’errore originario. La guida di ZimaSpace per individuare la dipendenza che causa un ciclo di riavvio è il passaggio diagnostico successivo quando errori di connessione, mount, segreti o disponibilità generano il sovraccarico di log.

Monitora separatamente i log di Docker, journald e delle applicazioni

Un container può inviare stdout a Docker e allo stesso tempo scrivere i propri file in un bind mount, mentre il servizio Docker stesso può inviare gli eventi del demone a journald. Ogni destinazione ha un responsabile diverso per la conservazione e può riempire indipendentemente lo stesso filesystem di avvio.

Gli operatori di home server hanno segnalato directory di log delle applicazioni in crescita nonostante l’aspettativa che la rotazione a livello Docker le contenesse. Un caso della community TrueNAS evidenzia la necessità di identificare quale livello di logging gestisce la conservazione prima di modificare i limiti.

Registra una baseline post-intervento relativa all’utilizzo del disco di avvio, ai file di log più grandi, alle dimensioni del journal, al numero di riavvii dei container e alla crescita giornaliera. La riparazione è completa solo quando ogni destinazione attiva dispone di una politica con limiti, il servizio rumoroso rimane stabile durante il normale carico di lavoro e un riavvio deliberato non ricrea file illimitati.