Как управлять журналами Docker на VPS

Чтобы журналы Docker помогали разбирать сбои и не заполняли VPS, настройте три вещи: полезные события приложения, ограничение хранения и способ поиска по времени. Начните с конкретного контейнера и его logging driver. После настройки проверьте журнал нового контейнера и безопасный пользовательский сценарий, а не только изменённый compose.yaml.

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

Какие события стоит писать в журнал

Полезная запись связывает действие со временем и результатом. Для веб-приложения это запуск процесса, начало и завершение фоновой задачи, отказ внешней зависимости, код ошибки и длительность операции. Для поиска нескольких строк одного действия подходит идентификатор запроса, не содержащий персональные данные.

Записывайте сведения, которые помогут принять решение. Сообщение «error» без компонента не отличает сбой базы от отказа API. Полный объект пользователя избыточен и опасен. Практичный пример формата: время UTC, уровень, компонент, request_id, событие, безопасный код результата. Это предложенная структура, а не стандарт, который Docker навязывает каждому приложению.

Разделите штатные события, предупреждения и ошибки. Если каждая проверка здоровья пишет многострочный успешный ответ, важные строки теряются среди повторов. Если ошибка подавляется полностью, контейнер может выглядеть работающим при неработающей функции. Выберите уровень production и оставьте возможность временной диагностики с заранее определённым возвратом к обычному режиму.

Не журналируйте Authorization, пароли, токены и полные тела заявок. Проверьте также библиотечные ошибки: они способны включать URL с секретом или параметры соединения. Маскирование нужно проверять на примере неудачного запроса, а не только успешной операции. Общие границы описаны в статье о хранении ключей приложения.

Как найти строки нужного контейнера

Откройте каталог нужного Compose-проекта и установите, какой сервис обслуживал действие. На общем VPS имя проекта важно: похожие api могут принадлежать разным сайтам. Сначала прочитайте список, затем ограниченный журнал:

docker compose ps
docker compose logs --since 15m --tail 100 --timestamps api

Справочник docker compose logs описывает фильтры времени и количества строк. Для отдельного контейнера существует docker logs. Опция follow продолжает чтение новых записей; завершение просмотра не останавливает контейнер. Учитывайте часовой пояс события и точность времени, когда сравниваете приложение с Nginx.

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

docker logs обычно работает с stdout и stderr приложения через поддерживаемый механизм журналирования. Если программа пишет только в собственный файл, её события могут не появиться в этом выводе. Проверьте документацию и конфигурацию программы. Пустой вывод способен означать другой канал, а не отсутствие ошибок.

Для внешнего драйвера доступность локального чтения зависит от его возможностей и кеширования. Это оговорено в документации docker logs. Если поток уходит во внешний сервис, проверьте доставку там. Состояние контейнера running не подтверждает, что запись дошла до хранилища.

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

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

docker info --format '{{.LoggingDriver}}'
docker inspect --format '{{json .HostConfig.LogConfig}}' myapp-api-1

Первая команда показывает настройку по умолчанию, вторая — конкретного контейнера. Имя myapp-api-1 учебное; возьмите фактическое из списка. На сервере могут одновременно работать контейнеры с разными драйверами, в том числе созданные до изменения default.

Вариант	Когда рассмотреть	Что проверить
local	Локальное чтение с контролируемым хранением	Параметры ротации и срок доступной истории
json-file	Нужен существующий совместимый процесс сбора	Явные ограничения размера и количества файлов
Внешнее хранилище	Несколько серверов или обязательная сохранность вне VPS	Доставка, доступ, лимиты, кеш и поведение при сбое

Согласно инструкции Docker по logging drivers, изменение default относится к вновь создаваемым контейнерам. Для одного приложения на общем VPS сначала используйте локальную настройку сервиса в Compose, не изменяя общий daemon.json. Это уменьшает область изменения и позволяет проверить результат отдельно.

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

Как задать ротацию в Docker Compose

Ротация ограничивает сохранённые локальные журналы. Это не резервная копия и не гарантия хранения событий за определённое число дней. Чем больше поток, тем быстрее старые события выходят за установленный объём.

services:
  api:
    image: example/myapp:approved-version
    logging:
      driver: local
      options:
        max-size: "10m"
        max-file: "3"

Образ и значения в этом фрагменте демонстрационные; image не нужно менять вместе с logging. Вставьте блок в существующее описание нужного сервиса, сохранив его остальные параметры. Настройка logging в Compose задаёт драйвер и его options. Выбранные здесь 10m и 3 показывают синтаксис, а не универсальный размер для любого приложения.

Выберите объём по фактической скорости записей и времени реакции администратора. Если для разбора нужен вчерашний запуск задания, а хранение покрывает лишь короткий интервал, настройка не решает задачу. Запишите, какой период реально доступен при обычной нагрузке. При всплеске ошибок период может сократиться; нужные события следует отдельно сохранять по правилам доступа.

