🔖Когда графики в Grafana врут?
Хотите разобраться почему графики показывают разные данные в grafana на разных интервалах и дипазонах? Сейчас мы с вами за 4 шага разберемся почему так происходит…
Я специально сделал гремучую смесь параметров в панели, чтобы детально показать что происходит под капотом. Нам важны три цифры со скрина:
• Окно в функции PromQL: increase(...[5m]).
• Interval: 10m.
• Глобальный диапазон: Last 7 days.
1. Какую сетку строит Grafana?
Смотрим на поле Interval – Grafana уже сама все посчитала и поставила 10m.
Тут сработала математика самой Grafana: она взяла 7 дней, разделила на ширину панели в пикселях (Max data points = 1146), получила число в районе 8.6 минут и округлила его вверх до ближайшего красивого шага – 10 мин. Формула подсчета интервала там есть прямо рядом Time range / max data points.
В данном примере Grafana выполнит range query с шагом 10 минут: 12:00, 12:10, 12:20, 12:30...
Немного отвлечемся на другой немаловажный параметр - Min interval. Представим, что мы решили посмотреть детально и выделили на графике узкий отрезок – всего в 15 мин (вместо текущих 7 дней).
Исходя из формулы Interval = Time range / max data points получились бы интервалы в 0.76 сек. и это очень мало для корректной визуализации. Тут в игру вступает Min interval = 1m:
• Grafana видит, что расчетный шаг (0.76 сек) меньше, чем лимит (1m).
• Она говорит: “Окей, я не буду частить. Буду просить данные с шагом строго 1 мин.”.
По сути Min Interval это защита от бессмысленных маленьких интервалов.
С этим вроде разобрались – погнали смотреть что в запросе PromQL.
2. Какое окно считает Prometheus?
Когда Prometheus выполняет запрос для каждой точки, он видит твою функцию increase(...[5m]). Это значит в этой конкретной точке оглянись назад ровно на 5 минут и посчитай прирост счетчика.
Складываем это вместе и смотрим на хронологию:
• Точка 12:10: Prometheus смотрит назад на 5 мин. – оценивает отрезок с 12:05 до 12:10. Отдает значение. Grafana рисует точку.
• Точка 12:20: Prometheus делает шаг в 10 мин., встает на новую точку и снова смотрит назад на 5 минут – оценивает отрезок с 12:15 до 12:20.
3. Главный инсайт – на графике появились “слепые зоны”!
Заметили, что произошло?
• 1 точка покрыла интервал 12:05 - 12:10.
• 2 точка покрыла интервал 12:15 - 12:20.
А куда делся промежуток времени с 12:10 до 12:15? Он просто выпал из расчетов. Он не попал ни в первую точку, ни во вторую.
Когда интервал шага на графике (10m) больше, чем окно в самой функции ([5m]) – наше временное окно больше не скользит с пересечением. Оно начинает прыгать через промежутки времени, оставляя слепые зоны.
Если в промежуток с 12:10 до 12:15 бахнет жесткий всплеск – график его вообще не покажет, потому что Prometheus физически не заглянет в этот пятиминутный отрезок.
4. Как это исправить, чтобы график стал адекватным?
Самый правильный путь – переписать запрос на rate с динамическим интервалом $__rate_interval = max( $interval + scrape_interval , 4 × scrape_interval ).
$__rate_interval значительно уменьшает вероятность появления слепых зон и делает поведение графика гораздо стабильнее при смене диапазона.
rate(postfix_smtp_messages_processed_total{...}[$__rate_interval])
На самом деле $__rate_interval довольно крут тем, что на широких дипазонах Grafana сама передаст Prometheus окно в 10m подстроившись под шаг графика. А если бы мы смотрели узкий диапазон (например, 15 мин), то:
• interval = 0.76 с.
• 4 × scrape_interval = 1 мин.
• Итоговое окно = 1 мин. (а не 0.76 сек.)
То есть $__rate_interval всегда не меньше 1 мин (или 4×scrape_interval), что защищает от слишком маленьких окон.
А на этом у меня всё – ставьте лайки, задавайте вопросы
Telegram | Github | YouTube | X
Хотите разобраться почему графики показывают разные данные в grafana на разных интервалах и дипазонах? Сейчас мы с вами за 4 шага разберемся почему так происходит…
Я специально сделал гремучую смесь параметров в панели, чтобы детально показать что происходит под капотом. Нам важны три цифры со скрина:
• Окно в функции PromQL: increase(...[5m]).
• Interval: 10m.
• Глобальный диапазон: Last 7 days.
1. Какую сетку строит Grafana?
Смотрим на поле Interval – Grafana уже сама все посчитала и поставила 10m.
Interval один из самых важных параметров. Grafana использует его и в запросах в PromQL, и в визуализации панели.
Тут сработала математика самой Grafana: она взяла 7 дней, разделила на ширину панели в пикселях (Max data points = 1146), получила число в районе 8.6 минут и округлила его вверх до ближайшего красивого шага – 10 мин. Формула подсчета интервала там есть прямо рядом Time range / max data points.
В данном примере Grafana выполнит range query с шагом 10 минут: 12:00, 12:10, 12:20, 12:30...
Немного отвлечемся на другой немаловажный параметр - Min interval. Представим, что мы решили посмотреть детально и выделили на графике узкий отрезок – всего в 15 мин (вместо текущих 7 дней).
Исходя из формулы Interval = Time range / max data points получились бы интервалы в 0.76 сек. и это очень мало для корректной визуализации. Тут в игру вступает Min interval = 1m:
• Grafana видит, что расчетный шаг (0.76 сек) меньше, чем лимит (1m).
• Она говорит: “Окей, я не буду частить. Буду просить данные с шагом строго 1 мин.”.
По сути Min Interval это защита от бессмысленных маленьких интервалов.
С этим вроде разобрались – погнали смотреть что в запросе PromQL.
2. Какое окно считает Prometheus?
Когда Prometheus выполняет запрос для каждой точки, он видит твою функцию increase(...[5m]). Это значит в этой конкретной точке оглянись назад ровно на 5 минут и посчитай прирост счетчика.
Складываем это вместе и смотрим на хронологию:
• Точка 12:10: Prometheus смотрит назад на 5 мин. – оценивает отрезок с 12:05 до 12:10. Отдает значение. Grafana рисует точку.
• Точка 12:20: Prometheus делает шаг в 10 мин., встает на новую точку и снова смотрит назад на 5 минут – оценивает отрезок с 12:15 до 12:20.
3. Главный инсайт – на графике появились “слепые зоны”!
Заметили, что произошло?
• 1 точка покрыла интервал 12:05 - 12:10.
• 2 точка покрыла интервал 12:15 - 12:20.
А куда делся промежуток времени с 12:10 до 12:15? Он просто выпал из расчетов. Он не попал ни в первую точку, ни во вторую.
Когда интервал шага на графике (10m) больше, чем окно в самой функции ([5m]) – наше временное окно больше не скользит с пересечением. Оно начинает прыгать через промежутки времени, оставляя слепые зоны.
Если в промежуток с 12:10 до 12:15 бахнет жесткий всплеск – график его вообще не покажет, потому что Prometheus физически не заглянет в этот пятиминутный отрезок.
4. Как это исправить, чтобы график стал адекватным?
Тут важно понимать, что я специально сделал довольно спорные параметры панели, которые в реальной жизни я бы не стал применять. Но (как я уже говорил) они отлично подходят для демонстрации того, что происходит под капотом.
Самый правильный путь – переписать запрос на rate с динамическим интервалом $__rate_interval = max( $interval + scrape_interval , 4 × scrape_interval ).
$__rate_interval значительно уменьшает вероятность появления слепых зон и делает поведение графика гораздо стабильнее при смене диапазона.
rate(postfix_smtp_messages_processed_total{...}[$__rate_interval])
На самом деле $__rate_interval довольно крут тем, что на широких дипазонах Grafana сама передаст Prometheus окно в 10m подстроившись под шаг графика. А если бы мы смотрели узкий диапазон (например, 15 мин), то:
• interval = 0.76 с.
• 4 × scrape_interval = 1 мин.
• Итоговое окно = 1 мин. (а не 0.76 сек.)
То есть $__rate_interval всегда не меньше 1 мин (или 4×scrape_interval), что защищает от слишком маленьких окон.
А на этом у меня всё – ставьте лайки, задавайте вопросы
Telegram | Github | YouTube | X