Dashboard Grafana сбрасывает изменения: UI, provisioning и источник файла

Инженер исправил запрос в Grafana и нажал Save. Панель заработала, но после следующего развёртывания вернулся старый запрос. Иногда откат происходит даже без релиза приложения: достаточно изменения файла, из которого Grafana получает dashboard. Для такого dashboard база Grafana может быть только одной из копий, а источник изменений находится в Git и provisioning.

Разберём файловое provisioning. Провайдер читает описания dashboard из каталога и создаёт либо обновляет их в Grafana. При этом разрешение редактировать панель в интерфейсе не означает автоматическую запись обратно в исходный файл. Именно эту границу стоит проверить первой.

Найдём владельца определения

Откройте настройки dashboard и сведения о provisioning. Запишите uid: он помогает сопоставить объект в UI с моделью в файле. На стороне развёртывания найдите provider и указанный им каталог. Он может быть bind mount, содержимым образа или результатом генерации из репозитория. Правка случайной локальной копии исчезнет при следующем обновлении.

apiVersion: 1
providers:
  - name: application-dashboards
    orgId: 1
    type: file
    allowUiUpdates: true
    disableDeletion: true
    updateIntervalSeconds: 30
    options:
      path: /var/lib/grafana/dashboards

Этот provider позволяет сохранить UI-изменение в базе. Но когда исходный файл обновится, его содержимое перезапишет сохранённый dashboard. Свойство version внутри файла не защищает более новую UI-версию от такого обновления. Увеличение version вручную поэтому не решает проблему двух источников.

Здесь выбран период больше десяти секунд, чтобы использовать периодический опрос файлов. В актуальной Grafana меньшие значения связаны с наблюдением за файловыми событиями; на некоторых mount-схемах события не доходят. Если правка файла не подхватывается, проверяйте механизм обнаружения и журнал provisioning, а не только модель панели.

Перенесём содержательную правку в источник

До повторного обновления экспортируйте исправленный dashboard в подходящем формате. Сопоставьте формат с версией Grafana и текущим способом provisioning: Classic и ресурсная модель V2 различаются. Сохраните uid существующего dashboard, если задача — обновить именно его, а не создать копию с другим адресом.

В репозитории сравните экспорт с исходной моделью. Для исправления одного запроса diff должен объяснимо менять нужную панель, переменные и связанные настройки. Экспорт может включать отличия служебных полей, поэтому полезно применять узкую содержательную правку к принятому в проекте источнику. Если JSON генерируется, меняйте шаблон или код генератора.

Проверьте references на data sources. Рабочая панель из личного окружения может ссылаться на uid источника, которого нет в production. Экспорт, открывающийся как JSON, ещё не доказывает, что запрос обращается к нужному Prometheus.

Выберем понятный режим редактирования

Если команда принимает изменения только через Git, allowUiUpdates: false делает правило явным: сохранить provisioned dashboard в UI нельзя. Временные эксперименты можно выполнять в отдельной копии, а проверенный результат переносить в источник. Если UI-редактирование разрешено, нужна процедура переноса, иначе база и файл будут регулярно расходиться.

disableDeletion: true в примере защищает от удаления dashboard при исчезновении файла источника. Это отдельное поведение; оно не запрещает обновление из файла и не сохраняет UI-правку поверх него. Настройку удаления выбирают по жизненному циклу проекта, чтобы удалённые из Git объекты не оставались навсегда без владельца.

Подтвердим результат после повторного чтения

После применения источника дождитесь его обработки и откройте dashboard по прежнему uid. Проверьте фактический PromQL и ответ панели, затем повторите обычную процедуру развёртывания на тестовом окружении. Сохранность изменения после этой процедуры и есть проверка того, что исправлен правильный источник.

Хороший результат здесь — один понятный путь изменения: эксперимент, проверка запроса, review модели и доставка файла. Тогда следующий инженер сможет восстановить dashboard из репозитория с тем же содержимым, которое видит в интерфейсе.

Ещё по теме

• Grafana показывает No data: проверяем метрику, время и переменные
• Alertmanager шлёт слишком много сообщений: group_by и интервалы уведомлений

Продолжить изучение

Хотите построить мониторинг, который помогает находить причины сбоев? Метрики, дашборды и оповещения входят в программу «Prometheus и Grafana: мониторинг и observability».