Сжатие и служебные накладные расходы влияют на размер, поэтому не объявляйте произведение max-size и max-file точным лимитом диска всего проекта. В него также входят другие контейнеры, собственные файлы приложения, образы и данные. Ротация одного stdout не ограничивает отдельный application.log, если программа продолжает писать туда.

Для существующего json-file поддерживаются max-size и max-file; условия описаны в документации этого драйвера. Не переносите options между драйверами без сверки: одинаковое название параметра не делает все реализации эквивалентными.

Как применить настройку без потери данных

Изменение описания контейнера не меняет уже созданный контейнер автоматически. Планируйте пересоздание нужного сервиса. До него проверьте, где находятся рабочие данные: persistent volume, bind mount или writable layer. Данные в последнем могут исчезнуть вместе со старым контейнером.

Сохраните текущий Compose-файл, версию образа, данные и необходимые журналы. Проверьте конфигурацию без вывода полного развёрнутого содержимого с секретами: для подходящей версии Compose используйте docker compose config --quiet. Если версия не поддерживает параметр, выберите предусмотренный ею безопасный способ валидации.

После подготовки отдельного окна точечное пересоздание может выглядеть так:

docker compose up -d --no-deps --force-recreate api

Это изменяющая операция: процесс api будет заменён, активные запросы могут прерваться. Она не является универсальной командой для неизвестного проекта. Сверьте поведение compose up, зависимости и способ хранения данных. Не добавляйте down -v: удаление volumes не требуется для настройки logging.

Проверьте его фактический LogConfig и безопасный запрос приложения. Убедитесь, что события появились в нужном журнале и данные не исчезли. Если обнаружена ошибка, возвращайте сохранённую конфигурацию и проверенную версию по подготовленному плану; возврат logging не восстанавливает потерянные пользовательские данные.

Что ротация не исправляет

Ротация не уменьшает число событий и не устраняет причину бесконечной ошибки. Если процесс перезапускается каждую секунду, сначала разберите старт и зависимость. Если одна операция печатает мегабайты, исправьте уровень или формат. Увеличение лимита без анализа только откладывает проблему.

В режиме blocking доставка журнала может влиять на поток выполнения приложения; режим non-blocking использует буфер, переполнение которого способно привести к потере событий. Эти условия нужно сверить в документации выбранного драйвера. Не включайте режим с потерей только ради скорости, если журнал нужен для обязательного аудита.

Доступ к Docker API даёт широкие возможности и не является безопасным правом «только читать журнал». Не добавляйте сотрудника в группу docker исключительно ради просмотра ошибок без оценки полномочий. Для делегированного доступа лучше предусмотренный ограниченный канал или очищенная выгрузка нужного фрагмента.

Если диск уже заполнен, настройка ротации нового контейнера не освобождает автоматически все старые данные. Диагностика описана в статье о нехватке места на VPS. Не редактируйте и не обнуляйте внутренние файлы драйвера вручную: Docker управляет ими сам, и вмешательство может нарушить чтение.

Для наблюдения установите контроль доступного места и доставки важных событий. Общая схема есть в материале о мониторинге VPS. Отдельно назначьте срок хранения и ответственного: «журналы есть» не объясняет, можно ли разобрать обращение недельной давности.

Чек-лист полезного журнала Docker

Этот список сохраняет отметки в браузере. Он не читает Docker и не измеряет размер файлов; каждый пункт отмечайте после собственной проверки.

Для обсуждения сопровождения опишите проект и нужный период диагностики через Умную форму. Не прикладывайте полный журнал с заявками или секретами.

Ответы на частые вопросы

Почему в docker logs ничего нет

Программа может писать в файл или использовать другой канал, а выбранный драйвер не предоставлять ожидаемое чтение. Проверьте stdout, stderr и конфигурацию доставки.

Достаточно ли изменить daemon.json

Изменение default не перенастраивает все существующие контейнеры. Для отдельного проекта сначала проверьте локальные настройки и план пересоздания.

Можно ли считать лимит гарантией хранения за неделю

Нет. Лимит объёма и срок различаются. При росте потока старые записи удаляются быстрее; измеряйте доступный интервал.

Нужно ли удалять volumes ради ротации

Нет. Настройка журналов не требует удаления пользовательских данных. Перед пересозданием проверьте их постоянное хранилище.

Ротация stdout ограничивает файл внутри приложения

Не автоматически. Для собственного файла нужен отдельный механизм либо изменение канала записи программы.

Можно ли оставить debug включённым постоянно

Только после оценки объёма и состава данных. Обычно подробный режим включают на ограниченный срок с возвратом и проверкой отсутствия чувствительных сведений.