На этой ссылке указывается причина, по которой скорость должна использоваться для микрометрических показателей.
Representing a counter without rate normalization over some time window is rarely useful, as the representation is a function of both the rapidity with which the counter is incremented and the longevity of the service.
Я до сих пор не могу понять, почему бы просто не просуммировать / подсчитать.
Любой ввод полезен.
Причина, по которой вам нужна функция rate() в запросе Prometheus, заключается в том, чтобы вы могли видеть, какая средняя скорость была в этом временном окне ([10s] в этом примере документа).
Если вместо этого вы используете общую сумму / подсчет, то это число будет продолжать расти, и среднее значение не будет охватывать последний период времени, а вместо этого будет средним значением за все время с момента запуска службы.
Пример:
Представьте, что у вас есть время, которое занимает 1 секунду каждый раз, когда он вызывается, и он вызывается примерно 30 раз каждую минуту:
Count Sum sum/count sum/count (with increase)
First Minute: 30 30 1 1
After 10 hour: 18,000 18,000 1 1
After 1000 hours: 1,800,000 1,800,000 1 1
Пока все выглядит идентично. Теперь предположим, что за последнюю 1 минуту все запросы занимают 10 секунд. Что в 10 раз медленнее. Вы бы хотели узнать об этой последней минуте
Count Sum sum/count sum/count (with increase)
First Minute: 30 300 10 10
After 10 hour: 18,000 18,270 1.015 10
After 1000 hours: 1,800,000 1,800,270 1.00015 10
Функция rate (или increase) гарантирует, что она просто использует изменение в этом окне для расчета. Поскольку показатель работает в течение более длительного периода, большое число маскирует любую волатильность.
Примечание. В моем примере я использовал функцию increase, поскольку ее немного легче понять. Он просто сообщает, насколько увеличился счетчик или сумма в этом окне. rate аналогичен, но просто нормализует его до скорости в секунду.
