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

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

• Просмотр логов контейнера
• Настройка отображения
• Драйверы логирования Docker
• Указание драйвера логирования
• Режимы доставки логов
• Лучшие практики
• Руководство по миграции и чек‑листы
• Отладка и когда это не работает
• Факты и глоссарий

Docker автоматически агрегирует стандартные потоки вывода контейнера — stdout и stderr — в логи, которые хранит демон Docker. Это позволяет просматривать поведение приложений без прямого подключения к контейнеру: вывод, который вы увидели бы в интерактивном терминале (-it), попадает в лог‑файл или в указанный драйвер логирования.

Логи будут доступны только если фоновый процесс в контейнере фактически что‑то выводит. Рекомендуется отправлять ошибки в stderr, чтобы инструменты Docker могли их отличить и корректно отображать.

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

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

docker logs my-container

Замените my-container на имя или идентификатор контейнера. Список контейнеров можно получить через docker ps -a.

Команда logs печатает накопленный вывод контейнера. По умолчанию вывод не стримится. Для поточной передачи новых строк используйте флаг --follow (аналог tail -f):

docker logs --follow my-container

Важно: логи сохраняются до удаления контейнера командой docker rm.

Настройка того, что отображается

Команда docker logs поддерживает флаги для тонкой настройки вывода:

• --timestamps — добавляет метки времени в начало каждой строки лога.
• --until и --since — позволяют получить строки за конкретный период. Можно передать полный ISO‑timestamp (например 2021-04-30T20:00:00Z) или удобное относительное значение (1h = 1 час назад, 30m, 2d).
• --tail — получить заданное число последних строк. --tail 10 покажет последние 10 строк.
• --details — выводит дополнительную информацию, которую генерирует драйвер логирования (метки контейнера, переменные окружения и другие детали, если драйвер их поддерживает).

Флаги --until, --since и --tail не действуют при использовании --follow для непрерывного стриминга.

Примеры комбинирования флагов:

# Показать последние 100 строк с метками времени
docker logs --tail 100 --timestamps my-container

# Стримить логи, начиная с часа назад
docker logs --since 1h --follow my-container

Драйверы логирования Docker

Docker записывает логи контейнеров через драйверы логирования. По контейнеру можно указать свой драйвер; при отсутствии указания используется драйвер json-file.

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

Существуют драйверы для облачных сервисов (CloudWatch, GCP), для ETW на Windows и другие. Также поддерживаются плагины третьих сторон; драйверы можно найти на Docker Hub и установить через docker plugin install plugin-name.

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

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

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

Чтобы изменить драйвер по умолчанию глобально, редактируйте /etc/docker/daemon.json и установите ключ log-driver в имя драйвера. Пример для json-file с настройкой ротации логов:

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

Многие драйверы принимают опции через --log-opts (в docker run) или log-opts в daemon.json. Пример с параметрами при запуске контейнера:

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

Опция max-size задаёт порог ротации для файла лога, max-file — сколько старых файлов хранить.

Режимы доставки логов

Драйверы логов могут работать в blocking (по умолчанию) или non-blocking режиме. Разница важна с точки зрения надёжности и производительности:

• Blocking — запись в драйвер происходит немедленно; приложение ждёт завершения записи. Это гарантия доставки, но потенциальный источник задержек, если драйвер занят.
• Non‑blocking — Docker буферизует вывод в оперативной памяти и не блокирует приложение. Производительность повышается, но увеличивается риск потери логов при переполнении буфера.

Параметры задать можно через mode и max-buffer-size для размеров буфера. Пример включения non‑blocking и установки буфера:

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

Важно: non‑blocking полезен для высоко нагруженных приложений, но следует оценить риск потери логов и доступную RAM.

Лучшие практики логирования

• Выводите структурированные логи (JSON) если требуется парсинг и агрегирование.
• Пишите ошибки в stderr; обычную информацию в stdout.
• Не дублируйте метки времени в приложении: большинство драйверов добавляют временные метки автоматически.
• Настройте ротацию и удержание, чтобы избежать переполнения диска (например, max-size/max-file).
• Используйте сеть доставки логов (fluentd, syslog, облачные) для централизованного хранения и поиска.
• Тестируйте производительность при включённом blocking режиме для критичных приложений.

