Мы часто видим один и тот же сценарий: 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+ компаний, и мы гарантируем прозрачность и отказоустойчивость вашего мониторинга.
