Аудит затрат на наблюдаемость для команд с растущими расходами

Почему расходы растут до того, как трафик это показывает

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

Метрики — частая причина. Добавьте ещё одну метку к загруженной метрике, и вы получите поток временных рядов. Счётчик, разбитый по сервису и региону, может оставаться управляемым. Добавьте build_id, tenant_id или user_id, и количество рядов быстро вырастет. Это кардинальность меток метрик простыми словами: каждое новое значение метки создаёт ещё один ряд для хранения и запросов.

Логи тратят деньги иначе. Команды добавляют новый агент, SDK или облачный форвардер во время миграции, а старый путь забывают убрать. Дашборды продолжают работать, поэтому никто не замечает. Счёт замечает.

Хранение — ещё одна тихая утечка. Многие инструменты сохраняют всё по умолчанию слишком долго, даже когда данные полезны лишь несколько дней. Отладочные логи помогают сразу после релиза, но хранить их 30 или 90 дней редко имеет смысл, если после первой волны инцидентов ими никто не пользуется.

Одни и те же проблемы повторяются снова и снова. Разработчик добавляет метку высокой кардинальности к загруженной метрике. Два коллектора отправляют одинаковые логи от одного сервиса. Стейджинг‑среды отправляют почти столько же данных, сколько продакшен. Трейсы и отладочные данные лежат в хранилище намного дольше, чем нужно.

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

Начинайте аудит с устройства, а не с графиков трафика. Количество рядов, пути поступления и политика хранения обычно объясняют скачок быстрее, чем отчёт по трафику.

Смапьте то, что вы сейчас собираете

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

Простая таблица работает лучше диаграммы. Дайте каждой строке один поток, а не один аккаунт поставщика. Разделите логи приложений, метрики инфраструктуры, трейсы, события браузера, логи баз данных и события ошибок на отдельные строки. Если вы используете Prometheus, Loki, Grafana, Sentry, OpenTelemetry или облачные сервисы, отметьте, куда попадает каждый поток и не хранится ли копия в другом пайплайне.

Держите столбцы простыми и согласованными: источник и область, куда уходят данные, суточный объём, месячная стоимость, дни хранения, назначение и владелец. Строка вроде "API‑логи из продакшена" или "ошибки браузера в чекауте" достаточно понятна.

Столбец с владельцем важнее, чем команды ожидают. Невладеемая телеметрия имеет тенденцию сохраняться вечно, даже если её никто не читает. Люди продолжают за неё платить, потому что никто не чувствует себя вправе удалить данные или сократить хранение.

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

Растущие SaaS‑команды часто видят один и тот же рисунок, когда сводят всё в таблицу. Логи доступа лежат в одном инструменте для поиска, во втором системе хранится дубликат для алертов, а сырые файлы остаются в object storage "на всякий случай". Каждая часть звучит разумно сама по себе. В связке же перекрытие становится очевидным.

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

Аудит количества меток шаг за шагом

Часто лучше начать с меток, потому что их взрыв может поднять счёт задолго до роста трафика. Каждое новое значение метки создаёт ещё один временной ряд. Одна метрика может превратиться в тысячи, если к ней прикрепить слишком много деталей.

Начните с экспорта метрик с наибольшим числом рядов из вашего мониторингового стека. В системах в стиле Prometheus это удобно благодаря обзору кардинальности. Если вы используете Grafana или другой слой дашбордов, выгрузите те же данные в таблицу и добавьте два полезных столбца: кто использует эту метрику и какие алерт или дашборд от неё зависит.

Затем отсортируйте метрику по меткам с наибольшим числом уникальных значений. Вы хотите увидеть, какие метки умножают комбинации. Метки вроде service, region или status code обычно остаются малыми. Проблемы начинаются, когда метка меняется почти на каждом запросе.

Несколько меток заслуживают немедленного подозрения:

• user IDs
• request IDs
• session IDs
• сырые URL с ID или query‑строками
• любой свободный текст, превращённый в метку

