Встроенные middleware: Logger, Recoverer, RequestID

middleware.RequestID достаёт идентификатор из заголовка X-Request-Id, а если его нет — генерирует свой: префикс с именем хоста и случайной строкой плюс счётчик запросов. Идентификатор кладётся в контекст запроса, откуда его достаёт middleware.GetReqID(r.Context()) — из любого middleware ниже по цепочке. Зачем это нужно: одна пользовательская операция в распределённом сервисе порождает запросы к нескольким службам, и общий id — единственная ниточка, по которой журнал одной службы сшивается с журналом другой. Прокладка простая: балансировщик генерирует X-Request-Id, chi на входе его переиспользует, ваши слои логируют тот же id. Когда что-то сломалось, поддержка первым делом запрашивает идентификатор запроса — и вторым делом советует печатать его в ответах об ошибках. Logger и Recoverer из этого пакета подхватывают id автоматически — но только если RequestID стоит в стеке раньше них; к порядку вернёмся после знакомства со слоями.

За nginx или HAProxy все запросы приходят с адресом прокси: r.RemoteAddr показывает 127.0.0.1, и лимиты по IP, гео-фильтры и статистика работают с одним и тем же «клиентом». middleware.RealIP смотрит на заголовки True-Client-IP, X-Real-IP и X-Forwarded-For — в этом порядке — и подменяет r.RemoteAddr на найденный адрес, после чего вся цепочка видит реального клиента. У слоя тяжёлая оговорка, которую chi теперь пишет прямо в коде: middleware помечен как deprecated. Причина — подмена адреса: заголовки слепо верят отправителю, и клиент без прокси может выдать себе любой X-Forwarded-For. Свежие версии chi предлагают семейство ClientIPFrom* с явным списком доверенных прокси и чтение адреса через GetClientIP. Для действующих проектов с nginx спереди RealIP остаётся рабочим, но правило неизменно: слой ставится только там, где перед сервисом стоит прокси, которому вы доверяете.

middleware.Logger печатает строку на каждый завершённый запрос: время, [request id], метод и адрес в кавычках, источник — from, затем статус, размер ответа в байтах и длительность; в терминале статус покрашен. Строка собирается после выполнения цепочки: Logger оборачивает ResponseWriter, запоминает статус и размер, а печатает всё разом в defer — поэтому в лог попадают и ранние ответы из middleware, и 500 от Recoverer. Для разработки это идеальный инструмент: включил — и видишь всё. В продакшене текстовых строк быстро перестаёт хватать: их нельзя фильтровать по уровню и полям, а поиск по десяткам сервисов превращается в grep-марафон. Стандартное движение — структурный логгер: в курсе zap этому посвящён урок про HTTP-middleware, где chi-стек соединяется с zap. Logger остаётся для консоли и стендов, структурный логгер — для централизованных журналов.

Паника в Go не перехватывается между горутинами: то, что упало внутри хендлера, убивает весь процесс — вместе с сотнями обрабатываемых запросов. middleware.Recoverer разрывает сценарий: в defer слой ловит recover(), печатает стек в журнал и отдаёт клиенту 500 Internal Server Error. С Logger в стеке стек-трейс попадает в общий журнал запросов, без него — на stderr в виде раскрашенного стека. Клиент получает честный 500, а не обрыв соединения, и мониторинг видит ошибку в статус-кодах. Деталь из исходников: панику http.ErrAbortHandler Recoverer сознательно не перехватывает — это сигнал net/http «оборвать соединение», и мешать ему нельзя. Recoverer — предохранитель, а не исправление: данные могли быть записаны наполовину, транзакция брошена. Правильная реакция на 500 из паники — починить код, который её вызвал, а не радоваться живучести.

Порядок r.Use(a, b) — это путь запроса из прошлого урока, и для боевого стека chi фиксирует рекомендации в исходниках. RequestID первым: идентификатор должен лежать в контексте до того, как Logger соберёт строку, — тогда в каждой записи есть [id]. RealIP до Logger: иначе в логе адрес прокси, а не клиента. Logger раньше Recoverer — контринтуитивно для привыкших, что recovery ставят первым слоем, но у chi расчёт на то: Recoverer, поймав панику, пишет 500 в обёрнутый Logger-ом ResponseWriter, и строка лога показывает 500, а сам стек паники уходит в общий журнал через запись, которую Logger положил в контекст. Поменяйте местами — клиент всё равно получит 500, но строка лога покажет 200: обёртка не видела записи статуса. Recoverer замыкает стек — ближе всего к хендлерам, где паники и рождаются.