Управление стоимостью Grafana Cloud¶

Если вы выбрали Grafana Cloud (managed-вариант), управление стоимостью легко теряется из виду. Через месяц можно получить счёт на 12 000 $ вместо ожидаемых 4 000 $. Почему? Потому что Grafana Cloud считает data series и выставляет счёт за них.

Понимание cost → стабильный счёт за месяц.

Что считается в Cloud для метрик¶

Количество Active Series — это каждая уникальная комбинация меток и имени метрики, по которой за последний период (часы/месяц) были данные. PromQL-запрос вида rate(http_requests_total[5m]) после развёртки генерирует отдельную серию для каждого сочетания labels внутри hash map.

Цена Cloud прямо пропорциональна количеству active series.

Антипаттерны в Cloud¶

Слишком частый scrape interval. scrape_interval 1s расходует series впустую (в 1.5 раза больше, чем 15s). Значение 30s — экономичнее, для большинства метрик его достаточно.
Группировка по высококардинальным полям. by(user_id) при миллионе пользователей даёт 3 миллиона series на одну метрику. Это типичный способ случайно «выстрелить себе в ногу» метриками.
Динамические имена метрик. Когда имя метрики меняется при каждом деплое или рестарте, старые серии остаются в памяти ещё около двух часов после того, как данные перестали поступать. Это сжигает ресурсы впустую.

Рекомендация: используйте Recording rules в Prometheus — агрегируйте данные до того, как отправлять их в Cloud.

Grafana Cloud для логов¶

Loki в Cloud тарифицирует по объёму данных, проглоченных за месяц, в гигабайтах. Преобразование логов в метрики (logs-to-metric) обходится в 10–12 раз дешевле, чем отправка тех же данных как отдельных метрик-измерений.

Мониторинг собственного Cloud Usage¶

Поднимите отдельный пайплайн с метриками Grafana Cloud usage внутрь самой Grafana — чтобы видеть «сколько дней до конца бюджета» и заранее реагировать:

avg(grafanacloud_usage_active_series)

Стены бюджета отодвигаются, если за ними следить.

Далее: Антипаттерны