Перейти к основному содержимому

Prometheus + Grafana — запросы

НЕ ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Для кого эта статья​

Если вы гуглите promql example, prometheus query up, grafana prometheus query, node_exporter cpu promql, prometheus rate example, histogram_quantile promql или prometheus grafana docker compose — здесь готовые запросы с разбором каждой части, как в популярной галерее Turtle и Fetch / axios. Можно скопировать строку, вставить в Prometheus или Grafana и сразу увидеть график.

Статья рассчитана на:

  • школьников и студентов — лабораторная по мониторингу, курс DevOps, дипломный стенд «поднял Docker — построил дашборд»;
  • начинающих, которым нужен шаблон «прямо сейчас», но хочется понять, что означает каждый фрагмент PromQL;
  • тех, кто уже поднял Prometheus + Grafana в Docker и ищет рабочий запрос для отчёта или презентации.

Prometheus собирает числа во времени (метрики). Grafana рисует по ним графики. PromQL — язык, на котором вы спрашиваете: «сколько запросов в секунду?», «жив ли сервер?», «диск забит?».

Сначала стенд — потом запросы

Поднять Prometheus и Grafana — практикум, шаг 2 или минимальный compose-стек №8. Теория — мониторинг и метрики. Пошаговый маршрут PromQL — практикум, шаг 3; дашборды — шаг 4.

Загрузка интерактивного демо…

Симулятор выше показывает pull-мониторинг, типы метрик и алерты. Запросы ниже — то, что вводят в поле Expression в Prometheus или Grafana Explore.

Как устроен каждый пример ниже

Задача — что вы получите и типичный поисковый запрос в Google.
PromQL — готовая строка для копирования.
Что делает запрос целиком — логика «снаружи внутрь» простыми словами.
Разбор по частям — таблица «что означает каждый фрагмент».
Что увидите — пример ответа в Table или на графике.
Попробуйте — маленький эксперимент для закрепления.
Частая ошибка — типичный промах новичков.
Так же устроены Turtle, Fetch и Docker Compose — сначала код, потом объяснение.

Как выполнить любой запрос​

Вариант 1 — Prometheus UI (самый быстрый)​

  1. Откройте http://localhost:9090 (или ваш <PORT_PROM> из compose).
  2. Вкладка Graph — график во времени; Table — число «прямо сейчас».
  3. В поле Expression вставьте PromQL.
  4. Execute → переключите Graph / Table.

Разбор интерфейса:

ЭлементСмысл
ExpressionПоле ввода PromQL — как формула в Excel
ExecuteВыполнить запрос к базе метрик
GraphЛинии по оси времени
TableТаблица label → значение на выбранный момент
Evaluation time«На какой момент» считать Table — по умолчанию «сейчас»

Попробуйте: вставьте up → Execute → Table. На минимальном стенде увидите одну строку.

Вариант 2 — Grafana Explore​

  1. http://localhost:3000 → логин admin / admin.
  2. Меню слева → Explore (иконка компаса).
  3. Data source — Prometheus.
  4. Вставьте тот же PromQL → Run query.

Зачем Grafana, если есть Prometheus: красивые дашборды, переменные $job, легенда &#123;&#123;instance&#125;&#125;, несколько панелей на одном экране.

Вариант 3 — панель дашборда​

Dashboards → New → New dashboard → Add visualization → Prometheus — запрос, тип Time series / Stat / Gauge. Подробнее — раздел Grafana.

Как читать PromQL​

PromQL читают слева направо, как формулу:

функция( метрика{фильтр}[окно] ) by (группировка)
ФрагментПростыми словамиПример
http_requests_totalИмя метрики«Счётчик HTTP-запросов»
&#123;job="api"&#125;Фильтр по labelТолько job api
[5m]Окно историиПоследние 5 минут точек
rate(...)Функция«Скорость роста counter в секунду»
sum(...) by (job)АгрегацияСложить и разбить по job

Два адреса — как в Docker Compose:

