docker logs с временными метками и дополнительными полями

Что возвращает docker logs и когда команда вообще работает

docker logs читает STDOUT и STDERR контейнера через настроенный logging driver и показывает записи, доступные на момент вызова. С -f команда продолжает поток новыми строками. Это важно отличать от чтения файлов внутри контейнера: если приложение пишет только в /var/log/app.log и не отправляет строки в stdout/stderr, docker logs этого файла не увидит. Ещё один нюанс — не каждый logging driver поддерживает локальное чтение командой logs; например, при драйвере none команда прямо сообщает, что чтение не поддерживается. Поэтому при «пустых логах» сначала проверьте, куда пишет приложение и какой log driver назначен контейнеру. Для обычной диагностики начинайте с ограниченного хвоста и временного окна, иначе многогигабайтный журнал затруднит поиск и создаст лишнюю нагрузку на терминал.

Совет: Для аварийной проверки удобная отправная точка: docker logs --tail 200 --timestamps <container>.

Ключи времени и объёма вывода

• --timestamps / -t. добавляет к каждой записи точное время RFC3339Nano
• --since 30m. показывает записи новее указанного момента или относительного интервала
• --until 2026-09-22T05:00:00Z. обрезает вывод по верхней границе времени
• --tail 200. берёт последние N строк вместо всего журнала
• --details. добавляет дополнительные атрибуты, переданные logging driver

Как собрать лог за конкретный инцидент

1. Определите временной диапазон события и часовой пояс. Если есть возможность, задавайте абсолютное время с Z или явным offset, чтобы не спорить с локальным временем клиента.
2. Запустите docker logs --timestamps --since <start> --until <end> <container>. Для недавнего события можно использовать относительное значение, например --since 15m.
3. Если записей слишком много, добавьте --tail перед фильтром для быстрого просмотра, но не используйте слишком маленький хвост при расследовании длительного инцидента.
4. Добавьте --details только если вы действительно передавали полезные labels/env как log attributes. Иначе ключ не создаст метаданные из воздуха.
5. Для живого воспроизведения добавьте --follow и повторите действие, вызывающее ошибку. Остановите поток после получения нужного фрагмента и сохраните его вместе с временными метками.

Предупреждение: Временная метка без часового пояса легко приводит к ложной корреляции. В отчётах фиксируйте UTC или явный offset.

Что означает --details и почему там может ничего не появиться

Опция --details показывает дополнительные атрибуты, которые logging driver сохранил вместе с записью, например отдельные labels или environment values, разрешённые log options. Она не раскрывает весь docker inspect и не добавляет произвольные поля приложения. Если --details ничего полезного не показывает, это нормальная ситуация: значит, соответствующие attributes не были настроены при создании контейнера. Не стоит помещать чувствительные значения в лог-атрибуты ради удобства поиска. Секреты, токены и пароли должны оставаться вне журнала. Для устойчивой эксплуатации лучше заранее выбрать небольшой набор безопасных идентификаторов — имя сервиса, окружение, instance/tenant без персональных данных — и затем одинаково использовать их в централизованном логировании. docker logs остаётся хорошим инструментом локального triage, но не заменяет политику хранения и ротации журналов.

Важно: Если приложение пишет секреты в stdout, --details тут ни при чём: сначала исправьте само логирование приложения.

Почему время в приложении и docker logs может выглядеть по-разному

Timestamp, который добавляет Docker через --timestamps, относится к записи в контейнерном журнале. Само приложение может печатать собственное время в начале сообщения — в другом часовом поясе, с другой точностью и даже с задержкой из-за буферизации. Поэтому две даты в одной строке не обязательно означают ошибку Docker. При корреляции выбирайте один эталон, обычно UTC, и учитывайте источник каждого timestamp. Если сервис активно буферизует вывод, время события внутри приложения может отличаться от времени появления записи в stdout. Для воспроизводимой диагностики полезно одновременно сохранить docker inspect с настройками logging driver и небольшой интервал docker logs, а не копировать только одну строку исключения. Так вы сможете понять контекст перезапуска, окружения и временной последовательности без попыток восстановить всё по памяти.

Как сохранить фрагмент лога так, чтобы его можно было воспроизвести

Для инцидента сохраняйте не бесконечный поток, а ограниченный интервал вместе с идентификатором контейнера, image reference и временем в UTC. Практически полезно сначала получить docker ps/inspect, затем вывести docker logs --timestamps --since и --until в файл. Если контейнер перезапускался, учитывайте, что имя может остаться тем же, а жизненный цикл и restart count измениться. Отдельно пометьте, что время приложения внутри текста строки может отличаться от timestamp Docker. При передаче фрагмента другому инженеру не удаляйте несколько строк до и после ошибки: именно там часто виден graceful shutdown, connection timeout или первый симптом OOM. Но и не отправляйте весь журнал без фильтра — так повышается риск утечки секретов и усложняется анализ. Для постоянного хранения используйте централизованный logging и ротацию, а docker logs оставляйте быстрым локальным инструментом для проверки конкретного контейнера и короткого временного окна.

Как сохранить диагностический фрагмент так, чтобы коллега увидел тот же интервал

Для разборов инцидента лучше сохранять не случайные последние строки, а воспроизводимое временное окно. Зафиксируйте идентификатор контейнера, явные --since и --until, включите --timestamps и перенаправьте вывод в файл вместе с командой, которой он получен. Если сервис перезапускался, дополнительно проверьте время создания и restart count контейнера: docker logs показывает журнал конкретного контейнера, а не абстрактного имени сервиса за всю историю. Не смешивайте локальное время приложения и timestamp Docker без указания часового пояса — сначала приведите их к UTC или одному offset. Если --details пуст, это не ошибка: дополнительные пары key=value появляются только когда соответствующие атрибуты были переданы logging driver. Для больших логов используйте ограниченный --tail плюс временное окно, иначе полезный фрагмент тонет в старых строках. Такой набор делает выгрузку пригодной для сравнения с reverse proxy, базой данных и системой мониторинга без повторного запроса полного журнала.

Что учитывать

Опция --details показывает дополнительные атрибуты, которые logging driver сохранил вместе с записью, например отдельные labels или environment values, разрешённые log options. Она не раскрывает весь docker inspect и не добавляет произвольные поля приложения. Если --details ничего полезного не показывает, это нормальная ситуация: значит, соответствующие attributes не были настроены при создании контейнера. Не стоит помещать чувствительные значения в лог-атрибуты ради удобства поиска. Секреты…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. docker container logs). Пример и формулировки — редакция N1RO на 2026-09-22.

• docker container logs
• docker container run