Настройка мониторинга серверов с помощью prometheus и grafana

Настройка мониторинга серверов с помощью Prometheus и Grafana включает установку Prometheus для сбора метрик, подключение экспортёров, настройку Grafana для визуализации и создание алертов. Безопасное внедрение начинают с тестового узла, ограничивают сетевой доступ, проверяют сохранность данных и только затем подключают остальные серверы.

Ключевые предпосылки перед развёртыванием

• Определите контролируемые показатели: загрузку CPU, память, диски, файловые системы, сеть и доступность сервисов.
• Разместите Prometheus там, где ему разрешён доступ к endpoint-ам метрик, но сами endpoint-ы не опубликованы в интернет.
• Запланируйте хранение данных и резервирование конфигураций Prometheus, Grafana и правил алертинга.
• Начинайте с одного тестового сервера: ошибка в конфигурации scrape может увеличить нагрузку или оставить систему без наблюдения.
• Сразу разделите права: сбор метрик не должен требовать административного доступа к операционным системам.

Архитектура мониторинга: схемы развертывания Prometheus и Grafana

Типовая схема для небольшого и среднего окружения выглядит так: Prometheus периодически забирает метрики с экспортёров, Grafana обращается к Prometheus как к источнику данных, а Alertmanager доставляет уведомления.

Серверы → node_exporter → Prometheus → Grafana
                                      ↘ Alertmanager → почта или корпоративный канал

Такой подход подходит для мониторинга серверов Prometheus Grafana, когда нужен контроль инфраструктуры с единым хранилищем временных рядов.

Кому подходит схема

• Командам, которым нужен самостоятельный контроль серверов без внешнего SaaS.
• Инфраструктуре с доступными HTTP endpoint-ами метрик.
• Проектам, где важны PromQL, собственные дашборды и гибкие правила оповещений.

Когда лучше не начинать с неё

• Если нет ресурсов на сопровождение, обновление и проверку алертов.
• Если инфраструктура распределена между сетями без устойчивой маршрутизации.
• Если требуется долговременное хранение в большом масштабе без отдельного решения для remote storage.

Развёртывание Prometheus: установка, конфиг и первичный сбор метрик

Для первого стенда понадобятся Linux-сервер, доступ администратора для установки пакетов, отдельный системный пользователь, свободное место для временных рядов и сетевой доступ от Prometheus к экспортёрам.

Что подготовить заранее

• Имя или IP-адрес узла Prometheus.
• Список серверов, которые нужно наблюдать.
• Политику firewall между Prometheus и endpoint-ами метрик.
• Путь для конфигурации и данных.
• Резервную копию конфигурационных файлов перед изменениями.

Для эксперимента можно использовать официальный архив Prometheus, пакет операционной системы или контейнерный образ. Независимо от способа установки проверьте контроль целостности загружанного файла и запускайте сервис от непривилегированного пользователя.

