Документация Grafana Документация GlaberGraph Оповещения Примеры High-cardinality alerts

Examples of high-cardinality alerts

В Prometheus и Mimir метрики хранятся как временные ряды, где каждый уникальный набор меток определяет отдельную серию.

Большое количество уникальных серий (высокая кардинальность) может перегрузить ваш бэкенд метрик, замедлить запросы дашбордов и оповещений и быстро увеличить ваши расходы на observability или превысить лимиты вашего плана Grafana Cloud.

Эти примеры показывают, как обнаруживать и оповещать о ранних признаках высокой кардинальности:

• Общее количество активных серий близко к лимитам: обнаруживайте, когда ваш экземпляр Prometheus, Mimir или Grafana Cloud Metrics приближается к мягким или жёстким лимитам.
• Рост серий по метрике или области: тонко настройте обнаружение, чтобы выявлять рост в конкретной метрике или домене.
• Внезапный рост серий: обнаруживайте неконтролируемый рост кардинальности, вызванный неправильно настроенными экспортёрами или новыми развёртываниями.
• Высокая скорость приёма: обнаруживайте, когда принимается слишком много сэмплов в секунду, даже если общее количество серий стабильно.

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

Choose metrics to monitor active series

Сначала определите, какая метрика сообщает количество активных временных рядов.

Prometheus, Mimir и Grafana Cloud предоставляют эту информацию по-разному:

Detect total active series near limits

Большое количество активных серий увеличивает использование памяти и может влиять на производительность. Grafana Cloud применяет лимиты использования, чтобы ваш экземпляр не столкнулся с этими проблемами производительности.

В Prometheus вы можете настроить оповещение, когда общее количество активных серий превышает порог:

shell Copy

prometheus_tsdb_head_series > 1.5e6

Это срабатывает, когда экземпляр превышает 1,5 миллиона активных серий.
Настройте порог в зависимости от ёмкости вашего хоста Prometheus и наблюдаемой нагрузки.

В Grafana Cloud используйте метрику grafanacloud_instance_active_series для мониторинга активных серий в вашем управляемом бэкенде Mimir:

shell Copy

grafanacloud_instance_active_series > 1.5e6

Grafana Cloud также предоставляет лимиты уровня аккаунта через метрику grafanacloud_instance_metrics_limits.

Для более надёжного оповещения вы можете сравнить ваше текущее использование с лимитом max_global_series_per_user:

shell Copy

(
  grafanacloud_instance_active_series
  / on (id)
    grafanacloud_instance_metrics_limits{limit_name="max_global_series_per_user"}
)
* on (id) group_left(name) grafanacloud_instance_info
> 0.9

• grafanacloud_instance_active_series
  Возвращает текущее количество активных серий для экземпляра (id) вашего источника данных Mimir (Prometheus).

• / on (id) grafanacloud_instance_metrics_limits{limit_name="max_global_series_per_user"}
  Делит текущее использование на лимит аккаунта, чтобы вычислить коэффициент утилизации от 0 до 1 (где 1 означает, что лимит достигнут).

• * on (id) group_left(name) grafanacloud_instance_info
  Присоединяет метаданные экземпляра, чтобы отобразить имя экземпляра.

• > 0.9
  Определяет условие порога для срабатывания, когда использование превышает 90 % лимита.
  Настройте это значение в соответствии с вашей целью оповещения. Либо вы можете задать порог как выражение Grafana Alerting в интерфейсе.

Detect high-cardinality per metric

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

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

Вы можете применять фильтры меток или использовать {__name__=~"regex"} для выбора конкретных метрик. Затем используйте count by (__name__), чтобы сгруппировать результаты по имени метрики.

Поскольку селектор __name__ запрашивает весь индекс TSDB, этот запрос рекомендуется выполнять через recording rule:

shell Copy

# Only HTTP/RPC-style metrics
active_series_per_metric:http_rpc =
label_replace(
  count by (__name__) ({__name__=~"http_.*|rpc_.*"}),
  "metric", "$1", "__name__", "(.*)"
)

