Логи Docker: просмотр, драйверы и лучшие практики

Быстрые ссылки

• Просмотр логов контейнера
• Настройка отображения
• Лог-драйверы Docker
• Указание лог-драйвера
• Режимы доставки драйвера
• Лучшие практики логирования
• Сводка

Docker автоматически агрегирует стандартные потоки вывода и ошибок (stdout / stderr) контейнеров в журналы, которые хранит демон Docker. Эти логи помогают понять, что происходит внутри контейнера.

Логи содержат тот же вывод, который вы увидите в интерактивном режиме (-it). Логи будут только если процесс в контейнере действительно что-то выводит. Убедитесь, что приложение логирует ошибки в stderr — тогда команды Docker смогут их показать.

Вы можете просматривать логи в любой момент жизненного цикла контейнера. Для запущенных контейнеров доступна потоковая передача в реальном времени; для остановленных — все логи, накопленные до завершения.

Просмотр логов контейнера

Чтобы увидеть логи контейнера, используйте команду docker logs:

docker logs my-container

Замените my-container на имя или ID проверяемого контейнера. Для списка контейнеров используйте docker ps -a.

Команда logs печатает весь вывод логов контейнера в терминал. Если вы хотите непрерывно просматривать новые записи, добавьте флаг –follow (аналог tail -f для обычных файлов).

Полезные флаги docker logs

• –timestamps — выводить полные метки времени в начале строки.
• –until и –since — получить строки за указанный период. Поддерживаются полные метки времени (например, 2021-04-30T20:00:00Z) и относительные значения (например, 1h — час назад).
• –tail — получить последние N строк. –tail 10 выведет последние десять строк.
• –details — добавить дополнительные поля, зависящие от опций лог-драйвера (например, метки контейнера и переменные окружения).

Флаги until, since и tail не применяются в режиме –follow (постоянная потоковая передача).

Лог-драйверы Docker — обзор

Docker собирает и хранит логи с помощью выбранного лог-драйвера. По умолчанию используется драйвер json-file.

• json-file: сохраняет логи в JSON-файл. Удобно для чтения и инструментов. Имеет опции ротации.
• local: компактное локальное хранилище, экономит место по сравнению с json-file в некоторых сценариях.
• syslog: пересылает записи в локальный syslog-демон.
• journald: отправляет в systemd-journald.
• fluentd: отправляет в демон fluentd.

Также доступны драйверы для облачных сервисов и сторонних решений (CloudWatch, GCP, ETW и др.). Плагины лог-драйверов можно найти на Docker Hub. Установка плагина:

docker plugin install plugin-name

После установки его можно указывать как –log-driver plugin-name.

Указание лог-драйвера

Лог-драйвер можно задать для контейнера через –log-driver при запуске:

docker run --log-driver systemd my-image:latest

По умолчанию драйвер задаётся глобально в /etc/docker/daemon.json. Пример изменения драйвера по умолчанию:

{
  "log-driver": "systemd"
}

Многие драйверы принимают дополнительные опции, задаваемые через –log-opts при docker run или через log-opts в daemon.json. Пример для json-file: инструкция по ротации при размере 8M и хранении пяти файлов:

Docker run:

docker run --log-driver json-file --log-opts max-size=8M --log-opts max-file=5 my-image:latest

/etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "8M",
    "max-file": 5
  }
}

Внимание: синтаксис daemon.json — валидный JSON. После правки необходимо перезапустить демон Docker.

Режимы доставки драйвера

Драйверы могут доставлять логи в блокирующем или неблокирующем режиме. По умолчанию используется блокирующая доставка: контейнер ждёт, пока запись будет передана драйверу. Это гарантирует доставку, но может снизить производительность при медленной записи логов.

Неблокирующий режим записывает логи во временный буфер в памяти. Контейнер не ждёт завершения операции записи. Это повышает производительность, но может привести к потере логов, если буфер переполняется.

