Что такое Provisioning и зачем он нужен¶

Grafana как код (GaC)¶

Когда вы впервые устанавливаете Grafana, она пустая. Нет источников данных. Нет дашбордов. Нет команд, алертов — ничего. Всё это вы добавляете руками через UI. Это нормально для одного человека и пяти дашбордов. Но только не для командной работы и не для продакшена.

Принцип Provisioning'а простой: конфигурация Grafana хранится не в базе данных, а в текстовых YAML и JSON файлах. Всегда актуально, всегда воспроизводимо.

Представьте себе ресторан. Рецепты блюд хранятся не в голове у шеф-повара (он может заболеть, уйти в отпуск, выиграть в лотерею), а в отдельном блокноте, с которым может работать любой повар на кухне. Provisioning — это ваш блокнот рецептов Grafana.

Три слоя provisioning'а:

файлы (Grafana читает директорию provisioning/ при старте) — для настройки источников данных и дашбордов
API (внешние инструменты, например CI/CD-конвейер, сами создают ресурсы через REST API Grafana). Полезно, когда вы разворачиваете через Terraform
Grafana Operator для Kubernetes — всё выше, но автоматизировано Kubernetes-контроллером, который сам следит за Custom Resources и применяет изменения.

Важно: provisioning через файлы — это не "один раз настроил и забыл". Это "настроил в Git, каждый PR проходит review, CI применяет изменения". Инфраструктура как код — Infrastructure as Code, IaC. А для Grafana — GaC — Grafana as Code.

Provisioning vs Terraform/Crossplane¶

Часто задают вопрос: "Terraform тоже умеет provisioning Grafana. В чём разница?"

Provisioning через файлы (родной): Grafana сама считывает YAML из provisioning/ при старте. Изменения применяются только при рестарте или reload'е. Масштабирование — нет общего состояния; каждый экземпляр Grafana читает одни и те же файлы. Простота настройки.
Terraform: внешний инструмент, который через Grafana API управляет ресурсами. Он может создать источник данных, когда тот не создавался Provisioning-файлом. Terraform хорош, когда у вас всё: Grafana, Prometheus, базы данных — управляются из одного Terraform-конфига.
Crossplane: это Kubernetes-ориентированный Control Plane. Ещё более глубокая автоматизация. Вместо Terraform вы описываете желаемое состояние как Kubernetes Custom Resources, и Crossplane сам приводит всё в соответствие.

Главное правило: используйте Provisioning, когда у вас уже развёрнут Grafana; Terraform — когда Grafana разворачивается вместе со всей инфраструктурой.

Как работает File Provisioning¶

Grafana ищет YAML-файлы в трёх поддиректориях provisioning/ — datasources, dashboards, alerting, plugins, iam:

/etc/grafana/provisioning/
  ├── datasources/
  │     └── datasources.yaml
  ├── dashboards/
  │     ├── dashboards.yaml
  │     └── dashboards/
  │           └── my-dash.json
  ├── plugins/
  │     └── plugins.yaml
  ├── alerting/
  │     └── alerting.yaml
  ├── access-control/
  │     └── iam.yaml
  └── ...

Если вы разворачиваете через Docker, монтируете эту директорию внутрь контейнера. Если через Kubernetes — подаёте через ConfigMap. И Grafana сама всё находит и применяет. Просто.

Git Sync — Provisioning наоборот (новое в 13.2)¶

До версии 13.2 provisioning через файлы работал в одну сторону: вы кладёте JSON/YAML в папку — Grafana читает. Но если кто-то изменил дашборд через UI — изменения не попадают обратно в Git.

Git Sync решает эту проблему двусторонней синхронизацией. Вы подключаете репозиторий (GitHub, GitLab, BitBucket) — и Grafana синхронизирует дашборды в обе стороны:

Изменили JSON в репозитории → дашборд обновился в Grafana.
Отредактировали дашборд через UI → создался коммит в репозитории.

C версии 13.2 Git Sync поддерживает авторство коммитов — коммиты подписываются пользователем, который сделал изменение через UI.

В OSS версии доступны только провайдеры GitHub и Pure Git, например, GitLab/BitBucket интеграции нет, она доступна только в Enterprise. Но я подключил GitLab через Pyre Git. Разница небольшая - хук раз в 60 секунд минимум, нет автоматических комментариев к MR с превью дашборда, нет прямых ссылок из Grafana на исходный файл в git.

Обратите внимание:¶

UIDы дашбордов должны быть уникальными в пределах одной организации Grafana. Если вы вручную переносите дашборды, следите за этим, иначе Git Sync не сработать или наплодить дублей.
Git Sync управляет только дашбордами и папками. Алерты и источники данных (datasources) не синхронизируются.
На один инстанс Grafana можно настроить только до 10 репозиториев.

Можно посмотреть видео про Git Sync - что это такое и как работает.

Далее: Provisioning источников данных