Прометей + Графана - данные графика сдвинуты на 2 минуты?
У меня Прометей соскабливает гистограмму задержки запроса с моего сервера API каждые 1m.
Затем я визуализирую гистограммы как тепловую карту в Grafana. Это выглядит так:
Мой запрос:
sum(http_request_duration_seconds_bucket) by (le)
-
sum(http_request_duration_seconds_bucket offset 1m) by (le)
Я понимаю, что это нужно сделать: возьмите вектор ведра в соответствующее время и вычтите вектор ведра за 1 минуту до того, как получить вектор ведра для этой минуты (гистограммы накапливаются и не очищают свои ведра при каждом цикле)
Но проблема в том, что, глядя в свои журналы запросов, я вижу:
...
13:56:13 GET 304 3 ms
13:56:18 GET 304 4 ms
13:56:18 POST - -
13:56:23 GET 304 4 ms
13:56:28 GET 304 0 ms
13:56:32 GET 304 3 ms
13:56:38 GET 304 6 ms
13:56:42 GET 304 4 ms
13:56:48 GET 304 9 ms
13:56:53 GET 304 2 ms
13:56:54 POST - -
13:56:58 GET 304 2 ms
13:57:01 GET 200 2 ms
13:57:03 GET 304 6 ms
13:57:08 GET 304 4 ms
13:57:12 GET 304 3 ms
13:57:18 POST - -
13:57:21 GET 304 8 ms
13:57:21 GET 304 8 ms
13:57:23 GET 304 4 ms
...
Как видите, первый раз запросы среды выполнения «Inf» были в 13:56, но если мы посмотрим на гистограмму, мы не увидим этого до 13:58.
Почему данные сдвинуты на 2 минуты?
Ответы 2
У Grafana есть кнопка Инспектор запросов, когда вы редактируете панель. Вы можете использовать это, чтобы увидеть точный ответ, возвращаемый Прометеем, и выяснить, вносит ли сдвиг Графана или Прометей (или оба).
Одна из возможных причин, по которой я вижу, что это происходит на стороне Prometheus, - это очистка разрешения. Если вы чистите только один раз в минуту, может потребоваться до одной минуты, чтобы увидеть увеличение (со средней задержкой вдвое меньше). Если, кроме того, вы записали правила, обрабатывающие очищенные данные, и отображаете результаты этих записанных правил, это также увеличивает задержку.
Таким образом, с интервалом очистки в 1 минуту и интервалом оценки в 1 минуту вы можете увидеть сдвиг от 0 до 2 минут (даже без учета джиттера из-за медленных целей и / или перегруженного экземпляра Prometheus).
Редактировать: Чуть не забыл, вы, скорее всего, также захотите использовать increase / rate вместо вычитания, чтобы правильно обрабатывать перезапуски экземпляров. (К сожалению, increase / rate исказит ваши показатели на величину, пропорциональную диапазону, разделенному на интервал очистки, и пропустит некоторые образцы, но вам нужно выбрать свой яд.)
Кроме того, хотя у меня есть возможность спросить, как вы думаете, сможет ли временные ряды засыпки улучшить ситуацию после его реализации? Я мог бы каким-то образом сказать системе, чтобы она помещала запросы во временные интервалы, в которых они возникли, а не во временные интервалы, в которых они закончились / были очищены?
Думаю, я могу объяснить задержку. Здесь есть два аспекта:
Я ошибочно предположил, что Прометей хранил временные метки отдельных событий. Вместо этого данные в гистограмме собираются в тот момент, когда происходит очистка, и данные помечаются как происходящие в этот момент.
Я забыл детали своего собственного инструментария - я добавляю точку данных в метрику гистограммы, используя клиентскую библиотеку Prometheus на данный момент запрос заканчивается (а как может быть иначе? Мы хотим знать задержку!)
Итак, если данные для запроса в 13:56:18 (первый длительный запрос) были добавлены к гистограмме в момент возврата запроса (более 30 секунд после этой точки), скажем, в 13:57:15, а затем время очистки было: [13:56:10, 13:57:10, 13:58:10], то запрос, который началось на 13:56:18 будет в конечном итоге частью очистки 13:58.
Спасибо за развернутый ответ! Думаю, вы указали мне правильное направление, подумав о временах очистки. Также совет по увеличению / скорости в целом хорош. Не могли бы вы проверить мой ответ и понять, имеет ли он смысл?