Миграция с log на slog: мосты и совместимость

Первый мост уже знаком по шестому уроку: slog.SetDefault перенаправляет логгер пакета log в ваш обработчик, и все log.Print, log.Printf и log.Println после этого попадают в общий поток на уровне Info, текстом в поле msg. Это мост нулевого дня: один вызов в main — и разнородные строки сервиса уже собираются в одном JSON, ещё до первой правки чужого кода. Второй мост работает в обратную сторону: slog.NewLogLogger(handler, level) возвращает настоящий log.Logger, который пишет записи через заданный обработчик на заданном уровне. Он нужен там, где API требует именно log.Logger: поле ErrorLog у http.Server, конструкторы шаблонов, внешние библиотеки с параметром старого типа. Вы передаёте им мост, и их строки становятся структурными записями уровня Error — без правки самой библиотеки. Третий мост — собственный код: вызовы log в вашем слое заменяются на slog слой за слоем, и это уже не мост, а переезд, у которого ниже будет свой план. Разбор перехода на slog стоит начать с первых двух: они дают результат в первый же день.

Замена вызовов механична, если под рукой есть таблица соответствия. Прямые переезды очевидны: log.Print и log.Println превращаются в slog.Info с одним сообщением, log.Printf — в slog.Info с fmt.Sprint-склейкой или, лучше, с настоящими атрибутами: раз уж переписывается вызов, время разложить fmt.Sprintf("подключение к %s", host) на два поля. Сложнее с парой Fatal: log.Fatalf печатает запись и завершает процесс кодом один, а slog.Error только печатает — выход нужно дописать руками. Обёртки log.New со своим writer переезжают на slog.New с обработчиком, а для чужого API, требующего log.Logger, остаётся NewLogLogger. Отдельно про место вызова: если в проекте есть хелпер с log.Output(2, msg) ради правильного имени файла в выводе, при переезде на slog вычислять глубину не нужно — место вызова достаёт Handler через AddSource. Таблица ниже закрывает большинство кодовых баз; остальное решается по месту с той же логикой.

Собственный код переезжает не по файлам, а по слоям, и порядок здесь такой же, как у зависимостей. Сначала транспорт: HTTP-обработчики и middleware — они чаще всего пишут, и именно здесь логгер на запрос из восьмого урока даёт мгновенный прирост. Затем слой логики: бизнес-операции с настоящими атрибутами вместо Printf-склеек. Утилиты и обёртки переезжают последними, потому что на них держится меньше всего контекста. После каждого слоя проект собирается, запускается и логируется целиком: старые строки через мост, новые через обработчик, общий формат один. Готовность проверяется поиском: в собственном коде не остаётся вызовов log, кроме мостов для чужих API, а grep по log.Print по пакетам проекта возвращает пустоту. Про инверсию — когда свою библиотеку требуется отдать наружу с API на log.Logger — снова выручает NewLogLogger: внутри библиотека живёт на slog, наружу отдаёт мост. Такой план не требует заморозки релизов: слои мигрируют между обычными задачами, а продуктовый поток не замечает переезда.

Финал миграции — не последний правленный файл, а список проверок. Первая: формат — все строки сервиса в одном выводе, и текстовые строки с датой в стиле пакета log больше не появляются ни в stdout, ни в stderr; их ловит простой скрипт по суффиксу формата. Вторая: уровни — записи, переехавшие как Info, размечены заново там, где на самом деле были ошибки; мост пишёт всё на Info, и часть Error-событий легаси-кода первое время живёт на уровне Info — это приемлемо на переходном этапе, но размечается в бэклоге. Третья: Fatal-пути — каждое место с выходом из процесса проверяется битым конфигом и недоступной зависимостью. Четвёртая: тесты из двадцатого урока — захват вывода в память и утверждения по полям работают и для мостов, потому что мост пишет через тот же Handler. Пятая: дашборды — фильтры по полям не опустели после смены путей, как это случалось с группами в седьмом уроке. Этот же чек-лист пригодится позже, когда сервис переедет на прод-настройки из восемнадцатого урока.