Итоговый проект: логгер для HTTP-сервиса

Модуль логирования в сервисе состоит из трёх файлов и не растёт дальше без причины. Конструктор NewLogger собирает уровень из окружения, обработчик и дефолт — единственное место, где появляется slog.NewJSONHandler. Middleware ставит поля запроса и пишет итоговую запись. Вспомогательные функции — parseLevel, levelByStatus, newRequestID — чистые и потому тестируются без HTTP. Всё остальное — конвенции, а не код: какой уровень у бизнес-отказа, где живут err и kind, что попадает в лейблы метрик, а что в записи. Карта решений ниже связывает каждое из них с уроком курса: при разборе инцидента или онбординге нового разработчика ссылка «почему так» важнее строк кода. Из работ с логами в проекте сознательно нет файла: логи едут в stdout, и это решение шестнадцатого урока, — ротация и место на диске остаются платформе.

Набор полей middleware — предмет споров в каждом втором проекте, поэтому короткая расшифровка. request_id — ключ склейки записей запроса, из пятнадцатого урока; при подключении трейсера рядом появляется trace_id из двадцать второго, middleware не меняется — добавляется один With. route — путь шаблона, а не фактический URL: иначе значения параметров раздувают кардинальность поля, о чём говорили семнадцатый и двадцать первый уроки. status и duration_ms — пара, по которой строится и поиск медленных запросов, и график; уровень итоговой записи выбирает дежурный, и levelByStatus — его семантика в коде. Логгер кладётся в контекст через withLogger: глубинные функции пишут записи с полями запроса, не зная про middleware. Конструктор при этом не паникует на битой переменной уровня — Warn-запись и дефолт: старт сервиса важнее, а молчать об опечатке нельзя. Честная граница: паника в обработчике гасит итоговую запись, поэтому recovery ставится выше middleware логов — об этом ниже.

Middleware отвечает за периметр, а записи внутри сервиса держит конвенция, которую курс собирал по урокам. Ошибки хранилища и внешних вызовов пишутся на Error с err в поле — оборачивание через %w, детали из одиннадцатого урока. Бизнес-отказы — на Warn с kind из классификации: заказ не оплачен из-за нехватки средств — это не сбой сервиса, и Error тут был бы спамом уровней из двадцать третьего урока. События — на Info с полями, по которым ищут: order, user_id, kind. Отладочные детали — на Debug, и прод-уровень их отсекает. Маскирование подключается в конструкторе: ReplaceAttr с картой чувствительных ключей и тип Token с LogValue из девятнадцатого урока — тест на маску в проекте обязательный, потому что секреты уезжают в хранилище молча. Метрики ошибок инкрементятся рядом с записью — пара из двадцать первого урока, — и лейблы держат только малые наборы.

Проект считается готовым, когда логи проверяются тестами из двадцатого урока. Первый тест — маскирование: фикстура с токеном проходит через логгер, в буфере маска, а не значение. Второй — поля запроса: после запроса в буфере есть request_id, route, status, duration_ms, и уровень итоговой записи соответствует статусу. Третий — отсутствие записей Error в штатном сценарии: успешный запрос не пишет ошибок, и регресс ловится в CI. Четвёртый — уровень: таблица статусов против levelByStatus. Сбор проверяется руками: сервис под journald или в контейнере, journalctl -u и docker logs показывают те же записи, что и буфер теста — это связка двадцать четвёртого урока. Приёмка завершается чек-листом ниже: он короткий, и каждый пункт из него когда-то был инцидентом в чужом проекте.

Мнение, которое стоит оспорить на старте проекта: логирование надо спрятать за своим интерфейсом, чтобы когда-нибудь сменить логгер. За: интерфейс Logger с методами Info и Error ограничивает поверхность и упрощает моки в тестах. Против: slog — стандартная библиотека, и смена на что-то другое — гипотетическая цена; обёртка теряет механику: Enabled до сборки полей из четырнадцатого урока, LogValuer, группами и With-копиями из восьмого. Практика обёрток тоже честно печальна: в каждом втором проекте своя обёртка, и каждая со своими особенностями. Компромисс проекта: slog.Logger живёт в коде напрямую, без посредников; обёртка уместна на одной границе — доменный фасад, который публикует бизнес-события, и под ней уже slog. Граница по тестам: тесты логов пишутся на Handler и буфер, а не на мок интерфейса — буфер проверяет то же, что увидит прод.