Сэмплирование — главный регулятор «цены трассировки». В этом уроке — экономика: сколько стоит трейс, как выставить бюджет и какие политикой его соблюсти.
Математика объёма
Средний спан в хранилище — 0.5–1 КБ (индексы + документ). Формула суточного объёма:
Объём/сутки ≈ RPS × спанов_на_трейс × сэмпл_% × 1КБ × 86400| Сценарий | RPS | Спанов/трейс | Сэмпл | ГБ/сутки |
|---|---|---|---|---|
| Микросервисный прод | 1 000 | 20 | 1% | ~1.7 |
| Тот же, 100% | 1 000 | 20 | 100% | ~170 |
| Крупный прод | 10 000 | 30 | 1% | ~26 |
| Крупный, 10% | 10 000 | 30 | 10% | ~260 |
Хранилище с retention 7 дней при 26 ГБ/сутки — уже ~180 ГБ только «горячего» индекса. Отсюда правило: решайте сэмплирование бюджетом, а не вкусом: «у меня есть 200 ГБ на трейсы, значит бюджет = X трейсов/сек».
Политика в проде (типовая)
- Корневой сэмплер: probabilistic 1–10% от общего трафика (или adaptive);
- Обязательно 100% для: запросов с ошибками — увы, head-based этого не умеет (решение ещё неизвестно) — это работа tail-сэмплирования (урок 5.2);
- Малые сервисы: не давите одинаковым процентом — 5% от 3 RPS = мёртвые данные; ставьте им ratelimit (например, 10 трейсов/сек) или 100%;
- Фоновые задачи: свой (обычно более щедрый) сэмплер — их мало, а разбирать хочется все.
Инструменты снижения объёма без потери ценности
- Фильтрация шума до записи: healthchecks, роботы, дубли — процессор filter (урок 3.2);
- Меньше атрибутов-балласта: полные SQL-тексты и URL — главные раздуватели спанов;
- Retention по этажам: 7 дней полного индекса + 30 дней «архива» только корневых спанов — зависит от хранилища (урок 5.3);
- Сжатие: OTLP-экспорт уже сжимает (gRPC+zlib); на уровне Kafka — compressor.
Частые ошибки стоимости
| Ошибка | Симптом |
|---|---|
| Один сэмплер на все сервисы «1%» | малые сервисы пустые, большие переполнены |
| always_on в проде «на время отладки» | ES не влезает, UI умирает; забыли выключить |
| Теги с высокой карточностью | индексы растут быстрее спанов |
| Бесконечный retention | дисковая катастрофа через полгода |
| Двойное сэмплирование (SDK и Collector независимо) | непредсказуемый итоговый процент |
Практика
- Посчитайте объём для своего приложения: RPS × спанов/трейс (возьмите из реального трейса) × 1% × 1КБ. Сравните с доступным местом.
- Задайте каждому сервису свой сэмплер: тяжёлому — 2%, малому — ratelimit 5/с. Проверьте в UI, что оба дают полезные трейсы.
- Сымитируйте «забыли выключить always_on»: замерьте рост хранилища за 10 минут под нагрузкой и посчитайте, через сколько дней закончится диск.
Мини-квиз
1. Почему head-based не может «все ошибки»? — Решение принимается до начала запроса: об исходе ещё ничего не известно.
2. Что не так с «5% для всех»? — Игнорирует профиль трафика: малым сервисам мало, большим — много; считать надо трейсы/сек.
3. Первые два подозреваемых при взрывном росте хранилища? — Кто-то включил always_on; появились атрибуты с высокой карточностью.