Logi kontenerów i jak ich nie zgubić

Gdy usługa pada, log jest jedynym źródłem prawdy. Domyślnie Docker zapisuje go do pliku obok kontenera i nie nakłada żadnego limitu rozmiaru: gadatliwa aplikacja potrafi zapełnić cały dysk w tydzień.

Jak czytać

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

Warto zapamiętać: Docker pokazuje to, co aplikacja wypisuje na standardowe wyjście i standardowy błąd. Jeśli pisze do własnego pliku wewnątrz kontenera, docker logs nic nie pokaże — musisz szukać logu w środku albo przekierować wyjście.

docker compose exec app ls -la /var/log

Ogranicz rozmiar od razu

Globalne ustawienie dla wszystkich kontenerów to /etc/docker/daemon.json:

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

sudo systemctl restart docker

Ustawienie działa dla kontenerów utworzonych po restarcie. Działające trzeba odtworzyć. Dla pojedynczej usługi to samo wpisujesz do Compose:

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

Efekt: maksymalnie 60 MB na usługę zamiast nieograniczonego wzrostu.

Sprawdź aktualny rozmiar, zanim cię zaskoczy: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. Działającego pliku nie obetniesz przez rm — miejsce nie zostanie zwolnione, dopóki Docker trzyma deskryptor. Właściwy sposób: odtwórz kontener albo sudo truncate -s 0 <file>.

Spraw, by logi przetrwały kontener

Plik logu jest usuwany razem z kontenerem. Jeśli historia ma znaczenie, oddaj ją do dziennika systemowego:

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

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

journald sam rotuje wpisy, a jego rozmiar ogranicza ustawienie SystemMaxUse w /etc/systemd/journald.conf. Aby sprawdzić, ile zajmuje: journalctl --disk-usage.

Przy kilku usługach naraz wygodniej zbierać wszystko w jednym miejscu — na przykład w dedykowanym kontenerze kolektora, który zapisuje wpisy do plików według dni. Ale zacznij od journald: już jest i nic nie kosztuje.

Na co patrzeć przy debugowaniu awarii

1. Ostatnie 200 linii przed crashem: docker logs --tail 200 <container>.
2. Kod wyjścia: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. Kod 137 i true w OOMKilled oznaczają, że jądro zabiło proces z powodu braku pamięci — zobacz limity zasobów.
3. Dziennik systemowy maszyny: sudo dmesg -T | tail -50 pokaże zabójstwa z powodu braku pamięci i błędy dysku.

Częste błędy

• Dysk zapełnił się logami i wszystkie usługi padły. Ograniczenie rozmiaru to obowiązek zaraz po instalacji Dockera.
• Patrzenie na log już usuniętego kontenera. Po docker compose down go nie ma. Zbieraj wpisy do journald zawczasu.
• Sekrety w logu. Aplikacje uwielbiają wypisywać ciągi połączeń z hasłami. Każdy z dostępem do maszyny może przeczytać log.
• Szukanie błędu w konsoli tekstowej. Zawsze ma 80×24, a długie linie się ucinają. Do czytania logów wygodniejszy jest SSH albo konsola „Screen”.