В этом материале
Запись в stdout может задерживать приложение, если logging driver принимает сообщения в blocking режиме и не успевает их обрабатывать. У Docker есть отдельные настройки доставки и ротации. Они решают разные задачи: обратное давление на процесс и ограничение объёма сохранённых логов.
Запись в stdout может задерживать приложение, если logging driver принимает сообщения в blocking режиме и не успевает их обрабатывать. У Docker есть отдельные настройки доставки и ротации. Они решают разные задачи: обратное давление на процесс и ограничение объёма сохранённых логов.
Проверьте фактический logging driver
Получите LogConfig работающего контейнера через inspect. Настройки default driver на демоне описывают новые контейнеры, а не обязательно существующий экземпляр. Сохраните driver, mode, параметры буфера и ротации. Уточните, куда пишет приложение: stdout/stderr или собственный файл. Изменение Docker logging configuration не управляет автоматически внутренними файлами программы. Если процесс пишет синхронно, участок ожидания может находиться непосредственно в операции записи диагностического сообщения.
Различайте blocking и потерю сообщений
В blocking режиме доставка в driver способна создавать backpressure. Non-blocking использует промежуточный буфер; при его заполнении новые сообщения не помещаются и теряются. Это осознанный компромисс, а не бесплатное ускорение. max-buffer-size относится к доставке, max-size и max-file у json-file — к сохранению и ротации. Не объединяйте эти настройки под одним числом «размер логов»: у них разные точки применения и последствия при переполнении.
Воспроизведите поток отдельно
В учебной среде сравните одинаковую работу с обычным объёмом сообщений и с диагностическим всплеском. Запишите длительность операции, число произведённых строк, доступность получателя и выбранный delivery mode. Затем повторите с ограниченным non-blocking буфером и проверьте пропуски. Не проводите такой эксперимент с секретами или содержимым пользовательских запросов: для проверки канала достаточно синтетических пронумерованных сообщений, не связанных с рабочими данными.
| Проверяемое свойство | Наблюдаемое подтверждение |
|---|---|
| Backpressure | Паузы процесса совпадают с затруднённой доставкой |
| Потеря сообщений | В последовательности получателя есть пропуски |
| Ротация | Файлы меняются по заданной политике |
| Новая конфигурация | Inspect нового контейнера показывает параметры |
Настройте канал по назначению
Сократите шумные сообщения и выберите допустимое поведение при недоступном получателе. Для json-file задайте документированные значения ротации, учитывая строковый формат daemon options. Не редактируйте вручную управляемые Docker log files: это может нарушить работу driver. Изменение default daemon settings следует довести до декларативного пересоздания контейнера в согласованном окне. Отдельно определите, какие события должны попадать в устойчивое внешнее хранилище для последующего расследования.
Проверьте два результата
Успех требует и приемлемого выполнения приложения, и известной полноты диагностического следа. После исправления сравните прежний всплеск, остаточный объём файлов и пропуски нумерованных сообщений. Сохраните driver options вместе с правилами сбора. Если non-blocking устранил задержку, но нужные события теряются, расширьте проектирование канала вместо заявления о полном восстановлении. Проблемы downstream backend, локального driver и собственного файлового логирования должны оставаться различимыми в отчёте.
Для сравнения используйте одинаковую нумерацию и частоту тестовых сообщений. Иначе меньшая задержка может объясняться снижением самого потока, а не изменением delivery mode, что сделает вывод о выбранной настройке недоказанным.
Связанные разборы: gpu monitoring scorecard; gpu maintenance change register.