Docker Logs richtig nutzen - Befehle, Filter und Log-Rotation

Wenn ein Container plötzlich Fehler wirft, entscheidet der Blick in die richtigen Protokolle oft schneller über Ursache oder Entwarnung als ein Neustart. Der Begriff docker log wird in der Praxis meist mit dem eigentlichen Docker-Befehl docker logs verbunden. Ich zeige, wie du Ausgaben live beobachtest, Zeiträume und Zeilen begrenzt, Log-Treiber sinnvoll auswählst und Speicherprobleme durch Rotation vermeidest.

Container-Logs schnell anzeigen und live verfolgen

Der Einstieg ist unkompliziert. Zuerst ermittelst du den Namen oder die ID des Containers und liest anschließend dessen Ausgabe aus.

docker ps
docker logs webserver

Auch bereits beendete Container lassen sich auslesen, solange sie nicht mit --rm entfernt wurden. Genau das ist bei einem Absturz hilfreich, weil die letzten Fehlermeldungen häufig erst nach dem Ende des Prozesses sichtbar werden.

Für den laufenden Betrieb nutze ich fast immer einen begrenzten Ausschnitt und aktiviere danach den Live-Modus:

docker logs --tail 100 webserver
docker logs --follow --tail 50 webserver

--follow beziehungsweise -f hält die Verbindung offen und zeigt neue Zeilen sofort an. Mit --tail verhinderst du, dass ein Container mit monatelanger Historie dein Terminal mit tausenden alten Meldungen flutet.

Zeitstempel und Zeitfenster nutzen

Bei Fehleranalysen ist nicht jede Logzeile gleich wichtig. Mit --since und --until kannst du die Ausgabe auf eine Dauer oder einen konkreten Zeitpunkt begrenzen.

docker logs --since 30m --timestamps webserver
docker logs --since 2026-08-18T08:00:00Z --until 2026-08-18T09:00:00Z webserver

--timestamps ergänzt RFC3339-Zeitstempel. Das ist besonders nützlich, wenn du Docker-Ausgaben mit Reverse-Proxy-, Datenbank- oder Systemprotokollen abgleichen musst. Relative Angaben wie 10m, 2h oder 1h30m sind im Alltag meist schneller als ein manuell eingetragenes Datum.

Warum die Ausgabe manchmal leer bleibt

Ein leeres Ergebnis bedeutet nicht automatisch, dass der Container gesund ist. Docker liest normalerweise nur das, was der Prozess nach stdout oder stderr schreibt. Anwendungen, die ausschließlich nach /var/log/app.log schreiben, erscheinen deshalb in docker logs oft stumm.

Für Container bevorzuge ich daher Prozesse, die direkt auf die Standardausgabe schreiben. Wenn eine Software zwingend Dateien verwendet, brauchst du entweder eine passende Weiterleitung, einen Log-Agenten oder eine bewusst eingebundene Protokollstruktur. Das direkte Bearbeiten der internen Docker-Logdateien auf dem Host ist keine gute Abkürzung, weil der Docker-Daemon diese Dateien exklusiv verwaltet.

Mit Filtern schneller zur eigentlichen Ursache kommen

Große Logmengen helfen wenig, wenn die relevante Meldung zwischen Debug-Ausgaben verschwindet. Docker selbst bietet keine vollständige Suche mit regulären Ausdrücken, deshalb kombiniere ich die Ausgabe bei Bedarf mit klassischen Shell-Werkzeugen.

docker logs --since 15m api 2>&1 | grep -i "error"
docker logs --tail 500 worker 2>&1 | grep -E "timeout|failed|exception"

Die Weiterleitung 2>&1 führt Standardfehler und Standardausgabe zusammen. Ohne sie kann eine Fehlermeldung je nach Shell oder Programm außerhalb des erwarteten Suchstroms liegen.

Details und Containerstatus gemeinsam prüfen

