Существуют реальные причины, по которым вы не всегда можете получить точное значение скорости / увеличения от Прометея.Один из них - неудачные соскобы, то есть время от времени сбои или сбои или истечение времени ожидания из-за медленного обслуживания, медленного Prometheus или проблемы с сетью.
Другая причина в том, что собранные образцы никогда не бывают точно scrape_interval отдельно: здесь и там всегда будет задержка в несколько миллисекунд или секунд.Итак (для крайнего примера), как вы можете определить точное увеличение за последние 1 минуту, если у вас есть только 2 выборки с интервалом в 63 секунды?Это разница между двумя значениями?Является ли эта разница скорректированной до 60 секунд (то есть / 63 * 60)?
При этом Прометей еще больше загоняет себя в угол, рассматривая только образцы, попадающие строго в требуемый диапазон времени.Поясню: как разумный человек может рассчитать увеличение счетчика за последние 30 минут?Скорее всего, они сейчас возьмут значение указанного счетчика и значение 30 минут назад и вычтут их.Т.е. в терминах PromQL (с учетом сброса счетчика, где это необходимо):
request_duration_bucket - request_duration_bucket offset 30m
То, что вместо этого делает Прометей (при условии scrape_interval из 1m и идеальной временной серии с выборками, разнесенными ровно на 1m)по сути это:
(request_duration_bucket - request_duration_bucket offset 29m) / 29 * 30
Т.е. требуется увеличение в течение 29 минут и экстраполяция его до 30. Из-за наложенных ограничений нет ничего общего с характером рассматриваемой проблемы.
Обратите внимание, что это прекрасно работает со счетчиками, которые увеличиваются плавно и непрерывно.Например, если у вас есть счетчик, который увеличивается на 500 каждую минуту, то взять увеличение за 29 минут и экстраполировать до 30 - это абсолютно правильно.Но для всего, что увеличивается в скачках и подгонках (что является большинством реальных счетчиков), оно будет либо слегка переоценивать увеличение, если оно происходит в течение 29 минут, которое оно фактически производит (точно на 1/29), либо серьезно недооценивать его (если увеличениепроисходит в течение 1 минуты, не включенной в выборку).Это еще хуже, если вы вычисляете скорость / увеличение в диапазоне, охватывающем меньшее количество выборок.Например, если ваш диапазон охватывает в среднем только 5 выборок, завышенная оценка составит 20%, то есть 1 / (5 - 1), и (каждый из) ваш прирост полностью исчезнет через 1 минуту из 5.
Единственный способ, которым яОбойти это ограничение можно (опять-таки, предполагая scrape_interval из 1m) для обратной инженерии экстраполяции Прометея:
increase(request_duration_bucket[31m]) / 31 * 30
Но для этого необходимо, чтобы вы знали о scrape_interval и настраивалипотому что он очень хрупкий (если вы когда-нибудь поменяете scrape_interval, все ваши осторожные настройки будут превращены в ад).
Или, если вы в порядке, ваше увеличение падает до нуля при каждом перезапуске экземпляра:
clamp_min(request_duration_bucket - request_duration_bucket offset 30m, 0)
У меня действительно есть предложенный патч для Prometheus для добавления xrate / xincrease функций, которые на самом деле ведут себя больше, чем вы ожидаете (и как описано выше), но выглядят не оченьвероятно будет принято: https://github.com/prometheus/prometheus/issues/3806