Как настроить мониторинг VPS с помощью Prometheus, Node Exporter и Grafana

В этой обзорной статье разберём без «адового дебага» и сложных настроек:

  • из чего состоит связка Prometheus + Node Exporter + Grafana и кто за что отвечает;
  • как выглядит типичная схема мониторинга на VPS;
  • как в общих чертах происходит установка и базовая настройка;
  • какие метрики можно увидеть и как использовать дашборды на практике;
  • когда такой стек оправдан, а когда достаточно более простых инструментов.

Общая архитектура: кто что делает

Чтобы понимать, что вы настраиваете, важно сначала разобрать роли компонентов.

Prometheus

  • Работает как «центр сбора» метрик.

  • Периодически опрашивает источники (экспортеры) по HTTP и сохраняет данные в свою базу.

  • Умеет строить простые графики и выполнять запросы к метрикам с помощью PromQL.

Node Exporter

  • Небольшой демон, который ставится на сам VPS.

  • Отдаёт метрики по CPU, памяти, диску, файловым системам, сети и т.д. в формате, понятном Prometheus.

  • Обычно слушает на локальном порту (по умолчанию 9100).

Grafana

  • Веб-интерфейс для построения дашбордов и графиков.

  • Подключается к Prometheus как к источнику данных (datasource).

  • Позволяет импортировать готовые дашборды и делать свои панели под проекты.

Вместе это выглядит так:

  • VPS → Node Exporter → Prometheus → Grafana → браузер администратора.

Типовая схема мониторинга для одного VPS

Для одного сервера схема обычно максимально простая:

  • Node Exporter установлен на этом же VPS и собирает метрики системы.

  • Prometheus может стоять либо на этом же VPS, либо на другом (центральном) сервере мониторинга.

  • Grafana подключается к Prometheus и открывается из браузера по HTTP/HTTPS.

Конфигурация Prometheus для одного VPS с Node Exporter в самом простом варианте выглядит примерно так:

global:
  scrape_interval: 15s  # как часто опрашивать метрики

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets:
        - 'localhost:9100'   # Node Exporter на этом же сервере

Эта настройка говорит Prometheus: «каждые 15 секунд ходи по адресу localhost:9100 и забирай оттуда метрики».

Установка и базовая настройка: общая логика

У каждого дистрибутива и хостинга будут свои нюансы, но общая логика развертывания выглядит так.

1. Установить и запустить Node Exporter

Главная задача — чтобы Node Exporter работал как системный сервис и отдавал метрики по HTTP на локальном порту.

  1. Скачать бинарник Node Exporter для своей архитектуры или установить пакет из репозитория.

  2. Создать unit-файл systemd (например, /etc/systemd/system/node_exporter.service), где прописать команду запуска.

  3. Включить автозапуск и запустить службу.

  4. Проверить, что по адресу http://127.0.0.1:9100/metrics отдаются текстовые метрики.

В простом сценарии достаточно, чтобы Node Exporter был доступен либо локально, либо с того сервера, где запущен Prometheus.

2. Настроить Prometheus

  1. Установить Prometheus (пакет/бинарник/Docker-контейнер).

  2. Указать в prometheus.yml свой scrape_config с адресом Node Exporter.

  3. Запустить службу Prometheus и открыть его веб-интерфейс (обычно http://IP:9090).

  4. На вкладке Targets увидеть, что job node в статусе UP.

3. Подключить Grafana и импортировать дашборд

  1. Установить Grafana и открыть её веб-интерфейс (по умолчанию http://IP:3000).

  2. Добавить новый datasource типа Prometheus, указав URL Prometheus (например, http://localhost:9090).

  3. Импортировать готовый дашборд для Node Exporter из каталога Grafana (по ID или JSON-файлу).

Важно: в боевой среде почти всегда добавляют ещё один слой — фаервол и/или обратный прокси с авторизацией, чтобы панели мониторинга не были открыты всему интернету.

Что можно увидеть в Grafana: ключевые метрики

После того как Grafana подключена к Prometheus и дашборд для Node Exporter импортирован, вы получаете набор стандартных панелей по серверу.

Типичные блоки дашборда

  • CPU usage — нагрузка на процессор (общая и по ядрам). Позволяет увидеть пики, среднюю загрузку и понять, не упирается ли всё в CPU.

  • Memory — использованная память, кэш, буферы, swap. Видно, когда сервер начинает активно использовать swap и когда стоит задуматься об увеличении RAM.

  • Disk I/O и Filesystems — загрузка диска, скорость чтения/записи, заполненность файловых систем. Это помогает найти моменты, когда дисковая подсистема становится узким местом.

  • Network — входящий/исходящий трафик, количество пакетов, ошибки. Удобно для отслеживания пиков нагрузки и подозрительной сетевой активности.

Плюс к этому можно добавить свои панели под конкретное приложение: метрики из PHP, Nginx, PostgreSQL, Redis и других экспортёров.

Когда имеет смысл заморачиваться с Prometheus и Grafana

Связка Prometheus + Node Exporter + Grafana — это уже «взрослый» мониторинг. Она особенно полезна в ситуациях, когда:

  • серверов несколько, и нужно смотреть на них одновременно;

  • нужна история метрик за недели/месяцы с гибкими запросами;

  • важно строить свои дашборды под проекты, продукты, клиентов;

  • планируются алерты по порогам (CPU, диски, задержки запросов и т.п.).

Если же у вас один VPS с несколькими сайтами и задача — раз в неделю проверить, «жив ли сервер» и не упирается ли он в ресурсы, то зачастую:

  • достаточно лёгких решений вроде Netdata;

  • или даже встроенного мониторинга у хостера + базовых утилит (top, htop, df, iostat).

Prometheus и Grafana начинают по-настоящему окупаться, когда мониторинг становится не разовой задачей, а частью постоянной работы с инфраструктурой.

Итоги

  • Разобрали роли компонентов в связке Prometheus + Node Exporter + Grafana и общую архитектуру мониторинга.

  • Посмотрели, как выглядит базовая конфигурация Prometheus для опроса Node Exporter на VPS.

  • Увидели, какие метрики по CPU, памяти, диску и сети можно получать и как они попадают на дашборды Grafana.

  • Обсудили, когда такой стек действительно нужен, а когда можно обойтись более простыми инструментами.

Вывод: Prometheus + Node Exporter + Grafana — это мощный и гибкий стек для мониторинга, который раскрывается на проектах с несколькими серверами и длительной историей метрик. Даже если на практике вы пока используете более простые решения, понимание этой архитектуры помогает выбирать инструменты осознанно и планировать развитие инфраструктуры VPS на будущее.

Оставить комментарий