Telemetry Economics

Один label с идентификатором пользователя, добавленный ради удобного дашборда, — самый частый способ вырастить счёт за observability, не меняя нагрузку. Сюжет я регулярно вижу в одном и том же порядке. Строка проходит review как безобидная. Число временных рядов растёт вместе с аудиторией, запросы к TSDB начинают отваливаться по таймауту, и только на этом шаге кто-то открывает счёт. В документации Prometheus про это написано прямо: каждая уникальная комбинация label создаёт новый временной ряд, поэтому user_id и email не годятся как значения label. Начинается всё с одной строки инструментации, а вылезает в хранилище, в запросах и в деньгах.

Telemetry Economics — инженерная дисциплина управления полезностью и полной стоимостью метрик, логов и трейсов: объём приёма, кардинальность, индексация, семплирование, срок хранения, вычисления, исходящий трафик и время сопровождения. Это не общий Cloud Cost Control: здесь единица решения — сигнал и путь телеметрии от SDK до хранилища. И это не разрешение резать данные вслепую ради экономии. После каждого такого изменения проверяется одно: сохранилась ли диагностика известных режимов отказа.

Что должен уметь

Главный навык на уровне L5 — связать каждый крупный класс телеметрии с потребителем, сроком хранения и измеримой стоимостью, а затем уменьшить объём без потери критичных сценариев расследования. Самая опасная оптимизация здесь — та, у которой есть экономия, но нет проверки диагностической ценности.

Оценивает суточный входящий объём по формуле events/s × average bytes/event × 86 400 и отдельно помечает, что сжатие, репликация и индексация изменят итоговую стоимость хранения.
Находит неограниченные labels и атрибуты (user_id, email, request ID) и объясняет, почему их место — в логах или трейсах, а не в labels метрик.
Читает потребление и счёт по сигналам: метрики, логи, трейсы; называет крупнейшие источники объёма для своего сервиса.

Задаёт бюджет сигнала для сервиса: допустимый объём приёма, кардинальность, срок хранения и владелец; настраивает уведомление о выходе за бюджет.
Применяет фильтрацию, агрегацию, relabeling и разные сроки хранения по классам данных; документирует, что удаляется и зачем.
Выбирает семплирование на входе или по итогу трассы, фиксирует правило и проверяет сохранение ошибок, высокой задержки и редких бизнес-критичных путей.
Сравнивает объём и качество диагностики до и после изменения на одинаковом окне нагрузки.

Проектирует путь телеметрии через OpenTelemetry Collector или эквивалентный слой: ограничения, обратное давление, пакетирование, маршрутизация, семплирование и наблюдаемость самого конвейера.
Вводит квоты и разнесение расходов по team / service / environment, не смешивая production и эфемерные окружения в одном неразличимом счёте.
Сравнивает управляемый сервис и развёрнутый самостоятельно по полной стоимости владения: вычисления, хранение, репликация, исходящий трафик, лицензии и инженерное сопровождение.
Определяет SLO для самого конвейера телеметрии: допустимые потери, задержка экспорта и поведение при перегрузке для каждого сигнала.

L6+

Задаёт правила уровня организации: кардинальность, сроки хранения, семплирование, вымарывание персональных данных и порядок исключений; каждое исключение имеет владельца и срок пересмотра.
Связывает расходы с полезностью: стоимость по сервису и сигналу, использование дашбордами и алертами, подтверждённые сценарии расследований.
Проектирует переносимость телеметрии и план ухода, чтобы смена хранилища не требовала заново инструментировать все сервисы.

Материалы

Книги

Charity Majors, Liz Fong-Jones, George Miranda — Observability Engineering (O’Reilly, 2022). Не книга про FinOps, но полезна для оценки диагностической ценности высококонтекстных событий; читать вместе с документацией конкретного конвейера и его тарифами.

Статьи и документация

Prometheus — Metric and label naming. Самый короткий обязательный источник перед проектированием labels: прямо связывает уникальную комбинацию label с новым временным рядом и приводит примеры неограниченной кардинальности.
OpenTelemetry — Sampling. Хорошая граница применимости: семплирование уменьшает стоимость, но добавляет вычисления, сопровождение и риск потерять критичное; отдельно разобраны варианты на входе и по итогу трассы.
OpenTelemetry — Scaling the Collector. По моим наблюдениям, разбор топологии без этой страницы получается неполным: обработчики без состояния и семплирование по итогу трассы масштабируются по-разному, а неверное распределение спанов даёт неполные трассы.
OpenTelemetry — Collector. Независимый от вендора слой приёма, обработки и экспорта телеметрии; удобная точка, где правила применяются до отправки в хранилище.