Пример архитектуры для крупных систем: приложение пишет в stdout в структурированном виде → Fluentd/Logstash собирает логи → хранилище (Elastic, CloudWatch) для поиска и алертинга.

Примечание: иногда проще управлять логами внутри контейнера — например, писать в файл на том же хосте через volume и собирать его специализированным агентом. Однако это усложняет использование docker logs.

Руководство по миграции и чек‑листы

Когда менять драйвер и как минимизировать риски — краткий SOP:

1. Оцените требования: поиск, хранение, соответствие (compliance), задержка доставки.
2. Выберите целевой драйвер (например, fluentd или cloud driver).
3. Настройте тестовый стенд и включите драйвер только для тестовых контейнеров.
4. Соберите метрики: задержку записи, потерю логов, нагрузку на сеть/CPU.
5. Подготовьте план отката: как вернуть json-file в daemon.json и перезапустить сервисы.
6. Прокатите изменение по окружениям: dev → staging → prod.

Чек‑лист разработчика:

• Логи структурированы (если требуется).
• Ошибки пишутся в stderr.
• Логи не содержат секретов.
• Приложение корректно обрабатывает блокировки IO.

Чек‑лист DevOps:

• [ ] Настроен daemon.json с нужным драйвером и опциями.
• Есть мониторинг использования диска/памяти/сети драйвера.
• План отката и бэкап конфигураций.

Чек‑лист безопасности:

• Логи не содержат PII/секретов.
• Передача логов шифруется (TLS) при отправке внешнему сервису.
• Политики доступа к логам задокументированы.

Методология хранения и ротации (мини‑метод)

1. Классифицировать логи: критичные, отладочные, аудиторные.
2. Для критичных — держать в центральном хранилище минимум 90 дней (бизнес‑требование). Для отладочных — 7–30 дней.
3. Настроить уровень агрегации и фильтрации на стороне агента (fluentd/logstash), чтобы уменьшить объём.
4. Применить ротацию на уровне драйвера (max-size, max-file) и/или на стороне хранилища (lifecycle policies).

Отладка и когда это не работает

Сценарии и действия:

• Нет логов в docker logs:

  • Проверьте, что приложение действительно пишет в stdout/stderr.
  • Убедитесь, что контейнер не запущен с перенаправлением логов внутрь файла без stdout.

• Логи обрываются или теряются:

  • Проверьте режим драйвера (non‑blocking) и размер буфера.
  • Мониторьте использование памяти и частоту логирования.

• Производительность падает при логировании:

  • Проверьте blocking режим; переключитесь на non‑blocking и/или ускорьте драйвер (локальное хранилище).

• Драйвер не принимает опции или не устанавливается:

  • Убедитесь, что плагин установлен (docker plugin ls).
  • Проверьте совместимость версии Docker и драйвера.

Критерии приёмки при смене драйвера:

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

Решение: как выбрать драйвер (логическая схема)

flowchart TD
  A[Требуется централизованное хранение?] -->|Да| B{Поддерживает ваш стек}
  A -->|Нет| C[Оставить json-file/local]
  B -->|Да: fluentd/syslog| D[Выбрать соответствующий драйвер]
  B -->|Нет| E[Использовать плагин или писать в файл + агент]
  D --> F[Тестировать в staging]
  E --> F
  C --> F
  F --> G[Резервный план/Откат]

Факты и полезные напоминания

• По умолчанию Docker использует драйвер json-file.
• Пример настройки ротации: max-size=8M, max-file=5.
• Режимы доставки: blocking (по умолчанию) и non‑blocking (с буфером).

Глоссарий (в 1 строке):

• stdout — стандартный поток вывода приложения; полезен для обычных сообщений.
• stderr — поток ошибок; используйте для сообщений об ошибках.
• logging driver — компонент Docker, который отправляет или сохраняет логи контейнера.

Итоги

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

Важно: никогда не храните секреты в логах и обеспечьте шифрование передачи логов, если используете внешние сервисы.