Настройки включения неблокирующего режима и размера буфера задаются через опции mode и max-buffer-size:

docker run --log-opt mode=non-blocking --log-opt max-buffer-size=8M my-image:latest

Если у вас достаточно оперативной памяти, увеличение max-buffer-size уменьшит риск потерь, но RAM — ограниченный ресурс. Подбирайте параметры с учётом нагрузки.

Когда docker logs не покрывает нужды (когда это не работает)

• Приложение пишет логи в файл внутри контейнера, а не в stdout/stderr. В этом случае docker logs ничего не покажет.
• Логи отправляются напрямую в внешнюю систему внутри приложения (например, через HTTP/UDP) и не дублируются в stdout.
• Логи теряются в неблокирующем режиме из-за малого размера буфера.
• Логи были удалены вместе с контейнером (docker rm) — их уже нет.

Если вы столкнулись с этими ограничениями, рассмотрите перенаправление логов в stdout/stderr или настройку sidecar/агрегатора.

Альтернативные подходы

• Sidecar-агрегатор: отдельный контейнер читает файлы логов приложения из общего тома и пересылает их в систему мониторинга.
• Экспорт внутри приложения: приложение напрямую отправляет логи в СЛД/ELK/Fluentd/CloudWatch.
• Файловые логи на томах Docker: сохранять логи в разделяемый том, где отдельный процесс собирает и обрабатывает их.

Каждый подход имеет плюсы и минусы: простота (docker logs) против гибкости (sidecar/агрегатор).

Практические рекомендации и лучшие практики

• Логируйте в stdout/stderr. Это упрощает интеграцию с Docker и сторонними инструментами.
• Не дублируйте по умолчанию большие двоичные данные в логах.
• Не полагайтесь на хранение логов внутри контейнера. Храните их в централизованной системе или включите ротацию.
• Настройте ротацию (max-size, max-file) для json-file или используйте local для экономии места.
• Для критичных сервисов используйте блокирующую доставку или внешний буфер, чтобы не терять записи.
• Для высокой нагрузки тестируйте режимы доставки и буферы под реальной нагрузкой.
• Учитывайте безопасность: не логируйте секреты и персональные данные в открытую.

Типичные ошибки и как их исправить

• “Ничего не выводится в docker logs” — проверьте, пишет ли приложение в stdout/stderr.
• “Логи исчезают после перезапуска” — убедитесь, что вы не удаляете контейнер или настроили ротацию слишком агрессивно.
• “Производительность падает при логировании” — попробуйте переключиться в non-blocking режим или увеличить буфер.

Роль‑ориентированные чек-листы

Разделю советы по ролям: разработчик, DevOps/SRE, инженер по безопасности.

Разработчик

• Писать лог в stdout/stderr.
• Добавлять уровни логирования (INFO/WARN/ERROR).
• Не включать чувствительные данные в текст логов.
• Тестировать поведение логирования локально с docker logs.

DevOps / SRE

• Настроить глобальный драйвер в /etc/docker/daemon.json.
• Определить политику ротации (max-size, max-file).
• Мониторить заполнение диска, связанное с логами.
• Тестировать non-blocking режим под пиком нагрузки.

Инженер по безопасности

• Проверять, что логи не содержат секреты или PII.
• Настроить контроль доступа к хранилищу логов.
• При необходимости шифровать лог-трафик к внешним сервисам.

Playbook — операция при потере логов во время инцидента

1. Оценить масштаб: пропали логи у одного контейнера или у многих?
2. Проверить конфигурацию лог-драйвера: docker inspect –format ‘{{.HostConfig.LogConfig}}’
3. Проверить свободное место и статус disk I/O.
4. Проверить daemon.json на предмет режима и размеров буфера.
5. При подозрении на переполнение буфера: временно переключить на блокирующий режим или увеличить max-buffer-size.
6. Перезапустить демон Docker аккуратно: systemctl restart docker.
7. Если логи критичны — восстановить из внешнего источника или включить агрегацию на будущее.

