Docker-Log-Bereinigung Komplettguide: 5 Methoden gegen json.log auf voller Festplatte

Kurzfassung (erst stoppen, dann dauerhaft absichern)

Wenn Docker-Logs die Platte füllen, ist die wirksamste Reihenfolge:
zuerst mit truncate Speicher freigeben, dann max-size + max-file für Rotation, zuletzt Container neu erstellen, damit die Konfiguration greift.
Nur bereinigen ohne Konfiguration – das Problem kommt zurück. Nur konfigurieren ohne Neuerstellung – alte Container wachsen weiter.

Um 3:17 Uhr morgens weckte mich ein lautes Handy-Vibrieren aus dem Halbschlaf.

Auf dem Display blinkte ein roter Alarm: „Produktionsserver: Festplatte 100 %, alle Dienste reagieren nicht mehr.“ In dem Moment wurde mir kalt – eine E-Commerce-Plattform mit Hunderttausenden Nutzern; jede Minute Ausfall kostet echtes Geld.

Per SSH auf dem Server: df -h bestätigte, die Root-Partition war voll. Nach ein paar Checks fand ich die Ursache unter /var/lib/docker/containers/: Die xxx-json.log eines Containers hatte 82 GB!

Ehrlich gesagt war ich erst perplex. Der Container lief normal – wie konnte das Log so explodieren?

Später wurde klar: Das ist kein Einzelfall. Docker begrenzt Log-Dateien standardmäßig nicht. Alles von stdout und stderr landet in json.log und wächst weiter, bis die Festplatte voll ist.

Wenn Docker-Logs Sie stressen: In diesem Artikel geht es um Notfall-Bereinigung, Log-Rotation gegen Wiederholung und die Wahl des passenden Log-Treibers. Die Stolpersteine aus der Praxis sind eingearbeitet – damit Sie sie umgehen können.

Warum Docker-Logs die Festplatte füllen

Wie Docker Logs speichert

Kurz der Mechanismus:

Schreibt Ihr Container per console.log(), System.out.println() oder anderweitig nach stdout/stderr, landet die Ausgabe in einer JSON-Log-Datei unter /var/lib/docker/containers/<container-id>/<container-id>-json.log.

Das klingt harmlos – Docker rotiert diese Logs standardmäßig nicht.

Die Datei wächst weiter, ohne automatisches Splitten oder Löschen alter Einträge. Ein Tag kann 1 GB bedeuten, eine Woche 7 GB, ein Monat 30 GB. Bei sehr gesprächigen Apps (z. B. DEBUG-Level) geht es noch schneller.

Grober Rechenwert: mittel stark frequentierte Web-App, 100 Logzeilen/Sekunde, ~100 Byte pro Zeile:

100 Zeilen/s × 86.400 s × 100 Byte ≈ 864 MB/Tag ≈ 25 GB/Monat

Bei 10 solchen Containern ist 100 GB Festplatte in unter einem Monat voll – und das ist konservativ gerechnet.

Typische Risikoszenarien

Aus eigener Erfahrung und von Kollegen: besonders gefährlich sind diese Fälle:

1. Zu niedriges Log-Level in Produktion

Für Debug in Entwicklung INFO oder DEBUG gesetzt und in Produktion vergessen zu ändern. Jeder HTTP-Request erzeugt viele Zeilen – Logs explodieren.

Extremfall: Node.js-Service loggte den kompletten Request-Body inkl. Base64 bei Bild-Uploads – ein Request = mehrere MB Log. Nach drei Tagen: 200 GB voll.

2. Endlosschleife mit Fehlerausgabe

Ein Bug lässt die App in einer Schleife Exceptions mit vollem Stack ausgeben – Wachstum in GB pro Stunde.

Einmal: Mikroservice mit falscher DB-Pool-Konfiguration, hunderte Verbindungsversuche pro Sekunde mit vollem Stack. In 3 Stunden von 2 GB auf 120 GB – Festplatte voll, System down.

3. Lang laufende Produktions-Container

Monate oder Jahre ohne Log-Rotation – Summe wird enorm.

