Цена логирования и мониторинга при росте нагрузки в десять раз

MAATRIX

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

Почему логи и метрики растут вместе с нагрузкой, а не сами по себе

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

• Логи приложения — на каждый HTTP-запрос обычно пишется от одной до нескольких строк (access-лог, лог бизнес-логики, лог обращения к базе). Больше запросов — больше строк, коэффициент почти не меняется с ростом нагрузки.
• Логи инфраструктуры — nginx, база данных, очередь сообщений, каждый прокси в цепочке пишет свою строку на то же событие. Если у вас между клиентом и приложением появился ещё один слой (балансировщик, API-шлюз), объём логов на один запрос вырос, даже если сам запрос не изменился.
• Метрики — тут ситуация сложнее и опаснее, потому что растёт не только количество точек данных во времени (это ожидаемо), но и кардинальность: количество уникальных комбинаций меток (labels/tags). Если у вас метрика с меткой user_id или container_id, рост числа пользователей или подов напрямую умножает число временных рядов, которые нужно хранить.
• Трейсы — при распределённой трассировке один запрос порождает трейс из нескольких спанов на каждый сервис, через который он прошёл. При росте нагрузки в десять раз и при добавлении новых микросервисов объём трейсов может вырасти даже быстрее, чем в десять раз.

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

Как считают деньги сервисы логирования и мониторинга

Ключевая причина, по которой эта статья расходов застаёт врасплох — модель тарификации у большинства облачных сервисов observability принципиально отличается от модели тарификации у хостинга. Сервер вы обычно оплачиваете фиксированно (за конфигурацию в месяц), а логирование и мониторинг — по объёму данных:

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

Иллюстрация: что происходит со счётом при росте нагрузки в десять раз

Возьмём условный пример (числа иллюстративные, не измеренные — у вас будет иначе). Допустим, сервис в среднем пишет один килобайт логов на запрос (access-лог + лог приложения + лог базы). При скромной нагрузке в сотни тысяч запросов в сутки это единицы гигабайт логов в сутки — в рамках бесплатного или недорого тира почти любого сервиса логирования. Проблема начинается, когда нагрузка вырастает в десять раз:

1. Объём логов вырастает примерно в десять раз тоже — с единиц до десятков гигабайт в сутки.
2. Одновременно с ростом нагрузки часто растёт и архитектура: появляется больше сервисов, больше реплик, балансировщик, кэш-слой — каждый добавляет свои логи и свой набор метрик. Это накладывается на десятикратный рост и даёт дополнительный множитель.
3. Метрики, которые раньше были дёшевы из-за низкой кардинальности (несколько инстансов приложения), при масштабировании вширь на десятки подов резко увеличивают число временных рядов — особенно если в лейблы метрик попадают идентификаторы конкретных инстансов или пользователей.
4. Если срок хранения логов не пересматривался (например, «храним 90 дней логов», как было настроено на старте), рост объёма в сутки умножается на неизменный срок хранения — суммарный объём в хранилище растёт пропорционально или быстрее.

В сумме нередкая ситуация — когда счёт за наблюдаемость при десятикратном росте нагрузки растёт заметно сильнее самого роста, просто потому что накладываются друг на друга несколько факторов: рост объёма событий, рост числа компонентов архитектуры, рост кардинальности метрик и переход в более дорогой тариф. Это тот самый «неожиданный» расход, который не видно в момент планирования масштабирования основной инфраструктуры — все смотрят на CPU, RAM и диск под базу, и почти никто заранее не пересчитывает бюджет на логи и метрики.

Кардинальность метрик — скрытый множитель, который не виден на старте

Для систем мониторинга на базе временных рядов (Prometheus, VictoriaMetrics, managed-аналоги) стоимость определяется не столько объёмом «сырых данных», сколько числом уникальных временных рядов — то есть уникальных комбинаций имени метрики и значений всех её меток. Это тонкий момент, который часто упускают:

# Метрика с низкой кардинальностью — один ряд на статус-код
http_requests_total{status="200"} 
http_requests_total{status="500"}

# Метрика с высокой кардинальностью — ряд на каждого пользователя
http_requests_total{status="200", user_id="8471"}
http_requests_total{status="200", user_id="8472"}
# ... и так на каждого активного пользователя

При росте базы пользователей или числа инстансов в десять раз метрика с меткой вроде user_id, session_id, pod_name или request_id увеличивает число временных рядов в системе мониторинга пропорционально этому росту — а managed-сервисы мониторинга почти всегда тарифицируют именно по числу активных series, а не по «объёму данных» в привычном смысле. Практическое правило: в метки метрик стоит выносить то, по чему вы реально хотите строить срезы и алерты (регион, тип сервиса, код ответа), и не выносить то, что уникально для каждого объекта или запроса (ID пользователя, ID запроса, точный timestamp) — для таких данных подходят логи или трейсы, а не метки метрики.

