Wie verhindert man, dass Docker-Logs das Boot-Laufwerk eines Hosts füllen?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How Do You Stop Docker Logs From Filling a Host Boot Drive? - Zima Store Online

Stoppen Sie den unmittelbaren Verursacher der Protokollflut, ermitteln Sie das aktive Protokollziel, wenden Sie anschließend eine begrenzte Rotation an und beheben Sie den Fehler oder die Neustartschleife, die die Flut verursacht.

Auf einem Docker-basierten NAS oder Heimserver kann sich das Startlaufwerk füllen, selbst wenn Medien und Datenbanken in einem anderen Pool liegen, da die Standardausgabe und Standardfehlerausgabe von Containern, systemd-Journal-Daten und anwendungseigene Dateien weiterhin im Systemdateisystem verbleiben können. Die sichere Vorgehensweise besteht darin, genügend aktuelle Beweise zu sichern, unkontrolliertes Wachstum zu stoppen, die für den Speicher verantwortliche Protokollierungsebene zu bestimmen, die Aufbewahrung für bestehende und zukünftige Dienste zu konfigurieren und zu überprüfen, dass die zugrunde liegende Anwendung nicht weiterhin dieselbe Datenmenge erzeugt.

Den tatsächlich wachsenden Protokollspeicher finden

Prüfen Sie den freien Speicherplatz auf dem Startdateisystem und vergleichen Sie anschließend die Größe des Docker-Datenverzeichnisses, der Protokolldateien einzelner Container, des System-Journals und der vom Host eingebundenen Anwendungsprotokollverzeichnisse. Notieren Sie die größten Pfade, bevor Sie etwas löschen oder abschneiden.

In einem Fall mit zu hohem Docker-Speicherverbrauch zeigten die üblichen Docker-Zusammenfassungen nicht den Hauptverursacher, da die Standardprotokolldatei unabhängig davon weiter anwuchs. Der entscheidende Hinweis war ein ständig wachsendes Containerprotokoll im lokalen Docker-Speicherpfad.

Prüfen Sie den konfigurierten Protokolltreiber und Protokollpfad jedes laufenden Containers und gleichen Sie die größte Datei mit dem Containernamen und aktuellen Meldungen ab. Wenn kein Containerprotokoll die Nutzung erklärt, fahren Sie mit journald und anwendungseigenen Verzeichnissen fort, statt anzunehmen, dass jedes Docker-bezogene Speicherproblem zu json-file gehört.

Den lautstarken Container vor der Notfallbereinigung stoppen

Wenn das Startlaufwerk fast voll ist, pausieren oder stoppen Sie den Container, der am schnellsten wächst. Sichern Sie einen begrenzten Protokollauszug, die Anzahl der Neustarts, den Beendigungsstatus, die Image-Version, die Umgebungsvariablen, die Einbindungen und den ersten wiederkehrenden Fehler, bevor Sie Speicherplatz freigeben.

Administratoren stellen häufig fest, dass JSON-Protokolle von Containern den verbleibenden Speicher aufbrauchen können, wenn keine Größenbegrenzung konfiguriert ist. Eine lang laufende Stack-Overflow-Diskussion beschreibt unbegrenztes Wachstum von JSON-Protokollen als ein vom Speicherbedarf für Images und Volumes getrenntes Kapazitätsrisiko.

Löschen Sie eine aktive Protokolldatei nicht unüberlegt, solange Docker sie geöffnet hält, und entfernen Sie niemals beliebige Verzeichnisse aus dem Docker-Metadatenbaum. Verwenden Sie das vom System unterstützte Verfahren zur Rotation oder Kürzung erst, nachdem Sie den Verursacher gestoppt haben, und bestätigen Sie anschließend, dass der freigegebene Speicherplatz sichtbar ist, bevor Sie betroffene Dienste neu starten.

Eine begrenzte Rotation für jeden dauerhaft laufenden Dienst anwenden

Legen Sie im Compose-Dienst oder in der Containerkonfiguration einen expliziten Protokolltreiber und begrenzte Rotationswerte fest. Beim verbreiteten JSON-Treiber sind eine maximale Dateigröße und eine begrenzte Anzahl aufbewahrter Dateien die wichtigsten Einstellungen.

Ein Rotationsthread in der Docker-Community erklärt, dass Optionen wie max-size und max-file die Menge des lokalen Verlaufs begrenzen, den ein Container speichert. Erforderlich ist eine begrenzte Rotationsrichtlinie, nicht eine einzelne Datei, die unbegrenzt wächst.

