Для чего используется Grafana и как с ней работать

Что проверяют

Понимаете ли вы, какое место Grafana занимает в работе тестировщика, и смотрели ли вы на неё сами при нагрузочном тестировании или разборе бага. Следом обычно спрашивают, откуда берутся данные на графиках и как найти причину ошибки по времени.

Как отвечать

Начните с главного: Grafana сама почти ничего не хранит, это слой визуализации и алертов поверх источников данных. Метрики лежат в Prometheus или InfluxDB, логи в Loki или Elasticsearch, бизнес-данные в PostgreSQL или ClickHouse.

Из чего состоит работа:

• дашборд и панели: каждый график это запрос к источнику, например PromQL rate(http_requests_total{status=~"5.."}[5m]);
• переменные: выпадающие списки $env и $service, чтобы один дашборд показывал и тестовый стенд, и прод;
• Explore: разовые запросы без дашборда, удобно искать логи по trace_id или по минуте, когда упал автотест;
• аннотации: отметки релизов и начала прогона прямо на графике;
• алерты: правила по порогам с отправкой в Telegram, Slack или почту.

Где это нужно QA. При нагрузочном тестировании k6 или JMeter пишут результаты в InfluxDB или Prometheus, а в Grafana вы рядом видите RPS, перцентили времени ответа, долю ошибок и потребление CPU и памяти сервисом. При разборе бага по времени запроса находите всплеск ошибок и связанные логи. Хорошо, если назовёте свой пример: какой дашборд смотрели и что на нём нашли.

Где спотыкаются

Называют Grafana системой сбора метрик. На вопрос, откуда данные, ответа уже нет.

Смотрят на среднее время ответа. Среднее в 300 мс легко прячет хвост в несколько секунд, поэтому нагрузку оценивают по p95 и p99.

Сравнивают графики, не проверив часовой пояс и диапазон времени дашборда, или смотрят метрики только сервиса, забыв про машину с генератором нагрузки. Упёршийся в CPU генератор даёт ложную деградацию.