Docker json-file или local: какой logging driver выбрать

Чем json-file отличается от local на практике

json-file — стандартный драйвер Docker Engine: каждая строка stdout/stderr сохраняется в JSON-представлении со временем и признаком потока. Это удобно для совместимости и привычно для старых инсталляций, но без max-size и max-file ротация не включается, поэтому шумный сервис способен постепенно занять заметную часть диска. local хранит те же контейнерные логи во внутреннем формате Docker, оптимизированном под меньшие накладные расходы, и изначально рассчитан на ротацию. В актуальной документации Docker local сохраняет по умолчанию до пяти файлов примерно по 20 МБ на контейнер и использует сжатие, то есть ориентир составляет около 100 МБ на контейнер до учета служебных деталей. Это не значит, что local всегда «лучше»: если сторонний инструмент напрямую рассчитан на json-file-семантику, изменение драйвера может потребовать адаптации. Для docker logs оба варианта подходят.

Совет: Перед выбором сначала проверьте текущий драйвер командой docker info --format "{{.LoggingDriver}}". Так вы не будете менять конфигурацию вслепую.

json-file и local: короткая таблица выбора

• Драйвер по умолчанию. Да, если daemon не перенастроен. Нет
• Ротация по умолчанию. Нет. Да
• Формат хранения. JSON, внутренние файлы Docker. Оптимизированный внутренний формат
• Настройка размера. max-size + max-file. max-size + max-file
• Типичный выбор. Совместимость и осознанно настроенная ротация. Обычный standalone Docker-хост без требования к JSON-файлам

Предупреждение: Не читайте и не редактируйте файлы логов в каталоге Docker внешними утилитами как обычные журналы: Docker прямо предупреждает, что ими должен управлять daemon.

Как переключить Docker на local по умолчанию

1. Проверьте действующий драйвер: docker info --format "{{.LoggingDriver}}".
2. Откройте конфигурацию daemon.json. На Linux это обычно /etc/docker/daemon.json; в Docker Desktop параметры Engine меняются через интерфейс настроек.
3. Добавьте или измените параметр: {"log-driver":"local"}. Если в файле уже есть другие ключи, не заменяйте весь JSON — аккуратно добавьте новый ключ с корректными запятыми.
4. Перезапустите Docker Engine. После рестарта проверьте docker info еще раз.
5. Создайте тестовый контейнер и выполните docker inspect -f "{{.HostConfig.LogConfig.Type}}" <container>, чтобы убедиться, что новый контейнер получил local.
6. По очереди пересоздайте сервисные контейнеры, которым нужен новый драйвер. Обычный restart старого контейнера настройки logging driver не меняет.

Важно: Ключевой нюанс: изменение daemon.json действует только на контейнеры, созданные после изменения. Для существующего контейнера нужен recreate.

Если нужен json-file: включите ротацию, а не оставляйте unlimited

Сохранять json-file допустимо, но его стоит сделать управляемым. Docker приводит конфигурацию с max-size и max-file: например, max-size="10m" и max-file="3" означают, что один контейнер держит несколько файлов ограниченного размера, а старые сегменты удаляются по мере ротации. Значения в log-opts внутри daemon.json должны быть строками, поэтому даже число файлов пишется в кавычках. После изменения daemon нужно перезапустить, а контейнеры пересоздать. Для единичного контейнера тот же принцип задается при docker run через --log-driver json-file --log-opt max-size=10m --log-opt max-file=3. Если сервис генерирует диагностические логи с высокой скоростью, лимит 10 МБ × 3 может быть слишком мал и затруднит разбор инцидента; размер подбирают по реальной скорости логирования и требуемому окну хранения.

Совет: Сначала оцените, сколько времени истории помещается в выбранный лимит. Размер в мегабайтах сам по себе ничего не говорит, если приложение пишет 50 МБ в минуту.

Как мигрировать без потери наблюдаемости