ОткудаКуда подключаться
Браузер на вашем ПКhttp://localhost:9090 — UI Prometheus
Grafana в контейнере → Prometheushttp://prometheus:9090 — имя сервиса из compose, не localhost

Три типа метрик — запомните раз и навсегда​

ТипПоведениеПример имениКак строить график «в секунду»
CounterТолько растёт (сброс при рестарте)http_requests_totalОбязательно rate() или increase()
GaugeМожет расти и падатьnode_memory_MemAvailable_bytesЧитать как есть, без rate()
HistogramРаспределение по «корзинам»http_request_duration_seconds_bucketrate() по bucket + histogram_quantile()

Аналогии:

  • Counter — одометр автомобиля (километры только прибавляются).
  • Gauge — спидометр (скорость сейчас 60, через минуту 0).
  • Histogram — корзины «сколько запросов уложилось в 0.1 с, 0.5 с, 1 с…».

Частые запросы в Google — куда смотреть​

Ищут в интернетеРаздел ниже
promql up / prometheus up query / check if target is upОбязательный шаблон up
prometheus rate example / rate counter promqlCounter — RPS
node_exporter cpu promql / prometheus cpu usage queryCPU хоста
prometheus memory usage query / node_memoryПамять
prometheus disk usage promql / filesystem fullДиск
http_requests_total promql / 5xx rate prometheusHTTP и ошибки
histogram_quantile promql / p99 latency grafanaP99 latency
promql sum by / avg by exampleАгрегации
grafana prometheus query variable / label_valuesПеременные Grafana
prometheus alert rule example / alertmanagerАлерты
prometheus query empty / no data grafanaТипичные ошибки

Основы — с чего начать​

Обязательный шаблон — up​

Любой мониторинг начинается с вопроса: жив ли сервис, который мы опрашиваем? Prometheus сам создаёт метрику up для каждого target из prometheus.yml.

Задача: увидеть, какие jobs доступны. Поиск: prometheus up query, promql check target.

up

Что делает запрос целиком:

  1. Берёт все time series с именем up.
  2. На каждом scrape Prometheus записывает 1 (успех) или 0 (ошибка).
  3. В Table вы видите текущее значение и labels job, instance.

Разбор по частям:

ЧастьЧто происходитЗачем
upИмя встроенной метрикиНе нужно настраивать — появляется автоматически
Без {...}Без фильтраПоказать все targets сразу
Значение 1Последний scrape успешенExporter ответил, порт открыт
Значение 0Scrape упалСервис выключен, неверный порт, firewall
Label jobИмя job из prometheus.ymlГруппировка «prometheus», «node», «windows»
Label instancehost:port targetКакой именно хост

Что увидите в Table (минимальный стенд):

up{instance="localhost:9090", job="prometheus"}    1

Легенда в Grafana: &#123;&#123;job&#125;&#125; / &#123;&#123;instance&#125;&#125;

Попробуйте: остановите контейнер с exporter → подождите один scrape (15–30 с) → снова up — значение станет 0.

Частая ошибка: путать up с health-check приложения. up=1 значит лишь «Prometheus достучался до /metrics», а не «бизнес-логика работает идеально».

Фильтр по одному job​

Задача: проверить только Prometheus, без остальных targets.

up{job="prometheus"}

Разбор по частям:

ЧастьСмысл
{ }Селектор labels — фильтр, как WHERE в SQL
job="prometheus"Точное совпадение: label job равен строке prometheus
"..."Строковые labels всегда в двойных кавычках

Что увидите: одна строка со значением 1, если job prometheus в конфиге и scrape работает.

Попробуйте: замените на up&#123;job="no-such-job"&#125; — Table будет пустой. Пустой результат ≠ ошибка синтаксиса.

Сколько targets лежат​

Задача: одно число «сколько сервисов недоступно» для панели Stat.

count(up == 0)

Что делает запрос целиком:

  1. up == 0 — для каждого ряда: true (1) если down, false (0) если up.
  2. count(...) — считает, сколько рядов с ненулевым результатом.

Разбор по частям:

ЧастьСмысл
== 0Сравнение — оставляет только «упавшие»
countАгрегатор — количество серий
Результат 0Все targets живы — хороший знак для учебного стенда