Logs erklären, was ein Prozess ausgibt. Sie erklären nicht immer, warum Docker ihn beendet oder neu startet. Deshalb prüfe ich bei auffälligen Meldungen zusätzlich Status, Exit-Code und Neustartzähler.

docker ps -a
docker inspect CONTAINER
docker inspect -f '{{.State.Status}} {{.State.ExitCode}} {{.RestartCount}}' CONTAINER

Ein Exit-Code ungleich null weist meist auf einen Anwendungsfehler hin, während ein Container mit Status OOMKilled eher wegen Speichermangels beendet wurde. Bei einem wiederkehrenden Neustart lohnt sich außerdem der Blick auf Abhängigkeiten wie Datenbankverbindungen, Healthchecks und Umgebungsvariablen.

Ausgaben in Compose und Swarm

Bei Docker Compose musst du nicht jeden Container einzeln identifizieren. Der Dienstname reicht aus und macht die Diagnose bei mehreren Komponenten deutlich angenehmer.

docker compose logs --follow --tail=100 web
docker compose logs --since=10m api database

Ohne Dienstnamen zeigt Compose die Logs des gesamten Projekts. In einer kleinen Entwicklungsumgebung ist das praktisch, in einer produktiven Umgebung wird die Ausgabe schnell unübersichtlich. Ich beginne dort mit einem einzelnen Dienst und erweitere die Auswahl nur, wenn die Abhängigkeit tatsächlich relevant ist.

docker service logs --follow --tail 100 frontend

Das ist ein wichtiger Unterschied. docker logs arbeitet mit einzelnen Containern, während docker service logs die Ausgaben der zugehörigen Tasks eines Services zusammenführen kann.

Log-Treiber entscheiden über Speicher, Format und Weiterleitung

Docker speichert Container-Ausgaben nicht einfach beliebig, sondern über einen Logging Driver. Der Treiber bestimmt, ob Meldungen lokal als Dateien liegen, an journald gehen oder direkt an Systeme wie CloudWatch, Graylog, Fluentd oder Splunk weitergeleitet werden.

Der klassische Standard ist json-file. Er schreibt jede Zeile mit Zeitstempel und Stream-Information in JSON. Für einen kleinen Testserver funktioniert das, für dauerhaft laufende Anwendungen würde ich es nur mit aktivierter Rotation einsetzen.

Die Docker-Dokumentation empfiehlt für viele andere Szenarien den Treiber local, weil er standardmäßig rotiert und weniger Verwaltungsaufwand verursacht. Für zentrale Logplattformen ist ein Remote-Treiber sinnvoll, aber nur dann, wenn Netzwerk, Zugriffsschutz und Ausfallverhalten sauber geplant sind.

Den aktuell verwendeten Treiber feststellen

docker inspect -f '{{.HostConfig.LogConfig.Type}}' CONTAINER

Die Ausgabe zeigt, wie der konkrete Container konfiguriert ist. Das ist wichtiger als ein Blick in die globale Docker-Konfiguration, denn bestehende Container übernehmen neue Standardeinstellungen nicht automatisch. Nach einer Änderung müssen sie in der Regel neu erstellt werden.

Log-Rotation verhindert volle Datenträger

Ein Container kann scheinbar stabil laufen und trotzdem den Host gefährden. Eine Anwendung mit 2 MB Logausgabe pro Stunde erzeugt bereits rund 1,4 GB in 30 Tagen, wenn niemand die Dateien begrenzt. Bei mehreren Containern oder ausführlichem Debugging wird daraus schnell ein Betriebsproblem.

Für json-file lässt sich eine einfache Rotation in der Docker-Daemon-Konfiguration festlegen:

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

Damit darf eine einzelne Datei ungefähr 10 MB groß werden und es bleiben bis zu drei Dateien erhalten. Die tatsächliche Belegung liegt wegen Format- und Verwaltungsdaten etwas darüber. Wichtig ist außerdem, dass Werte in daemon.json als Strings geschrieben werden, also auch "3" statt der Zahl 3.

