docker logs

docker logs pokazuje to, co kontener wypisał na standardowe wyjście (stdout) i wyjście błędów (stderr). To pierwsze miejsce, do którego zaglądasz, gdy aplikacja w kontenerze nie wstaje, restartuje się w kółko albo zachowuje się dziwnie. Nie musisz wchodzić do środka przez docker exec ani grzebać w plikach — komenda wyciąga zebrane logi prosto z demona Dockera i wrzuca je do twojego terminala. Działa tak samo na Linuksie, macOS i Windowsie, bo to po prostu klient gadający z silnikiem Dockera.

Składnia i najważniejsze opcje

Podstawowa forma to: docker logs [OPCJE] KONTENER, gdzie KONTENER to nazwa albo ID (wystarczy kilka pierwszych znaków).

• -f, --follow — strumieniuje logi na żywo, dopisując nowe linie w miarę ich pojawiania się (jak tail -f). Przerywasz przez Ctrl+C.
• --tail N — pokazuje tylko ostatnie N linii zamiast całej historii. Domyślnie jest all, czyli wszystko.
• -t, --timestamps — dokleja do każdej linii znacznik czasu w formacie RFC3339Nano.
• --since — tylko logi od podanego momentu: data RFC3339, uniksowy timestamp albo czas względny typu 10m, 2h.
• --until — logi do podanego momentu (ten sam format co --since); razem dają okno czasowe.
• --details — dorzuca dodatkowe atrybuty dołączone przez --log-opt przy tworzeniu kontenera.
• -n — krótki alias dla --tail.

Przykłady użycia

• docker logs nginx — wypluwa całą dotychczasową historię logów kontenera o nazwie nginx.
• docker logs -f --tail 100 api — pokazuje ostatnie 100 linii i zostaje, śledząc nowe wpisy na żywo. Najczęstszy wariant przy debugowaniu.
• docker logs -t --since 15m worker — logi z ostatnich 15 minut, każda linia ze znacznikiem czasu.
• docker logs --since 2026-06-29T08:00:00 --until 2026-06-29T09:00:00 db — wycina dokładne okno godzinne, idealne gdy wiesz mniej więcej kiedy coś się wywaliło.
• docker logs app 2>/dev/null — pokazuje tylko stdout, odsiewając stderr (logi lecą na oba strumienie, więc czasem chcesz je rozdzielić).

Częste błędy i pułapki

Najważniejsza pułapka: docker logs działa tylko ze sterownikami logowania json-file (domyślny), local oraz journald. Jeśli kontener pisze przez syslog, gelf czy fluentd, dostaniesz błąd, że sterownik nie wspiera odczytu — logów szukaj wtedy w docelowym systemie.

Druga sprawa: jeśli aplikacja loguje do pliku wewnątrz kontenera zamiast na stdout/stderr, ta komenda nic nie pokaże — Docker widzi tylko strumienie procesu o PID 1. Pusty wynik to nie zawsze brak logów, czasem zła konfiguracja aplikacji.

Uważaj też na rozmiar: bez --tail na długo żyjącym kontenerze możesz dostać setki tysięcy linii i zapchać terminal. A domyślny sterownik json-file bez ustawionej rotacji (max-size, max-file) potrafi po cichu zjeść dysk.

Powiązane komendy: docker ps (znajdź nazwę/ID kontenera), docker exec (wejście do środka), docker inspect (konfiguracja i sterownik logów), docker compose logs (logi wielu usług naraz), docker events (zdarzenia demona).