На проде: journald, Docker, сбор

Контейнер пишет JSON в stdout и stderr — это весь вклад приложения в логи docker go-инфраструктуры. Дальше работает Docker: демон читает поток процесса и складывает записи согласно драйверу логирования. Драйвер по умолчанию — json-file: записи ложатся файлом на диск хоста, в каталог контейнера, и docker logs читает именно их. Важное свойство: zerolog выдаёт поток JSON-строк, и драйвер их не разбирает — он сохраняет как есть, поэтому лента в файле остаётся вашей: те же ключи level и message, что и в любом другом writer-е. STDERR уходит в ту же ленту с маркером потока, и docker logs печатает обе части; zerolog по умолчанию пишет всё в один writer из New. Если сервис ведёт и stdout, и файл — например, в переходной схеме — держите одно содержание в обоих местах: расхождение лент хуже каждой поодиночке. Файлы json-file живут на хосте и переживают рестарт контейнера, но стираются при его удалении — для истории дольше жизни контейнера нужен агент. Частая ошибка — вести логи в файл внутри контейнера: файл попадает в слой, теряется при пересоздании и не виден docker logs, а сборщикам нужен доступ в файловую систему конкретного контейнера. Контракт один: процесс — поток — драйвер — лента. Всё, что ушло в stdout, доедет; всё, что спрятано в файлах контейнера, исчезнет вместе с подом.

По умолчанию у json-file нет ни ограничения размера, ни ротации: max-size по документации Docker равен unlimited, max-file — единице, и лента одного болтливого контейнера способна съесть диск целиком. Ротация включается опциями драйвера: max-size задаёт порог файла, max-file — количество кусков; старший стирается при переполнении. Рабочий пример: max-size=10m и max-file=3 — потолок тридцать мегабайт на контейнер, три файла по десять. Те же опции ставятся глобально в daemon.json — тогда применяются ко всем контейнерам хоста; флаги docker run перекрывают глобальные и удобны точечно. Нюанс, о котором узнают на инциденте: docker logs читает только текущий набор файлов, и стёртые ротацией куски не вернуть — если записи нужны дольше потолка, это задача системы сбора, а не драйвера. Рядом с json-file есть драйвер local — тоже файловый, со сжатием и собственными лимитами по умолчанию; выбирается теми же флагами, а ленты читаются демоном одинаково.

Чтение — то, что делают чаще всего, и обе утилиты дают минимум, за который не стыдно. docker logs app печатает ленту контейнера целиком, --tail 100 обрезает до хвоста, -f следит в реальном времени, --since 10m или --since с меткой времени режет окно — записи zerolog при этом печатаются как есть, JSON-строками, поэтому по ним удобно ходить jq-фильтрами прямо в терминале. Для bare-metal сервиса под systemd ленту собирает journald: процесс пишет в stdout, юнит подключает его к журналу, и journalctl -u app показывает записи именно этого сервиса. Флаги те же по смыслу: -f следит, --since режет окно, -n 100 ограничивает число строк. Разница глубже утилит: journald добавляет к каждой записи свои поля — юнит, hostname, момент приёма, — но JSON zerolog доезжает внутри без изменений, и поля событий остаются ваши. Практичный порядок чтения при разборе одинаковый у обеих утилит: сначала хвост через --tail, затем окно --since вокруг инцидента, затем -f после воспроизведения; формат --since понимает и абсолютные метки, и относительные значения вроде 10m. Смешивать потоки двух сервисов в одну ленту не нужно никогда: у каждого юнита свой журнал, и разделение уже сделано за вас.

journald ведёт счёт на каждый сервис: RateLimitIntervalSec задаёт окно, RateLimitBurst — число сообщений на окно; в типовой конфигурации это тридцать секунд и десять тысяч сообщений на юнит, директивы живут в journald.conf. Пока сервис в лимите, всё доезжает; как только всплеск превысил burst, новые записи отбрасываются до конца окна — молча, без предупреждения в самой ленте. Эффект на «болтливый» сервис ровно такой: в худший момент, когда записей больше всего, лента исчезает, и на разборе видна дыра вместо истории. Лечится не поднятием лимита до бесконечности, а объёмом: сводки вместо построчных логов из урока про антипаттерны, прореживание семплером, дисциплина уровней. Проверка простая: отправьте всплеск из теста и посчитайте записи journalctl-ом — часть пропадёт ровно на burst. Юнит-файл сервиса тоже участвует в схеме: StandardOutput по умолчанию уходит в журнал, и переопределять его стоит осознанно — вывод в файл силами systemd возвращает проблему ротации, только теперь в конфиге юнита. Отдельная настройка — Storage в journald.conf: значение auto хранит журнал на диске только при существующем каталоге /var/log/journal, иначе в памяти — это первый вопрос, когда после рестарта journalctl оказывается пуст.

Инфраструктура проверяет принципы курса с удвоенной ставкой: спам из урока про антипаттерны доезжает до драйвера, потерянные единицы — до хранилища, двойная запись — до алертов. Дальше — итоговый проект: логгер для CLI-сервиса, где конфиг, уровни, файл и stdout собираются в один каркас и проверяются сборкой. Справочное закрепление: соберите Dockerfile из урока, запустите контейнер с лимитами и посчитайте куски ленты; затем поднимите тот же сервис systemd-юнитом на виртуалке и сравните journalctl -u с docker logs — записи должны совпасть, потому что writer один и тот же. Разница, если найдётся, обычно в обёртке: journald добавляет свои поля, docker — маркер потока, но JSON событий остаётся тем же артефактом. Если разница есть, она в инфраструктуре, и теперь вы знаете, где искать.