Ротация: lumberjack рядом с zerolog

Библиотека живёт по пути gopkg.in/natefinch/lumberjack.v2 и выставляет наружу одну структуру — lumberjack.Logger с полями-настройками. В связке lumberjack zerolog она играет роль writer-а: logger := zerolog.New(lumber).With().Timestamp().Logger() — и всё, дальше обычный код событий. Внутри lumberjack.Logger — мьютекс, открытый файл и текущий размер. Каждый Write, который приходит от zerolog, проверяет: влезет ли эта строка в лимит MaxSize; если нет — файл закрывается, переименовывается с меткой времени в имени, открывается новый с прежним именем, и только затем запись дописывается уже в новый файл. Ротация происходит прямо между записями, на лету, без остановки сервиса и без сигналов. Текущий файл всегда носит имя из Filename — logs/app.log, — а бэкапы получают суффикс с датой и временем. Для системы сбора это значит: хвостить нужно одно и то же имя, а появившиеся рядом файлы с метками — архив, который можно читать, не боясь, что в него пишут. Ровно на этом контракте строятся filebeat, promtail и простой scp-скрипт дежурного.

Пять полей структуры делятся на два типа: пороги и уборка. MaxSize — максимальный размер текущего файла в мегабайтах перед ротацией; дефолт 100 МБ. Внимание к единицам: поле целое и измеряется именно мегабайтами — MaxSize: 10 это десять мегабайт, и наивное «10 для десяти килобайт» сделает файл в тысячу раз больше задуманного. MaxBackups — сколько старых файлов хранить; дефолт 0 означает «хранить все», что вместе с нулевым MaxAge ведёт к бесконечному росту архива — именно поэтому число стоит задавать всегда. MaxAge — предельный возраст бэкапа в днях; дефолт 0 — не удалять по возрасту вовсе. Compress включает gzip для переименованных файлов; дефолт false — бэкапы лежат сырыми. LocalTime определяет, в какой зоне штампуется имя бэкапа: дефолт — UTC, и это разумный дефолт для серверов, но при сверке с локальными журналами удобно LocalTime: true. Нюанс уборки: удаление старых и сжатие выполняются фоново, после ротации — не блокируя запись; поэтому сжатый .gz может появиться чуть позже самого переименования.

Ротация превращает неограниченный рост в константу, и эту константу стоит назвать до того, как диск назовёт её сам. Верхняя граница занятого места — MaxSize, умноженный на количество текущих и резервных файлов: MaxSize: 100 при MaxBackups: 5 — это до шестисот мегабайт в худшем случае, Compress отыгрывает ещё в разы на текстовых JSON-логах. Пороги работают независимо: по документации lumberjack файлы старше MaxAge дней удаляются независимо от MaxBackups, поэтому мягкий ретеншен задаёт MaxAge, а жёсткий потолок места — именно MaxBackups. Дальше обратная задача: сколько пишет ваш сервис? Оцените средний размер записи — у zerolog со структурными полями это обычно двести-четыреста байт, — умножьте на события в час и получите мегабайты в сутки; от них вверх возьмите MaxSize. Если сервис на пике пишет гигабайты в час, сначала уберите объём, а не наращивайте диск: прореживание потока из урока про sampling режет повторяющиеся записи до того, как они доедут до writer-а, и ротация становится техникой, а не спасением. Худшее, что может случиться без этой арифметики, — не переполнение диска само по себе, а то, что вместе с логами место кончится у базы данных, живущей на той же машине.

Границы библиотеки важнее её возможностей, потому что их узнают по факту. Lumberjack не пишет по сети: это файловый writer, и для Loki или Kafka нужен сборщик-агент, читающий каталог. Он не ротирует по дням автоматически: порог у него один — размер, а календарную разбивку делают своим кодом — меняйте Filename на dated-имя и вызывайте Rotate() в полночь, если формат дневных журналов обязателен. Он ничего не знает о содержимом: не режет спам, не разметит поля, не пришлёт алерт — всё это уровни логгера и сэмплеры zerolog. Наконец, он не координируется с соседними процессами: два сервиса на один Filename сообща будут устраивать гонку за файл — каждому сервису свой путь, это дешёвая дисциплина. Для типового сервиса всё перечисленное не нужно: размерный порог, уборка, сжатие покрывают девять случаев из десяти, а остальное — работа агента на стороне читателя. Честный вывод: lumberjack решает ровно одну задачу — диск не переполнится, — и решает её без движения со стороны zerolog. Проверить связку руками можно за пять минут, и это стоит сделать локально: песочница сайта — тематическая программа на чистом Go, файловые операции и сигналы в ней недоступны. Соберите программу из первого примера с намеренно крошечным лимитом — MaxSize: 1, — закиньте в цикл тысячу записей и посмотрите ls logs/: увидите свежие бэкапы с метками в именах и одиночный app.log, в который пишется прямо сейчас. Затем выполните gzip -t на бэкапе, чтобы убедиться в валидности сжатия, и подождите пару секунд с MaxBackups: 2 — лишние куски исчезнут фоном. На этой же программе проверьте tail -F против tail -f: запустите хвост, сгенерируйте ротацию и посмотрите, кто из них продолжит показывать новые записи. Пятиминутный прогон надолго снимает вопросы «а как оно выглядит».

Ротация — последний кирпич локального хранения: в уроке про запись в файл лежит базовая связка с os.OpenFile, а здесь она обросла жизненным циклом. Дальше два пути: продовая эксплуатация — что мониторить и куда отдавать записи, разберёт урок про логи на проде, — и экономия потока до writer-а: сэмплеры из урока о прореживании убирают повторяющийся спам так, что ротация успевает дышать. Практический тест на сегодня: соберите сервис из урока с MaxSize: 1 и MaxBackups: 2, прогоните пару тысяч записей и посчитайте занятое место в каталоге. Совпало с формулой MaxSize × (MaxBackups + 1)? Диск теперь под контролем, и это главный результат урока.