Перейти к содержанию

9. Производительность и best practices

Тяжёлый дашборд — это не только «долго крутится кружок»: он многократно бьёт по Prometheus, раздувает трафик и может уронить Grafana при одновременном открытии онколлом. Ниже — как оптимизировать запросы, держать кардинальность под контролем, проектировать дашборды без перегруза и снижать нагрузку на Prometheus.

См. также: производительность Prometheus.

Откуда берётся нагрузка

Источник Комментарий
Много панелей × много запросов Каждый refresh дашборда = пачка запросов к TSDB
Высокая кардинальность Сотни рядов на график → большой ответ и рендер
Слишком мелкий шаг min step / разрешение времени ниже scrape_interval не даёт новой правды, но даёт нагрузку
Длинный time range Больше точек, тяжелее агрегации

Оптимизация запросов (Prometheus datasource)

Согласовать интервалы

В настройках datasource (JSON) полезно задать:

jsonData:
  timeInterval: 30s      # не чаще реального scrape_interval
  queryTimeout: 60s      # защита от «зависших» запросов

На панели: Query options → Min interval (или $__interval) — не форсировать 1s, если scrape 30s.

Упростить PromQL

Было (тяжело) Стало (легче)
sum(rate(huge[5m])) без by на 10k контейнеров sum by (deployment) (...) + переменная $deployment
Десятки or в одном запросе Несколько recording rules или отдельные панели
histogram_quantile на сыром потоке с лишними лейблами Агрегат в recording rule (см. PromQL в Grafana)

Комментарий: откройте Query inspector на панели и смотрите Stats (время, размер ответа).

Cardinality control в дашбордах

  • Переменные: не включайте Multi + All на лейблах с тысячами значений без regex-фильтра.
  • topk / bottomk для «топ N» вместо вывода всех серий.
  • Repeating panels — осторожно: N панелей × M запросов.
# Пример: только 10 самых нагруженных pod по CPU
topk(10, sum by (pod) (rate(container_cpu_usage_seconds_total{namespace="$ns"}[5m])))

Дизайн дашбордов: не перегружать

Принцип Смысл
Один экран — одна история «Здоровье API» отдельно от «Ёмкость кластера»
3–6 ключевых графиков вверху Остальное — свернутые rows
Правильные агрегации Для алертов/SLO — то же, что в recording rules, без расхождений
Лимит легенды Скрыть лишние лейблы в легенде, Max data points в разумных пределах

Anti-pattern: 40 панелей на одной вкладке «на всякий случай» — при инциденте всё равно смотрят 3–4.

Практика: ускорить «медленный» дашборд

  1. Query inspector на самой долгой панели — какой запрос, сколько серий.
  2. Сузить time range по умолчанию (например 6h вместо 30d для детальных рядов).
  3. Поднять Min interval до ≥ 2× scrape_interval.
  4. Вынести тяжёлый кусок в recording rule в Prometheus; в Grafana — один простой селектор.
  5. Убрать repeat или сократить число значений переменной.

Практика: снизить нагрузку на Prometheus

  • Разнести «тяжёлые» дашборды по разным командам и расписаниям обновления (реже refresh у редко смотримых).
  • Включить caching где поддерживается (зависит от архитектуры: query-frontend, Mimir, proxy).
  • Alerting на длинных окнах не дублировать теми же тяжёлыми запросами, что и дашборд — вынести в recording rule.
# Пример recording rule (сторона Prometheus) — один раз считать, много панелей читают
groups:
  - name: dashboard_helpers
    interval: 1m
    rules:
      - record: cluster:container_cpu_usage:sum5m
        expr: sum by (namespace) (rate(container_cpu_usage_seconds_total[5m]))

Grafana как сервис

Ресурс Замечание
CPU/RAM pod Grafana Растёт с числом одновременных пользователей и сложностью рендера
БД Grafana (Postgres/SQLite) Большое число избранного/истории — планировать retention и бэкап
Реплики Несколько инстансов за LB при stateless + общая БД

Чеклист

# Практика
1 timeInterval, timeouts, min interval согласованы со scrape
2 Тяжёлый PromQL → recording rules
3 Переменные и topk против взрыва кардинальности
4 Дашборды дробить по ролям и сценариям
5 Раз в квартал — «аудит» самых тяжёлых дашбордов по метрикам Ingress/Gateway и самого Prometheus

Дополнительные материалы