Nach dem Neustart des Docker-Daemons gilt die Konfiguration in erster Linie für neu erstellte Container. Ein bereits vorhandener Container wird nicht durch einen bloßen Daemon-Neustart nachträglich umgestellt. In produktiven Umgebungen sollte die Änderung deshalb mit dem vorgesehenen Deployment-Prozess ausgerollt und anschließend kontrolliert werden.

Rotation ist kein Archivkonzept

Eine lokale Rotation schützt den Speicher, ersetzt aber keine langfristige Aufbewahrung. Wenn Logs für Audits, Sicherheitsanalysen oder Fehlersuchen über mehrere Monate gebraucht werden, sollten sie an eine zentrale Plattform weitergeleitet und dort mit einer klaren Aufbewahrungsfrist versehen werden.

Ich trenne dabei drei Ziele voneinander: kurzfristige Diagnose auf dem Host, zentrale Suche über mehrere Dienste und revisionssichere Aufbewahrung. Eine einzige Logdatei soll diese drei Aufgaben selten gleichzeitig zuverlässig erfüllen.

Typische Fehler bei der Diagnose vermeiden

Der häufigste Denkfehler ist, Docker-Logs mit allen Protokollen eines Systems gleichzusetzen. Die Ausgabe des Containers, die Logs des Docker-Daemons und die Meldungen des Betriebssystems liegen auf unterschiedlichen Ebenen.

Containerlog und Daemonlog nicht verwechseln

Wenn der Docker-Dienst selbst Probleme macht, hilft die Ausgabe des Containers nicht weiter. Unter Linux prüfst du den Daemon beispielsweise mit:

journalctl -xu docker.service

Bei Docker Desktop werden Daemon- und VM-Komponenten anders verwaltet. Dort solltest du die Diagnosefunktionen der Desktop-Oberfläche verwenden. Ein Container kann fehlerfrei sein, während Docker Desktop oder der Host Probleme melden, und umgekehrt.

Remote-Treiber und fehlende Ausgabe

Wenn ein Treiber Logs an ein externes System sendet, kann die lokale Anzeige eingeschränkt sein. Ob docker logs weiterhin verwertbare Daten liefert, hängt vom Treiber und von der aktivierten Dual-Logging-Funktion ab.

Für kritische Dienste teste ich deshalb nach jeder Umstellung drei Dinge. Die Anwendung muss lokal oder zentral sichtbar sein, ein kurzzeitiger Ausfall des Logziels darf den Dienst nicht unerwartet blockieren, und die Zugriffsrechte auf die Meldungen müssen zum Schutz sensibler Daten passen.

Lesen Sie auch: Was ist TCP? Handshake, Ports und typische Fehler erklärt

Geheimnisse gehören nicht in die Ausgabe

Ich maskiere sensible Felder bereits in der Anwendung und beschränke den Zugriff auf zentrale Logs nach Rollen. Zusätzlich sollten Aufbewahrungsfristen, Verschlüsselung und der Umgang mit Exporten festgelegt sein. Logdaten sind Betriebsdaten, aber oft auch sicherheitsrelevante Daten.

Ein kleines Log-Setup, das später Ärger spart

Für einen einzelnen Linux-Host mit wenigen Diensten genügt meist ein klarer Standard: Anwendungen schreiben strukturierte Meldungen nach stdout und stderr, der lokale Treiber rotiert die Dateien, und die wichtigsten Container werden mit begrenztem Speicher und Healthcheck betrieben.

Mein pragmatischer Ablauf lautet deshalb: zuerst den betroffenen Dienst mit --since und --tail eingrenzen, danach Status und Ressourcen prüfen, anschließend den Log-Treiber und die Rotation kontrollieren. So bleibt die Fehlersuche überschaubar und aus einer kleinen Warnung wird nicht durch unkontrolliertes Logwachstum der nächste Ausfall.