Самая полезная метрика Прометея - это счетчик . По сути, это вечно увеличивающееся значение времени жизни процесса (которое начинается заново с нуля каждый раз, когда отслеживаемый процесс перезапускается). Основываясь на этом, вы можете вычислить, насколько увеличилась отслеживаемая метрика за любой временной интервал (предыдущие 5 минут, вчера, с начала года), просто вычитая его значение в начале диапазона из его значения в конце. (И корректировка любого сброса до нуля.) Prometheus делает это автоматически для вас с помощью функций increase()
и rate()
, которые он обеспечивает.
Для ваших конкретныхВ случае использования среднее число элементов, обработанных за единицу времени, будет, например, rate(items_processed_total[5m])
, где rate()
предоставлено Прометеем;items_processed_total
- это счетчик, который вы должны будете определять и увеличивать каждый раз, когда обрабатываете элемент (или его партию);и 5m
- это временной интервал, по которому вы хотите рассчитать среднее значение (очевидно, что вы можете использовать произвольное значение, если оно в несколько раз превышает интервал очистки). Это даст вам среднее значение QPS, т. Е. Количество обработанных элементов в секунду, усредненное за 5 минут.
Для вашего второго пункта маркера (среднее время обработки запроса) вам понадобятся два счетчика, скажем requests_processed_total
(увеличивается на 1 каждый раз, когда вы заканчиваете обработку запроса) и request_processing_time_seconds_total
(который увеличивается на request_end_time - request_start_time
каждый раз, когда вы заканчиваете обработку запроса). Тогда искомое значение будет получено как
rate(request_processing_time_seconds_total[5m]) / rate(requests_processed_total[5m])
Т.е. на сколько увеличилось время обработки запроса за предыдущие 5 минут, поделенное на количество запросов, обработанных за предыдущие 5 минут. (Или произвольный диапазон времени по вашему выбору.)
Для вашей конечной точки маркера (среднее время ожидания между запросами), это либо
1 / rate(requests_processed_total[5m])
(т. Е. Обратное число "запросов в секунду). ", т.е." секунд на запрос "), если вы хотите среднее время между запросами.
Или, если вас интересует время простоя между запросами:
(1 - rate(request_processing_time_seconds_total[5m]))
/
rate(requests_processed_total[5m])
, если вы 'интересует только время простоя между запросами. Чтобы объяснить это, 1 - rate(request_processing_time_seconds_total[5m])
- это процент времени, в течение которого ваша работа простаивает (100% - время обработки);и деление его на QPS - это то же самое, что умножение на средний интервал между запросами (см. выше).
Последнее выражение предполагает, что это однопоточный процесс, который либо обрабатывает запрос, либо не используется. Если вы фактически обрабатываете запросы параллельно, «простой» не имеет большого смысла как метрика.
И, наконец, в случае, если вас интересует больше, чем средние значения (например, медиана или другие процентили) гистограммы великолепны. Если бы они не использовали на порядок больше метрик (и хранилище, и ЦП и т. Д.), Я бы использовал их для всего. Например, гистограмма времени обработки запроса даст вам среднее время обработки, а также приблизительное среднее время обработки и любой другой процентиль, который вы хотите (предполагаемый). Плюс, конечно, количество запросов и общее время обработки (которые встроены). И они позволяют вам создавать агрегированные метрики для нескольких экземпляров, в отличие от итоговой метрики.