Метрика вроде http_requests_total кажется безобидной, пока path=/product/48291 не станет отдельным рядом для каждой страницы товара. Замените это на имя маршрута, например /product/:id, и число рядов быстро упадёт. Если нужна дополнительная детализация, поместите её в логи или трейсы, а не в метки метрик.

Некоторые исправления просты. Замените точные значения на бакеты. Используйте response_size_bucket=small|medium|large вместо точного числа байт. Группируйте клиентов по плану или сегменту вместо ID клиента. Сохраняйте детальные данные только для выборки при необходимости глубокой отладки.

Не вносите изменения в метки вслепую. Дашборды и оповещения часто зависят от старых имён и значений меток. Прежде чем разворачивать изменения, скопируйте самые используемые дашборды, обновите их и сравните старые и новые представления день или два. То же самое и с алертами. Если алерт раньше срабатывал по сырому URL, а теперь по имени маршрута, убедитесь, что он по‑прежнему ловит ту же проблему.

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

Найдите дублированный приём данных

Дублирование приёма часто даёт самое быстрое сокращение расходов. Инструменты добавляются со временем, и старые пути продолжают работать после запуска новых. Одна ошибка, одна строка лога или одна метрика попадают в две или три системы — и вы платите за каждую копию.

Начните с простого инвентаря каждого коллектора и отправителя. Проверьте хосты, контейнеры и бессерверные задания. Многие команды одновременно запускают хост‑агент, сайдкар кластера и SDK в приложении без намерения.

Пройдитесь по каждому уровню по порядку. Перечислите агенты на VM и bare‑metal хостах. Проверьте DaemonSets Kubernetes, сайдкары и лог‑шипперы. Просмотрите код приложения на предмет OpenTelemetry и SDK поставщиков. Проверьте serverless‑функции и batch‑задачи на скрытые обёртки. Это не займёт много времени и часто объясняет неожиданно большую часть расходов.

Затем проследите одно реальное событие от начала до конца. Возьмите строку лога с уникальным request ID. Пройдите её от приложения, через коллекторы, очереди, процессоры и экспортеры, пока событие не попадёт в платное хранилище. Если одна и та же запись появляется дважды, спросите, для чего нужна каждая копия. Иногда один путь кормит поиск, а другой — оповещения. Часто обе копии делают одно и то же.

Смешанные настройки создают большую часть перекрытий. Команда отправляет трейсы через OpenTelemetry, держит SDK в приложении от вендора и дополнительно запускает агент, который собирает логи и превращает их в события. Это кажется безопасным, но часто добавляет расходы без увеличения покрытия.

Зеркальные пайплайны требуют повышенного внимания. Они обычно появляются после миграций, приобретений или срочных исправлений после инцидента, которые никто не почистил. Если дублированный путь не выполняет явную задачу, выключите его в контролируемом тесте и наблюдайте алерты, дашборды и поток инцидентов несколько дней.

Один владелец на путь телеметрии решает многие проблемы. Назначьте каждому пути именованного владельца и короткое письменное назначение. Если никто не может объяснить, зачем пайплайн существует, это обычно уже ответ.

Настройте хранение по реальным случаям использования

Один универсальный срок хранения для всех логов и метрик — ленивый вариант, и он обычно обходится слишком дорого. Большинство команд держат шумные данные гораздо дольше, чем кто‑то их читает, в то время как данные, важные для аудита или разбора инцидентов, теряются в той же куче.

Начните с простого разделения: что люди смотрят каждый день, что проверяют только при инциденте и что хранится для юридических или финансовых целей. Это небольшое изменение часто быстро сокращает объёмы хранения без потери видимости.

Отладочные логи обычно первое место для обрезки. Они шумные, повторяющиеся и полезны короткое время, пока команда исправляет свежую проблему. Если после недели никто не обращается к этим логам, хранить их 30 дней или 90 дней — просто платить за старый шум.

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

Практичная политика часто выглядит так:

• Отладочные и трейс‑тяжёлые логи приложения: 3–7 дней
• Обычные логи приложения и инфраструктуры: 14–30 дней
• Данные для разбора инцидентов: 30–90 дней
• Логи безопасности и доступа: дольше, в зависимости от риска и политики
• События, связанные с финансами: столько, сколько требуют бухгалтерия или юристы

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

Команды, использующие Prometheus, Loki или Sentry, часто экономят больше, задавая правила по потоку, а не одним глобальным параметром. На бумаге это выглядит менее аккуратно, но совпадает с тем, как люди реально работают.

Пересматривайте хранение при добавлении новой продуктовой области, выходе на регулируемый рынок или изменении модели оплаты клиентов. Счета дрейфуют потому, что правила хранения дрейфуют.

Простой пример из растущей SaaS‑команды

Небольшая команда запустила приложение для управления проектами с относительно стабильным счётом за логи и метрики. Потом они добавили фоновые задания для импорта, синхронизации почты и генерации отчётов. Трафик вырос примерно на 20%, но счёт за наблюдаемость прыгнул с ~$800 в месяц до почти $2,400.

Эта разница смутила их, потому что продукт для пользователей почти не изменился. Аудит показал, что использование выросло, но правила сбора выросли гораздо быстрее.

Первая проблема — кардинальность меток метрик. Их API‑метрики хранили сырые пути запросов, поэтому /projects/41, /projects/42 и /projects/43/tasks/9 стали отдельными рядами. Когда рабочие фоновые задания начали вызывать внутренние эндпоинты с ID в путях, число временных рядов взорвалось.

Вторая проблема — дублированная телеметрия. Команда установила хост‑агент на каждую VM, а позже добавила сбор через контейнерный стек. Оба агента слали похожие данные по CPU, памяти, диску и процессам. Они платили двойную цену за данные, которые смотрели один раз.

Логи дали третий слой расхода. Приложение хранило 30 дней подробных логов приложения, включая debug‑записи для рутинных фоновых задач. При разборе инцидентов команда обнаружила простую истину: большинство проверок происходят в первые 72 часа. После этого к шумным логам почти не возвращаются.

Они привели всё в порядок за неделю. Заменили сырые пути на шаблоны роутов вроде /projects/:id/tasks/:id. Убрали один набор хост‑агентов. Разделили хранение логов по назначению: три дня для подробных debug‑логов, 14 дней для обычных логов приложения и 30 дней только для аудита и безопасности.

Команда беспокоилась, что алерты потеряют видимость после зачистки. Этого не случилось. Дашборды по‑прежнему показывали задержки, ошибочные ответы, задержку очередей и здоровье хостов. Дежурные имели достаточно контекста для устранения проблем.

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

Ошибки, которые поддерживают высокий счёт

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

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

Другая дорогая привычка — хранить все трейсы одинаково долго. Большинству команд не нужна полная история успешных запросов. Чаще требуется длинное хранение для ошибок, редких пиков и небольшой выборки нормального трафика для сравнения.

Рост меток делает более медленный, но постоянный вред. Кто‑то добавляет метки для удобства — build_id, путь запроса, заметка клиента, временное поле для отладки — и никто потом не убирает. Кардинальность растёт, запросы тормозят, затраты на хранение ползут вверх месяц за месяцем. Утечка легко незаметна, потому что каждая метка сама по себе выглядит незначительной.

Затраты также скачут, когда каждая команда ставит свой коллектор, агент или сайд‑пайплайн. Это даёт дублированную телеметрию, разное сэмплирование и три версии одной метрики с чуть разными именами. Одна команда думает, что она аккуратна. Для всей компании это превращается в расточительство.

Последняя ошибка проста: никто не смотрит расходы до срока продления. К тому моменту плохие привычки стали настройками по‑умолчанию.

Ежемесячный обзор должен ловить потоки стейджинга, уходящие в долгосрочное продакшен‑хранилище, полное хранение трейсов для рутинных запросов, метки, которые никто не использует в оповещениях или отладке, несколько коллекторов, шлющие одни и те же события, и любой скачок затрат без назначенного владельца.

