Docker-Log-Management in der Praxis: Von Treiber-Konfiguration bis zentraler Sammlung

Das Handy vibrierte: Festplattenalarm auf dem Produktionsserver, Schwellwert 85 %.

Ich öffnete den Laptop und loggte mich per SSH ein. df -h zeigte: auf der Root-Partition blieben nur noch 12 % frei. Nach einer Runde Diagnose fand ich in /var/lib/docker/containers den Übeltäter – ein Nginx-Container, der seit zwei Wochen lief, mit Log-Dateien von 12 GB.

Viele wissen nicht: Docker begrenzt Log-Größe standardmäßig nicht. Der Container schrieb täglich Zehntausende Access-Logs; der json-file-Treiber speicherte alles – in zwei Wochen war die Platte voll.

Ich löschte die Log-Datei und richtete Rotation für alle Container ein. Das zog bis vier Uhr morgens.

Danach habe ich eine Woche lang Docker-Log-Management systematisch aufgearbeitet – Treiberwahl, Rotationsparameter, zentrale Sammlung in Multi-Container-Umgebungen. Dieser Artikel fasst die Lehren aus jenem Vorfall zusammen.

1. Überblick über Docker-Log-Treiber

Grundlage: Container-Logs werden nicht beliebig geschrieben – ein Log-Treiber legt fest, wohin sie gehen und wie sie gespeichert werden.

Docker unterstützt mehrere Treiber für unterschiedliche Szenarien. Standard ist json-file: stdout und stderr landen als JSON in einer lokalen Datei unter /var/lib/docker/containers/<Container-ID>/<Container-ID>-json.log.

json-file ist einfach – keine Extra-Konfiguration, einheitliches Format, docker logs funktioniert direkt. Der Haken: keine Größenbegrenzung. Läuft der Container dauerhaft, wachsen die Logs, bis die Festplatte voll ist.

Die folgende Tabelle fasst sechs gängige Treiber zusammen:

json-file und syslog sind am verbreitetsten. json-file für lokales Debugging und leichte Deployments; syslog, wenn rsyslog oder syslog-ng bereits da ist – Logs gehen direkt in die zentrale Infrastruktur.

journald übergibt Logs an systemd journal. Auf modernen Linux-Systemen mit systemd praktisch; Abfrage mit journalctl.

fluentd und gelf zielen auf zentrale Sammlung. fluentd kann an Elasticsearch, Kafka, Cloud-Speicher u. a. senden; gelf ist das Graylog-Format. Beide brauchen zusätzliche Dienste – sinnvoll in Clustern mit vielen Containern.

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

15 % Rabatt sichern →Anzeige

none deaktiviert Logging – für temporäre oder Batch-Container, bei denen Logs irrelevant sind.

Auswahl:

• Single-Host, Entwicklung: json-file mit Rotation (nächster Abschnitt).
• Unternehmen mit syslog: syslog, Infrastruktur wiederverwenden.
• Cluster, zentrale Sicht: fluentd oder Loki (später ausführlich).
• Temporäre Container ohne Logs: none.

2. Log-Rotation in der Praxis

Zurück zum 12-GB-Problem: vermeiden mit Rotationsparametern.

json-file unterstützt drei zentrale Optionen:

• max-size: Maximale Größe einer Log-Datei. Wird sie überschritten, legt Docker eine neue an; alte Dateien werden nummeriert. Beispiel max-size=10m: maximal 10 MB pro Datei.
• max-file: Anzahl behaltener Archivdateien. Älteste werden gelöscht. Beispiel max-file=3: bis zu drei Archive plus die aktuelle Datei.
• compress: Archivierte Dateien komprimieren (Standard: false). Spart Platz, leicht mehr CPU.

Kombiniert z. B. max-size=10m, max-file=3 begrenzen Sie die Belegung auf etwa 30 MB (mit compress oft weniger).

Konfiguration: global vs. pro Container

Rotation ist auf drei Ebenen möglich:

1. Global (daemon.json)

Gilt für alle Container – einmal einrichten. In /etc/docker/daemon.json:

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

Docker-Daemon neu starten: sudo systemctl restart docker. Neue Container erben die Einstellungen.

Hinweis: Bestehende Container bleiben unverändert – neu anlegen oder einzeln anpassen.

2. Pro Container (docker run)

Für individuelle Limits:

docker run -d \
  --name nginx \
  --log-driver json-file \
  --log-opt max-size=50m \
  --log-opt max-file=5 \
  --log-opt compress=true \
  nginx:alpine

Bei hohem Traffic z. B. max-size=50m, max-file=10 für mehr Puffer.

3. Docker Compose

In Produktion meist der Standard:

version: "3.9"
services:
  webapp:
    image: webapp:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
        compress: "true"

  nginx:
    image: nginx:alpine
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"

Pro Service eigene Werte – flexibel.

Empfohlene Werte für Produktion

SigNoz empfiehlt in seinem Leitfaden von 2024 unter anderem:

• Entwicklung/Test: max-size=10m, max-file=3 – ausreichend.
• Mittlerer Traffic: max-size=50m, max-file=5 – mehr Historie für Analysen.
• Hoher Traffic: max-size=100m, max-file=10 – weniger Risiko, dass Rotation zu schnell Historie löscht.

