Docker логи: как просматривать, сохранять и управлять

Что такое Docker логи

Docker логи — это последовательность сообщений, которые контейнер выводит в stdout и stderr. Они содержат сообщения приложений, предупреждения, ошибки и часто помогают понять состояние контейнера и причины сбоев.

По умолчанию Docker сохраняет логи в виде JSON-файлов на хосте в директории /var/lib/docker/containers. Каждый контейнер имеет файл с именем вида [container_id]-json.log. Вместо прямого чтения файлов удобнее использовать команду docker logs, которая форматирует вывод и поддерживает фильтры.

Ключевые понятия в одной строке:

• Лог-драйвер: компонент Docker, который определяет, куда и как отправлять логи (json-file, journald, fluentd, gelf и др.).
• Blocking vs non-blocking: режимы доставки логов, влияющие на задержку и надёжность.

Зачем это важно

Логи помогают:

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

Важно: контейнеры по своей природе эфемерны — храните логи вне контейнера для длительного анализа.

Как получить и просмотреть Docker логи

Базовая команда для просмотра логов контейнера:

docker logs [OPTIONS] CONTAINER_NAME_OR_ID

Узнать список работающих контейнеров:

docker ps

Пример — просмотр логов по имени контейнера:

docker logs openwebui

Или по ID:

docker logs 1f351684ae30

Полезные опции команды docker logs

Ниже — распространённые флаги для фильтрации и просмотра логов.

Пример: посмотреть последние 50 сообщений и следить за новыми:

docker logs --tail 50 -f openwebui

Сохранение логов в файл

Чтобы сохранить вывод команды в файл, перенаправьте стандартный вывод или используйте утилиты для ротации:

docker logs container_name > container_logs.txt

Для дозаписи используйте >>:

docker logs container_name >> container_logs.txt

Откройте файл в редакторе, например nano, vim или VS Code. Это полезно для передачи логов в службу поддержки или для анализа с инструментами.

Просмотр логов в Docker Compose

Для проекта Docker Compose используйте:

docker compose logs

Чтобы получить логи конкретного сервиса:

docker compose logs service_name

Примечание: в старых версиях команда называлась docker-compose logs (с дефисом).

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

Docker поддерживает разные лог-драйверы: json-file (по умолчанию), journald, fluentd, gelf, awslogs и др. Драйвер определяет формат и конечное хранилище логов.

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

• Blocking — запись логов синхронно; обеспечивает надёжность, но может влиять на производительность приложения.
• Non-blocking — асинхронная отправка; снижает задержки, но при переполнении буфера возможна потеря логов.

Рекомендации:

• В production лучше пересылать логи в централизованную систему (ELK, Loki, Fluentd) для долгосрочного хранения и поиска.
• Для критичных сервисов используйте драйверы с подтверждением доставки или хранение на диске хоста через volumes.

Лучшие практики

• Выводите структурированные логи (JSON) из приложения, чтобы облегчить парсинг и фильтрацию.
• Не храните логи внутри слоёв контейнера — используйте volumes или внешний агрегатор.
• Настройте ротацию логов (logrotate или встроенные механизмы драйверов) чтобы избежать переполнения диска.
• Добавляйте уникальные контекстные поля (request_id, trace_id) для трассировки запросов.

Когда стандартный подход не работает — контрпримеры и альтернативы

Контрпримеры:

• Если приложение пишет логи во внутреннюю директорию (файлы), команда docker logs ничего не покажет — docker logs отслеживает stdout/stderr.
• При использовании нестандартного лог-драйвера (например, syslog) локальные JSON-файлы могут отсутствовать.

Альтернативы:

• Собрать файлы логов из контейнера через docker cp или смонтированные volumes.
• Использовать встроенные средства сбора логов на хосте (journald, rsyslog) или агента (Fluentd, Filebeat).

Инструменты для анализа логов

Популярные системы:

• ELK Stack (Elasticsearch + Logstash + Kibana) — полнофункциональный стек поиска и визуализации.
• Grafana + Loki — оптимизировано для меток и логов в контексте временных рядов.
• Fluentd / Filebeat — лёгкие агенты для переотправки логов.
• Prometheus — собирает метрики (не логи), но полезен в связке для алертов.

Выбирайте систему в зависимости от объёма, требований к хранению и бюджета.

Шаблон SOP: как действовать при проблемах с контейнером и логами

1. Получить список контейнеров и их статус:

docker ps -a --format "table {{.ID}}    {{.Names}}  {{.Status}}"

2. Просмотреть последние логи:

docker logs --tail 200 -t контейнер

3. Если логи пустые — проверить, пишет ли приложение в stdout/stderr, или в файлы внутри контейнера.

4. Собрать файлы логов из контейнера:

docker exec -it контейнер sh -c "tar -cz /path/to/logs" > logs.tar.gz

5. Перезапустить контейнер и наблюдать за логами в реальном времени:

docker restart контейнер && docker logs -f контейнер

6. При обильном логировании — включить ротацию и перенаправить в агрегатор.

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