Быстрая проверка перед следующим счётом

Короткий аудит часто занимает меньше часа и может остановить ещё один месяц пустой траты. Вам не нужен полный редизайн, чтобы найти экономию. Нужен небольшой набор чисел, который покажет, что выросло, что никто не использует и что хранится по два раза.

Начните с пунктов, которые быстрее всего влияют на стоимость:

• Вытяните 10 метрик с наибольшим числом рядов. Если одна метрика взрывается из‑за меток вроде user_id, request_id или полного URL, исправьте это в первую очередь.
• Вытяните 10 потоков логов по суточному объёму в ГБ. Большие потоки обычно идут от болтливых сервисов, оставленных включёнными debug‑логов или повторяющихся stack trace.
• Отметьте любую метрику или поток логов, который не питает ни один дашборд, ни один алерт и ни один отчёт. Если никто этого не читает — обрежьте или семплируйте.
• Проверьте каждую рабочую нагрузку на предмет двух коллекторов, делающих одну и ту же работу. Нода‑агент плюс сайдкар или два лог‑шиппера на одном хосте могут удвоить счёт без пользы.
• Сравните правила хранения с текущими потребностями продукта. Команды часто хранят 90 или 180 дней просто потому, что это было старое значение по умолчанию, а не потому, что кому‑то это всё ещё нужно.

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

Использование важнее привычки. Если команда пользуется логами только для отладки инцидентов за последние 14 дней, держите короткое хранение в hot‑хранилище и переводите старые данные в более дешёвый путь. Та же логика применима к метрикам. Держите долго только те данные, которые вы реально анализируете для бизнес‑или ёмких трендов.

Даже зрелые стеки пропускают дублирование приёма. Один сервис шлёт логи на платформу, затем хост‑агент снова шлёт тот же файл. Счёт делает это очевидным, но только после того, как деньги потрачены.

Если вы повторяете эти проверки перед каждым счётом, скачки расходов перестанут казаться загадкой. Они превратятся в короткий список правок с понятными владельцами.

Что делать дальше

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

Маленький план лучше большого проекта по очистке. Просмотрите логи, метрики и трейсы одной службы за последние 7–30 дней. Установите ежемесячный лимит бюджета для каждого типа сигналов, чтобы скачки появлялись рано. Назначьте одного владельца, который одобряет новые метки и изменения хранения. Запишите, что остаётся, что семплируется и что удаляется быстрее.

Роль владельца важнее, чем большинство команд ожидают. Если никто не утверждает изменения меток, кардинальность растёт случайно. Если никто не владеет хранением, старые значения по умолчанию остаются месяцами, и счёт продолжает расти.

Задавайте ограждения в числах, а не расплывчатыми целями. Дайте логам месячный лимит, метрикам — отдельный лимит, а трассам — свой предел. Если одна область прыгает на 20% без соответствующего роста трафика, воспринимайте это как баг и расследуйте на той неделе.

Короткое письменное правило помогает. Новые метки нуждаются в причине. Поля высокой кардинальности, такие как user_id, request_id и сырые URL, не должны попадать в метрики, если команда не согласна, что они стоят своей цены. Хранение должно соответствовать кейсу использования: возможно 30 дней для большинства логов приложения, дольше для событий безопасности и намного меньше для шумных debug‑данных.

Если хотите второе мнение, Oleg Sotnikov на oleg.is даёт советы стартапам и небольшим командам по архитектуре, инфраструктуре и работе на позиции Fractional CTO. Он запускал продакшен‑стэки с инструментами вроде Sentry, Grafana, Prometheus и Loki, поэтому обзор наблюдаемости может вписаться в более широкий аудит затрат и систем.

Этого достаточно, чтобы начать действовать. Одна служба, один владелец, один бюджет и одна письменная политика принесут больше пользы, чем ещё один месяц надежды, что следующий счёт будет лучше.