Як розгорнути Grafana на власній інфраструктурі у 2026 році: дашборди, сповіщення та збереження стану

Є дві версії «запущеної Grafana»: контейнер існує або сервіс виконує свою реальну роботу. Важлива лише друга. У цьому випадку перевіркою буде додавання джерела даних лише для читання, збереження панелі, перевірка правила сповіщення та надсилання тестового сповіщення через contact point.

Grafana призначена для роботи саме з цим: дашбордами та сповіщеннями на основі metrics, logs і traces. Розгортання має зберігати компоненти, що забезпечують таку поведінку; порт, volume і сертифікат — це вхідні дані, а не результат.

Production-архітектура Grafana

HTTP-процес Grafana прослуховує порт 3000; залиште цей порт у мережі застосунку й опублікуйте лише маршрут платформи. Мережевий контракт Grafana передбачає доступні джерела даних і SMTP, якщо потрібне доставлення сповіщень. Залишайте приватні endpoints у внутрішньому DNS, дозволяйте лише необхідні вихідні виклики та надайте Grafana service credential з обмеженими правами.

Зафіксуйте межі у вигляді короткого контракту: хто відповідає за вимогу, які облікові дані використовуються, який timeout є прийнятним і як проявляється збій. Потім виконайте таку транзакцію: додайте джерело даних лише для читання, збережіть панель, перевірте правило сповіщення та надішліть тестове сповіщення через contact point. Під час перевірки спостерігайте за query 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

Якщо процес зациклюється, порівняйте очікуваного користувача образу з власником кожного підключеного шляху. Якщо він працює, перевірте порт 3000 локально, а потім одразу перейдіть до workflow: додайте джерело даних лише для читання, збережіть панель, перевірте правило сповіщення та надішліть тестове сповіщення через contact point. Зафіксуйте версію образу лише після успішної наскрізної перевірки та збережіть точну конфігурацію поруч із сервісом.

Надайте Grafana одну канонічну адресу

Випуск TLS — лише половина маршруту Grafana. Встановіть GF_SERVER_ROOT_URL як публічну HTTPS-адресу. Передавайте трафік усередині на порт 3000 і пересилайте зовнішню схему, щоб згенеровані URL і secure cookies залишалися узгодженими.

Перевіряйте повний сценарій Grafana з чистої мережі, а не лише кореневу сторінку. Помилку 502 або проблему із сертифікатом можна ізолювати за допомогою автоматичного налаштування домену й TLS. Якщо трафік доходить до процесу, а дашборди зникають разом із файлом SQLite або OAuth callbacks використовують localhost, діагностуйте цю умову саме там, де вона виникає, замість того щоб додавати нові redirects.

Спроєктуйте відновлення Grafana до запуску

Набір даних для надійного відновлення складається з database Grafana, плагінів і provisioned configuration. Підключіть /var/lib/grafana до bootstrap, запишіть безпечні тестові дані та замініть контейнер, щоб довести, що цей шлях справді зберігається. Volume захищає дані від заміни контейнера, але не від втрати хоста, випадкового видалення чи пошкодження на рівні застосунку.

Створюйте резервні копії з урахуванням джерела даних: за потреби використовуйте logical dumps для активних databases і копіюйте файли лише зі стабільного стану. Зберігайте одну зашифровану копію окремо від хоста Grafana. Критерій приймання відновлення має бути конкретним — користувачі, папки, дашборди, правила сповіщень і metadata джерел даних мають повернутися, а тестове сповіщення — пройти перевірку. У посібнику з резервного копіювання з перевіреним відновленням пояснюється, чому самого успішного завершення job недостатньо.

Закрийте тимчасовий доступ для налаштування

Безпечне розгортання Grafana починається з позбавлення зайвих прав. Не залишайте admin/admin і не відкривайте anonymous access ненавмисно; натомість замініть bootstrap-пароль адміністратора, обмежте редагування джерел даних і надавайте service-account tokens лише необхідні права.

Негайно замініть приклад GF_SECURITY_ADMIN_PASSWORD, зберігайте його поза образом і змінюйте як облікові дані адміністратора, якщо вони стали доступними стороннім. Обмежте адміністративні маршрути, використовуйте приватний DNS для залежностей і перевірте кожне bind mount. Якщо logs надсилаються централізовано, відфільтруйте секрети та приватний вміст до того, як вони залишать сервер.

Відпрацюйте ризиковану зміну Grafana