Панель Grafana: тип Stat, порог красный если > 0.

Стартовые запросы​

Сколько метрик хранит Prometheus​

Задача: понять, не «раздулась» ли база. Поиск: prometheus_tsdb_head_series.

prometheus_tsdb_head_series

Что делает запрос: возвращает одно число — сколько time series (уникальных комбинаций метрика+labels) сейчас в памяти TSDB.

Разбор:

ЧастьСмысл
prometheus_tsdb_head_seriesВстроенная gauge-метрика самого Prometheus
Рост с 500 до 500 000 за деньЧасто cardinality explosion — слишком много labels (например user_id в каждом запросе)

Что увидите: на маленьком стенде — от сотен до нескольких тысяч. На проде — смотрят динамику, не абсолют.

Версия Prometheus​

prometheus_build_info

Разбор: info-метрика — значение всегда 1, версия сидит в labels version, goversion, revision.

Что увидите в Table:

prometheus_build_info{version="2.53.0", ...}    1

Зачем: на дашборде «инфраструктура» сразу видно, какой бинарник крутится после docker compose pull.

Длительность scrape​

Задача: target отвечает медленно? Поиск: scrape_duration_seconds prometheus.

scrape_duration_seconds

Разбор по частям:

ЧастьСмысл
scrape_duration_secondsСколько секунд длился последний опрос каждого target
Значение 0.0550 ms — нормально
Значение > 1 при scrape_interval: 15sТяжёлый /metrics или сеть тормозит — риск пропуска scrape

Попробуйте: в Grafana постройте Time series — резкий скачок после деплоя часто означает «приложение отдало огромный /metrics».

Примеры запросов​

1. Counter — скорость событий​

Counter (*_total, *_count) монотонно растёт. Если построить график «как есть», получится восходящая линия «сколько всего накопилось с установки» — для мониторинга нагрузки так не смотрят. Нужна скорость — функции rate() или increase().

Откуда берётся http_requests_total — фрагмент текста с /metrics приложения:

# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 15234
http_requests_total{method="POST",status="500"} 3

Каждая строка с уникальными labels — отдельный ряд на графике.

1.1. Запросов HTTP в секунду (RPS)​

Задача: «сколько запросов в секунду в среднем за 5 минут». Поиск: prometheus rate example, http_requests_total rate.

rate(http_requests_total[5m])

Что делает запрос целиком:

  1. Берёт counter http_requests_total за последние 5 минут ([5m]).
  2. rate() считает среднюю скорость роста в единицах в секунду.
  3. Если labels method, status, job различаются — на графике несколько линий.

Разбор по частям:

ЧастьЧто происходитЗачем
http_requests_totalИмя counter-метрикиСколько запросов накопилось с запуска
[5m]Range vector — окно 5 минутБез окна rate не работает
rate(...)Производная counter с учётом сброса при рестарте«Запросов в секунду», а не «всего за всё время»
Несколько рядовРазные &#123;method=..., status=...&#125;Каждая комбинация labels — своя линия

Правило окна: [5m] ≥ 2 × scrape_interval. При scrape 15s разумно [1m]–[5m]; [30s] — минимум, но график шумнее.

Что увидите: если приложение не шлёт http_requests_total, Table пустая — подключите exporter или шаг 5 практикума.

Попробуйте: смените [5m] на [1h] — линия сгладится, реакция на всплеск станет медленнее.

Частая ошибка: применять rate() к gauge (память, температура) — получите бессмысленный «шум». Gauge читают напрямую.

1.2. Сумма RPS по job​

Задача: одна линия «весь RPS сервиса api», без разбивки по status.

sum(rate(http_requests_total[5m])) by (job)

Что делает запрос целиком:

  1. rate(...) — RPS каждого ряда.
  2. sum(...) by (job) — складывает все status/method внутри одного job.

Разбор по частям:

ЧастьСмысл
sumСложить значения matching рядов
by (job)Отдельная сумма для каждого job
Без by (job)Одна линия «всё на всех jobs»