Инструменты

OpenTelemetry Collector — центральный слой маршрутизации, фильтрации, пакетирования и семплирования. По моим наблюдениям, к нему приходят не ради независимости от вендора, а когда надоедает менять правила фильтрации в десятке SDK вместо одного места. Его собственные метрики очередей, потерь, задержки и потребления ресурсов входят в обязательную наблюдаемость конвейера.
Отчёты по временным рядам и labels на стороне хранилища — первый инструмент поиска источников кардинальности. Я вижу, что команды чаще обходятся встроенными средствами своего TSDB и берут отдельный анализатор редко: обычно тогда, когда хранилище такой отчёт не отдаёт вовсе.
Выгрузка счетов и потребления из хранилища — источник истины для удельной стоимости сигнала. Я регулярно вижу, что поставщик не отдаёт потребление в разрезе команд и сервисов; тогда разнесение приходится строить самому, по атрибутам ресурсов ещё до экспорта.

Best practices

Самая простая проверка начинается не с переезда на другое хранилище, а с таблицы signal → producer → consumer → retention → daily volume → owner. Я считаю отсутствие потребителя и владельца достаточной причиной для ревизии, но не для мгновенного удаления: редкий сигнал может быть нужен только во время аварии, и это проверяется по runbook и прошлым расследованиям.

Бюджет ставится до оптимизации, а не после. Без точки отсчёта нельзя ни доказать экономию, ни заметить, что объём просто переехал из одного сигнала в другой — из метрик в логи, например, и счёт остался прежним.

Неограниченные идентификаторы в labels метрик не попадают. Никогда. Request ID и user ID сохраняют контекст в логах или трейсах, а в метриках живут только ограниченные измерения, у которых число значений известно заранее.

Семплирование — правило с проверкой, а не процент. Оно хранится как код, проходит ревью и проверяется на трёх вещах: ошибках, высокой задержке и редких бизнес-критичных путях. Процент в конфиге без такой проверки — это ставка вслепую.

Семплирование по итогу трассы не бесплатно. Оно умеет то, чего не умеет отбор на входе: сохранить трассу, если в ней в итоге оказалась ошибка, высокая задержка или нужный атрибут. Расплата — состояние, которое надо где-то держать, и осторожное масштабирование. При низком объёме или при запрете отбрасывать данные семплирование не подходит вовсе, и OpenTelemetry прямо предлагает рассмотреть отказ от него.

Конвейер телеметрии — такой же прод, как и всё остальное. Если Collector теряет данные под нагрузкой, observability слепнет ровно в тот момент, когда она нужнее всего, — во время перегрузки, когда именно по этим сигналам предстоит понять, что происходит с сервисом. Хуже отсутствия данных только их незаметная потеря. Поэтому его мощность, очереди, потери, ошибки экспорта и задержка получают владельца, SLO и проверяемое поведение при отказе хранилища.

Сокращение сроков хранения не заменяет классификацию. Короткоживущие данные для отладки я отделяю от аудита и доказательной базы по инцидентам до того, как выбирать сроки. Юридические и договорные требования проверяются с теми, кто отвечает за комплаенс. Универсального срока для всех сигналов нет.

Связанные листья

Cloud Cost Control — задаёт общий контур FinOps; этот лист уточняет удельную экономику конвейера наблюдаемости.
SLI-based Alerting — телеметрию, которая питает SLI и вызовы дежурного, нельзя резать без проверки алертов и расчёта скорости сжигания.
Alert Fatigue Management — неиспользуемые сигналы и плохие алерты тратят и внимание дежурного, и деньги.
Capacity Planning — нагрузка на конвейер телеметрии требует собственной модели мощностей, особенно там, где семплирование хранит состояние.
Infrastructure as Code — квоты, сроки хранения и правила семплирования живут кодом: их можно отревьюить и воспроизвести.

Открытые вопросы

Как оценивать ценность сигнала, который почти никогда не запрашивают, но который однажды оказался решающим в критическом расследовании? Хорошего ответа у меня нет. Считать такой сигнал по частоте обращений — значит удалить его до следующей аварии; хранить всё на всякий случай — вернуться к тому счёту, ради которого этот лист и написан. Второй незакрытый вопрос проще формулируется: как единообразно считать стоимость профилей рядом с метриками, логами и трейсами, пока поддержка профилирования в экосистеме ещё дозревает.