Ein übernommenes Projekt: Nginx-Container 8 Monate online, Log 150 GB. docker logs hing, weil Docker die Riesendatei lesen musste.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

4. Hoher Traffic

Viele Requests → viele Zeilen. Selbst eine Zeile pro Request summiert sich bei Millionen PV/Tag.

Viele merken es erst, wenn nachts die Platte voll ist und alles abstürzt.

Notfall: sofort Speicher freigeben

Die Platte ist voll, Dienste liegen, im Chat wird gedrängt. Ruhe bewahren – erst Platz schaffen.

Schritt 1: Die größten Dateien finden

find /var/lib/docker/ -name "*.log" -exec ls -sh {} \; | sort -h -r | head -20

Listet die 20 größten Log-Dateien, z. B.:

82G /var/lib/docker/containers/a1b2c3d4.../a1b2c3d4...-json.log
35G /var/lib/docker/containers/e5f6g7h8.../e5f6g7h8...-json.log
12G /var/lib/docker/containers/i9j0k1l2.../i9j0k1l2...-json.log
...

Container-ID notieren (die lange Zeichenkette).

Pfad eines bestimmten Containers:

docker inspect --format='{{.LogPath}}' <container_name_or_id>

Beispiel:

docker inspect --format='{{.LogPath}}' nginx
# Ausgabe: /var/lib/docker/containers/abc123.../abc123...-json.log

Schritt 2: Logs sicher leeren

Wichtig: Nicht einfach rm auf die Log-Datei!

rm -f xxx-json.log hält Docker verwirrt: Der Prozess hat den Dateideskriptor noch, schreibt weiter, aber der belegte Speicher wird oft nicht freigegeben.

Richtig: Inhalt leeren, Datei behalten.

Methode 1: cat

cat /dev/null > $(docker inspect --format='{{.LogPath}}' <container_id>)

Leert die Datei auf 0 Byte; Docker merkt nichts Störendes.

cat /dev/null > $(docker inspect --format='{{.LogPath}}' nginx)

Methode 2: truncate (empfohlen)

truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container_id>)

-s 0 setzt die Dateigröße auf 0.

truncate -s 0 $(docker inspect --format='{{.LogPath}}' nginx)

Methode 3: alle Container-Logs auf einmal

sudo sh -c 'truncate -s 0 /var/lib/docker/containers/*/*-json.log'

Achtung: Leert alle Container-Logs. Nur im Notfall; sonst lieber gezielt pro Container.

Wirkung prüfen

df -h /var/lib/docker/

Die Nutzung sollte deutlich sinken. Bleibt sie hoch, schreibt vermutlich noch ein Container massiv – z. B. DEBUG abschalten oder die Fehlerschleife fixen.

Nach dem 82-GB-Fall: von 100 % auf ~60 %, Dienste sofort wieder da. Klar war aber: das ist Symptombehandlung – Rotation ist Pflicht.

Dauerhaft: Log-Rotation konfigurieren

Notfall-Bereinigung reicht kurzfristig. Docker muss Log-Größe automatisch begrenzen.

Global: daemon.json

Häufigster Weg: globale Parameter in /etc/docker/daemon.json.

Datei anlegen oder ergänzen:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}

Parameter:

• max-size: maximale Größe einer Datei, danach Rotation
• max-file: wie viele Dateien behalten werden; älteste werden gelöscht
• compress: alte Dateien komprimieren

Mit dieser Konfiguration: höchstens etwa 10 MB × 3 = 30 MB pro Container (ohne Kompression).

Empfehlung Produktion:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3",
    "compress": "true"
  }
}

100m lässt mehr Historie für Analyse; 3 Dateien ≈ 300 MB recent logs.

Anpassung nach Bedarf:

• wenig Logs: max-size: "10m", max-file: "3"
• mittel: max-size: "50m", max-file: "3"
• viel: max-size: "100m", max-file: "5"

Hinweis: Werte als Strings in Anführungszeichen – "max-size": "10m", nicht "max-size": 10m.

