Эксплуатация: хранение, поиск, алерты

Каноничный конвейер устроен по принципу разделения труда. Приложение пишет JSON в stdout или файл — OutputPaths из урока про выводы, — и на этом его ответственность кончается. Дальше работает агент на хосте: Vector или Fluent Bit читают поток, разбирают JSON и пересылают батчами в хранилище. Разделение не случайное: приложение не платит за сетевые ретраи и не держит очередь в памяти, backpressure живёт в агенте, который для этого и сделан. Vector — конвейер на Rust с конфигом из трёх ролей: source забирает хвост файла, transform выравнивает поля, sink отправляет в назначение. Fluent Bit — лёгкий агент с теми же ролями, стандарт де-факто на узлах Kubernetes. Хранилище выбирают под запросы. Loki индексирует только метки и жмёт тело чанками — дёшево и сердито. Elasticsearch из стека ELK строит инвертированный индекс по всему тексту — дорого, зато полнотекстовый поиск. ClickHouse — колоночная СУБД, где каждое JSON-поле становится колонкой, а поиск — обычным SQL. Конвейер целиком потрогать можно и на ноутбуке: локальный Go, docker compose с агентом и Loki — честный способ увидеть поиск до прода.

Конвейер выгоден ровно настолько, насколько структурны ваши записи. JSON-энкодер выравнивает каждое поле в ключ верхнего уровня, и агент отдаёт хранилищу готовые метки: service, level, request_id, status. Поиск «ошибки сервиса tasks за полчаса с таким request_id» становится запросом по индексу, а не сканом текста: цепочка, как в уроке про request id, собирается одним кликом. Отсюда правило для полей: то, по чему вы собираетесь искать, должно быть колонкой, меткой или термином индекса, а не куском сообщения. Тонкое место — кардинальность. Метка с миллионом разных значений раздувает индекс и замедляет запросы: user_id в качестве метки Loki — классическая ошибка, после которой индекс оказывается толще самих логов. Я больше не кладу идентификаторы сущностей в метки после одного месяца с раздутым индексом: идентификатор живёт в теле записи или в колонке ClickHouse, где высокая кардинальность обходится дешевле. Метки — для малого набора: сервис, окружение, уровень.

Как это выглядит руками дежурного. Пришла страница «бёрст Error в tasks». Первый запрос — по меткам: service=tasks, level=error, последние пятнадцать минут; ответ — сотни записей, и их сужают полями: конкретный хендлер, конкретный код ответа. Второй запрос — по request_id из первой подозрительной записи: он вытаскивает всю цепочку запроса — access-лог, slow sql из моста GORM, запись об ошибке с полем error. Третий — по сообщению или его фрагменту, когда симптома ещё не знаешь и ищешь похожие строки за прошлые сутки. Именно на третьем шаге становится видно, почему формат записи стоит держать стабильным: сообщение — это тоже поисковый ключ, и переформулировка «не удалось обновить» вместо «update failed» ломает сохранённые запросы дежурных. Поля ищутся, сообщение ищется, время фильтрует — этих трёх средств хватает на девять из десяти разборов без какого-либо парсинга.

Retention — политика срока жизни: что удаляем, что сжимаем, что отдаём в архив. Рабочая схема — три слоя: горячие данные за последние семь дней на быстром диске с полным индексом, тёплый слой до тридцати дней со сжатием, архив до года на дешёвых томах, куда ходят только по запросу безопасности. Сроки — не эстетика: 152-ФЗ и внутренние регламенты фиксируют, сколько живут записи с персональными данными, и удерживать их дольше — риск, а не запас. Стоимость считается на салфетке: суточный поток, сжатие, цена гигабайта, дни. JSON жмётся в пять-десять раз — цифры условные, свои замерьте. Второй рычаг дешевле любого диска — писать меньше: сэмплинг из урока про прореживание, дисциплина уровней и отказ от логирования тел запросов режут поток на входе, и каждый несохранённый гигабайт не нужно ни хранить, ни архивировать. Для файлов на самом хосте та же математика в меньшем масштабе: ротация lumberjack с MaxAge и есть локальный retention, пока централизация не выросла. В Loki и ClickHouse срок жизни настраивается правилами TTL: хранилище само удаляет или перекладывает партиции по возрасту — политика живёт в нём, а не в cron-скрипте.

В логи просачивается то, что закон запрещает хранить без нужды: пароли, токены, номера карт, паспорта, история болезней. 152-ФЗ в России и GDPR в Европе требуют минимизации данных: собирать ровно столько, сколько нужно для цели, и держать не дольше срока этой цели. Минимизация — не про юридический страх, а про цену ошибки: утёкший лог с токенами — инцидент безопасности, утёкший лог с request_id — просто лог. Порядок обороны идёт от дешёвого к дорогому. Первая линия — не логировать вовсе: конвенция команды и ревью, где поле password просто не имеет права появиться. Вторая — маскировать при записи: в месте формирования поля значение заменяется звёздочками или хвостом из четырёх символов. Третья — последняя линия: обёртка WriteSyncer, прогоняющая готовую строку через маскирование на выходе. Обёртка спасает и от чужих ошибок в старом коде, но регэксп на каждой записи не бесплатен: меряйте цену, прежде чем вешать её на нагруженный сервис.

Хранилище без алертов — архив, куда ходят по праздникам. Алерты по логам строятся на трёх приёмах — и на четвёртом, без которого первые три бессмысленны ночью. Первый — Error-бёрст: правило считает записи уровня error за окно и стреляет только после порога с фазой ожидания; одиночная ошибка — не инцидент, серия — инцидент, порог подбирается по истории. Второй — латентность: zap.Duration пишет числовое поле, и по нему считается доля запросов медленнее порога; алерт ставят на долю — «больше одного процента запросов дольше 300 мс», а не на каждую медленную запись. Третий — дедупликация: пятьсот одинаковых ошибок одного цикла — один инцидент, и алерт выстреливает один раз; отпечаток собирают из сервиса, сообщения и ключевых полей. Четвёртый — runbook: в аннотации алерта живёт ссылка на инструкцию — что проверить, как откатить, кому звонить. Алерт без runbook — загадка в три часа ночи, и дежурный, однажды решивший её в одиночку, перестанет верить всем вашим правилам. Отсюда привычка ревизии: раз в квартал команда проходит по правилам и удаляет те, что не сработали ни разу.

Разметка полей под поиск проектируется до первого инцидента, потому что задним числом её не добавить: старые записи останутся без новых колонок. Минимальный набор для сервиса: service с именем приложения, env с окружением, level, request_id и поле компоненты — http, repo, scheduler. К нему добавляются доменные идентификаторы: task_id, order_id, user_id в теле записи — что угодно, по чему поддержка найдёт историю конкретного клиента. Чего закладывать не стоит — полей на всякий случай. Каждое поле — это байты на каждой записи и ещё одна колонка в хранилище; поле, которое никто не ищет, дороже своего отсутствия. Рабочий приём — ревью полей вместе с алертами: если поле фигурирует в правиле или в рантбуке, оно обязано быть; если нет — вопрос, зачем оно вообще. Так набор остаётся коротким годами, а поиск остаётся быстрым, потому что индекс не разросся от щедрости.

Сбор, поиск, retention, маскирование, алерты — эксплуатационный контур собран, и осталась одна вещь: сложить весь курс в один сервис. Итоговый проект — урок 25 — делает это на observable-tasks: HTTP-сервис, где конфиг из окружения встречается с цепочкой посредников, GORM с сэмплером, а тесты observer с чеклистом запуска. Карта всех уроков — на странице курса zap.