Працюючий контейнер необхідний, але недостатній. Service-level indicator — це успішне виконання операції «додати джерело даних лише для читання, зберегти панель, перевірити правило сповіщення та надіслати тестове сповіщення через contact point», тоді як імовірними сигналами навантаження є query fan-out, інтервали оновлення дашбордів, перевірка сповіщень і використання пам’яті плагіна, а не власні збережені метрики Grafana.

Change control має значення, оскільки migrations database Grafana і сумісність плагінів потребують поетапного оновлення з тими самими provisioning files. Збережіть старий образ, протестуйте migrations на копії стану та задокументуйте, чи підтримується rollback після зміни schema. Якщо дашборди зникають разом із файлом SQLite або OAuth callbacks використовують localhost, діагностуйте першу межу, яка відрізняється від робочого середовища.

Зафіксуйте перевірене розгортання Grafana

Для Grafana визначте перевірену транзакцію до запуску: додайте джерело даних лише для читання, збережіть панель, перевірте правило сповіщення та надішліть тестове сповіщення через contact point. Збережіть її prerequisites, очікувану відповідь і кроки очищення у version control без секретних значень. Зафіксуйте версію образу, використаного для створення цього еталона.

Використовуйте транзакцію для перевірки заміни та незалежного відновлення. Відновлений сервіс можна вважати прийнятним лише тоді, коли користувачі, папки, дашборди, правила сповіщень і metadata джерел даних повернулися, а тестове сповіщення пройшло перевірку. Водночас спостерігайте за query fan-out, інтервалами оновлення дашбордів, перевіркою сповіщень і використанням пам’яті плагіна, а не за власними збереженими метриками Grafana, і перетворіть найповільнішу або найобмеженішу частину на service-level alert.

Цей gate також має містити негативний сценарій: тимчасово забороніть тестовій identity доступ до доступних джерел даних і SMTP, якщо потрібне доставлення сповіщень. Переконайтеся, що Grafana створює придатну для діагностики помилку, зберігаючи дані, відновіть коректну умову та повторіть перевірену транзакцію. Збереження обох результатів не дає поверхневому health endpoint стати єдиним production-доказом.

Як Dockup спрощує роботу з Grafana

Маршрутизація, сертифікати, заміна сервісу та підключене сховище — цілком доречні цілі для автоматизації. Dockup обробляє їх для Grafana та може підготувати пов’язану managed database або підключитися до сервісів на власному сервері клієнта.

Водночас Dockup не має вигадувати політику довіри Grafana. Після розгортання встановіть GF_SERVER_ROOT_URL як публічну HTTPS-адресу, забезпечте дотримання цієї межі — замініть bootstrap-пароль адміністратора, обмежте редагування джерел даних і надавайте service-account tokens лише необхідні права — та перевірте результат такого сценарію: додайте джерело даних лише для читання, збережіть панель, перевірте правило сповіщення та надішліть тестове сповіщення через contact point. Результат — інфраструктура в один клік із application-specific acceptance test.

Часті запитання

Що потрібно Grafana для production-розгортання?

Маршрутизуйте контейнер Grafana на порт 3000 через один HTTPS origin. Додаткова мережева вимога — доступні джерела даних і SMTP, якщо потрібне доставлення сповіщень. Не вважайте Grafana готовою, доки не зможете додати джерело даних лише для читання, зберегти панель, перевірити правило сповіщення та надіслати тестове сповіщення через contact point.

Які дані Grafana потрібно включати до резервної копії?

Забезпечте збереження /var/lib/grafana та включіть database Grafana, плагіни й provisioned configuration до того самого recovery manifest. Чисте відновлення Grafana успішне лише тоді, коли користувачі, папки, дашборди, правила сповіщень і metadata джерел даних повернулися, а тестове сповіщення пройшло перевірку.

Чи потрібен Grafana HTTPS за reverse proxy?

Використовуйте HTTPS для публічного Grafana origin, а порт 3000 залиште у внутрішньому маршруті. Коректно застосуйте налаштування Grafana: встановіть GF_SERVER_ROOT_URL як публічну HTTPS-адресу. Для Grafana HTTPS захищає облікові дані або користувацький вміст під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Grafana?

Відновіть поточний стан Grafana в ізольованому розгортанні, застосуйте candidate version і повторіть acceptance transaction. Приділіть цьому особливу увагу, оскільки migrations database Grafana і сумісність плагінів потребують поетапного оновлення з тими самими provisioning files. Зберігайте попередній образ Grafana, доки не буде зрозумілою межа міграції даних і rollback.