Не переключайте весь хост и одновременно не удаляйте старые контейнеры, если логи нужны для расследования текущей проблемы. Зафиксируйте последние важные фрагменты через docker logs --since или выгрузите их штатным способом в систему логирования, затем меняйте драйвер. В Compose-проекте изменение daemon default не требует добавлять logging в каждый service, но контейнеры все равно должны быть пересозданы. Если отдельному сервису нужен другой драйвер, задайте его на уровне контейнера/Compose, чтобы исключение было явным. После recreate проверьте не только тип драйвера, но и фактическую ротацию: создайте контролируемый поток тестовых логов, посмотрите docker logs и свободное место. Для продакшена полезно дополнительно поставить мониторинг раздела, где расположен Docker data-root: ротация снижает риск, но не заменяет контроль диска, особенно при большом количестве контейнеров.

Предупреждение: Не путайте лимит контейнерных stdout/stderr с файлами, которые приложение пишет внутрь volume. Logging driver такие файлы не ротирует.

Как выбрать лимит хранения под реальную нагрузку

Выбор между json-file и local лучше завершать не названием драйвера, а расчетом допустимого окна логов. Сначала посмотрите, сколько контейнеров активно на хосте и какие из них действительно шумные. У local базовая политика уже ограничивает историю и ротирует ее; у json-file лимит появляется только после явной настройки max-size и max-file. Поэтому одинаковое число контейнеров может вести себя на диске совершенно по-разному. Если хост обслуживает двадцать небольших сервисов, а расследование обычно требует последние несколько часов, можно начать с консервативного лимита и проверить, сколько времени реально помещается до ротации. Для сервиса, который пишет десятки мегабайт в минуту во время ошибки, тот же лимит уничтожит полезную историю за несколько минут. В таком случае проблема не решается увеличением max-file до огромного значения: лучше снизить шум приложения или отправлять логи во внешнее хранилище. Отдельно учитывайте, что logging driver контролирует только stdout и stderr контейнера. Файлы, которые приложение пишет в volume или bind mount, живут по своим правилам и могут заполнить диск независимо от local или json-file. После изменения политики полезно снять исходный размер Docker data-root, через несколько часов повторить измерение и проверить несколько самых активных контейнеров. Если диск продолжает быстро расти, ищите volumes, build cache, образы и writable layers, а не увеличивайте лимит логов вслепую. Такой подход отделяет проблему хранения логов от общего расхода диска и позволяет выбрать драйвер по фактическому поведению хоста, а не по привычке. Если хост критичен по месту на диске, полезно задать отдельный alert на свободное пространство и на резкий рост каталога Docker. Это даст сигнал раньше, чем daemon перестанет записывать данные из-за заполненного раздела. После перехода на local не удаляйте старые контейнеры только ради освобождения места, пока не убедились, что нужная история уже сохранена: смена драйвера сама по себе не переносит старые записи в новый формат. Для хостов с централизованным сборщиком логов вопрос json-file versus local вообще может быть вторичным — тогда главным становится драйвер, который соответствует принятой цепочке доставки и требованиям к потерям сообщений. Если после недели наблюдения окно истории слишком короткое, увеличивайте лимит постепенно и фиксируйте эффект на свободном месте, а не переходите сразу к заведомо огромному запасу.

Что проверить после изменения

• docker info показывает ожидаемый Logging Driver.
• Новые контейнеры через docker inspect используют нужный тип LogConfig.
• docker logs продолжает показывать диагностический вывод приложения.
• Старые контейнеры пересозданы либо оставлены на старом драйвере осознанно.
• Свободное место на разделе Docker перестало неконтролируемо уменьшаться.
• Если выбран json-file, max-size и max-file заданы как строки и реально применились.

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

Условия меняются. Страница отражает состояние на 2026-09-20; при расхождении с официальной документацией приоритет у первоисточника.

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

Фактическая часть сверена по первичным источникам (в т.ч. Configure logging drivers). Пример и формулировки — редакция N1RO на 2026-09-20.

• Configure logging drivers
• JSON File logging driver
• Local file logging driver