Перевод статьи подготовлен в преддверии старта курса «Мониторинг и логирование: Zabbix, Prometheus, ELK».
Ранее мы рассматривали счетчик (counter), измеритель (gauge) и сводку (summary). Теперь же давайте поговорим о том, как работает гистограмма (histogram) в Prometheus.
Гистограмма имеет некоторые сходства со сводкой. Гистограмма — это комбинация различных счетчиков. Как и сводные метрики, метрики гистограмм используются для отслеживания размерных показателей событий, зачастую их продолжительности, с помощью метода
Ниже приведен пример формата экспозиции Prometheus с меткой
Однако существуют очень редкие случаи где
Примечательная часть гистограммы — временные ряды
Чтобы вычислить, скажем, квантиль 0,9 (90-й процентиль), вам следует использовать:
Одно большое преимущество гистограмм перед сводками заключается в том, что вы можете агрегировать bucket-ы перед вычислением квантиля — следя за тем, чтобы не потерять метку
В дополнении к агрегируемости, гистограммы дешевле на клиенте, так как счетчики быстро инкрементируются. Так почему бы не использовать гистограммы всегда? Есть длинный ответ, но короткая версия состоит в том, что с гистограммами вы должны предварительно выбирать свои bucket-ы, и затраты перемещаются с клиента на сам Prometheus из-за количества элементов bucket. Десять bucket-ов по умолчанию охватывают типичный веб-сервис с задержкой в диапазоне от миллисекунды до секунды, и в некоторых случаях вам может понадобиться это изменить. Здесь, например, они были переопределены, чтобы лучше отслеживать запросы на PromQL, которые по умолчанию имеют двухминутный тайм-аут. Наличие более десятка bucket-ов даст более точные результаты, но может также наплодить множество временных рядов. Особенно в сочетании с другими метками.
При использовании системы мониторинга в реальном времени, такой как Prometheus, цель должна заключаться в том, чтобы обеспечить аналитическую ценность, достаточную для принятия инженерных решений на ее основе. Например, знать, что задержка 90-го процентиля увеличилась на 50 мс, важнее, чем знать, составляет ли сейчас значение 562 мс или 563 мс, и обычно для этого хватает десяти bucket-ов. Если вам нужен точный ответ, вы всегда можете рассчитать его позже из своих логов. В случае, если есть bucket-ов слишком много, их можно отбросить при обработке данных, как было показано ранее. В более экстремальных случаях вы можете полностью игнорировать серию
В заключение, гистограммы допускают агрегируемое вычисление квантилей, хотя нужно брать во внимание количество элементов. Помните, что сводка без квантилей — более дешевый вариант, если вам не нужна гистограмма.
Подробнее о курсе
Ранее мы рассматривали счетчик (counter), измеритель (gauge) и сводку (summary). Теперь же давайте поговорим о том, как работает гистограмма (histogram) в Prometheus.
Гистограмма имеет некоторые сходства со сводкой. Гистограмма — это комбинация различных счетчиков. Как и сводные метрики, метрики гистограмм используются для отслеживания размерных показателей событий, зачастую их продолжительности, с помощью метода
observe. Средства для упрощения хронометража обычно такие же, как и для сводок. В чем они различаются, так это в обработке квантилей.Ниже приведен пример формата экспозиции Prometheus с меткой
handler:# HELP prometheus_http_request_duration_seconds Histogram of latencies for HTTP requests.
# TYPE prometheus_http_request_duration_seconds histogram
prometheus_http_request_duration_seconds_bucket{handler="/",le="0.1"} 25547
prometheus_http_request_duration_seconds_bucket{handler="/",le="0.2"} 26688
prometheus_http_request_duration_seconds_bucket{handler="/",le="0.4"} 27760
prometheus_http_request_duration_seconds_bucket{handler="/",le="1"} 28641
prometheus_http_request_duration_seconds_bucket{handler="/",le="3"} 28782
prometheus_http_request_duration_seconds_bucket{handler="/",le="8"} 28844
prometheus_http_request_duration_seconds_bucket{handler="/",le="20"} 28855
prometheus_http_request_duration_seconds_bucket{handler="/",le="60"} 28860
prometheus_http_request_duration_seconds_bucket{handler="/",le="120"} 28860
prometheus_http_request_duration_seconds_bucket{handler="/",le="+Inf"} 28860
prometheus_http_request_duration_seconds_sum{handler="/"} 1863.80491025699
prometheus_http_request_duration_seconds_count{handler="/"} 28860_sum и _count работают точно так же, как и для сводки, и могут быть использованы для получения средней продолжительности выполнения в течение последних пяти минут: rate(prometheus_http_request_duration_seconds_sum[5m]
/
rate(prometheus_http_request_duration_seconds_count[5m])Однако существуют очень редкие случаи где
_sum отсутствует, например, в некоторых метриках из экспортера MySQLd.Примечательная часть гистограммы — временные ряды
_bucket, которые фактически являются гистограммной частью метрики. Более конкретно, это счетчики, которые формируют кумулятивную гистограмму. le обозначают меньше или равно. Таким образом, 26688 запросов заняли меньше или равно 200мс, 27760 запросов заняли меньше или равно 400мс, а всего было 28860 запросов. Значения в bucket-ах будут монотонно неубывающими, а +Inf bucket будет иметь наибольшее значение. +Inf bucket должен присутствовать всегда и соответствовать значению _count.Чтобы вычислить, скажем, квантиль 0,9 (90-й процентиль), вам следует использовать:
histogram_quantile(0.9,
rate(prometheus_http_request_duration_seconds_bucket[5m])
)Одно большое преимущество гистограмм перед сводками заключается в том, что вы можете агрегировать bucket-ы перед вычислением квантиля — следя за тем, чтобы не потерять метку
le:histogram_quantile(0.9,
sum without (handler)(
rate(prometheus_http_request_duration_seconds_bucket[5m])
)
)В дополнении к агрегируемости, гистограммы дешевле на клиенте, так как счетчики быстро инкрементируются. Так почему бы не использовать гистограммы всегда? Есть длинный ответ, но короткая версия состоит в том, что с гистограммами вы должны предварительно выбирать свои bucket-ы, и затраты перемещаются с клиента на сам Prometheus из-за количества элементов bucket. Десять bucket-ов по умолчанию охватывают типичный веб-сервис с задержкой в диапазоне от миллисекунды до секунды, и в некоторых случаях вам может понадобиться это изменить. Здесь, например, они были переопределены, чтобы лучше отслеживать запросы на PromQL, которые по умолчанию имеют двухминутный тайм-аут. Наличие более десятка bucket-ов даст более точные результаты, но может также наплодить множество временных рядов. Особенно в сочетании с другими метками.
При использовании системы мониторинга в реальном времени, такой как Prometheus, цель должна заключаться в том, чтобы обеспечить аналитическую ценность, достаточную для принятия инженерных решений на ее основе. Например, знать, что задержка 90-го процентиля увеличилась на 50 мс, важнее, чем знать, составляет ли сейчас значение 562 мс или 563 мс, и обычно для этого хватает десяти bucket-ов. Если вам нужен точный ответ, вы всегда можете рассчитать его позже из своих логов. В случае, если есть bucket-ов слишком много, их можно отбросить при обработке данных, как было показано ранее. В более экстремальных случаях вы можете полностью игнорировать серию
_bucket-ов и полагаться на среднее значение от _sum и _count.В заключение, гистограммы допускают агрегируемое вычисление квантилей, хотя нужно брать во внимание количество элементов. Помните, что сводка без квантилей — более дешевый вариант, если вам не нужна гистограмма.
Подробнее о курсе
