Знакомство с zerolog: логгер без аллокаций

Знакомство с zerolog начинается с другой модели: лог — это не строка, а событие. Каждая запись — JSON-объект с фиксированными ключами level, time, message и любым числом ваших полей: user_id, order_id, elapsed. Поля типизированные: число пишется числом, строка строкой, длительность числом миллисекунд — для системы сбора это данные, по которым строятся фильтры и графики, а не текст, из которого регуляркой надо выковыривать значения. Zerolog появился в 2017 году — Оливье Пуатре, автор библиотеки, в то же время, когда Uber собирал zap, — и с самого начала был спроектирован вокруг одной цели: сериализация JSON без рефлексии, без промежуточных структур и без аллокаций на горячем пути. При этом API остался компактнее, чем у конкурентов: одна запись собирается цепочкой методов в одну строку, и читать её можно почти как предложение. Поля — это ещё и контракт со следующей версией вашего сервиса: ключ, однажды попавший в записи, обрастает дашбордами и алертами, и убрать его без последствий уже не выйдет. Поэтому события проектируют как схему данных: немного стабильных ключей, понятные типы, никаких одноразовых полей на каждый чих.

Главное инженерное решение zerolog спрятано в слове «без аллокаций». Пока вы собираете событие, zerolog держит его не в структуре с полями, а в байтовом буфере: каждый метод цепочки дописывает в буфер готовые JSON-байты — ключ, кавычки, значение. Никакой рефлексии, никаких промежуточных слайсов полей, как в zap, и никаких map. Буфер берётся из sync.Pool: после вызова Msg он уходит в writer и возвращается в пул для следующего события, поэтому steady-state не создаёт мусора для сборщика. А если уровень события отключён — например, глобальный уровень Info, а вы вызвали Debug, — zerolog возвращает nil-событие, и вся цепочка превращается в no-op: методы проверяют receiver на nil и сразу возвращаются. Для сравнения: подход «собери структуру и отдай json.Marshal» платит рефлексией на каждом поле и аллоцирует результат на каждую запись — на тысячах RPS это уже график. Почему аллокации важны сами по себе: каждая из них — работа для сборщика мусора, а GC в Go стартует чаще, чем растёт куча. Логгер с десятками аллокаций на запись при десятках тысяч RPS стабильно подогревает кучу, и сборщик отбирает процессор у бизнес-кода — не паузами, которые видно на отдельном графике, а общим временем ответа. Ноль аллокаций — не трюк для бенчмарков, а способ вынести логирование из уравнения производительности целиком. Отключённая запись стоит единицы наносекунд, и это меняет привычку: отладочные вызовы можно не вычищать из горячего пути. Разбор с бенчмарками по этой теме — в уроке про производительность.

Собственные бенчмарки zerolog из README дают такой порядок величин: пустое событие — около 19 наносекунд, Info с сообщением — около 42, событие с полями — около 184 наносекунд, и во всех случаях ноль аллокаций. В бенчмарке самого zap на записи статичной строки zerolog выигрывает у zap в разы (50 против 236 наносекунд), а у logrus — на порядок (1244 наносекунды и 27 аллокаций). На событии с десятью полями разрыв с zap сжимается до процентов: 767 против 848 наносекунд — здесь у zerolog появляются единичные аллокации из-за упаковки значений в interface{}, которую требует сам бенчмарк. Числа — синтетические, зависят от машины и версии, и на вашем железе они будут другими; прогоните бенчмарки из репозитория сами, если решение стоит денег. Практический вывод не в цифрах, а в форме кривой: zerolog предсказуем на горячем пути — одинаковая цена на каждую запись без пиков на GC. Отдельно читайте колонку аллокаций, а не только время: logrus в том же прогоне отдаёт сборщику 27 объектов на каждую запись, zerolog — ноль. На коротком прогоне разница невидима, на длинном именно аллокации решают, как сервис ведёт себя под затяжной нагрузкой: куча не растёт, GC срабатывает реже, хвосты латентности не плывут.

Чем цепочечный API отличается от соседей — на этом держится половина впечатления от библиотеки. В zap то же событие выглядит как logger.Info("user logged in", zap.String("user", "ann"), zap.Int("age", 30)): конструкторы полей перечисляются аргументами. В slog — атрибуты: slog.Info("user logged in", "user", "ann", "age", 30). В zerolog поля вплетены в цепочку: log.Info().Str("user", "ann").Int("age", 30).Msg("user logged in"). Мне цепочка читается легче: ключ и значение стоят рядом, тип виден в имени метода, и длинная запись не превращается в простыню аргументов. У этого вкуса есть и цена, о которой честно предупреждают в уроке про первый лог: цепочку надо чем-то завершить — вызовом Msg, — иначе запись не случится вовсе. Есть и практический бонус: порядок ключей в JSON совпадает с порядком вызовов, так что при ревью видно, как запись будет выглядеть в системе сбора, а автодополнение в редакторе предлагает ровно те типы полей, которые валидны для значения. Если после zap вам удобнее перечисление полей аргументами, это нормально; выбор логгера — командное решение, а не религиозное, и умение читать оба API окупается при миграциях.

Во втором уроке — первый лог в zerolog: zerolog.New(os.Stdout), ключ time, глобальный логгер из zerolog/log и честный ответ на вопрос, почему здесь нет Sync. Третий — уровни логов: от Trace до Fatal и SetGlobalLevel. Четвёртый — поля события во всей красе: Str, Int, Err и цена Any. Дальше ConsoleWriter, контекстные поля и вся библиотека до итогового проекта. Пока — установите zerolog локально и запустите пример из этого урока: первая JSON-строка в терминале объясняет идею библиотеки лучше любого текста.