Сообщить об ошибкеКороткий ответ
Самые частые ошибки: путать среднее значение с процентилем, не замечать смену масштаба оси Y между обновлениями, не учитывать интервал агрегации (rate(...[5m]) сглаживает резкие всплески) и забывать про часовой пояс при сравнении графика с временем инцидента.
Как это работает подробнее
Grafana строит ось Y автоматически по диапазону данных на экране, поэтому один и тот же абсолютный разброс значений может казаться "маленьким" или "огромным" в зависимости от текущего авто-масштаба — нужно явно проверять числа, а не только форму линии. Окно агрегации в rate()/avg_over_time() сглаживает короткие пики: пятиминутный всплеск ошибок на 30 секунд может быть почти не виден на графике с окном [5m].
Пример кода
example.txt
Панель А: диапазон оси Y автоматический, 118–122 мс — выглядит "стабильно"
Панель Б: тот же ряд, ось Y закреплена на 0–500 мс — виден реальный разброс и пара всплесков до 300 мсЧто использовать на практике
- Практика. при расследовании инцидента стоит сверять время на графике с временем в логах/алертах в одном часовом поясе (Grafana и Prometheus обычно работают в UTC, если явно не настроено иное) и уменьшать окно агрегации для поиска коротких всплесков, а не полагаться только на пятиминутное сглаживание. Также полезно смотреть абсолютные числа через
Explore, а не только форму линии на маленькой панели. - Практика. Закрепление минимума и максимума оси Y (
Min: 0) в настройках панели устраняет обманчивое автомасштабирование и даёт более честную визуальную картину при сравнении разных периодов времени.
Подводные камни
- Частые ошибки. делать вывод "всё стабильно" по плоской линии, когда на самом деле ось Y автомасштабировалась и скрыла реальные колебания; путать p99 latency с "максимальной" latency — p99 всё ещё означает, что 1% запросов были медленнее; сравнивать два дашборда в разных часовых поясах и делать неверные выводы о времени начала проблемы.