Grafana рисует данные из разных источников на одном экране: Prometheus, VictoriaMetrics, Loki, Tempo, Elasticsearch, PostgreSQL, ClickHouse и десятки других. Её сила не в красивых графиках, а в том, чтобы дежурный за минуту понял, что сломалось.
Основные понятия
- Data source: подключение к хранилищу данных.
- Dashboard: набор панелей, разложенных по строкам (rows).
- Panel: один запрос или несколько и визуализация: time series, stat, gauge, bar chart, table, heatmap, logs.
- Variables: выпадающие списки вверху дашборда (
$env,$service,$instance), которые подставляются в запросы. Один дашборд обслуживает все сервисы и окружения. - Annotations: отметки событий на графиках, например деплоев. Ответ на вопрос «что изменилось в 14:05» часто виден сразу.
- Explore: режим свободных запросов для расследования, с переходами между метриками, логами и трейсами.
Переменные
sum by (route) (rate(http_requests_total{job="$service", env="$env"}[$__rate_interval]))
Переменная $service заполняется запросом label_values(http_requests_total, job). $__rate_interval Grafana вычисляет сама с учётом интервала опроса и шага графика, чтобы в окне rate всегда было достаточно точек.
Какой дашборд нужен
Хороший дашборд отвечает на вопрос, а не показывает всё, что есть.
- Обзорный (уровень сервиса): RED на входе, SLO и остаток бюджета ошибок, статус зависимостей. Должен читаться за 10 секунд: «всё хорошо» или «плохо вот здесь».
- Детальный по сервису: разрезы по маршрутам, подам, версиям, исходящие вызовы, пулы, GC, очереди.
- Инфраструктурные: USE для узлов, кластеров, баз.
Правила:
- Сверху самое важное, сверху вниз от симптомов к причинам.
- Единицы измерения на осях (секунды, байты, проценты), а не голые числа.
- Пороги и SLO видны на графиках (линия или цвет).
- Ошибки и задержки рядом с трафиком: всплеск ошибок при падении трафика выглядит иначе, чем при росте.
- Не больше 15-20 панелей на экран; остальное в свёрнутые строки или отдельные дашборды по ссылке.
- Гистограмму задержек удобно показывать heatmap: видно, раздвоилось ли распределение.
Дашборды как код
Дашборд в Grafana это JSON. Если его правят руками в интерфейсе, через полгода никто не знает, почему он такой, и его легко сломать. Варианты:
- Provisioning: Grafana при старте загружает дашборды и источники данных из файлов в репозитории.
- Terraform-провайдер Grafana: дашборды, папки, права и алерты как ресурсы.
- Генерация: Grafonnet (Jsonnet), Grafana Foundation SDK на Go, TypeScript или Python, чтобы не копировать JSON между сервисами.
- В kube-prometheus-stack дашборды кладут в ConfigMap с меткой, и sidecar Grafana подхватывает их.
Алерты в Grafana
В Grafana есть свой механизм алертов (Grafana Alerting) с правилами по любому источнику, контактными точками и политиками уведомлений. Его выбирают, когда источников много или алерты хотят править в интерфейсе. Если всё в Prometheus и правила лежат в git, часто остаются на Prometheus и Alertmanager. Смешивать без договорённости плохо: алерты окажутся в двух местах.
Стек LGTM
Grafana Labs развивает свой стек: Loki (логи), Grafana, Tempo (трейсы), Mimir (метрики), плюс Pyroscope (профили) и Alloy (агент сбора на базе OpenTelemetry Collector). Все сигналы связываются: из графика задержки по exemplar к трейсу, из трейса к логам этого запроса.
Частые ошибки
- Дашборд из 80 панелей, в котором в инцидент никто ничего не находит.
- Средние значения вместо перцентилей.
- Фиксированное окно
[1m]вrateпри опросе раз в 30 секунд: дыры на графике. - Дашборды только в базе Grafana, без бэкапа и истории.
- Нет аннотаций деплоев.
Что спросят на собесе
- Как бы вы построили дашборд сервиса и что на нём будет сверху.
- Зачем переменные и
$__rate_interval. - Как хранить дашборды как код.
- Grafana Alerting или Alertmanager.
- Как связать метрики, логи и трейсы в Grafana.