Какую метрику Prometheus использовать для подсчета RPS сервера

Что проверяют

Понимаете ли вы типы метрик Prometheus и то, что RPS не хранится, а вычисляется запросом. Следом обычно просят объяснить разницу между rate и irate и спрашивают, какие лейблы вы повесите на метрику.

Как отвечать

Для RPS нужен Counter, монотонно растущий счётчик запросов, например http_requests_total с лейблами method, route и code. Сам по себе он показывает число запросов с запуска процесса, а скорость даёт PromQL:

• rate(http_requests_total[5m]): средняя скорость в секунду за окно, сброс счётчика при рестарте учитывается сам. Окно берут хотя бы в четыре интервала скрейпа, чтобы в нём было несколько точек даже при пропущенном сборе;
• sum by (route) (rate(...)): RPS по эндпоинтам, sum без группировки даст общий RPS сервиса по всем подам;
• irate: считает по двум последним точкам окна. Хорошо показывает всплески на детальном графике, но для алертов слишком шумный;
• increase: число запросов за период, например за сутки.

Часто отдельный счётчик не нужен вовсе: у гистограммы http_request_duration_seconds уже есть серия _count, и rate(http_request_duration_seconds_count[5m]) даёт тот же RPS, а сама гистограмма ещё и латентность.

В Go это prometheus/client_golang: promauto.NewCounterVec для объявления метрики и promhttp.Handler() для эндпоинта /metrics. Готовые обёртки promhttp.InstrumentHandlerCounter и promhttp.InstrumentHandlerDuration навешиваются на хендлер как middleware.

Где спотыкаются

Используют Gauge и сами обнуляют его раз в секунду. Такой RPS зависит от момента скрейпа и теряет данные между сборами, а у Counter с rate этих проблем нет.

Кладут в лейбл сырой путь запроса или id пользователя. /users/123 и /users/124 становятся разными временными рядами, кардинальность растёт без предела и роняет Prometheus. В лейбл идёт шаблон маршрута, /users/{id}.

Суммируют раньше, чем берут скорость, например в recording rule складывают счётчики всех подов, а потом считают rate от суммы. Рестарт одного пода обнуляет его слагаемое, rate принимает это за сброс всего счётчика и рисует ложный всплеск. Правильный порядок: сначала rate по каждому ряду, потом sum.