Попробуйте: уберите by (job) — линии схлопнутся в одну. Так проверяют, нужна ли группировка.

1.3. Только ошибки 5xx​

Задача: RPS ответов с кодами 500–599. Поиск: prometheus 5xx rate.

sum(rate(http_requests_total{status=~"5.."}[5m])) by (job)

Разбор по частям:

ЧастьСмысл
&#123;status=~"5.."&#125;Фильтр: label status совпадает с regex
=~«matches regex» (как LIKE в SQL)
5..Цифра 5, затем любые два символа → 500, 502, 503…
!= / !~Отрицание — «всё, кроме»

Что увидите: линия около нуля на здоровом стенде; всплеск при симуляции ошибок.

Попробуйте: замените на &#123;status=~"4.."&#125; — увидите клиентские ошибки 4xx.

1.4. Доля ошибок (error rate)​

Задача: «какой процент запросов — 5xx». Поиск: prometheus error rate query.

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Что делает запрос целиком:

  1. Числитель — RPS ошибок 5xx.
  2. Знаменатель — общий RPS.
  3. Деление — доля от 0 до 1.

Разбор по частям:

ЧастьСмысл
/Побочные labels должны совпадать — здесь оба sum без лишних labels
Результат 0.022% запросов — ошибки
Grafana UnitPercent (0.0–1.0) или умножить на 100

Что увидите: на учебном стенде без трафика — NaN или пусто (деление на 0). Нагрузите API через curl — появятся числа.

Частая ошибка: делить сырые counters без rate() — получится бессмыслица, потому что counters всегда растут.

1.5. Сколько событий за час — increase​

Задача: «сколько запросов за последний час» (не в секунду). Поиск: prometheus increase vs rate.

increase(http_requests_total[1h])

Разбор по частям:

ЧастьСмысл
increaseНасколько вырос counter за окно (с экстраполяцией при сбросе)
[1h]За последний час
rate vs increaserate — в секунду; increase — сумма за окно

Когда что брать:

ВопросФункция
Запросов в секундуrate(...[5m])
Запросов за час / за суткиincrease(...[1h])

2. Gauge — загрузка CPU и памяти​

Gauge — «сколько сейчас». Не оборачивайте в rate() без причины.

2.1. Загрузка CPU (node_exporter)​

Задача: процент занятости CPU по каждому серверу. Поиск: node_exporter cpu promql, prometheus cpu usage query.

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle"}[5m])
  ) * 100
)

Что делает запрос целиком:

  1. node_cpu_seconds_total&#123;mode="idle"&#125; — counter «сколько секунд CPU простаивал».
  2. rate(...[5m]) — доля idle в секунду (от 0 до 1).
  3. avg by (instance) — усреднить по ядрам одного хоста.
  4. * 100 → проценты idle.
  5. 100 - ... → процент занятости.

Разбор по частям:

ШагФрагментСмысл
1node_cpu_seconds_totalCounter от node_exporter — секунды CPU по режимам
2&#123;mode="idle"&#125;Только время простоя
3rate(...[5m])Counter → скорость; здесь «доля idle»
4avg by (instance)На 8 ядрах — 8 рядов → одно число на хост
5100 - (...)*100Инверсия idle → utilization %

Что увидите: без node_exporter — пусто. После шага 5 — линия 5–40% на idle-стенде.

Windows: метрики другие — дашборд Grafana 14694.

Попробуйте: запустите stress-ng --cpu 4 на Linux-хосте — линия CPU вырастет за 1–2 минуты.

Частая ошибка: забыть &#123;mode="idle"&#125; — попадут все режимы CPU, формула станет неверной.

2.2. Свободная память (процент)​

Задача: «сколько RAM свободно в %». Поиск: prometheus memory usage node_exporter.

node_memory_MemAvailable_bytes
/
node_memory_MemTotal_bytes
* 100

Что делает запрос целиком: делит доступную память на общую и умножает на 100.

Разбор по частям:

ЧастьСмысл
MemAvailable_bytesПамять, которую можно выделить без swap (Linux)
MemTotal_bytesОбъём RAM
Результат 73.573.5% RAM свободно
«Занято»100 - (этот запрос)

Grafana: Unit → Percent (0–100).

2.3. Заполнение диска​

Задача: «насколько заполнен каждый раздел». Поиск: prometheus disk usage promql.

(
  1 -
  node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
  /
  node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}
) * 100

Что делает запрос целиком:

  1. avail / size — доля свободного места.
  2. 1 - ... — переворот в «занято».
  3. * 100 — проценты.
  4. Фильтр fstype убирает tmpfs и overlay Docker.

Разбор по частям:

ЧастьСмысл
node_filesystem_avail_bytesСвободные байты на mountpoint
node_filesystem_size_bytesРазмер раздела
`fstype!~"tmpfsoverlay"`
Labels mountpoint="/"Отдельная линия на /, /home, …

Что увидите: несколько линий — по одной на каждый реальный диск.

Попробуйте: добавьте &#123;mountpoint="/"&#125; к обеим метрикам — только корневой раздел.

Алерт > 90% — раздел 6.1.

2.4. Load average (Linux)​

node_load1

Разбор:

ЧастьСмысл
node_load1Средняя длина очереди задач за 1 минуту
ИнтерпретацияСравните с числом CPU: load 8 на 4 ядрах — перегруз

Gauge — без rate().

3. HTTP-запросы и ошибки​

3.1. RPS по методу и статусу​

Задача: разложить трафик — GET 200 отдельно от POST 500.

sum(rate(http_requests_total[5m])) by (method, status)

Grafana Legend: &#123;&#123;method&#125;&#125; &#123;&#123;status&#125;&#125;

Что увидите: несколько линий — GET 200, POST 201, …

3.2. Только успешные GET​

sum(rate(http_requests_total{method="GET", status="200"}[5m])) by (job)

Разбор: два фильтра в селекторе через запятую — И (AND).

3.3. Top-3 job по RPS​

Задача: «кто больше всех нагружает». Поиск: promql topk example.

topk(3, sum(rate(http_requests_total[5m])) by (job))

Разбор:

ФункцияСмысл
topk(3, expr)Только 3 ряда с максимальным значением
bottomk(3, expr)3 наименьших — «самые тихие» сервисы

4. Histogram — latency и перцентили​

Histogram создаёт три семейства рядов:

http_request_duration_seconds_bucket{le="0.1"} 1200
http_request_duration_seconds_bucket{le="0.5"} 3400
http_request_duration_seconds_bucket{le="+Inf"} 3500
http_request_duration_seconds_sum 890.2
http_request_duration_seconds_count 3500
СуффиксСмысл
_bucket&#123;le="..."&#125;Сколько запросов уложилось не дольше le
_sumСумма всех времён (для среднего)
_countКоличество запросов

Label le (less or equal) обязателен в sum by (le) — иначе перцентиль сломается.

4.1. P99 latency HTTP​

Задача: «99% запросов быстрее чем X секунд». Поиск: histogram_quantile promql, p99 latency grafana.

histogram_quantile(
  0.99,
  sum by (le, job) (
    rate(http_request_duration_seconds_bucket[5m])
  )
)

Что делает запрос целиком:

  1. rate(..._bucket[5m]) — скорость попаданий в каждую «корзину» времени.
  2. sum by (le, job) — сложить bucket с сохранением le (границы корзин).
  3. histogram_quantile(0.99, ...) — статистическая оценка 99-го перцентиля.

Разбор по частям:

ЧастьСмысл
0.9999-й перцентиль (0.50 = медиана, 0.95 = P95)
_bucketCounter корзин histogram
leВерхняя граница bucket: 0.1, 0.5, 1, +Inf
sum by (le, job)le нельзя выкинуть — без него quantile бессмысленен
Результат 0.3499% запросов быстрее 340 ms

Grafana: Unit → seconds (s); для ms умножьте весь expr на 1000.

Попробуйте: смените 0.99 на 0.50 — медиана обычно ниже P99.