Сэмплирование и агрегация: как срезать объём без потери сигнала

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

• Сэмплирование менее критичных логов. Access-логи успешных запросов (200 OK) обычно можно писать не все подряд, а с вероятностной выборкой — например, сохранять каждую десятую или сотую запись, но всегда сохранять 100% ошибок (4xx, 5xx) и медленных запросов. Большинство коллекторов логов (Vector, Fluent Bit, Fluentd) поддерживают сэмплирование на уровне пайплайна:

# пример трансформации в Vector: сэмплировать успешные запросы 1 к 10,
# ошибки пропускать без сэмплирования
[transforms.sample_success]
type = "sample"
inputs = ["parse_logs"]
rate = 10
key_field = "trace_id"
exclude = '.status_code >= 400'

• Sampling трейсов (tail-based или head-based) — стандартный приём в распределённой трассировке: сохранять все трейсы с ошибкой или аномальной задержкой, а «нормальные» — с низкой вероятностью (например, 1–5%). Это в разы снижает объём хранимых трейсов без потери способности находить инциденты.
• Агрегация метрик до записи — вместо хранения сырых событий держать recording rules, которые заранее агрегируют часто используемые запросы:

# Prometheus recording rule — предвычисленная агрегация
# снижает нагрузку на запросы к дашбордам и не растит кардинальность хранимых сырых данных
groups:
  - name: aggregations
    rules:
      - record: job:http_requests:rate5m
        expr: sum(rate(http_requests_total[5m])) by (job, status)

• Разделение логов по важности на уровне приложения. Не весь DEBUG-уровень нужен в проде — это первое, что стоит проверить при неожиданном росте объёма логов.
• Фильтрация на источнике, а не после приёма. Дешевле не отправлять лишние данные в систему логирования, чем отправить и потом платить за их хранение — фильтруйте и агрегируйте ближе к источнику (в приложении или локальном коллекторе), а не в централизованном хранилище.

Политики хранения, ротация и холодное хранение логов

Вторая по значимости переменная в формуле стоимости — не объём в сутки, а срок хранения. Многие команды настраивают retention один раз на старте («храним 30 дней», «храним 90 дней») и не пересматривают его при росте нагрузки — а между тем при десятикратном росте объёма в сутки тот же срок хранения даёт кратно больший объём в хранилище.

Практичный подход — многоуровневое хранение, где горячий, быстрый доступ стоит дороже, а холодный архив — дешевле:

Ключевая мысль: не всё, что вы логируете, должно быть одинаково быстро доступно одинаково долго. Логи для расследования инцидента за последнюю неделю нужны с быстрым полнотекстовым поиском. Логи шестимесячной давности, которые вы храните только потому, что того требует политика или закон (например, требования к логам доступа для отдельных отраслей), можно держать в сжатом виде в объектном хранилище без дорогого индекса — это на порядок дешевле, но подходит только если вам не нужен быстрый поиск по ним.

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

# /etc/logrotate.d/myapp — пример с учётом выросшего объёма
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    maxsize 500M
}

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

Что настроить заранее, чтобы не получить неожиданный счёт

Практическая последовательность действий для команды, которая планирует рост в несколько раз:

1. Посчитайте текущий объём логов и метрик на один запрос или на одного активного пользователя, а не в абсолютных цифрах за сутки — именно этот коэффициент нужно умножать на ожидаемый рост нагрузки.
2. Проверьте кардинальность метрик до масштабирования — найдите метки, растущие вместе с числом пользователей или инстансов, и решите, нужны ли они как метрики или их место в логах.
3. Разделите логи по критичности и настройте сэмплирование для низкоприоритетных категорий заранее, а не в панике, когда счёт уже пришёл.
4. Настройте многоуровневый retention — горячее хранение для недавних данных, холодный архив для старых, если этого требует комплаенс.
5. Установите алерт на сам счёт за observability, а не только на технические метрики — многие сервисы логирования дают настроить бюджетный алерт на превышение объёма приёма данных.
6. Пересчитывайте бюджет наблюдаемости при каждом изменении архитектуры (новый сервис, новый прокси, переход на микросервисы) — это момент, когда меняется коэффициент «логов на запрос», а не только их число.

Если вы разворачиваете стек логирования и мониторинга (например, Grafana Loki или Graylog) на собственном сервере — читайте о том, как понять, что выгоднее — Graylog или Grafana Loki в вашей ситуации, и о том, во что превращаются 300 ГБ логов, которые никто не читал — это тот самый сценарий, когда объём наблюдаемости растёт, а пользы от него не прибавляется. Также полезно заранее сравнить стоимость собственного мониторинга против готового сервиса, прежде чем закладывать конкретную статью бюджета на рост.

Частые вопросы