Container-Logs und wie Sie sie nicht verlieren

Wenn ein Dienst ausfällt, ist das Log die einzige verlässliche Quelle. Standardmäßig schreibt Docker es in eine Datei neben dem Container und setzt keine Obergrenze für deren Größe: Eine geschwätzige Anwendung kann die gesamte Festplatte in einer Woche füllen.

So lesen Sie das Log

docker logs -f --tail 100 <container>
docker compose logs -f app
docker compose logs --since 30m --timestamps app
docker logs <container> 2>&1 | grep -i error | tail -50

Wichtig zu wissen: Docker zeigt an, was die Anwendung auf die Standardausgabe und den Standardfehlerkanal schreibt. Schreibt sie in eine eigene Datei im Container, zeigt docker logs nichts an — Sie müssen das Log im Container suchen oder die Ausgabe umleiten.

docker compose exec app ls -la /var/log

Begrenzen Sie die Größe sofort

Die globale Einstellung für alle Container ist /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "20m", "max-file": "3" }
}

sudo systemctl restart docker

Die Einstellung gilt für Container, die nach einem Neustart erstellt werden. Laufende müssen neu erstellt werden. Für einen einzelnen Dienst kommt dasselbe in Compose:

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "3"

Das Ergebnis: nicht mehr als 60 MB pro Dienst statt unbegrenzten Wachstums.

Prüfen Sie die aktuelle Größe, bevor sie Sie überrascht: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. Eine laufende Datei können Sie nicht mit rm kürzen — der Speicherplatz wird nicht freigegeben, solange Docker den Deskriptor hält. Der richtige Weg: den Container neu erstellen oder sudo truncate -s 0 <file>.

Sorgen Sie dafür, dass Logs den Container überleben

Die Logdatei wird zusammen mit dem Container gelöscht. Wenn der Verlauf wichtig ist, übergeben Sie ihn an das System-Journal:

logging:
  driver: journald
  options:
    tag: "myapp"

journalctl -t myapp -n 200 --since today
journalctl -t myapp -p err --since "2 days ago"

journald rotiert Einträge selbstständig und wird durch die Einstellung SystemMaxUse in /etc/systemd/journald.conf begrenzt. Um zu prüfen, wie viel Speicherplatz es belegt: journalctl --disk-usage.

Für mehrere Dienste auf einmal ist es bequemer, alles an einem Ort zu sammeln — zum Beispiel mit einem dedizierten Collector-Container, der Einträge tageweise in Dateien speichert. Beginnen Sie aber mit journald: Es ist bereits vorhanden und kostet nichts.

Worauf Sie beim Debuggen eines Ausfalls achten sollten

1. Die letzten 200 Zeilen vor dem Absturz: docker logs --tail 200 <container>.
2. Exit-Code: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. Code 137 und true bei OOMKilled bedeuten, dass der Kernel den Prozess beendet hat, weil ihm der Speicher ausging — siehe Ressourcenlimits.
3. Das Systemlog der Maschine: sudo dmesg -T | tail -50 zeigt Out-of-Memory-Kills und Festplattenfehler.

Häufige Fehler

• Die Festplatte lief mit Logs voll und jeder Dienst fiel aus. Die Größe zu begrenzen ist ein Muss direkt nach dem Installieren von Docker.
• Das Log eines bereits gelöschten Containers ansehen. Nach docker compose down ist es weg. Sammeln Sie Einträge vorab in journald.
• Geheimnisse im Log. Anwendungen drucken gerne Verbindungszeichenfolgen mit Passwörtern. Jeder mit Zugriff auf die Maschine kann das Log lesen.
• Den Fehler in der Textkonsole suchen. Sie ist immer 80×24 und lange Zeilen werden abgeschnitten. Zum Lesen von Logs sind SSH oder die Konsole „Screen“ bequemer.