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

Grafana выпустила Workflows и расширила Adaptive Telemetry, Sentry объяснил разницу между логом и метрикой, OpenTelemetry поменял правила версий ради безопасности, а в блоге CNCF показали, как урезать телеметрию AI-помощника в коде. Всё это написано для команд с десятками сервисов. Вопрос «что писать в журнал, а что считать» стоит и перед системой на одном сервере, и владельцу бизнеса полезно знать, за что он платит в мониторинге.

Что вышло

Grafana Labs 21 октября представила Grafana Workflows в публичном preview: процесс команды превращается в автоматические шаги. Шаблон major incident kickoff создаёт канал в Slack, находит дежурного командира по расписанию, закрепляет runbook и пишет в таймлайн инцидента. Шаг ask Assistant просит их модель собрать сводку по инциденту и отделить наблюдения от гипотез. Шаблон on-call handoff report при смене дежурного собирает отчёт по инцидентам за неделю.

Днём раньше, 20 октября, Grafana описала, как Adaptive Telemetry отвязывает счёт от объёма данных. Для трасс: volumetric sampling делит бюджет выборки между сервисами и, по их тестам, даёт примерно на 25 % больше полезной информации, чем случайная выборка того же объёма, а отброшенные трассы 24 часа доступны по ID. Для логов: правила отбрасывания применяются прямо на коллекторах, а то, что жалко терять, уходит в ваше дешёвое объектное хранилище с возможностью вернуть обратно.

Sentry 22 октября ответил на вопрос, когда нужен лог, а когда метрика. Формулировка у них короткая: логи для отладки, метрики для анализа. Лог фиксирует, что было правдой в момент события, чтобы потом восстановить картину; метрика нужна там, где есть число, за которым следят во времени, даже когда всё в порядке. Трассы сэмплируются, логи и метрики нет.

OpenTelemetry 22 октября обновил политику версий: стабильные SDK и компоненты Contrib теперь могут менять поведение ради безопасности в минорных и патч-релизах, публичный API при этом не трогают, а release notes обязаны объяснить, что менять в конфигурации.

Самый практичный текст недели: CNCF 22 октября показала, как фильтровать телеметрию AI-помощника в коде через OpenTelemetry Collector. Одна небольшая задача для Claude Code дала 181 запись и 289 КБ JSON. Автор выписал шесть вопросов: стоимость по моделям, токены, какие инструменты падают, где задержка, что сломалось. На все отвечают счётчики и короткие атрибуты, а тела файлов и промпты только занимают место. Дальше конфигурация коллектора: отбросить событие api_request, это около четверти записей, удалить шесть атрибутов, захешировать идентификаторы и обрезать хеш до 16 символов, потому что полный SHA256 длиннее UUID и после первого прогона объём логов вырос.

Зачем это бизнесу

Возьмём теплицу, где насосы и полив ведут контроллеры. Можно писать в журнал каждое показание каждого датчика текстом. Через полгода журнал весит гигабайты, а ответа на вопрос «почему вчера в три ночи не включился насос» в нём нет: строка про насос утонула среди показаний температуры. Правильнее наоборот: уровень воды и температура это метрики, по ним строится график и порог для уведомления, а момент, когда насос получил команду и не ответил, это лог с причиной.

Вывод: наблюдаемость измеряется числом вопросов, на которые можно ответить. Если ни один график и ни одно уведомление не читают поле, за его хранение вы платите зря.

Как это устроено у меня

С PDR-компанией в США я работаю с 2021 года и инфраструктуру мониторю сам: сервер на Debian в Google Cloud, VPN, сетевое оборудование и телефонию. Grafana Workflows там не нужны, дежурный один, и это я. Зато в 2025 году я вывел TV-борд на 4 телевизора в компании, на каждом своя доска: для собственника, для производства по заказам, для фронт-деска и для продавцов. Для бизнеса это те же метрики, что инженер смотрит в дашборде. Leaderboard считает сотрудников по 15 показателям. А запись каждого звонка и AI-разбор, кто и зачем звонил, это лог в терминах Sentry: по нему восстанавливают, что произошло с конкретным клиентом.

На гидропонной ферме, где я с 2023 года отвечаю за сервер, сеть и связь с контроллерами, данные с 25 контроллеров на двух площадках приходят в одну базу MariaDB на сервере. Что хранить как историю, а что считать сводкой, решает другая команда, которая делает логику автоматизации и интерфейс. Моя часть: чтобы данные доходили.

AI-помощник в коде у меня тоже есть, он берёт рутину, тесты и отладку. Его телеметрию в коллектор я не заводил, но порядок из статьи CNCF правильный: сначала вопросы, потом поля.

Что я бы сделал

Выписать пять вопросов, на которые система должна отвечать. Например: сколько заявок пришло сегодня, когда последний раз отвечал контроллер, сколько стоит AI-разбор за день.

Под каждый вопрос решить: это число во времени или событие с контекстом. Число становится метрикой с порогом. Событие становится логом с полями, по которым его найдут: ID заявки, клиент, причина.

Остальное не собирать: тела документов и полные ответы моделей в логах не нужны, достаточно их длины и статуса.

Раз в квартал смотреть, какие поля никто не читал, и убирать их или складывать в дешёвое хранилище, как предлагает Grafana.

Про фоновые задачи и повторы, которым логи нужны чаще всего, я писал в статье Воркеры: фоновые задачи и повторные попытки. Направления: инфраструктура, которую можно выпускать и восстанавливать и мониторинг оборудования и уведомления. Кейсы: технический партнёр PDR-компании и гидропонная ферма с 25 контроллерами. По той же теме: что я доверил бы AI-дежурному на одном сервере и какие метрики учат команду плохим решениям. Раньше я писал, что наблюдаемость начинается с решения, которое команда должна принять. Если не понимаете, за что платите в мониторинге, покажите, что сейчас собирается: Обсудить задачу.