Экономия на observability: удерживаем затраты в пределах 5% infra

Инженерная org на 200 сервисов присылает тебе счёт за observability: $680k/год, и он растёт быстрее трафика. Команда платформы получает два квартала, чтобы срезать его вдвое — не теряя debugging-мощь. Без нового тулинга. Без смены вендора. Разница между хорошо настроенной org и ненастроенной — не в бэкенде, а в трёх рычагах и дисциплине их применения.

Почему observability масштабируется супералинейно без дисциплины

Production observability масштабируется линейно с трафиком по базовому объёму сигналов, но супералинейно — с кардинальностью. Один новый неограниченный лейбл (например, добавление user_id в метрику) может умножить количество metric series на 10–100x за ночь. Объём трейсов растёт вместе с числом запросов. Объём логов растёт с числом запросов и может спайкнуть при ошибках. Без governance рост трафика в 10x может означать рост стоимости в 50–100x.

Отраслевой бенчмарк для хорошо настроенной org: $1–5 за миллион запросов для полной четырёхсигнальной observability. Для ненастроенной: $10–50 за миллион запросов. Разница — в инженерной дисциплине, а не в выборе вендора.

Три рычага управления стоимостью

Рычаг 1: Лимиты кардинальности на метриках

Каждая уникальная комбинация значений лейблов создаёт одну time-series. Метрика http_requests_total{service, route, status_code} при 200 сервисах × 500 маршрутах × 600 кодах статуса = 60 миллионов серий. Реалистичный бюджет кардинальности — 5–10k активных серий на сервис.

Правила, предотвращающие взрывы кардинальности:

• Использовать шаблоны маршрутов, а не полные URL (/users/{id}, а не /users/17384).
• Использовать классы статусов, а не точные коды (2xx, 4xx, 5xx, а не 200, 201, 404).
• Никогда не использовать user_id, request_id, email или любое неограниченное значение как лейбл.
• Применять лимиты в CI: lint-шаг отклоняет любой новый лейбл с неограниченными значениями.

Рычаг 2: Tail sampling на трейсах

Без tail sampling org на 200 сервисов при 10k запросов/сек генерирует ~10k трейс-деревьев в секунду. Хранить их все 30 дней — главный драйвер стоимости. Policy tail sampling:

• 100% трейсов с любым ERROR-span’ом.
• 100% трейсов с суммарной длительностью выше порога медленного трейса (типично 2 с).
• 5% случайный baseline всего остального.

Ожидаемый результат: сокращение объёма трейсов на 80–90% без потери debugging-мощи. Ошибочные и медленные трейсы — единственные, по которым ты когда-либо навигируешь; 5% baseline обеспечивает контекст для анализа частот и паттернов.

Рычаг 3: Тиерная retention логов и профилей

Не все данные должны быть queryable на полном разрешении вечно.

Логи в зрелых org: hot 14 дней, summary 30 дней, archival 90 дней. Профили: hot 30 дней, downsampled 90 дней. Тиерная retention делает рост стоимости логарифмическим, а не линейным.

Применение playbook сокращения затрат

Вернёмся к команде платформы со счётом $680k/год и задачей срезать его вдвое за два квартала.

Шаг 1: Pareto-анализ. Получи счёт с разбивкой по сервисам и типам сигналов. Топ-5 сервисов обеспечивают ~60% стоимости. Топ-1 тип сигнала (обычно логи) даёт ~50% стоимости.

Шаг 2: Логи на $300k/год. Ищи: verbose-уровни логирования в production (INFO или DEBUG вместо WARN); сообщения об ошибках, логируемые при каждом retry; per-request log-строки, дублирующие span-события трейсов; повторяющиеся одинаковые сообщения. Фиксы: аудит лог-уровней, dedup, перенос per-request-инфо в span-атрибуты, rate-limit шумных событий.

Шаг 3: Метрики на $200k. Найди топ-20 метрик по числу серий. У большинства будут неограниченные лейблы. Дроп через collector relabeling; маршрутизируй измерение в трейсы или логи. Ожидаемо: 50–70% сокращение серий.

Шаг 4: Трейсы на $150k без tail sampling. Разверни tail-sampling policy (ошибки 100% + медленные 100% + 5% baseline). Ожидаемо: 80–90% сокращение объёма трейсов.

Шаг 5: Профили на $30k. Оставь. Профилирование — ~10% общей стоимости; урезание даёт мало, а CPU debugging-мощь уничтожает. Лучше включить его там, где его нет — это сэкономит больше, предотвращая будущие инциденты.

Ожидаемые результаты: Логи −40% ($120k), метрики −50% ($100k), трейсы −85% ($127k). Итого: $347k сэкономлено. Стоимость с $680k до $333k — снижение 49% за два квартала.

MTTD vs MTTR: оба важны, но MTTD — больший рычаг

Mean Time To Detect (MTTD): сколько времени проходит от поломки до срабатывания алерта. Multi-window burn-rate алерты (урок 05) снижают MTTD до 1–5 минут.

Mean Time To Resolve (MTTR): сколько времени от алерта до фикса. Дисциплина воронки снижает MTTR до 3–10 минут.

MTTD 30 секунд превращает 10-минутный инцидент в 5-минутный для пользователей. MTTD 5 минут превращает тот же инцидент в 15 минут. MTTD накапливается быстрее MTTR, поскольку затрагивает каждый запрос, отправленный в окне сбоя. Измеряй оба раздельно; показывай оба в reliability-scorecards команды.