Skip to content
VDS · Docker і контейнери

Логи контейнерів і як їх не втратити

Де зберігаються логи Docker, як обмежити їхній розмір, щоб вони не заповнили диск, і що зробити, щоб записи пережили перестворення контейнера.

Оновлено 23 серпня 2026 р.

Коли сервіс падає, лог — єдине джерело правди. Типово Docker пише його у файл поруч із контейнером і не обмежує розмір: балакучий застосунок може заповнити весь диск за тиждень.

Як читати

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

Варто пам'ятати: Docker показує те, що застосунок пише у стандартний вивід і стандартний потік помилок. Якщо він пише у власний файл усередині контейнера, docker logs не покаже нічого — доведеться шукати лог усередині або перенаправляти вивід.

docker compose exec app ls -la /var/log

Обмежити розмір просто зараз

Глобальне налаштування для всіх контейнерів — /etc/docker/daemon.json:

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

sudo systemctl restart docker

Налаштування діє для контейнерів, створених після перезапуску. Запущені потрібно перестворити. Для одного сервісу те саме прописується в Compose:

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

Результат: не більше ніж 60 МБ на сервіс замість необмеженого зростання.

Перевірте поточний розмір, перш ніж він вас здивує: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. Обрізати запущений файл через rm не можна — місце не звільниться, поки Docker тримає дескриптор. Правильний спосіб: перестворити контейнер або sudo truncate -s 0 <file>.

Збережіть логи після контейнера

Файл логу видаляється разом із контейнером. Якщо історія важлива, передайте її системному журналу:

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

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

journald самостійно ротує записи, а обмежується він налаштуванням SystemMaxUse у /etc/systemd/journald.conf. Щоб перевірити, скільки місця він займає: journalctl --disk-usage.

Для кількох сервісів одразу зручніше збирати все в одному місці — наприклад, окремим контейнером-колектором, який зберігає записи у файли за днями. Але почніть із journald: він уже є і нічого не коштує.

На що дивитися під час розбору збою

  1. Останні 200 рядків перед падінням: docker logs --tail 200 <container>.
  2. Код виходу: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. Код 137 і true у OOMKilled означають, що ядро вбило процес через нестачу пам'яті — дивіть обмеження ресурсів.
  3. Системний журнал машини: sudo dmesg -T | tail -50 покаже вбивства через нестачу пам'яті та помилки диска.

Типові помилки

  • Диск заповнився логами, і всі сервіси впали. Обмеження розміру — обов'язкове одразу після встановлення Docker.
  • Перегляд логу вже видаленого контейнера. Після docker compose down він зникає. Збирайте записи в journald заздалегідь.
  • Секрети в логу. Застосунки люблять друкувати рядки підключення з паролями. Будь-хто з доступом до машини може прочитати лог.
  • Пошук помилки в текстовій консолі. Вона завжди 80×24, і довгі рядки обрізаються. Для читання логів зручніше SSH або консоль «Screen».