Docker neu starten

sudo systemctl restart docker

Wichtig: Gilt nur für neu erstellte Container – laufende behalten die alte Konfiguration.

Container neu anlegen:

docker run:

docker stop <container_name>
docker rm <container_name>
docker run [ursprüngliche Parameter] <image>

docker-compose:

docker-compose down
docker-compose up -d

down entfernt Container; up -d erstellt sie mit neuer Log-Konfiguration.

Pro Container konfigurieren

Ohne globale Änderung – nur für „laute“ Container:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

docker run:

docker run -d \
  --name my-app \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  nginx:latest

docker-compose.yml:

version: '3.8'
services:
  web:
    image: nginx:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
        compress: "true"

Flexibel pro Dienst, z. B. Nginx 50m / 5, Cron-Job 5m / 2.

Konfiguration verifizieren

docker inspect <container_name> | grep -A 10 LogConfig

Erwartung:

"LogConfig": {
    "Type": "json-file",
    "Config": {
        "max-file": "3",
        "max-size": "10m",
        "compress": "true"
    }
}

Leeres {} = noch Default (unbegrenzt) → Container neu erstellen.

Ein kleines Prüfskript für alle Container hat mir später Ärger erspart.

Log-Treiber im Überblick

Bisher vor allem json-file – Docker bietet mehrere Treiber.

json-file (Standard)

Vorteile:

• docker logs für schnelle Fehlersuche
• einfach mit max-size / max-file
• lokal, schneller Zugriff

Nachteile:

• ohne Rotation: volle Platte (Hauptthema dieses Artikels)
• Logs auf dem Host – weg mit dem Container

Einsatz: die meisten Szenarien, wenn Rotation gesetzt ist.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3",
    "compress": "true"
  }
}

local (empfohlen ab Docker 18.09)

Vorteile:

• automatische Rotation mit Standard-Limits
• effizienteres Format als json-file
• docker logs funktioniert

Nachteile:

• Docker 18.09+
• binäres Format – kein direktes cat (selten nötig)

Einsatz: Produktion – weniger manuelle Pflege.

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

Neue Projekte setze ich oft auf local.

journald

Auf systemd-Hosts (Ubuntu 16.04+, CentOS 7+).

Vorteile:

• Integration ins System-Logging
• eigene Rotation
• strukturierte Metadaten (Container-ID, Name)
• docker logs und journalctl

Nachteile:

• nur mit systemd
• journald-Kenntnisse nötig

Einsatz: wenn die Ops-Kette schon journald nutzt.

{
  "log-driver": "journald"
}

journalctl -u docker.service -f CONTAINER_NAME=my-app

syslog

Logs an einen syslog-Server.

Vorteile:

• zentrale Logs, remote
• TCP/UDP
• Anbindung an bestehende syslog-Infrastruktur

Nachteile:

• kein docker logs – Troubleshooting unbequem
• Netzwerk-Latenz
• syslog-Server pflegen

Einsatz: große Cluster mit etabliertem syslog.

{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "tcp://192.168.1.100:514",
    "syslog-facility": "daemon",
    "tag": "{{.Name}}/{{.ID}}"
  }
}

Ohne zwingenden Bedarf rate ich von syslog ab – fehlendes docker logs schmerzt.

Empfehlung nach Szenario

Praxis: kleine Projekte local; große json-file + Loki zentral, lokal einige hundert MB für Notfälle.

Prinzip: lokale Log-Größe immer begrenzen – sonst platzt die Platte irgendwann.

Best Practices und Betrieb

Checkliste Produktion

1. Globale Log-Konfiguration

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

oder json-file:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3",
    "compress": "true"
  }
}

2. Alle Container prüfen

#!/bin/bash
for container in $(docker ps -q); do
  name=$(docker inspect --format='{{.Name}}' $container | sed 's/\///')
  logconfig=$(docker inspect --format='{{json .HostConfig.LogConfig}}' $container)
  echo "Container: $name"
  echo "Log-Konfiguration: $logconfig"
  echo "---"
done

