Сублоггеры: логгер на модуль

Сублоггер в zerolog — это логгер модуля go, собранный от базового одной строкой: auth := base.With().Str("module", "auth").Logger(). Механика та же, что у логгера на запрос из урока про Logger.With: With возвращает накопитель контекста, Str дописывает подпись, Logger финализирует — и на выходе тип-значение zerolog.Logger со всеми свойствами родителя: тем же writer-ом, уровнем и временем, плюс собственный байтовый кусок контекста с module. Каждый вызов auth.Info() подписывает запись модулем автоматически, и код событий не упоминает module ни разу. Дерево продолжается вниз: auth.With().Str("component", "oauth").Logger() даст события с двумя полями сразу — модуль и компонент, — и на любом этаже дерево можно разветвить ещё раз. Важно, что base никуда не девается: он остаётся точкой сборки, от которой отрастают новые ветки, — конструкторы подсистем принимают base параметром и строят себе сублоггер на входе. Логгер модуля — не отдельная сущность, а та же копия логгера с готовой разметкой, и вся сила подхода в том, что разметка задаётся один раз в месте, которое легко найти и проверить.

Ключ module станет координатой в каждой записи сервиса, поэтому конвенцию фиксируют письменно. Имя — существительное из словаря домена: auth, billing, worker, mailer; без версий и имён файлов, потому что переименованный модуль сломает дашборды, настроенные на старое значение. Вложенность раскладывают на соседние ключи — module и component, — а не в один составной auth.oauth: по каждому ключу фильтруется независимо, и графики строятся на любом уровне. Литералы в вызовах запрещают правилом линтера и ревью: имя живёт в константе пакета, а лучше — в одном месте. Когда модулей больше пяти, вместо набора констант заводят реестр: пакет logger с функцией Get(name), которая при первом обращении собирает и кеширует сублоггер от base — подсистемы просят логгер по имени и не знают, как он собран. base в реестре прячут за атомарной ссылкой или sync.Once, а до инициализации Get возвращает запасной логгер с полем module=uninitialized — такие записи в системе сбора видны сразу, и пропущенную инициализацию ловят на первом же запуске, а не по пустому каталогу через неделю. Смысловая нагрузка одна: zerolog сублоггеры работают только при дисциплине имён, потому что их продуктом является не запись, а предсказуемый ключ, по которому записи одного модуля собираются в систему сбора. Сломанный ключ — это тишина на дашборде, и её заметят позже, чем падение теста, поэтому конфигурацию сублоггеров проверяют тестом, как ниже в этом уроке.

Раз сублоггер — полноценный логгер, у него можно переопределить и уровень, и приёмник. Метод Level(lvl) возвращает копию со своим порогом: шумный модуль отладочных трасс переводится на Warn одной строкой — auth := base.With().Str("module", moduleAuth).Logger().Level(zerolog.WarnLevel), — и это не глушит соседей: базовый уровень и глобальный SetGlobalLevel из урока про уровни логов работают как раньше, порог копии проверяется своим полем. Метод Output(w) аналогично меняет writer копии: модуль аудита получает отдельный журнал, модуль отладки — файл с темами. Оба метода возвращают новые копии и не трогают родителя — value-семантика, разобранная в уроке про контекст, — поэтому эксперименты с уровнем безопасны: не понравилось, пересобрали. Порог копии без записи проверяет GetLevel(): собрали ветку с Warn — GetLevel вернёт WarnLevel, что дешевле разбора JSON в тестах конфигурации. Практический порядок такой: общий base задаёт writer и время, сублоггеры добавляют разметку, а точечные отклонения уровня или приёмника — уже поверх, на конкретных ветках. Глобальный SetGlobalLevel остаётся общим фильтром поверх всех локальных порогов, и это стоит держать в голове, когда ищете, почему модуль молчит. Если отклонений становится много, это сигнал не разветвлять дерево дальше, а возвращаться к единому приёмнику и фильтрации на стороне системы сбора: чем больше индивидуальных конфигураций, тем труднее ответить, куда вообще попадёт запись.

Сублоггер — тип-значение, и в горутины он уезжает копией: go func(l zerolog.Logger) {...}(authLog). Копия безопасна: writer общий, но писатели zerolog — os.File и stdout — рассчитаны на параллельные записи, а буфер события у каждой записи свой из sync.Pool. Копия логгера дешёвая — структура примерно на сотню байт плюс ссылка на общий writer и уже собранные байты контекста, — так что передача по значению в воркеры и горутины норма, а не расточительство. Никаких мьютексов на логгере держать не нужно, и это осознанный контракт zerolog: один writer на сервис, логгеров сколько угодно. Гонка возможна там, где её создаёт автор кода: перезапись глобальной переменной-логгера во время работы, о чём честно предупреждал урок про первый лог, — сублоггеры эту проблему не создают, если собираются один раз и дальше только читаются. Передавайте в горутину самый размеченный логгер из доступных: воркер очереди получает логгер модуля плюс идентификатор задачи в контексте, и все его записи самодостаточны, сколько бы задач ни крутилось параллельно. Глубокая проверка потокобезопасности — pprof и гонки — отдельная тема, ей посвящён урок про логи в горутинах, а здесь достаточно правила: собрал — раздал — не меняй.

Сублоггер — прикладной итог темы контекста: в уроке про Logger.With лежит механика With и порядок полей, здесь — дисциплина именования и конфигурация. Дальше по курсу: логирование HTTP покажет сублоггер-промежуточник, который размечает запросы request_id автоматически, а урок про тесты логов развернёт буферный приёмник из этого урока в целую методику проверки записей. Справочная задача на закрепление: соберите сервис с тремя модулями, один из них переведите на Warn и напишите тест, который ловит поломку подписи module. Если тест проходит на правильной конфигурации и падает на сломанной — вы освоили главный навык урока: разметка модулей проверяется машиной, а не глазами дежурного.