Критерии приёмки

• Логи доступны с помощью docker logs для всех рабочих контейнеров.
• Политика ротации предотвращает заполнение диска.
• Нет утечек секретов в логах.

Шпаргалка: команды и шаблоны конфигурации

Просмотр логов:

docker logs --follow --timestamps --tail 100 my-container

Настройка ротации в daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "8M",
    "max-file": 5
  }
}

Неблокирующий режим с буфером:

docker run --log-opt mode=non-blocking --log-opt max-buffer-size=8M my-image:latest

Установка плагина лог-драйвера:

docker plugin install plugin-name

Факто-бокс: ключевые параметры

• По умолчанию: log-driver = json-file
• Пример ротации: max-size=8M, max-file=5
• Режимы доставки: blocking (по умолчанию), non-blocking

Ментальные модели и эвристики

• “stdout-first”: думайте о логировании как о выводе в консоль. Если вы логируете в файл — это исключение, а не правило.
• “Буфер vs Гарантия”: non-blocking = производительность, но риск потерь; blocking = гарантия, но риск задержки.
• “Централизация лучше локальной”: при наличии множества сервисов – агрегатор/sidecar или внешняя платформа упрощают анализ.

Миграция и совместимость

• При миграции с json-file на облачный драйвер проверьте поддержку опций log-opts.
• Тестируйте производительность перед массовым переходом.

Мини‑методология внедрения логирования в проект

1. Прописать требование: все сервисы логируют в stdout/stderr.
2. Настроить глобальную политику ротации в daemon.json.
3. Добавить мониторинг использования диска и задержек логирования.
4. Для критичных сервисов задать централизованный сбор логов (агрегатор).
5. Регулярно проверять логи на утечки секретов.

Примеры приёмки/тест-кейсы

• Запустить контейнер, сгенерировать 1000 строк логов, убедиться, что последние 100 доступны через docker logs –tail 100.
• Запустить нагрузочный тест на запись логов и замерить задержку ответа приложения при разных режимах (blocking vs non-blocking).
• Проверить, что после удаления контейнера логи исчезают (если нет внешней агрегации).

Решающее дерево для выбора подхода к логированию

flowchart TD
  A[Нужен простой просмотр] -->|Да| B[Использовать docker logs + json-file]
  A -->|Нет| C[Есть требования агрегации]
  C --> D{Вам нужен централизованный поиск и алерты?}
  D -->|Да| E[Использовать внешнюю систему + fluentd/sidecar]
  D -->|Нет| F[Sidecar или хранение на томе]

Безопасность и конфиденциальность

• Не записывайте пароли и токены в логах. Если это неизбежно, используйте фильтрацию перед отправкой в общий пул.
• Контролируйте доступ к файлам логов и к интерфейсам, которые их показывают.

Локальные варианты и подводные камни

• На локальной машине systemd/journald часто удобнее, чем json-file.
• При использовании Docker Desktop на macOS/Windows пути и поведение логов могут отличаться от Linux-серверов.

Короткое объявление для команды (100–200 слов)

Docker теперь стандартизирует вывод логов через stdout/stderr. Настройте ротацию логов в /etc/docker/daemon.json (пример: max-size=8M, max-file=5). Для простых случаев используйте docker logs; для централизованного сбора и анализа — разверните fluentd/ELK/CloudWatch или sidecar-агрегатор. Тестируйте режимы доставки (blocking vs non-blocking) под нагрузкой и не храните секреты в логах.

Сводка

Docker предоставляет гибкую систему логирования: локальные драйверы, плагины и опции ротации позволяют подстроить хранение и доставку логов под ваши требования. Для большинства задач достаточно логировать в stdout/stderr и настроить ротацию. Для сложных требований используйте агрегаторы или sidecar-подход. Соблюдайте правила безопасности и тестируйте параметры под реальной нагрузкой.