Как развернуть Grafana на собственном сервере в 2026 году: дашборды, алерты и постоянное хранение данных
Разверните Grafana с правильным портом, надёжным хранилищем, TLS, аутентификацией и резервным копированием. Узнайте, как устранить исчезновение дашбордов вместе с файлом SQLite в production.
Есть два варианта «запустить Grafana»: контейнер существует или сервис действительно выполняет свою работу. Важен только второй. Доказательством будет добавление источника данных только для чтения, сохранение панели, проверка правила алерта и отправка тестового уведомления через contact point.
Grafana нужна для этого: она предоставляет дашборды и алерты поверх метрик, логов и трейсов. При развёртывании необходимо сохранить компоненты, обеспечивающие такую работу; порт, volume и сертификат — это входные параметры, а не результат.
Как должна выглядеть Grafana в production
HTTP-процесс Grafana слушает порт 3000; оставьте этот порт в сети приложения и публикуйте только маршрут платформы. Сетевой контракт Grafana включает доступные источники данных и SMTP, если требуется доставка алертов. Держите приватные endpoints во внутреннем DNS, разрешайте только необходимые исходящие вызовы и выдайте Grafana service credential с ограниченными правами.
Зафиксируйте границы в виде короткого контракта: кто отвечает за требование, какие credentials используются, какой timeout допустим и как проявляется сбой. Затем выполните такую транзакцию: добавьте источник данных только для чтения, сохраните панель, проверьте правило алерта и отправьте тестовое уведомление через contact point. Во время выполнения отслеживайте fan-out запросов, интервалы обновления дашбордов, проверку алертов и потребление памяти плагинами, а не собственные сохранённые метрики Grafana, поскольку такая нагрузка даёт более полезную отправную точку для определения размера, чем простаивающий контейнер.
Запустите Grafana, не скрывая важные компоненты
Запустите Grafana так, чтобы маршрут оставался приватным до завершения bootstrap.
docker run -d \
--name grafana \
--restart unless-stopped \
-p 127.0.0.1:3000:3000 \
-v grafana-data:/var/lib/grafana \
-e GF_SECURITY_ADMIN_PASSWORD=replace-with-a-long-random-value \
grafana/grafana:latest
Если процесс зацикливается, сопоставьте ожидаемого пользователя image с владельцем каждого подключённого пути. Если процесс работает, проверьте порт 3000 локально и сразу переходите к workflow: добавьте источник данных только для чтения, сохраните панель, проверьте правило алерта и отправьте тестовое уведомление через contact point. Фиксируйте версию image только после успешной сквозной проверки и сохраните точную конфигурацию рядом с сервисом.
Назначьте Grafana один канонический адрес
Выпуск TLS — лишь половина маршрута Grafana. Установите GF_SERVER_ROOT_URL, указав публичный HTTPS URL. Направляйте трафик внутри системы на порт 3000 и передавайте внешнюю схему, чтобы сгенерированные URL и secure cookies оставались согласованными.
Проверяйте полный сценарий Grafana из чистой сети, а не только корневую страницу. Ошибку 502 или сбой сертификата можно локализовать с помощью автоматической настройки домена и TLS. Если трафик достигает процесса, а дашборды исчезают вместе с файлом SQLite или OAuth callbacks используют localhost, диагностируйте проблему на соответствующем уровне, а не добавляйте новые редиректы поверх существующих.
Спроектируйте восстановление Grafana до запуска
Набор данных для надёжного восстановления включает базу данных Grafana, плагины и provisioned configuration. Подключите /var/lib/grafana до bootstrap, запишите безвредные тестовые данные и замените контейнер, чтобы убедиться, что этот путь действительно сохраняется. Volume защищает данные от замены контейнера, но не от потери хоста, случайного удаления или повреждения на уровне приложения.
Создавайте резервные копии с учётом источника данных: при необходимости используйте logical dumps для работающих баз данных, а файлы копируйте только из согласованного состояния. Храните одну зашифрованную копию отдельно от хоста Grafana. Критерий успешного восстановления должен быть конкретным — должны вернуться пользователи, папки, дашборды, правила алертов и metadata источников данных, а тестовый алерт должен сработать. В руководстве по резервному копированию с проверенным восстановлением объясняется, почему одного успешного выполнения job недостаточно.
Закройте временный доступ, использованный при настройке
Безопасное развёртывание Grafana начинается с удаления лишних полномочий. Не оставляйте admin/admin и не открывайте anonymous access случайно; вместо этого замените bootstrap-пароль администратора, ограничьте редактирование источников данных и выдавайте service-account tokens с ограниченными правами.
Немедленно замените пример GF_SECURITY_ADMIN_PASSWORD, храните его за пределами image и ротируйте как credential администратора, если значение стало доступно посторонним. Ограничьте административные маршруты, используйте приватный DNS для зависимостей и проверьте каждый bind mount. Если логи отправляются в централизованную систему, отфильтруйте secrets и приватное содержимое до того, как они покинут сервер.
Отрепетируйте рискованное изменение Grafana
Работающий контейнер необходим, но недостаточен. Service-level indicator — успешное выполнение сценария «добавить источник данных только для чтения, сохранить панель, проверить правило алерта и отправить тестовое уведомление через contact point», а наиболее вероятные сигналы нагрузки — fan-out запросов, интервалы обновления дашбордов, проверка алертов и потребление памяти плагинами, а не собственные сохранённые метрики Grafana.
Change control важен, поскольку миграции базы данных Grafana и совместимость плагинов требуют поэтапного обновления с теми же provisioning files. Сохраните старый image, протестируйте миграции на копии состояния и задокументируйте, поддерживается ли rollback после изменения схемы. Если дашборды исчезают вместе с файлом SQLite или OAuth callbacks используют localhost, диагностируйте первую границу, которая отличается от рабочего окружения.
Зафиксируйте эталонное рабочее развёртывание Grafana
Для Grafana до запуска определите эталонную рабочую транзакцию: добавьте источник данных только для чтения, сохраните панель, проверьте правило алерта и отправьте тестовое уведомление через contact point. Зафиксируйте её prerequisites, ожидаемый ответ и шаги очистки в системе контроля версий, не добавляя secret values. Зафиксируйте версию image, использованного для создания этого эталона.
Используйте транзакцию для проверки замены и независимого восстановления. Восстановленный сервис можно считать работоспособным только после того, как вернутся пользователи, папки, дашборды, правила алертов и metadata источников данных, а тестовый алерт сработает. Одновременно отслеживайте fan-out запросов, интервалы обновления дашбордов, проверку алертов и потребление памяти плагинами, а не собственные сохранённые метрики Grafana, и превратите самый медленный или наиболее ограниченный компонент в service-level alert.
Проверка также должна включать negative case: временно запретите тестовой identity доступ к доступным источникам данных и SMTP, если требуется доставка алертов. Убедитесь, что Grafana выдаёт информативную ошибку, сохраняя данные, восстановите корректное состояние и повторите эталонную рабочую транзакцию. Наличие обоих результатов не позволяет поверхностному health endpoint стать единственным свидетельством работоспособности в production.
Как Dockup упрощает работу с Grafana
Маршрутизация, сертификаты, замена сервисов и подключённое хранилище — разумные цели для автоматизации. Dockup выполняет эти задачи для Grafana, а также может подготовить соответствующую managed database или подключиться к сервисам на собственном сервере клиента.
Не следует автоматически придумывать trust policy Grafana. После развёртывания установите GF_SERVER_ROOT_URL, указав публичный HTTPS URL, обеспечьте выполнение этой границы — замените bootstrap-пароль администратора, ограничьте редактирование источников данных и выдавайте service-account tokens с ограниченными правами — и проверьте результат такого сценария: добавьте источник данных только для чтения, сохраните панель, проверьте правило алерта и отправьте тестовое уведомление через contact point. В результате вы получаете инфраструктуру в один клик с acceptance test, учитывающим специфику приложения.
Часто задаваемые вопросы
Что требуется Grafana для развёртывания в production?
Направьте контейнер Grafana на порт 3000 через один HTTPS origin. Сетевые требования включают доступные источники данных и SMTP, если требуется доставка алертов. Не объявляйте Grafana готовой, пока не сможете добавить источник данных только для чтения, сохранить панель, проверить правило алерта и отправить тестовое уведомление через contact point.
Какие данные Grafana нужно включать в резервную копию?
Сохраняйте /var/lib/grafana и включайте базу данных Grafana, плагины и provisioned configuration в один recovery manifest. Чистое восстановление Grafana считается успешным только после возвращения пользователей, папок, дашбордов, правил алертов и metadata источников данных, а также успешной проверки тестового алерта.
Нужен ли Grafana HTTPS за reverse proxy?
Используйте HTTPS для публичного origin Grafana, а порт 3000 оставляйте во внутреннем маршруте. Корректно применяйте настройку Grafana: установите GF_SERVER_ROOT_URL, указав публичный HTTPS URL. Для Grafana HTTPS защищает credentials и пользовательский контент при передаче и сохраняет согласованное поведение клиента, зависящее от origin.
Как тестировать обновление Grafana?
Восстановите текущее состояние Grafana в изолированном развёртывании, примените candidate version и повторите acceptance transaction. Обратите особое внимание на этот этап, поскольку миграции базы данных Grafana и совместимость плагинов требуют поэтапного обновления с теми же provisioning files. Сохраняйте предыдущий image Grafana, пока не будут понятны границы миграции данных и rollback.