Die exakten Werte hängen vom Szenario ab. Prinzip: Balance zwischen Festplatte und Bedeutung der Logs – viel Platz und wichtige Logs: großzügiger; knappe Platte, weniger kritische Logs: straffer.

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

Jetzt starten →Anzeige

3. Zentrale Log-Sammlung im Vergleich

Rotation reicht auf einem Host. Bei vielen Containern auf mehreren Maschinen ist docker logs pro Server mühsam.

Zentrale Sammlung bündelt alles an einem Ort – Speicherung und Abfrage einheitlich.

Drei gängige Ansätze:

ELK Stack (Elasticsearch + Logstash + Kibana)

Klassiker: Logstash sammelt, Elasticsearch indexiert, Kibana visualisiert.

Stärken: Volltextsuche, komplexe Queries, reife Ökosystem. Schwächen: hoher Ressourcenbedarf – Elasticsearch oft mehrere GB RAM; Logstash schwer und komplex.

Für große Unternehmen mit Ops-Team, hohem Log-Volumen und anspruchsvollen Abfragen.

EFK (Fluentd statt Logstash)

Fluentd ist leichter (hunderte MB RAM), viele Plugins, viele Quellen und Ziele. Elasticsearch bleibt schwer – Gesamtaufwand weiterhin hoch, eher mittelgroße bis große Teams.

Loki + Promtail + Grafana

Loki indexiert nur Labels (Containername, App), nicht den Volltext – Inhalt in komprimierten Dateien, Abfrage per grep-ähnlichem Matching.

Ergebnis: sehr geringer Footprint, günstiger Speicher als Elasticsearch. Promtail als Agent, Grafana als UI – nahtlos integriert.

Ideal für Cloud-native und Kubernetes; für kleine Teams mit begrenztem Budget oft die beste Relation.

Vergleich

Empfehlung:

• Kleines Team (unter 10 Personen), knappes Budget: Loki.
• Mittleres Team (10–50), Ops-Kapazität vorhanden: Loki oder EFK – je nach Log-Volumen.
• Großes Unternehmen, professionelles Ops: ELK.

Mit Grafana-Monitoring ist Loki oft die naheliegende Ergänzung – Metriken und Logs in einer Oberfläche.

4. Fallstricke in der Produktion

Abschließend ein paar Stolpersteine aus der Praxis.

1. Keine Rotation – volle Festplatte

Der häufigste Fehler: Container deployen, an Logs nicht denken – Monate später Alarm und Log-Dateien im zweistelligen GB-Bereich.

Empfehlung: Globale Defaults in daemon.json. Menschen vergessen --log-opt; Konfiguration nicht.

2. Logs nach Neustart weg

json-file: Beim Löschen des Containers verschwinden die Log-Dateien. docker rm + docker run statt docker restart – Historie weg.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Problematisch bei Crash-Analysen: Container nachts neu gebaut, Logs vor dem Absturz nicht mehr da.

Empfehlung:

• docker restart statt Löschen und Neu-Anlegen.
• Kritische Apps: fluentd oder syslog zu externem Speicher.
• Wichtige Logs in Produktion regelmäßig sichern.

3. Falsche Fluentd-Adresse

Mit fluentd gehen Logs per TCP an Fluentd. Falsche Adresse: Container startet, aber nichts wird gesammelt – Verlust fällt spät auf.

Beispiel:

docker run -d \
  --log-driver fluentd \
  --log-opt fluentd-address=127.0.0.1:24224 \
  --log-opt tag="docker.{{.Name}}" \
  my-web-app

fluentd-address muss zum tatsächlichen Listener passen. Standardport 24224, TCP.

Debugging:

• Fluentd läuft? curl http://localhost:24224 oder netstat -tlnp | grep 24224.
• docker inspect <Container-ID> – Log-Treiber korrekt?
• Fluentd-Logs: kommen Docker-Streams an?

4. Monitoring und Alarme

Log-Management endet nicht bei der Konfiguration.

Zwei Kennzahlen:

• Festplatte: Größe von /var/lib/docker/containers regelmäßig prüfen; Alarm z. B. ab 10 GB.
• Schreiblatenz: Bei zentraler Sammlung Fluentd/Loki beobachten – hohe Latenz deutet auf Netzwerk oder Speicher-Engpass.

Prometheus + Grafana oder ein Cron-Skript – je nach Aufwand.

Fazit

Kernpunkte des Docker-Log-Managements:

1. Treiber: json-file am universellsten; syslog für bestehende Infrastruktur; fluentd für zentrale Sammlung.
2. Rotation: max-size + max-file; global in daemon.json oder pro Container/Compose.
3. Zentrale Sammlung: Loki für kleine Teams, ELK für große – je nach Größe und Budget.
4. Fallstricke: Globale Rotation, Logs nicht durch Neuanlegen verlieren, Fluentd-Adresse prüfen, Festplatte überwachen.

Schnellvorlage:

// /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}

Handlungsempfehlung: Wenn Sie noch keine Rotation haben – jetzt prüfen. Schauen Sie in /var/lib/docker/containers nach oversized Logs, tragen Sie Rotationsparameter in daemon.json ein, starten Sie den Docker-Daemon neu. Ein paar Minuten Arbeit können Sie vor dem nächtlichen Festplattenalarm bewahren.