Контекст логгера: With и Named

logger.Named("billing") возвращает логгер, у которого имя «billing» попадает в каждую запись — в JSON его пишет ключ из EncoderConfig: NameKey, у production-энкодера это «logger». Имя — это иерархия через точку: Named у именованного логгера добавляет подскоп, billing.Named("repo") даст «billing.repo». Если логгер ещё не имел имени, первый Named становится корнем; два Named подряд складываются, не перезаписывают. Связка zap With Named — это то, что в англоязычных источниках зовут child loggers: контекст накапливается слоями, и каждый слой добавляет только своё. Зачем имя, если есть поле? Фильтрация в системах сбора: в Loki и Kibana выборка по имени логгера — операция первого класса, а поле service вам всё равно придётся ставить отдельным With, потому что имя логгера и имя сервиса — вещи разные: сервис один, модулей внутри много. На практике работают так: корневой логгер собирается при старте из конфига, и каждый пакет при инициализации создаёт себе именованного потомка — auth, billing, api, worker. В записи это выглядит как поле «logger» со значением «billing.repo» — и ночные расследования перестают быть археологией.

logger.With(fields...) — вторая половина контекста: возвращает логгер, который на каждую запись приклеивает переданные поля. Экономия видна сразу: вместо logger.Info("charge started", zap.String("service", "billing"), zap.String("module", "repo")) в каждом вызове — один раз base := logger.With(zap.String("service", "billing"), zap.String("module", "repo")) и дальше короткие Info и Warn. Но главное не удобство, а корректность: повторяющиеся поля, набитые руками в каждом вызове, рано или поздно расходятся — в одном месте забыли version, в другом опечатались в ключе, и одинаковые события перестали группироваться в системе сбора. With решает это структурно: контекст задаётся в одном месте. Иммутабельность при этом полная: With не меняет исходный логгер, а возвращает нового потомка; поля потомка не просачиваются к родителю и наоборот. Наследование накопительное: потомок получает всё от родителя плюс своё — с этим мы уже сталкивались в уроке про SugaredLogger, у которого есть собственные With и Named с парами ключ-значение вместо конструкторов полей.

Контекст накапливается слоями, и полезно видеть типовую схему целиком. Первый слой — приложение: метки app, version, env из InitialFields или опции zap.Fields живут в каждой записи с первого байта. Второй — модуль: Named-потомок при инициализации пакета, он же корень для всего его кода. Третий — операция: With-потомок в обработчике запроса, в обработчике сообщения из очереди, в вызове одного отчёта; у него общий идентификатор операции и, возможно, идентификатор пользователя. Четвёртый — точечные поля в самих вызовах Info: то, что относится к конкретной строке. Слои не мешают друг другу, потому что складываются: имя от Named сохранится через все With, поля операции дополнят метки приложения, а точечные поля лягут последними. Ошибка начинается тогда, когда слой пропускают: операцию логируют от корневого логгера — и записи теряются в общем потоке; или, наоборот, приложение пихает в каждый вызов поля второго слоя — и код обрастает повторами. Дисциплина слоёв — и есть та выгода, ради которой дешёвые потомки вообще придуманы.

На этом месте у бдительного читателя вспыхивает рефлекс: создание объекта на каждый запрос — дорого? В zap нет: With и Named не открывают файлов, не берут замков и не копируют энкодеры. Потомок — это копия маленькой структуры логгера: указатель на общее ядро плюс слайс полей контекста, который растёт на ваши несколько полей. Всё тяжёлое — ядро, энкодер, приёмники, сэмплер — общее и создаётся один раз. Поэтому здесь разрешено то, что в других библиотеках запрещено: заводить логгера на каждый HTTP-запрос, на каждую горутину-обработчик, на каждое сообщение из очереди. Что действительно дорого — создавать ЛОГГЕРОВ заново: zap.NewProduction или Build открывают приёмники и строят ядро; в двух местах программы — два набора открытых файлов и рассинхрон настроек. Правило простое: ядро и корневой логгер — один раз при старте, всё дальше — With и Named от него. С этим согласуется и Sync: вызов у потомка пробрасывается в общее ядро, поэтому дожидаться закрытия каждого дочернего логгера не нужно — достаточно корневого.

Дешевизна потомков подсказывает организацию, которая работает в проектах любого размера. Корневой логгер создаётся один раз при старте — из конфига, с метками приложения из урока про zap.Config. Каждый модуль при инициализации берёт себе именованного потомка и хранит его: пакет billing живёт с logger.Named("billing"), внутренние слои уточняют — Named("billing").Named("repo"). Дальше два варианта, и оба честные. Пакетная переменная: var log = базовый.Named(...) — удобно, но глобально: в тестах подменить труднее, а порядок инициализации пакетов становится незримой зависимостью. Структурный подход: логгер — поле структуры, которое прокладывается при конструировании, — стоит дороже в набивке кода, но продаёт себя в тестах и многомодульных сервисах. Третьего не дано: создавать логгер внутри каждой функции — потеря контекста и путаница с конфигурацией. Спорное мнение, к которому я пришёл: пакетная переменная допустима в прикладном коде конечного приложения, но библиотеку, которую читают чужие проекты, логгер обязан принимать параметром — навязывать свой logger чужому приложению невежливо.

Передача логгера через поле структуры — это dependency injection в его простейшей форме, и у неё три практических плюса. Первый — явность: Handler с полем log *zap.Logger видно в сигнатуре конструктора, зависимости не прячутся в глобальных переменных. Второй — тесты: в конструктор подсовывается наблюдатель из zaptest, и тест читает записи обработчика, не трогая stdout; тестируемость логов — тема отдельного урока курса. Третий — изоляция конфигурации: структура хранит контекстуализированного потомка, и никто внутри не знает про глобальные состояния. Глобальный zap.L — законная альтернатива для кода, куда логгер не протянешь: глубокие легаси-слои, сторонние обёртки, отладочный вывод в библиотечных хелперах; ReplaceGlobals делает его безопаснее, но глобальность остаётся глобальностью: тесты, параллельность и скрытые зависимости никуда не деваются. Мой рабочий баланс: прикладной код — поле структуры, межпакетные границы — Named-потомки, глобальный логгер — аварийный люк, а не архитектура.

Следующий уровень контекста — сквозной: request ID в логах порождает дочерний логгер на каждый HTTP-запрос, и приём With из этого урока превращается в middleware по образцу middleware Gin. Ошибки внутри модулей стоит прикладывать целиком, со стеком при необходимости, — этому посвящён урок про zap.Error и стек-трейсы. Карта курса — на странице курса.