Настройка ротации логов Docker с помощью драйвера логирования Docker: логирование Docker journald и локальный файловый драйвер Docker
Уровень: Эксперт
Ориентировочное время: ~20 минут
Цель: Настроить ротацию логов Docker для обеспечения бесперебойного управления логами и предотвращения исчерпания дискового пространства.
Введение
Неуправляемые логи Docker могут быстро исчерпать дисковое пространство сервера. По умолчанию демон Docker записывает логи в формате json-file без ограничений по размеру. Для поддержания надежной инфраструктуры необходимо настроить ротацию логов Docker, используя масштабируемый драйвер логирования Docker. В этом руководстве подробно описано, как глобально реализовать ротацию логов Docker с помощью логирования Docker journald или локального файлового драйвера Docker. Выбор правильной конфигурации обеспечивает эффективное управление логами и стабильность системы.
Терминология
Прежде чем продолжить, ознакомьтесь с этими основными понятиями:
- Docker: Платформа для запуска приложений в изолированных средах, называемых Контейнерами.
- Docker logs: Потоки вывода, захваченные из Stdout (стандартный вывод) и Stderr (стандартная ошибка) контейнера.
- Log rotation: Практика архивирования и удаления старых логов для освобождения пространства.
- Logging driver: Механизм, который Docker использует для захвата, форматирования и маршрутизации логов.
- Journald: Служба логирования systemd, идеальная для централизованного логирования на хосте.
- Local file driver: Высокопроизводительный встроенный драйвер, оптимизированный для локального хранения.
- Json-file: Драйвер по умолчанию, который записывает логи как массивы JSON.
- Docker daemon: Фоновая служба, управляющая операциями Docker.
- Daemon.json: Конфигурационный файл демона.
- Log driver configuration: Глобальная или индивидуальная для каждого контейнера настройка логирования.
- Log options: Специфические параметры, передаваемые драйверу.
- Max-size: Пороговый размер, после которого происходит ротация файла лога.
- Max-file: Максимальное количество сохраняемых файлов после ротации.
Предварительные требования
Прежде чем начать, убедитесь, что у вас есть:
- Операционная система: Ubuntu 22.04 / 24.04 LTS, Debian 12 / 13, RHEL 9 / 10, AlmaLinux 9 / 10, Rocky Linux 9 / 10
- Docker: установленная версия 24.x или новее
- Доступ: привилегии sudo
- Необходимые знания: администрирование Linux и концепции "Инфраструктура как код" (Infrastructure as Code)
Шаг 1: Понимание драйверов Docker json-file и local
При сравнении драйверов Docker json-file и local выбор зависит от производительности и накладных расходов. Драйвер json-file по умолчанию прост, но потребляет больше ресурсов процессора и дискового пространства из-за форматирования JSON. В отличие от него, локальный файловый драйвер local имеет бинарный формат только для добавления (append-only), оптимизированный специально для эффективности ротации. При нормальных рабочих нагрузках в продакшене использование локального файлового драйвера Docker снижает накладные расходы на диск и надежно обеспечивает ротацию нативно.
Чтобы проверить текущий драйвер, выполните:
docker info --format '{{.LoggingDriver}}'
Ожидаемый вывод:
json-file
Если вы видите json-file, перейдите к изменению конфигурации daemon.json Docker logging.
Шаг 2: Настройка ротации логов Docker с помощью локального файлового драйвера Docker
Чтобы применить глобальные ограничения ко всем контейнерам, вам нужно отредактировать файл /etc/docker/daemon.json. Это рекомендуемый подход для daemon.json Docker logging.
Откройте конфигурационный файл:
Если /etc/docker/daemon.json не существует в вашей системе, nano создаст его при сохранении. Это нормально - Docker использует встроенные значения по умолчанию, когда файл отсутствует.
sudo nano /etc/docker/daemon.json
Добавьте следующую конфигурацию драйвера логирования (log driver configuration):
{ "log-driver": "local", "log-opts": { "max-size": "50m", "max-file": "3" } }
Сохраните и закройте файл. Новые настройки записываются на диск. Эта конфигурация применяет драйвер глобально. Параметры логирования (log options) указывают Docker выполнять ротацию логов, когда они достигают 50 мегабайт (max-size Docker logs), и сохранять максимум 3 файла (max-file Docker logs). Обратите внимание, что драйвер local нативно поддерживает эти явные ограничения размера и файлов, в отличие от journald.
Перезапустите демон Docker, чтобы применить изменения. Служба docker.service управляет контейнерами, поэтому ее перезапуск применяет ограничения:
sudo systemctl restart docker
Вы потеряете соединение с демоном на несколько секунд. После перезапуска все вновь созданные контейнеры будут использовать локальный файловый драйвер Docker и унаследуют эти ограничения max-size Docker logs и max-file Docker logs.
Драйвер логирования неизменяем для каждого контейнера. Существующие контейнеры сохранят прежний драйвер логирования; команда docker update не может его изменить. Чтобы применить новый драйвер логирования Docker, необходимо пересоздать контейнер (например, с помощью docker compose up -d или повторного развёртывания через систему оркестрации), поскольку живой миграции не существует. В противном случае на вашем хосте окажутся смешанные состояния логирования.
Кроме того, поймите порядок приоритета конфигураций логирования:
- Флаги CLI (
docker run --log-driver) переопределяют всё остальное. - Переопределения логирования в
docker-compose.ymlдействуют для каждого сервиса во время создания контейнера. daemon.jsonдействует как глобальный резервный вариант по умолчанию для всех контейнеров без явных настроек.
Шаг 3: Включение логирования Docker journald в качестве вашего драйвера логирования Docker
В качестве альтернативы вы можете маршрутизировать логи непосредственно к демону системы journald. Логирование Docker journald легко интегрируется с systemctl и внешними системами пересылки логов.
Откройте конфигурационный файл:
sudo nano /etc/docker/daemon.json
Замените содержимое конфигурацией journald. Полностью замените содержимое файла - удалите любые предыдущие записи log-opts, поскольку journald не поддерживает параметры max-size или max-file:
{ "log-driver": "journald" }
Сохраните и закройте файл. Конфигурация обновлена.
Перезапустите службу. docker.service необходимо перезагрузить, чтобы перенести управление логами в journald:
sudo systemctl restart docker
При использовании Docker logs journald драйвер journald снимает контроль за ротацией на стороне Docker. Ротация логов все еще существует, но она полностью обрабатывается вне Docker системным журналом systemd. Вы увидите, что логи маршрутизируются непосредственно в журнал systemd. Эти логи индексируются по полям метаданных контейнера, а не привязаны к юниту docker.service.
В операционном плане journald управляет этими логами, используя конкретные ограничения, настроенные в файле /etc/systemd/journald.conf, в частности SystemMaxUse, RuntimeMaxUse и MaxRetentionSec. Это несет значительный риск масштабного влияния на систему: исчерпание ресурсов journald может повлиять на логирование ssh, логи ядра, логи аудита и все другие службы, совместно использующие журнал в продакшене. Обратите внимание, что параметры max-size и max-file применяются только к драйверам json-file и local, а не к journald.
Чтобы применить изменения к конфигурации journald:
sudo systemctl restart systemd-journald # Или чтобы вызвать немедленную ротацию без полного перезапуска: sudo systemctl kill -s SIGUSR2 systemd-journald
Используйте Docker logs journald при развёртывании в средах, где логи напрямую собираются из системного журнала.
Шаг 4: Управление выводом journalctl
Когда вы настраиваете ротацию логов Docker через journald, вы взаимодействуете с логами с помощью journalctl вместо docker logs. Служба journald обрабатывает эти логи централизованно.
Чтобы просмотреть логи определенного контейнера с помощью Docker logs journald, выполните:
journalctl CONTAINER_NAME=<YOUR_CONTAINER_NAME> -o cat
Если вы предпочитаете фильтровать по ID, а не по имени, используйте CONTAINER_ID_FULL=$(docker inspect -f '{{.Id}}' <YOUR_CONTAINER_NAME>), чтобы получить полный ID, или передайте ID через cut -c1-12, чтобы получить короткую форму, хранящуюся в CONTAINER_ID. Поле _CONTAINER_ID относится к systemd-cgroup и не соответствует ID Docker-контейнера.
Ожидаемый вывод:
Application started successfully
Шаг 5: Проверка
Чтобы проверить конфигурацию драйвера логирования Docker на запущенном контейнере, запустите тестовый контейнер:
docker run -d --name log-test nginx:latest
Проверьте параметры логирования контейнера:
docker inspect -f '{{.HostConfig.LogConfig.Type}}' log-test
Ожидаемый вывод для драйвера local:
local
Если вы настроили journald, вместо этого вывод будет journald.
Проверьте примененные параметры для драйвера local:
docker inspect -f '{{.HostConfig.LogConfig.Config}}' log-test
Ожидаемый вывод:
map[max-file:3 max-size:50m]
Это подтверждает, что ваша настройка daemon.json Docker logging успешно применила параметры max-size Docker logs и max-file Docker logs. Обратите внимание, что journald здесь не отображает параметры max-size или max-file, так как ротация передана на уровень ОС.
Используйте эту команду, чтобы определить любые ранее существовавшие контейнеры, которые все еще используют предыдущий драйвер. Драйвер логирования фиксируется во время создания контейнера - эти контейнеры необходимо пересоздать (например, docker compose up -d --force-recreate), чтобы унаследовать новую конфигурацию:
docker ps -aq | xargs -r docker inspect -f '{{.Name}}: {{.HostConfig.LogConfig.Type}}'
Отмена изменений
Чтобы вернуть глобальную конфигурацию драйвера логирования к формату по умолчанию, удалите конфигурацию из daemon.json.
Удалите файл (всегда создавайте резервные копии конфигурационных файлов перед изменением) и перезапустите службу Docker:
sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak.$(date +%F) sudo rm /etc/docker/daemon.json sudo systemctl restart docker
Отмена этих изменений немедленно снимет ограничения для всех вновь создаваемых контейнеров, что может привести к исчерпанию дискового пространства, если они будут генерировать большой объём логов.
Если файл /etc/docker/daemon.json содержит другие настройки демона (зеркала реестров, драйвер хранилища, DNS, MTU, insecure-registries и т. д.), удаление этого файла также приведёт к удалению этих настроек. Поэтому либо сначала создайте резервную копию файла (как показано выше), либо отредактируйте его вручную, удалив только разделы log-driver и log-opts.
Устранение неполадок
journalctlне возвращает вывод дляCONTAINER_ID: Драйвер Dockerjournaldзаписывает короткий 12-символьный ID вCONTAINER_ID, тогда какdocker inspectвозвращает полный 64-символьный ID. Используйте вместо этогоCONTAINER_NAMEилиCONTAINER_ID_FULL.- Существующие контейнеры все еще используют
json-fileпосле перезапуска: Командаdocker updateне изменяет драйвер логирования. Вы должны пересоздать контейнер (например, черезdocker compose downиup), чтобы применить новый драйвер логирования. max-sizeиmax-fileне имеют эффекта сjournald: Ротация логов дляjournaldуправляется глобально через/etc/systemd/journald.conf(например,SystemMaxUse), а не черезlog-optsDocker.
Заключение
Надлежащее управление выводом контейнеров является фундаментальной частью надежной инфраструктуры. Правильно выбирая между драйверами Docker json-file и local, вы предотвращаете проблемы с хранилищем. Независимо от того, настраиваете ли вы ротацию логов Docker, используя легкий локальный файловый драйвер Docker, или нативно интегрируете через логирование Docker journald, ваша среда теперь оборудована для безопасной обработки массивных потоков логов. Внедрение этих практик ротации логов Docker гарантирует, что конфигурация вашего драйвера логирования Docker останется стабильной, а ресурсы хоста – предсказуемыми.
Версия документа: 1.0
Последнее обновление: май 2026
Владелец: Команда технической документации