Логи для сбора: поля для Loki и ELK

Каждая запись JSONHandler несёт три служебных поля: time в RFC3339 с миллисекундами и зоной процесса, level строкой вроде INFO или ERROR и msg с сообщением, а дальше — атрибуты плоскими полями. Этой схемы достаточно конвейеру для базы: время даёт порядок и графики, уровень — фильтры и алерты, сообщение — контекст для человека. Системы различаются подробностями. Loki хранит записи потоками по лейблам и парсит поля в момент запроса, поэтому важна кардинальность лейблов: уникальные значения вроде request_id в лейблы не кладут. Elasticsearch складывает записи как документы и индексирует каждое поле, поэтому важна стабильность имён: каждое новое имя поля попадает в mapping индекса. Уровни по умолчанию печатаются в верхнем регистре — INFO, ERROR — и часть конвейеров ожидает нижний: это поправимо на стороне приложения через ReplaceAttr, и менять лучше у источника, чтобы конвенция была видна в коде и в ревью. Время записывается в зоне процесса: контейнер живёт в UTC, машина разработчика — в локальной зоне, и разнобой зон в одном хранилище стоит исправить на старте, а не во время инцидента.

В хранилище логов десятки сервисов пишут в один поток, и без общих полей записи неразличимы. Минимальный набор идентичности собирается один раз на старте: service с именем сервиса, env с окружением, version с версией сборки — всё через logger.With, чтобы каждое поле стояло в каждой записи без повторения в вызовах. Сквозные поля запроса добавляются логгером на запрос: request_id из middleware, идентификатор пользователя, имя обработчика — механика разбиралась в уроке про With и в уроке про request ID. Имена полей — договорённость, а не истина: часть команд живёт в snake_case, часть в camelCase, и оба варианта работают, пока выбор одинаков во всех сервисах компании. Служебные имена трогать без нужды не стоит: msg, level и time знакомы каждому конвейеру, а переименование через ReplaceAttr добавляет ещё одно место, где записи расходятся с примерами документации. В ELK существуют и зарезервированные имена вроде @timestamp — маппинг msg и time на них настраивается на стороне конвейера, и это ещё один аргумент за стабильную схему: чем меньше сюрпризов в именах, тем проще конфиг сбора.

Коллекторы режут поток по строкам: одна строка — одна запись. Встроенные обработчики slog держат контракт: переносы внутри значения экранируются — JSONHandler превращает их в \n внутри строки JSON, TextHandler закавычивает значение целиком, — и запись остаётся однострочной. Ломается там, где строки пишет не Handler. Первое место — паники Go: рантайм печатает стек в stderr сам, мимо slog, отдельными строками, и каждая строка становится независимой записью без msg, уровня и полей. Второе — легаси-пути через fmt.Println и log.Printf, куда уезжает ошибка со стеком через %+v: та же расползшаяся запись. Третье — собственный Handler без экранирования значений. Решение у всех трёх общее: многострочное значение логируется полем, а не печатается напрямую, а паника ловится recover-обёрткой и логируется slog.Error со стеком в поле — обработчики сами позаботятся об экранировании. Тогда запись со стеком остаётся одной строкой, поиск находит её целиком, а счётчик ошибок не завышается кадрами стека.

Мнение, которое стоит оспорить на ретро: схема полей — дело конвейера, а приложение должно печатать минимум и не знать про сбор. За конвейерную позицию: коллектор видит метаданные окружения — pod, namespace, образ — и добавляет их без единой строчки кода; переименование полей для конкретного хранилища делается в конфиге парсера. Против: схема размазывается между кодом и конфигом, и вопрос «почему в записи нет service» ведёт сначала в конфиг promtail, потом в код; тестировать сборку полей на стороне коллектора сложнее, чем в Go-тестах из двадцатого урока; а переезд конвейера выносит схему на переписывание заново. Компромисс, который прижился: идентичность и смысл — в приложении, инфраструктура — на коллекторе. service, env, version, request_id и бизнес-поля кладёт код, потому что их никто, кроме кода, не знает; pod, namespace и метки платформы добавляет конвейер, потому что у него они уже есть. Ошибка обратного рода — дублировать одно и то же поле на обеих сторонах с разными значениями: разнобой в схеме найдётся только на дашборде, когда графики перестанут сходиться.