• Логи доступны в центрелизованном хранилище в читаемом формате;
• В течение 24 часов после инцидента доступны все записи необходимого периода;
• Метрики и алерты генерируются на основе логов/метрик.

Инцидентный рукоплан (runbook) для расследования ошибок

1. Идентифицировать сервис и контейнеры, затронутые инцидентом.
2. Получить последние 500 строк логов с метками времени.

docker logs --tail 500 -t контейнер > incident_logs.txt

3. Найти ключевые ошибки (ERROR, Exception, FATAL) и correlate trace_id.
4. Если отсутствуют логи — проверить драйвер логирования и подключение к агрегатору.
5. При необходимости выполнить откат (rollback) на предыдущий образ или пересобрать контейнер.
6. После восстановления собрать постмортем: причины, действия, план предотвращения.

Важно: не выполняйте force-restart без сохранения логов, если нужно разбирать причину сбоя.

Decision flow: что делать, если контейнер падает и логов мало

graph TD
  A[Контейнер падает] --> B{Есть логи в docker logs?}
  B -- Да --> C[Ищем ошибки и трассы]
  B -- Нет --> D{Пишет ли приложение в stdout/stderr?}
  D -- Да --> E[Проверить драйвер логирования и ротацию]
  D -- Нет --> F[Проверить файловые логи внутри контейнера]
  F --> G[Собрать файлы логов через docker cp или tar]
  E --> H[Проверить перегрузку буфера 'non-blocking' и диск]
  C --> I[Если ошибка в коде — фикс и деплой]
  G --> I
  H --> I
  I --> J[Мониторинг и алерты настроены]

Ролевые чек-листы

Разработчик:

• Выводить структурированные логи в stdout/stderr.
• Добавлять context fields (request_id, user_id).
• Покрыть критичные места логами уровня ERROR/DEBUG.

DevOps / SRE:

• Настроить централизованный сбор логов и ротацию.
• Проверять использование диска на хосте и лимиты логов.
• Настроить алерты по ошибкам и по росту объёма логов.

QA:

• Проверять, что тестовое окружение сохраняет логи и что они доступны.
• Включать отладочные сообщения при воспроизведении багов.

Технические приёмы и сниппеты

Список мест хранения и команды для базовой диагностики:

• Логи Docker (хост): /var/lib/docker/containers//-json.log
• Проверить используемый лог-драйвер:

docker inspect --format='{{.HostConfig.LogConfig.Type}}' container_name

• Установить лимиты для json-file (ротация):

"log-opts": {
  "max-size": "10m",
  "max-file": "3"
}

(Добавьте в daemon.json на хосте или в конфигурацию docker-compose для соответствующего сервиса.)

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

1. Определите минимальный набор полей в логах (timestamp, level, message, trace_id).
2. Выберите формат (JSON предпочтителен для парсинга).
3. Решите куда хранить логи: локально (для dev) и централизованно (для prod).
4. Настройте ротацию и мониторинг использования диска.
5. Внедрите агрегацию и дашборды для ключевых ошибок.

Сравнение подходов (кратко)

• Локальные JSON-файлы (json-file): просты, подходят для небольших систем.
• Journald: интеграция с системным журналом, удобно на системах с systemd.
• Fluentd/ELK/GELF: мощная аналитика и поиск, требует инфраструктуры.

Выбор зависит от объёма логов, требований к хранению и возможностей команды.

1-строчный глоссарий

• stdout/stderr — стандартный вывод и поток ошибок приложения;
• log driver — механизм Docker для отправки логов;
• rотация логов — процесс архивирования и удаления старых файлов логов.

Частые ошибки и как их избежать

• Проблема: пустые docker logs при падении сервиса. Причина: приложение пишет логи в файлы внутри контейнера, а не в stdout/stderr. Рекомендация: перенастроить логгер приложения.
• Проблема: переполнение диска из-за логов. Рекомендация: включить ротацию (max-size, max-file) и перенаправление в удалённый агрегатор.
• Проблема: потеря логов в non-blocking режиме. Рекомендация: для критичных сообщений использовать надёжный драйвер или обеспечить устойчивую очередь.

Итог и рекомендации

Docker логи — ключевой источник информации при отладке контейнеров. Для стабильной эксплуатации:

• убедитесь, что приложение пишет логи в stdout/stderr;
• настроьте ротацию и централизованный сбор;
• создайте SOP и инцидентный рукоплан;
• используйте структурированное логирование и идентификаторы трассировки.

Заключение: базовые команды (docker logs, docker compose logs) решают многие задачи, но для надёжности и масштабируемости лучше настроить централизованный сбор и ротацию логов.

Краткий план действий (annoucement): настройте агрегацию логов и ротацию в течение следующей недели — это снизит время расследования инцидентов и риск переполнения диска.

Краткое резюме

• Docker логи — stdout и stderr контейнера;
• Используйте docker logs с флагами –tail, -f, –since для анализа;
• В production перенаправляйте логи в агрегатор и включайте ротацию;
• Имейте SOP и runbook для быстрого реагирования.