Частая ошибка: histogram_quantile без rate() по bucket — на counter напрямую quantile не работает.

4.2. P50, P95 и P99 на одной панели​

В Grafana добавьте три Query (A, B, C):

histogram_quantile(0.50, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
QueryLegendСмысл
AP50Медиана — «типичный» запрос
BP955% медленнее
CP991% самых медленных — «хвост»

4.3. Средняя latency (не перцентиль)​

sum(rate(http_request_duration_seconds_sum[5m]))
/
sum(rate(http_request_duration_seconds_count[5m]))

Разбор:

ЧастьСмысл
_sum / _countКлассическое среднее арифметическое
vs P99Среднее тянут редкие таймауты; P99 показывает «худших 1%»

5. Агрегации — sum, avg, by​

5.1. Одна линия — общий RPS​

sum(rate(http_requests_total[5m]))

Разбор: все labels схлопываются — одна цифра «весь кластер».

5.2. Средний сетевой приём по хосту​

avg by (instance) (rate(node_network_receive_bytes_total[5m]))

Разбор: counter байт → rate = байт/с; avg by (instance) — если несколько интерфейсов, усредняет (часто лучше sum by (instance) для total traffic).

5.3. Максимальная загрузка CPU среди хостов job​

max by (job) (
  100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100
)

Разбор: внутри — CPU% каждого instance; снаружи max by (job) — «самый горячий» хост в job.

5.4. Сколько targets живы​

count(up == 1)

Панель Stat: «3 из 3 UP».

6. Запросы для алертов​

В правилах алертинга expr должен стать true (1), когда проблема есть. В Prometheus rule добавляют for: 5m, чтобы не будить ночью из-за секундного всплеска.

6.1. Диск заполнен более чем на 90%​

PromQL (условие):

(
  1 -
  node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
  /
  node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}
) * 100 > 90

Файл rules/disk.yml — разбор по строкам:

groups:
  - name: disk_alerts
    rules:
      - alert: DiskAlmostFull
        expr: |
          (
            1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
              / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}
          ) * 100 > 90
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Диск {{ $labels.mountpoint }} на {{ $labels.instance }} заполнен более чем на 90%"
СтрокаСмысл
groups:Набор правил в одном файле
alert: DiskAlmostFullИмя алерта в UI Alertmanager
expr:PromQL — когда выражение true, алерт pending
for: 5mДолжен быть true 5 минут подряд → firing
labels.severityМаршрутизация (warning / critical)
annotations.summaryТекст для Telegram/Slack; &#123;&#123; $labels.mountpoint &#125;&#125; подставляется из метрики

6.2. Target недоступен​

up == 0

Разбор: самый простой алерт — любой down target.

For: 2m — exporter перезапускается быстрее, чем диск заполняется.

6.3. Error rate выше 5%​

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
> 0.05

Разбор: > 0.05 = больше 5% RPS — ошибки.

6.4. P99 latency выше 2 секунд​

histogram_quantile(
  0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
) > 2

Разбор: 2 — секунды; для ms используйте > 0.5 (500 ms).

6.5. Recording rule — предвычисленный RPS​

Задача: не пересчитывать длинный rate() на каждой панели.

groups:
  - name: api_rules
    interval: 30s
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

Разбор по строкам:

СтрокаСмысл
record:Имя новой метрики, которую Prometheus сам записывает
job:http_requests:rate5mСоглашение имён: level:metric:window
interval: 30sКак часто пересчитывать
expr:Исходный PromQL

На дашборде:

job:http_requests:rate5m

Зачем: дашборд с 20 панелями не нагружает TSDB одним и тем же тяжёлым запросом 20 раз.

Grafana — панели и переменные​

Первая панель — Stat «Targets UP»​

Задача: одно большое число «сколько сервисов мониторим».

Шаг в UIЗначение
VisualizationStat
Querysum(up)
Value options → ShowCalculate → Last
ThresholdsBase green; добавить step red если < 1 (для стенда с 1 target — настройте под себя)

Разбор запроса sum(up): складывает все up (каждый = 0 или 1) → «сколько targets в состоянии up».

