Какой тип метрики Prometheus лучше всего подходит для графика количества заказов в секунду?

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

Понимаете ли вы модель данных Prometheus: приложение отдаёт текущее значение, а скорость Prometheus считает сам при запросе. Следом обычно спрашивают, как сложить заказы со всех инстансов и чем rate отличается от increase.

Как отвечать

Нужен Counter: монотонно растущий счётчик, который приложение увеличивает на каждом заказе. «Заказов в секунду» в приложении не считают, это делает PromQL:

• rate(orders_total[5m]): средняя скорость в секунду за окно. Сброс счётчика при рестарте пода rate распознаёт и учитывает;
• increase(orders_total[1h]): прирост за окно, то есть «сколько заказов за час». По сути это rate, умноженный на длину окна;
• irate: скорость по двум последним точкам. Реагирует быстрее, но график дёрганый, для дашбордов и алертов обычно берут rate;
• sum by (channel) (rate(orders_total[5m])): суммарная скорость по всем инстансам с разбивкой по каналу.

Окно для rate берут минимум в четыре интервала скрейпа: при скрейпе раз в 15 секунд [1m] ещё работает, но пропуск одного скрейпа уже даёт провалы.

В Spring Boot счётчик заводят через Micrometer: Counter.builder("orders.created").tag("channel", channel).register(registry), затем increment() на каждый заказ. В Prometheus он приедет как orders_created_total, суффикс _total реестр добавит сам. В голом client_java версий 1.x классы лежат в пакете io.prometheus.metrics.core.metrics, старый io.prometheus.client относится к устаревшему simpleclient.

Если время обработки заказа уже пишется в Timer или Histogram, у него есть серия _count. Это тот же счётчик, и отдельный Counter не нужен.

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

Берут Gauge и сами считают «заказов за секунду» в приложении. Всё, что случилось между скрейпами, теряется, а корректно сложить такие значения с нескольких подов уже нельзя.

Суммируют до rate, например через подзапрос rate(sum(orders_total)[5m:]). Сначала rate по каждой серии, потом sum, иначе рестарт одного пода выглядит как обвал и всплеск на графике.

Вешают на счётчик метку с order_id или user_id. Каждое значение метки создаёт новую серию, и Prometheus захлёбывается от кардинальности.