VDS · Docker и контейнеры

Журналы контейнеров и как их не потерять

Где лежат журналы Docker, как ограничить их размер, чтобы не забить диск, и что делать, чтобы записи переживали пересоздание контейнера.

Обновлено 23 августа 2026 г.

Когда сервис падает, единственный источник правды — журнал. По умолчанию Docker пишет его в файл рядом с контейнером и не ограничивает размер: болтливое приложение способно за неделю заполнить диск целиком.

Как читать

docker logs -f --tail 100 <контейнер>
docker compose logs -f app
docker compose logs --since 30m --timestamps app
docker logs <контейнер> 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 <файл>.

Чтобы журнал пережил контейнер

Файл журнала удаляется вместе с контейнером. Если история важна, отдавайте её системному журналу:

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 <контейнер>.
  2. Код выхода: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <контейнер>. Код 137 и true в OOMKilled означают, что процесс убило ядро из-за нехватки памяти — см. ограничения ресурсов.
  3. Системный журнал машины: sudo dmesg -T | tail -50 покажет убийства по памяти и ошибки диска.

Частые ошибки

  • Диск кончился из-за журналов, и все сервисы встали. Ограничение размера — обязательная настройка сразу после установки Docker.
  • Смотрят журнал уже удалённого контейнера. После docker compose down его нет. Собирайте записи в journald заранее.
  • Секреты в журнале. Приложения любят печатать строки подключения с паролями. Журнал читают все, кто имеет доступ к машине.
  • Ищут ошибку в текстовой консоли. Она всегда 80×24, длинные строки рвутся. Для чтения журналов удобнее SSH или консоль «Экран».