3. Monitoring und Alarme

• Festplatte > 80 %: Warnung

• 90 %: kritisch

• Größe von /var/lib/docker/containers/ über Schwellwert: Warnung

Beispiel Prometheus:

- alert: HighDiskUsage
  expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes > 0.8
  for: 5m
  annotations:
    summary: "Festplattennutzung über 80 %"

4. Regelmäßige Kontrolle

du -sh /var/lib/docker/
du -sh /var/lib/docker/containers/
find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} \; | sort -h -r | head -10

Optimierung auf Anwendungsebene

1. Log-Level

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Produktion: WARN oder ERROR, nicht DEBUG/INFO. Das reduziert oft > 80 % des Volumens.

2. Dedizierte Log-Plattform

Bei sehr hohem Volumen: ELK, Loki + Grafana oder Cloud-Logging (SLS, CLS …). Docker-Logs nur als kurzer Puffer für Notfälle.

3. Strukturierte Logs

// schlecht
console.log("Benutzer angemeldet, ID: " + userId);

// gut
console.log(JSON.stringify({
  level: "info",
  event: "user_login",
  userId: userId,
  timestamp: new Date().toISOString()
}));

4. Sampling

if (Math.random() < 0.1) {
  console.log("HTTP-Anfragedetails...");
}

oder Details nur bei Fehlern:

if (error) {
  console.log("Detaillierte Anfrageinformationen: ", requestDetails);
}

FAQ

F1: Beeinflusst ein Docker-Neustart nach daemon.json laufende Container?

Nein – sie laufen weiter. Die neuen Einstellungen gelten nur für neu erstellte Container; bestehende müssen neu gebaut werden.

F2: Stört Leeren der Log-Datei die Anwendung?

Nein. Docker hält den Deskriptor; nach truncate wird normal weitergeschrieben.

F3: Braucht journald noch max-size?

Nein – journald rotiert selbst.

F4: Rotation konfiguriert, Logs trotzdem riesig?

Prüfen: (1) Container neu erstellt? (2) extrem lange einzelne Logzeilen? Rotation ist dateigrößenbasiert, nicht zeilenbasiert.

F5: Alte rotierte Dateien (xxx-json.log.1.gz) löschen?

Ja, wenn rotiert/archiviert. Die aktuelle xxx-json.log nicht rm – truncate verwenden.

Kurz die Fallstricke

1. daemon.json nur für neue Container – bestehende neu erstellen
2. Werte in Anführungszeichen: "max-size": "10m"
3. truncate, nicht rm
4. syslog ohne docker logs – json-file und journald unterstützen es
5. Nach Änderung: systemctl restart docker
6. Regelmäßig prüfen – besonders bei neuen Deployments

Kernbotschaft: früh konfigurieren, regelmäßig prüfen – nicht erst bei voller Platte.

Fazit

Zurück zum Alarm um 3:17 Uhr.

Etwa 30 Minuten Bereinigung, 2 Stunden Rotation und Monitoring, alle Container neu erstellt – gegen 6 Uhr war es erledigt.

Lehre: Docker-Log-Management ist kein Detail – es ist eine Zeitbombe.

Notfall: truncate für sofort freien Speicher.
Prävention: Rotation in daemon.json (max-size + max-file), Treiber local oder json-file, Container neu erstellen.
Dauerhaft: Festplatten-Alarme, Log-Konfiguration prüfen, App-Logs optimieren.

Jetzt prüfen:

1. find /var/lib/docker/ -name "*.log" -exec ls -sh {} \; | sort -h -r | head -10
2. /etc/docker/daemon.json auf Rotation
3. docker inspect – Limits auf allen Containern

Nicht erst um 3 Uhr nachts durch den Alarm.

Hat der Artikel geholfen, teilen Sie ihn gern – weniger Überraschungen, mehr Schlaf.

Weiterlesen

• Docker Exit-Code 137/1: Container-Absturz debuggen
• Docker-Ressourcenlimits: CPU, Speicher und Stabilität
• Docker-Logs anzeigen und analysieren