promtool check config /etc/prometheus/prometheus.yml
promtool check rules /etc/prometheus/rules/*.yml

Минимальная конфигурация может выглядеть так:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets:
          - 127.0.0.1:9090

После запуска откройте веб-интерфейс Prometheus только из административной сети и проверьте состояние цели в разделе /targets. Изменения конфигурации сначала проверяйте командой promtool, затем применяйте способом, предусмотренным вашей системой запуска.

Экспортёры, сервис-дискавери и тонкости конфигурации scrape_configs

Для Linux-серверов обычно используют node_exporter. Он предоставляет системные метрики по HTTP; отдельный экспортёр нужен для базы данных, reverse proxy, очереди или другого прикладного сервиса.

Риски и ограничения перед подключением

• Открытый порт экспортёра может раскрыть сведения об инфраструктуре.
• Слишком короткий интервал сбора увеличивает сетевую и дисковую нагрузку.
• Избыточные или динамические labels ускоряют рост числа временных рядов.
• Перезапись конфигурации без проверки может остановить сбор метрик со всех целей.

1. Установите экспортёр на тестовый сервер.

   Создайте отдельного системного пользователя и запускайте node_exporter без root-прав. Разрешите доступ к его порту только с адреса Prometheus.

   • Не публикуйте endpoint экспортёра напрямую в интернет.
   • Зафиксируйте версию и способ обновления.
2. Добавьте тестовую цель.

   В prometheus.yml укажите отдельную группу:

   scrape_configs:
     - job_name: linux-servers
       static_configs:
         - targets:
             - 10.0.0.21:9100
           labels:
             environment: test
             role: web

   Значения job, instance и labels используйте последовательно: они влияют на запросы, графики и маршрутизацию алертов.

3. Проверьте доступность endpoint-а.

   С узла Prometheus выполните запрос к адресу экспортёра и убедитесь, что возвращается текстовый набор метрик:

   curl http://10.0.0.21:9100/metrics

   Если запрос не проходит, проверьте маршрут, firewall, прослушиваемый адрес и состояние сервиса.

4. Проверьте scrape-конфигурацию.

   Перед перезагрузкой выполните проверку синтаксиса и посмотрите статус цели в Prometheus. Статус DOWN означает, что метрики не собираются, даже если сам сервер работает.

5. Подключите сервис-дискавери при росте окружения.

   Для виртуальных машин, Kubernetes или облачных ресурсов используйте соответствующий механизм обнаружения, чтобы не поддерживать длинные списки адресов вручную.

   • Ограничивайте обнаруживаемые цели фильтрами.
   • Нормализуйте labels через relabeling.
   • Не переносите в labels уникальные идентификаторы запросов и пользователей.
6. Настройте relabeling осторожно.

   Удаляйте внутренние технические labels только после проверки дашбордов и правил. Ошибочный relabeling может объединить разные серверы в одну серию или сделать цель непредсказуемой.

Такая последовательность подходит для сценария "мониторинг инфраструктуры с Prometheus": сначала проверяется один endpoint, затем добавляются группы серверов и автоматическое обнаружение.

Настройка Grafana: источники данных, дашборды и визуализационные паттерны

Установите Grafana на отдельный узел либо рядом с Prometheus в небольшом тестовом окружении. В интерфейсе добавьте Prometheus как источник данных, укажите внутренний URL и выполните проверку соединения. Не делайте административный интерфейс общедоступным.

Проверка результата

• Источник данных Prometheus успешно проходит проверку соединения.
• Запрос к метрике доступности возвращает данные.
• На графике различаются серверы по label instance.
• Есть отдельные панели для CPU, памяти, файловых систем и сети.
• Временной диапазон панели соответствует интервалу хранения данных.
• Пустые значения и отсутствие цели визуально заметны.
• Дашборд экспортирован в файл или хранится в системе управления версиями.
• Права пользователей Grafana ограничивают изменение источников и алертов.

Для панели CPU можно начать с PromQL-запроса, который показывает долю времени, не занятую ожиданием и другими исключёнными состояниями:

100 - (avg by (instance) (
  rate(node_cpu_seconds_total{mode="idle"}[5m])
) * 100)

Для свободного места используйте отдельную панель с фильтрами файловых систем. Проверяйте запросы на тестовом сервере: неверные регулярные выражения могут скрыть проблемные точки или создать слишком много серий.

Алертинг и обработка инцидентов: правила, маршруты и интеграции

Алерт должен описывать наблюдаемое условие, длительность его сохранения и понятное действие. Пример правила:

groups:
  - name: host-health
    rules:
      - alert: TargetDown
        expr: up{job="linux-servers"} == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Цель недоступна"
          description: "Prometheus не получает метрики с {{ $labels.instance }}."

Пример показывает принцип; пороги и длительность нужно согласовать с особенностями вашей инфраструктуры и графиком обслуживания.

Распространённые ошибки

• Алерты создаются без for, поэтому кратковременный сетевой сбой превращается в шум.
• В правилах нет labels для маршрутизации по окружению или критичности.
• Текст уведомления не содержит имени цели и причины срабатывания.
• Не настроено состояние resolved, поэтому команда не видит восстановление.
• Порог выбран по общему мнению, а не по наблюдаемому поведению сервиса.
• Есть алерт на каждую техническую метрику, но нет алертов на пользовательский эффект.
• Правила не проверяются через promtool перед применением.
• Канал доставки не тестируется после изменения маршрутов.

Перед включением уведомлений проведите контролируемый тест: временно остановите экспортёр на тестовом сервере, убедитесь в срабатывании, доставке и закрытии инцидента, затем восстановите сервис.

Ограничения, безопасность и масштабирование в продуктивной среде

Базовая установка Prometheus и Grafana хорошо подходит для начала, но продуктивная эксплуатация требует контроля доступа, резервирования и наблюдения за самой системой мониторинга.

• Reverse proxy с TLS. Уместен, когда нужно централизовать шифрование, аутентификацию и сетевые политики для Grafana.
• Remote write или долгосрочное хранилище. Подходит, если локального хранения Prometheus недостаточно по объёму или сроку.
• Федерация Prometheus. Полезна для разделения регионов, команд или кластеров при необходимости собирать агрегированные метрики.
• Операторная установка. Подходит для Kubernetes, где конфигурация целей и правил должна управляться декларативно.

Практические меры защиты

• Ограничьте доступ к Prometheus, Grafana, Alertmanager и endpoint-ам экспортёров сетевыми правилами.
• Храните секреты интеграций вне открытого репозитория и ограничьте права на конфигурационные файлы.
• Регулярно сохраняйте дашборды, правила, конфигурации и параметры запуска.
• Контролируйте заполнение диска и состояние самого Prometheus.
• Тестируйте восстановление конфигурации, а не только создание резервной копии.
• Следите за количеством временных рядов и не добавляйте высококардинальные labels без необходимости.

Быстрые решения для распространённых проблем и сомнений

Почему цель Prometheus отображается как DOWN?

Проверьте сетевой маршрут, firewall, адрес прослушивания экспортёра и доступность URL /metrics с узла Prometheus. Затем изучите сообщение об ошибке в разделе целей.

Нужно ли устанавливать экспортёр на каждый сервер?

Для системных метрик обычно нужен экспортёр на каждом наблюдаемом узле. Для прикладных метрик установка зависит от конкретного сервиса и доступного экспортёра.

Можно ли разместить Prometheus и Grafana на одном сервере?

Для небольшого стенда это допустимо. В продуктивной среде разделение упрощает контроль нагрузки и снижает риск, что сбой одного компонента одновременно скроет метрики и дашборды.

Как часто нужно собирать метрики?

Начните с умеренного интервала и изменяйте его после оценки нагрузки, объёма данных и требований к обнаружению инцидентов. Более частый сбор не всегда улучшает диагностику.

Что делать, если Grafana показывает пустой график?

Проверьте источник данных, временной диапазон, название метрики и labels. Выполните запрос в Explore и убедитесь, что Prometheus действительно получил образцы.

Как не потерять настройки при обновлении?

Храните конфигурацию, правила и экспорт дашбордов в резервной копии или системе управления версиями. Перед обновлением проверьте конфигурацию и подготовьте план отката.

Подходит ли Prometheus как единственная система мониторинга серверов?

Он хорошо закрывает сбор временных рядов, визуализацию и алертинг в связке с Grafana и Alertmanager. Для трассировки, журналов и длительного хранения могут понадобиться отдельные специализированные компоненты.