Все предыдущие выпуски серии были про то, откуда берётся сырой материал для графиков — метрики хоста, Postgres, очередей, трейсы, логи. Grafana сама ничего не собирает и почти ничего не хранит — она подключается к уже готовым источникам (Prometheus, Loki, Tempo) и рисует поверх них дашборды и алерты. Логично, что в серии про стек она закрывающая, а не первая — смотреть особо не на что, пока нет источников.
Один дашборд редко нужен только для одного хоста или окружения — для этого есть переменные вида ${var_name}, которые подставляются в запрос вместо жёстко прописанного значения:
rate(node_cpu_seconds_total{instance="$instance", mode="idle"}[5m])
Сверху встаёт выпадающий список хостов, и один и тот же дашборд работает для всего парка серверов без копирования.
Алерты в Grafana строятся поверх тех же запросов к Prometheus/Loki — правило состоит из query-стадии и условия (reduce + math-выражение или classic condition с порогом). Отдельно стоит решить, где правило живёт: Grafana-managed хранит и считает его сама, data source-managed отдаёт эту работу встроенному ruler’у Mimir или Loki — тогда правило переживёт перезапуск самой Grafana.
Дашборды тоже не обязательно тащить руками через UI — provisioning читает JSON из каталога на диске по конфигу вида dashboards.yaml:
apiVersion: 1
providers:
- name: "default"
type: file
options:
path: /etc/grafana/provisioning/dashboards
Grafana периодически сканирует path и подхватывает изменения — дашборд становится частью репозитория и деплоя, а не ручным экспортом JSON после правок через веб-интерфейс.
На этом цикл про LGTM закрыт — от сырых метрик хоста до визуализации и алертов. Дальше по теме мониторинга пойдут уже отдельные частные темы, не привязанные к одной сквозной серии.
#grafana #lgtm