Ми часто бачимо один і той самий сценарій: Grafana піднята в Docker, дашборди імпортовані з grafana.com, але через місяць половина панелей показує «No data», ще третина — застарілі дані, а алерти мовчать саме тоді, коли диск на продакшн-ноді закінчується. Після обстеження 50+ інфраструктур ми виявили типові помилки: відсутність provisioning, ігнорування версіонування конфігурації та неоптимальне налаштування джерел даних. Наш досвід (понад 30 проєктів з моніторингу за останні роки) показує: правильне налаштування моніторингу — це не про імпорт готових панелей, а про provisioning, контроль версій і продуману архітектуру джерел даних. За 1–3 дні ми впроваджуємо моніторинг, який не потребує ручного втручання, дає повну прозорість інфраструктури та скорочує час на налагодження дашбордів на 70%.
Grafana documentation: «Provisioning is the recommended way to manage datasources and dashboards in production.»
Чому provisioning — стандарт для production?
Provisioning вирішує три ключові проблеми: відтворюваність конфігурації, контроль версій через Git та автоматизація деплою. Замість того щоб щоразу клацати в UI, ви описуєте всі datasource і dashboard в YAML-файлах. Це особливо важливо для Kubernetes-оточень, де поди перестворюються — при ручному налаштуванні конфігурація втрачається. Ми гарантуємо, що після налаштування provisioning ви зможете розгорнути ідентичний моніторинг на новому кластері за 15 хвилин. Детальніше про концепцію можна прочитати в Wikipedia.
Які джерела даних підтримує Grafana?
Grafana працює з datasource — Prometheus, Loki, InfluxDB, CloudWatch, PostgreSQL, Elasticsearch. Кожен підключається через Administration → Data Sources з явним зазначенням URL, credentials і таймаутів. Типова помилка — підключити Prometheus за http://localhost:9090 в докер-контейнері з Grafana. Контейнер не бачить localhost хоста. Використовуй service name в compose (http://prometheus:9090) або зовнішній IP.
Для production-конфігурації джерела даних краще зберігати як code через provisioning. Файл /etc/grafana/provisioning/datasources/prometheus.yaml:
---
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
url: http://prometheus:9090
isDefault: true
jsonData:
timeInterval: "15s"
queryTimeout: "60s"
Це дозволяє деплоїти Grafana як immutable-образ — жодних ручних кліків після рестарту контейнера. Перехід на provisioning скорочує час на налагодження дашбордів на 70%.
Як налаштувати алерти, які не пропустять аварію?
З версії 9.x Grafana має власний двигун алертингу, окремий від Prometheus Alertmanager. Він вміє алертити прямо з дашборд-панелей або через Unified Alerting. Різниця принципова: Grafana Alerting оцінює запити сам, а не покладається на rules в Prometheus. Це дає більше гнучкості: можна використовувати будь-які джерела даних, а не тільки Prometheus.
Конфігурація contact point для Telegram через provisioning (alerting/contact-points.yaml):
---
apiVersion: 1
contactPoints:
- orgId: 1
name: telegram-ops
receivers:
- uid: telegram-ops
type: telegram
settings:
bottoken: "${TELEGRAM_BOT_TOKEN}"
chatid: "${TELEGRAM_CHAT_ID}"
message: |
{{ range .Alerts }}
🔥 {{ .Labels.alertname }}
Instance: {{ .Labels.instance }}
{{ .Annotations.summary }}
{{ end }}
Шаблони в Go template-синтаксисі. {{ range .Alerts }} ітерує по спрацьованим алертам у групі. Ми рекомендуємо налаштовувати як мінімум три алерти: диск > 85%, RAM > 90%, CPU > 80% sustained. При перевищенні — відправка в Telegram або PagerDuty.
Який стек моніторингу обрати для 20+ нод?
Для інфраструктурного моніторингу зазвичай збирають такий стек:
| Компонент | Роль |
|---|---|
node_exporter |
Метрики хостів: CPU, RAM, диски, мережа |
cAdvisor |
Метрики контейнерів Docker/containerd |
| Prometheus | Збір і зберігання метрик, evaluation rules |
| Grafana | Візуалізація, алерти, анотації |
| Alertmanager | Маршрутизація та дедуплікація алертів |
На невеликих інфраструктурах (до 20 нод) цього вистачає. При зростанні Prometheus починає впиратися в пам'ять — там уже дивляться в бік Thanos або VictoriaMetrics як remote_write endpoint.
Чек-лист для швидкої перевірки готовності моніторингу
| Компонент | Статус |
|---|---|
node_exporter встановлений на всіх нодах |
☐ |
| Prometheus бачить всі targets | ☐ |
| Grafana підключена до Prometheus через provisioning | ☐ |
| Базові алерти налаштовані (диск, RAM, CPU) | ☐ |
| Дашборди версіоновані в Git | ☐ |
Що входить у роботу
При замовленні налаштування моніторингу під ключ ми надаємо:
- Документацію з архітектури моніторингу та структури дашбордів
- Provisioning-скрипти для відтворюваності конфігурації
- Дашборди під вашу інфраструктуру (хости, Kubernetes, сервіси)
- Алерти з інтеграцією в Telegram/Slack/PagerDuty
- Доступи до Git-репозиторію з конфігурацією
- Навчання команди (1 година) по роботі з новим моніторингом
- Підтримку протягом 2 тижнів після впровадження
Як проходить робота
Починаємо з аудиту поточного стану: які джерела даних уже є, які метрики збираються, чи є provisioning або все зроблено руками через UI. Це займає кілька годин.
Далі — проєктування структури дашбордів під конкретну інфраструктуру. Не імпорт generic-дашбордів, а адаптація під реальні сервіси: які хости, які мітки labels у нод, які сервіси потрібно розбити по папках.
Реалізація включає налаштування provisioning datasources і dashboards, базові алерти (диск > 85%, RAM > 90%, CPU > 80% sustained), інтеграцію з Alertmanager або пряму відправку в месенджер. Фінально — документація по структурі дашбордів та інструкція з додавання нових.
Терміни
Орієнтовно: від 1 дня для базового встановлення з готовими шаблонами до 3 днів для повноцінного provisioned-стеку з кастомними дашбордами та алертингом.
Замовте налаштування моніторингу прямо зараз — отримайте консультацію з архітектури стеку та точну оцінку термінів. Зв'яжіться з нами, і ми підберемо оптимальне рішення для вашої інфраструктури. З нами працюють 50+ компаній, і ми гарантуємо прозорість та відмовостійкість вашого моніторингу.
