Итоговый проект: наблюдаемость сервиса

Всё начинается с конфига, потому что от него зависит каждая следующая деталь. Пресеты NewDevelopment и NewProduction годились для первых уроков, но observable-tasks живёт в трёх средах — ноутбук, staging, прод — и различается уровнем, форматом и приёмником. Решение из урока про zap.Config: базовый пресет плюс переопределение из переменных окружения. LOG_LEVEL задаёт стартовый порог, LOG_ENCODING выбирает json или console, LOG_PATH указывает файл для lumberjack или stderr по умолчанию, DB_SLOW_THRESHOLD настраивает порог медленного SQL, APP_ENV подписывает записи средой. Ключевая мелочь, на которой всё держится: loadConfig возвращает пару zap.Config и zap.AtomicLevel — тот самый ссылочный уровень из урока про динамические уровни. Логгер соберётся на нём, а переменная уйдёт в ручку смены уровня, и порог на живом процессе станет штатной операцией, а не хаком. Один и тот же приём env() читает и DB_SLOW_THRESHOLD при сборке моста GORM — конфигурация сервиса имеет один вход. Среды различаются только значениями: на ноутбуке LOG_LEVEL=debug и stderr, в staging — info и файл, в проде — info и файл под агентом; код при этом один и тот же.

Правило сборки цепочки одно: посредник, создающий контекст, всегда снаружи посредника, который его потребляет. request id из урока 14 генерирует идентификатор, кладёт поле request_id в логгер и прячет потомка в контекст — значит, он первый. Access-лог из урока 15 достаёт логгер из контекста, замеряет время и пишет запись по статусу: 5xx — Error, 4xx — Warn, остальное — Info, и правило живёт в одном switch, а не по всему проекту. Recovery идёт внутри access-лога: паника гасится до него, ответ получает 500, и запись access-лога честно покажет статус аварии рядом с request_id. Шумные ручки глушатся не посредником, а сэмплером ядра: /healthcheck ходит каждую секунду с одним и тем же сообщением, и NewSamplerWithOptions прореживает его до пары записей в тик — это урок 11, применённый по назначению. Цепочка короткая, но порядок в ней решает всё: переставьте два звена, и access-лог пойдёт без идентификатора. В поля access-лога уходят method, path, status, latency и client — минимум, по которому ищут и строят графики латентности из прошлых уроков.

Слой данных получает двух говорящих. Первый — мост GORM из урока 16: LogLevel Warn, SlowThreshold из конфига, IgnoreRecordNotFoundError true, чтобы ErrRecordNotFound не превращался в Error-алерт. Мост пишет slow sql с полями elapsed и threshold — это прямой материал для алерта на долю медленных запросов из прошлого урока. Второй говорящий — сам репозиторий: логгер достаётся из контекста через LoggerFromContext, значит, каждая запись несёт request_id без единого лишнего аргумента. При ошибке — Error с контекстом из урока 18: With добавляет task_id и took, рядом zap.Error с исходной ошибкой, и по записи можно ответить на вопрос «что упало и в каком запросе», не поднимая код. Ноль затронутых строк при апдейте — не ошибка, но подозрительное поведение: Warn с task_id, канал — чат, не пейджер. Разница между «не получилось» и «такой задачи нет» стоит двух уровней, и в разборе инцидента именно она экономит вечер. IgnoreRecordNotFoundError заслуживает отдельного слова: NotFound в API — штатный ответ, и превращать его в Error — значит кормить алерты обычным трафиком.

main собирает всё в одном месте, и каждая строка там — ссылка на урок. Приёмник: stderr по умолчанию, а при заданном LOG_PATH — lumberjack с рабочими параметрами: MaxSize 100 МБ до ротации, пять бэкапов, хранение тридцать дней; механика из урока 09 съедает диск по расписанию, а не по факту падения. Пятый параметр, Compress, жмёт архивы gzip-ом: тот же MaxAge вмещается в заметно меньший объём. Ядро: JSON-энкодер, приёмник, атомарный уровень — и сверху NewSamplerWithOptions со схемой 100/100: первые сто однотипных записей за тик проходят, дальше по одной за тик; /healthcheck и циклы ретраев перестают топить поток, а уникальные сообщения проходят всегда. Ручка /internal/loglevel получает атом и логгера: каждая смена уровня логируется — кто и с какого уровня на какой перешёл, — порог возвращается после расследования. Ни один из этих кусков не нов — новым является только их порядок, и порядок этот продиктован зависимостями: конфиг до логгера, логгер до цепочки, цепочка до ListenAndServe.

Требования из первого блока проверяются тестами, а не верой. Из урока про zaptest берётся observer.New(zapcore.InfoLevel): ядро подставляется в сборку логгера вместо боевого, код под тест гоняет настоящий zap.Logger, а тест читает записи как объекты. Три теста закрывают контракт: запрос с паникой даёт Error со статусом 500 и полем request_id; несуществующий путь даёт Warn; /healthcheck за один тик оставляет не больше сотни записей — контракт сэмплера. FilterMessageSnippet и FilterField делают проверки читаемыми: сначала по сообщению, потом по полю, Len после фильтра — ассерт количества. Тест живёт рядом с хендлерами: buildLogger принимает ядро параметром, и подмена боевого ядра на наблюдателя — одна строка в подготовке теста, а не хак. Полный разбор приёмов — в уроке Тестирование логов: zaptest и observer. Прогон — go test на локальном Go, в CI ставится так же без изменений. Ниже — чеклист, с которым observable-tasks выходит в прод; по нему же проверяется любой сервис, который вы соберёте после курса.

Если observable-tasks отвечает на запросы, пишет по договорённости и не падает под curl — курс пройден, и это не фигура речи: от первого NewDevelopment до этой цепочки в main вы собрали полный прикладной стек. Честное поздравление: до финального проекта доходят не все, у вас получилось. Сам проект остаётся у вас: он ровно настолько живой, насколько вы его запускаете и дорабатываете. Дальше два естественных продолжения. Админ-CLI — команды tasks-admin loglevel и tasks-admin rotate из терминала — делает курс Cobra: там cmd/ и internal/, сигналы и версии через goreleaser. TUI-дашборд по хвосту логов — курс Bubble Tea: список, фильтры и статус-бар на тех же записях. Карта всех уроков — на странице курса zap — останется под рукой, когда понадобится освежить конкретную деталь.