Это recording rule сохраняет количество активных серий по имени метрики.

• count by (__name__) ({__name__=~"http_.*|rpc_.*"})
  Считает количество активных серий по метрике, соответствующей регулярному выражению http_.* или rpc_.*.

• label_replace(..., "metric", "$1", "__name__", "(.*)")
  Копирует имя метрики в новую метку под названием metric.
  Это позволяет создавать один экземпляр оповещения на метрику, поскольку __name__ не рассматривается как обычная метка.

Настройте порог и область действия recording rule в зависимости от использования меток и обычного поведения ваших наблюдаемых метрик.

После того как recording rule доступно, вы можете определить это многомерное правило оповещения следующим образом:

shell Copy

active_series_per_metric:http_rpc > 100

Grafana Alerting оценивает каждую строку (или временной ряд), возвращаемую recording rule active_series_per_metric:http_rpc, как отдельный экземпляр оповещения, создавая независимые состояния экземпляров оповещений:

Каждое имя метрики (__name__) становится отдельным экземпляром оповещения, поэтому вы сразу видите, какая метрика превышает ожидаемый лимит.

Detect sudden cardinality growth

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

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

shell Copy

delta(active_series_metric[10m]) > 1000

Это оповещение срабатывает, когда количество активных серий увеличивается более чем на 1000 за последние 10 минут.
Настройте временное окно (например, [5m] или [30m]) и порог в соответствии с обычной изменчивостью вашей среды.

Detect high ingestion rate

Даже если кардинальность меток остаётся под контролем, высокая скорость приёма может влиять на производительность Prometheus или увеличивать расходы на observability.

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

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

В Prometheus используйте метрику prometheus_tsdb_head_samples_appended_total, чтобы измерить количество добавленных сэмплов за один сбор:

shell Copy

rate(prometheus_tsdb_head_samples_appended_total[10m]) > 1e5

Запрос правила оповещения возвращает среднюю скорость приёма в секунду за последние 10 минут и срабатывает, когда значение превышает 100 000 сэмплов в секунду.

В Grafana Cloud используйте метрику grafanacloud_instance_samples_per_second для мониторинга общей скорости приёма ваших экземпляров Mimir:

shell Copy

grafanacloud_instance_samples_per_second
  * on (id) group_left(name) grafanacloud_instance_info
> 1e5

Либо лимиты метрик Grafana Cloud основаны на точках данных в минуту (DPM): количестве сэмплов, отправляемых в минуту по всем вашим активным сериям.

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

shell Copy

(
  (grafanacloud_instance_samples_per_second * 60)
  / grafanacloud_org_metrics_included_dpm_per_series
)
> 0.9

• (grafanacloud_instance_samples_per_second * 60)
  Преобразует скорость приёма из точек данных в секунду в точки данных в минуту.

• / grafanacloud_org_metrics_included_dpm_per_series
  Делит текущее использование DPM на лимит DPM, чтобы вычислить коэффициент утилизации от 0 до 1 (где 1 означает, что лимит достигнут).

• > 0.9
  Определяет условие порога для срабатывания, когда использование превышает 90 % лимита DPM.

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

Learn more

Ниже приведён список дополнительных ресурсов, связанных с этим примером:

• Пример многомерных оповещений — Узнайте, как Grafana создаёт отдельные экземпляры оповещений для каждого уникального набора меток.
• Понимание активных серий и DPM в Grafana Cloud — Посмотрите, как активные серии и точки данных в минуту (DPM) используются для расчёта использования метрик в Grafana Cloud.
• Создание оповещений об использовании Grafana Cloud — Настройте оповещения, когда ваше использование или расходы приближаются к заданным лимитам.
• Планирование ёмкости для Mimir — Узнайте, как планировать скорость приёма и ёмкость памяти для сред Mimir или Prometheus.
• Рекомендации Adaptive Metrics — Используйте Adaptive Metrics для автоматического сокращения высококардинальных метрик и контроля расходов на observability.