Логи Docker, Compose и Caddy: tail, since и поиск ошибок
Автор: Казачкин Даниил Михайлович · Обновлено
Для диагностики полезен ограниченный фрагмент журнала: нужный контейнер, время и событие. Покажем последние 100 строк, наблюдение новых сообщений и поиск ошибки, затем отдельно…
Для диагностики полезен ограниченный фрагмент журнала: нужный контейнер, время и событие. Покажем последние 100 строк, наблюдение новых сообщений и поиск ошибки, затем отдельно включим access log Caddy. Команда docker log в единственном числе неверна; рабочие варианты — docker logs и её полная форма docker container logs.
Небольшой журнал для проверки
Создадим контейнер с двумя потоками вывода, который завершится сам:
docker run --name yk-logs-demo alpine:3.22 sh -c 'echo "INFO started"; echo "ERROR sample" >&2; echo "INFO done"'
docker logs --tail 100 --timestamps yk-logs-demo
docker logs --since 10m yk-logs-demo 2>&1 | grep -F ERRORВ последней команде 2>&1 объединяет stderr и stdout перед grep: иначе сообщение из stderr может пройти мимо фильтра. Ожидайте строку ERROR sample. Это искусственная ошибка для проверки канала, а не неисправность Docker. Установка --tail 100 ограничивает число строк, а не удаляет старую историю. Опции logs.
Для работающего сервиса используйте docker logs --tail 100 -f NAME; Ctrl+C останавливает просмотр, а не сам контейнер. При потоковом поиске в GNU grep доступно --line-buffered: docker logs -f NAME 2>&1 | grep --line-buffered -F ERROR. Для переносимого скрипта сначала проверьте поддержку опции вашей версией grep.
Время вместо огромной выгрузки
--since 30m выбирает недавний интервал; абсолютное время лучше указывать с зоной, например --since 2026-09-29T10:00:00Z --until 2026-09-29T10:05:00Z. Если зона не задана, интерпретация зависит от клиента. Сопоставляя журнал proxy и приложения, проверяйте время и идентификатор запроса, а не только одинаковый текст ошибки.
В Compose обращаться удобнее по имени сервиса:
docker compose logs --no-color --tail 100 web
docker compose logs --since 15m --timestamps web db
docker compose logs --no-color --tail 100 -f web--tail применяется к каждому контейнеру, поэтому итоговый поток нескольких реплик может содержать больше 100 строк. Префиксы помогают понять источник; убирайте их только когда отдельно сохраняете связь события с сервисом. Compose logs.
Как посмотреть логи Caddy
На вопрос «how to check docker logs caddy» сначала найдите настоящий контейнер через docker ps -a или сервис через docker compose ps. Затем docker logs --tail 100 caddy либо docker compose logs --tail 100 caddy покажут доступный stdout/stderr. Имя в примере замените фактическим: имя образа не обязано совпадать с именем контейнера.
Служебные сообщения Caddy и журнал HTTP-запросов — разные потоки. Чтобы увидеть обращения, включите access log в собственном Caddyfile:
:80 {
log {
output stdout
format json
}
respond "caddy ready" 200
}Смонтируйте файл в /etc/caddy/Caddyfile образа caddy:2-alpine, опубликуйте локальный порт и выполните curl. В журнале должна появиться JSON-запись запроса. Не считайте отсутствие access log доказательством отсутствия трафика, пока директива log не включена. Настройка Caddy log.
Когда журнал пуст
Приложение может писать только в файл внутри контейнера; Docker не считывает произвольные файлы автоматически. Ещё две причины — буферизация программы и logging driver без доступного локального чтения. Проверьте команду запуска, настройки logger и HostConfig.LogConfig через inspect. Пароли и токены не должны попадать в диагностику; не публикуйте полный журнал без просмотра.
Упражнение
Запишите в stdout и stderr одинаковые маркеры, сравните grep с перенаправлением и без него. Ограничьте выборку коротким интервалом и объясните, почему отсутствие строки может означать неверное время. Удалите только yk-logs-demo после сохранения учебного результата. Для сбоев самого daemon нужен [journalctl](/lessons/without-university/docker-containerization/docker-developer-32), а не журнал произвольного контейнера.