Логи и метрики: путь к наблюдаемости

Ключ к связке — идентификатор, общий для всех сигналов. В трейсах это trace_id: hex-строка из 32 символов, которая живёт в span-контексте и путешествует между сервисами в заголовке traceparent. Логирующий middleware достаёт контекст пропагатором OpenTelemetry, берёт SpanContext и кладёт trace_id в логгер через With — дальше каждая запись запроса несёт его как обычное поле. Не путайте с request_id из урока про request id: тот генерируется вашим приложением для локальной хронологии, trace_id приходит из системы трассировки и соединяет сервисы между собой. В зрелом проекте живут оба: request_id отвечает за порядок внутри сервиса, trace_id — за путь между ними, и в записи они сосуществуют без конфликтов. Достаётся идентификатор строго из контекста: единственный источник правды — span, который принесла входящая цепочка, а не придуманное на месте значение.

Заголовок приходит от клиента, и пропагатор примет любой валидный по форме trace_id: не совпал с форматом — извлечение вернёт пустой контекст и сработает проверка IsValid; совпал — поле уйдёт в лог как есть. Это не уязвимость, а договорённость: trace_id — данные, а не доверенное значение, и фильтровать записи по нему безопасно только внутри одного инцидента. Практические следствия: маскировать поле не нужно — hex без секретов, но строить по нему авторизацию нельзя; длина фиксирована, раздуть запись им не получится; сервис, начинающий трейс первым, обязан генерировать новый идентификатор, а не принимать нулевой от клиента — IsValid и это ловит.

Логи в OpenTelemetry — третий сигнал рядом с трейсами и метриками: у SDK есть LoggerProvider, у API — запись с телом, уровнем и атрибутами. Прикладной код при этом не переписывается: есть мосты, которые берут записи у существующего логгера. Для zap такой мост — otelzap из contrib: он оборачивает ядро и пересылает записи в LoggerProvider, дальше их собирает коллектор и маршрутизирует в хранилище. Обратная дорога тоже есть: SDK умеет приписывать трейсовый контекст событиям лога, поэтому поле trace_id может прийти как от вашего With, так и от моста. Здесь обзор сознательно короткий: связка «SDK, коллектор, экспортёр» — отдельная дисциплина со своей документацией, и для первого знакомства достаточно локального Go, коллектора рядом и пары записей в консоль.

Полный лог каждого запроса — роскошь, которая на гигантском трафике превращается в отдельную статью расходов, и трейсы решают ту же задачу сэмплированием: head-сэмплер режет поток на входе по вероятности, tail-сэмплер в коллекторе отбирает интересные — с ошибками и большими латентностями. У zap своя механика прореживания: NewSamplerWithOptions пропускает первые N однотипных записей за тик и дальше одну на тик — именно она включена в production-пресет. Гранулярность у сэмплирования и трейсов разная: логи прореживаются по сообщению, трейсы — по запросу целиком; идеи родственные, слои разные, и одно не заменяет другое. Дропы стоит видеть: хук SamplerHook отдаёт метрику отброшенных записей, и её график — честная цена прореживания, а не абстрактное «что-то потерялось».

Связка уровней с алертами — договорённость, заключённая заранее, а не спонтанно в три ночи. Error — сигнал аварии: на него смотрит правило бёрста. Warn — подозрительное поведение: ретраи, рой 404, медленные запросы у порога; на Warn стреляет только накопительный сигнал, и канал — чат, а не пейджер. Fatal — процесс умирает, и алерт ставят на отсутствие сигналов: метрику живости, а не лог, потому что последняя запись Fatal до тёплой системы сбора может не доехать вовсе. Info — не сигнал, а материал: по нему считают трафик и долю ошибок. У такого контракта есть побочный эффект: ревью уровня записи становится ревью её цены в алертах, и вечные споры «Info или Warn» заканчиваются быстрее, потому что уровень теперь стоит денег.

Бывают события, у которых нет метрики: редкая ошибка интеграции, аномальный код ответа, сообщение уровня Fatal. Для них работают алерты по потоку логов: счётчик Error за окно, порог, окно тишины. Правило реакции простое: одиночная ошибка — не инцидент, бёрст — инцидент, и порог подбирается по истории, а не по желанию «наконец-то узнавать всё». Тонкая настройка — дедупликация: пятьсот одинаковых записей из одного цикла — это один инцидент, и алерт должен стрелять один раз; отпечаток собирают из имени сервиса, сообщения и ключевых полей. Полный конвейер — централизованное хранилище, правила поверх него и канал с эскалацией — тема следующего урока, а здесь важно направление: логи не только читают глазами, на них ещё и сигналят.

Наблюдаемость имеет смысл, когда есть цель. SLO фиксирует обещание уровня сервиса: например, 99,9% запросов списков задач отвечают быстрее 300 миллисекунд за месяц. Остаток — error budget, бюджет ошибок, который можно потратить на эксперименты и релизы. Метрики следят за бюджетом и триггерят разговор, когда он тает; логи — материал разбора, куда именно ушла доля. Из этого растут решения всего курса: Error — для аварий, Warn — для подозрительного, тишину в штатном сценарии проверяют тесты, сэмплинг экономит бюджет хранения. Алерты на каждую запись Error ломают модель: доля ошибок — дело бюджета, а не каждой строчки. Дежурный просыпается на тренд, а не на единичный сбой, и тем самым сохраняет способность вообще просыпаться на настоящие аварии. Отсюда и отказ алертить каждую строчку: строчка — материал, тренд — сигнал.

Хранение, поиск и полный конвейер алертов — тема урока про эксплуатацию: там Loki и ClickHouse разбираются по одной строке и появляются retention и 152-ФЗ. Прореживание потока в цифрах — урок про сэмплирование, разделение request_id и trace_id — урок про request id. Карта курса — на странице курса zap.