Wählen Sie die Grenzwerte danach, wie schnell ein Vorfall diagnostiziert werden muss und wie viel Speicherplatz auf dem Startlaufwerk der Host sicher reservieren kann. Erstellen Sie den Dienst neu, damit der laufende Container die neue Protokollkonfiguration erhält, prüfen Sie anschließend seine effektiven Einstellungen und führen Sie einen kleinen kontrollierten Test durch, um zu bestätigen, dass die Dateien wie erwartet rotiert werden.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Standardeinstellungen für zukünftige Container festlegen, ohne Änderungen an bestehenden anzunehmen

Konfigurieren Sie einen Standard auf Daemon- oder Plattformebene für neu erstellte Container, damit eine fehlende Diensteinstellung nicht unbemerkt zu unbegrenzter lokaler Protokollierung führt. Lassen Sie wichtigen Diensten die Möglichkeit, eine engere individuelle Einstellung zu verwenden, wenn ihre Diagnoseanforderungen abweichen.

Das Ändern eines Docker-Standards für die Protokollierung schreibt die Hostkonfiguration nicht rückwirkend für jeden bestehenden Container um. Dieselben Hinweise aus der Community unterscheiden zwischen Daemon-Standards und Einstellungen pro Container bei der Erstellung. Daher müssen alte Dienste geprüft und gezielt neu erstellt werden.

Führen Sie die Änderung zunächst bei einem unkritischen Dienst ein. Bestätigen Sie, dass Protokollabruf, Überwachung, Warnungen und Supportabläufe weiterhin funktionieren, und erstellen Sie anschließend die übrigen Dienste in kontrollierten Gruppen neu, ohne ihre persistenten Volumes zu entfernen.

Das Ereignis beheben, das die Protokollflut erzeugt

Rotationsgrenzen begrenzen den Schaden, reparieren aber keinen Container, der alle paar Sekunden neu startet, wiederholt eine nicht erreichbare Datenbank kontaktiert, jede Gesundheitsprüfung protokolliert, einem Angriff oder einer Anfragenflut ausgesetzt ist oder nach der Fehlersuche im Debug-Modus belassen wurde.

Ein Docker-Nutzer führte ein etwa 80 GB großes JSON-Protokoll auf übermäßige Debug-Ausgaben zurück. Dies zeigt, wie Ausgaben auf Debug-Stufe ein Startlaufwerk überlasten können, selbst wenn Rotation die unmittelbare Schutzmaßnahme ist.

Gruppieren Sie wiederkehrende Meldungen nach Häufigkeit und erstem Zeitstempel und beheben Sie den frühesten Grundfehler. Der ZimaSpace-Leitfaden zum Ermitteln einer Abhängigkeit in einer Neustartschleife ist der nächste Diagnoseschritt, wenn Verbindungs-, Einbindungs-, Secret- oder Bereitschaftsfehler den Protokollsturm auslösen.

Docker-, journald- und anwendungseigene Protokolle getrennt überwachen

Ein Container kann seine Standardausgabe an Docker senden und gleichzeitig eigene Dateien in eine Bind-Mount schreiben, während der Docker-Dienst selbst Daemon-Ereignisse an journald senden kann. Jedes Ziel hat einen anderen Verantwortlichen für die Aufbewahrung und kann dasselbe Startdateisystem unabhängig füllen.

Betreiber von Heimservern haben berichtet, dass Anwendungsprotokollverzeichnisse trotz der Erwartung wachsen, die Docker-Rotationsebene würde sie begrenzen. Ein Fall aus der TrueNAS-Community unterstreicht, wie wichtig es ist, zunächst zu bestimmen, welche Protokollierungsebene für die Aufbewahrung zuständig ist, bevor Grenzwerte angepasst werden.

Erfassen Sie nach der Behebung einen Ausgangswert für die Nutzung des Startlaufwerks, die größten Protokolldateien, die Journalgröße, die Neustartzahlen der Container und das tägliche Wachstum. Die Reparatur ist erst abgeschlossen, wenn jedes aktive Protokollziel über eine begrenzte Richtlinie verfügt, der lautstarke Dienst unter seiner normalen Arbeitslast stabil bleibt und ein gezielter Neustart nicht erneut unbegrenzt wachsende Dateien erzeugt.