Logy kontajnerov a ako o ne neprísť

Keď služba spadne, log je jediným zdrojom pravdy. Docker ho štandardne zapisuje do súboru vedľa kontajnera a nekladie na jeho veľkosť žiadny strop: ukecaná aplikácia dokáže zaplniť celý disk za týždeň.

Ako čítať

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

Stojí za zapamätanie: Docker zobrazuje to, čo aplikácia zapisuje na štandardný výstup a štandardný chybový výstup. Ak zapisuje do vlastného súboru vnútri kontajnera, docker logs neukáže nič — musíš hľadať log vnútri alebo presmerovať výstup.

docker compose exec app ls -la /var/log

Obmedz veľkosť hneď teraz

Globálne nastavenie pre všetky kontajnery je /etc/docker/daemon.json:

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

sudo systemctl restart docker

Nastavenie platí pre kontajnery vytvorené po reštarte. Bežiace treba znovu vytvoriť. Pre jednu službu to isté patrí do Compose:

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

Výsledok: namiesto neobmedzeného rastu maximálne 60 MB na službu.

Skontroluj aktuálnu veľkosť, kým ťa neprekvapí: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. Bežiaci súbor nemôžeš orezať pomocou rm — kým Docker drží deskriptor, miesto sa neuvoľní. Správny postup: znovu vytvor kontajner alebo sudo truncate -s 0 <file>.

Nechaj logy prežiť kontajner

Súbor logu sa zmaže spolu s kontajnerom. Ak na histórii záleží, odovzdaj ju systémovému journalu:

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

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

journald rotuje záznamy sám a je ohraničený nastavením SystemMaxUse v /etc/systemd/journald.conf. Koľko miesta zaberá, zistíš pomocou journalctl --disk-usage.

Pri viacerých službách naraz je pohodlnejšie zbierať všetko na jednom mieste — napríklad pomocou vyhradeného kontajnera zberača, ktorý ukladá záznamy do súborov po dňoch. Ale začni s journald: už tam je a nič nestojí.

Čo hľadať pri ladení výpadku

1. Posledných 200 riadkov pred pádom: docker logs --tail 200 <container>.
2. Návratový kód: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. Kód 137 a true v OOMKilled znamenajú, že jadro proces zabilo, pretože mu došla pamäť — pozri limity zdrojov.
3. Systémový log stroja: sudo dmesg -T | tail -50 ukáže zabitia z dôvodu nedostatku pamäte a chyby disku.

Časté chyby

• Disk sa zaplnil logmi a všetky služby spadli. Obmedzenie veľkosti je nutnosť hneď po inštalácii Dockeru.
• Pozeranie do logu už zmazaného kontajnera. Po docker compose down je preč. Zbieraj záznamy do journald vopred.
• Tajomstvá v logu. Aplikácie rady vypisujú pripojovacie reťazce s heslami. Ktokoľvek s prístupom k stroju si log prečíta.
• Hľadanie chyby v textovej konzole. Má vždy 80×24 a dlhé riadky sa odrežú. Na čítanie logov je pohodlnejší SSH alebo konzola „Screen“.