Time series — CPU​

ШагЗначение
Query Aформула CPU
Legend&#123;&#123;instance&#125;&#125;
UnitPercent (0–100)
Min / Max0 / 100 (опционально — фиксирует шкалу)

Legend &#123;&#123;instance&#125;&#125;: подставляет label instance в подпись линии — 192.168.1.10:9100.

Переменная $job​

Dashboard settings → Variables → Add variable

ПолеЗначениеЗачем
NamejobВ запросах пишут $job
TypeQueryСписок из Prometheus
Data sourcePrometheus
Querylabel_values(up, job)Все значения label job
Multi-valueOnВыбрать несколько jobs
Include All optionOnПункт «All» в dropdown

Запрос на панели:

sum(rate(http_requests_total{job="$job"}[5m])) by (status)

Разбор:

ЧастьСмысл
$jobGrafana подставляет выбранное значение
$job = AllРазворачивается в regex `job=~"a
by (status)Отдельная линия на 200, 404, 500…

Попробуйте: смените job в dropdown — график перестроится без правки PromQL.

Переменная $instance (зависимая)​

Query variable:

label_values(up{job="$job"}, instance)

Разбор: список instance только для выбранного job — «каскадный» фильтр.

Запрос панели:

up{job="$job", instance="$instance"}

Explore — сравнение «вчера / сегодня»​

  1. Explore → введите sum(rate(http_requests_total[5m])).
  2. Справа Split — два окна.
  3. В правом окне Time range → Yesterday.

Зачем: после деплоя видно, вырос ли RPS или latency относительно вчерашнего дня.

Селекторы — шпаргалка​

# точное совпадение
http_requests_total{job="api", method="GET"}

# regex «начинается с prod»
up{instance=~"prod-.*"}

# исключить namespace
http_requests_total{namespace!="kube-system"}

# несколько jobs через «или»
up{job=~"prometheus|node"}

# математика — labels слева и справа должны совпадать
node_filesystem_avail_bytes / node_filesystem_size_bytes
ОператорСмыслПример
=равноjob="api"
!=не равноstatus!="200"
=~regex matchstatus=~"5.."
!~regex not match`fstype!~"tmpfs

Типичные ошибки​

СимптомПричинаИсправление
Пустой графикНет метрики на стендеStatus → TSDB или &#123;__name__=~".+"&#125;
rate() на gaugeGauge — не counterУберите rate, читайте напрямую
Дёргающийся графикОкно [1m] при scrape 30sУвеличьте до [5m]
Все линии слиплисьНет by (label)sum by (job) или by (status)
P99 = NaNМало точек в bucketПодождите 2–3 × scrape_interval
Grafana No data, Prometheus OKURL datasourcehttp://prometheus:9090, не localhost
parse errorКавычки labelsjob="api", не job=api
Cardinality

Не кладите в labels user_id, order_id, полный URL — на каждое значение Prometheus создаёт отдельный ряд. Миллионы рядов «положат» TSDB. Для id запроса — логи и трассировки.

Переиспользуемые шаблоны​

Availability — три панели Stat​

count(up == 1)
count(up == 0)
avg(up)
ПанельСмысл
1Сколько targets UP
2Сколько DOWN (должно быть 0)
3Доля доступных 0…1

HTTP dashboard — RPS, errors, P99​

sum(rate(http_requests_total[5m]))
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

Три панели — «здоровье API» для слайда лабораторной.

node_exporter — хост целиком​

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
(1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100
ПанельМетрика
CPU %Занятость процессора
Memory %Свободная RAM
Disk %Заполненность /

Связь с практикумом​

ШагЧто отработать из этой галереи
2 — установкаup, prometheus_build_info, UI Graph
3 — PromQLCounter, Gauge, Histogram
4 — GrafanaПанели, переменные, Explore
5 — exportersnode_*, /metrics приложения
6 — алертыРаздел 6, YAML rules

Официальные материалы​

Связанные темы

См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").

Ещё 60 статей в разделе

Последнее обновление
Освоение главы0%