Метрики и Prometheus

Что такое Prometheus

Метрики — это числа во времени. Кто-то должен их собирать, хранить и отдавать на графики. Стандарт для этого в облачном мире — Prometheus. Это база данных временных рядов плюс система сбора, заточенная под метрики.

Главная особенность — pull-модель. Prometheus не ждёт, пока сервисы пришлют метрики, а сам ходит к ним и забирает. Это упрощает сервисы (им не нужно знать про Prometheus) и даёт самому Prometheus контроль над частотой сбора.

Pull и эндпоинт /metrics

Сервис, который хочет отдавать метрики, поднимает HTTP-эндпоинт (по соглашению /metrics) и отдаёт там текущие значения в простом текстовом формате:

$ curl http://app:8080/metrics
# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 1530
http_requests_total{method="GET",status="500"} 12
process_resident_memory_bytes 4.12e+08

Prometheus периодически (раз в 15–30 секунд) ходит на этот эндпоинт у всех сервисов. Это называется scrape. Адреса целей он берёт из своего конфига или находит автоматически через service discovery.

Типы метрик

Prometheus различает несколько типов:

• Counter — только растёт (или сбрасывается в 0 при рестарте). Количество запросов, ошибок, обработанных задач. По нему считают скорость: «сколько запросов в секунду».
• Gauge — может расти и падать. Текущая память, число активных соединений, температура. Снимок «сколько прямо сейчас».
• Histogram — распределение по корзинам. Задержка запросов: сколько уложилось в 100 мс, сколько в 500 мс. Перцентили (p95, p99) считает сам Prometheus функцией histogram_quantile, уже по собранным корзинам со всех инстансов.
• Summary — тоже про распределение, но перцентили считает сам сервис и отдаёт готовыми числами. Настраивать корзины не нужно, зато и посчитать что-то новое поверх нельзя: полученные перцентили нельзя складывать между инстансами. Общий p99 по кластеру из summary не получить.

Histogram и summary решают одну задачу с разных сторон, и выбор между ними сводится к одному вопросу. Если метрика с одного инстанса и корзины подбирать лень, хватит summary. А когда нужна агрегация по всему сервису или гибкость в запросах, берут histogram. На практике в облачных сервисах почти всегда histogram.

Путать counter и gauge — частая ошибка. Счётчик запросов всегда растёт, поэтому смотрят не на само значение, а на его прирост.

Лейблы

У метрики могут быть лейблы — пары ключ-значение, которые режут одну метрику на измерения:

http_requests_total{method="GET", status="200", path="/api"}

Лейблы позволяют спросить «сколько было 500-х ошибок на /api», не заводя отдельную метрику под каждый случай. Но у лейблов есть ловушка: каждое уникальное сочетание значений — отдельный временной ряд. Класть в лейбл что-то с огромным числом значений (ID пользователя, URL с параметрами) взрывает количество рядов и кладёт Prometheus. Это называется high cardinality.

Запросы и алерты

Данные достают языком PromQL:

rate(http_requests_total{status="500"}[5m])

Это «скорость 500-х ошибок за последние 5 минут». Поверх таких запросов строят графики (обычно в Grafana) и алерты: «если скорость ошибок выше порога 5 минут, буди дежурного».

Что важно запомнить

Prometheus собирает метрики pull-моделью: сам ходит на /metrics сервисов (scrape) и хранит как временные ряды.

Типы: counter только растёт (считают rate), gauge меняется в обе стороны, histogram копит корзины и даёт перцентили с агрегацией по инстансам, summary считает перцентили на стороне сервиса и агрегации не допускает. Лейблы режут метрику на измерения, но высокая кардинальность лейблов кладёт систему.

Запросы пишут на PromQL, графики смотрят в Grafana, поверх вешают алерты.

В следующих темах метрики соединяются с логами и трейсами в общий мониторинг.