Как настроить мониторинг VPS через Prometheus, Grafana и Node Exporter

Prometheus, Grafana и Node Exporter позволяют собрать полноценную систему мониторинга VPS без использования внешних SaaS-сервисов. Node Exporter предоставляет системные метрики сервера, Prometheus регулярно собирает и хранит их, а Grafana отображает данные на понятных дашбордах.

В этом руководстве настроим мониторинг загрузки CPU, использования RAM, диска, файловой системы и сетевого трафика. Также импортируем готовый дашборд Node Exporter, зададим retention для Prometheus и создадим оповещения о заполнении диска, высокой нагрузке и недоступности Node Exporter.

Для использования в production-среде, корректнее настраивать систему мониторинга и хранить метрики на отличном от объекта мониторинга сервере - это позволит иметь доступ к историческим данным при серьёзном сбое VPS или расследовании инцидентов. Но мы сегодня настроим комбайн на одном VPS, в рамках демонстрации технологий и возможностей.

Система позволит:

• Отслеживать состояние VPS в реальном времени;
• Анализировать загрузку CPU, RAM, дисков и сети;
• Хранить историю метрик в Prometheus;
• Выявлять проблемы с ресурсами сервера;
• Контролировать доступность Node Exporter.

Prometheus и Node Exporter при этом не будут доступны напрямую из интернета. Для внешнего доступа оставим только Grafana, которую опубликуем через Nginx по HTTPS. В результате получим централизованный и безопасный мониторинг VPS с историей показателей, дашбордом и базовыми оповещениями.

Как устроен мониторинг VPS через Prometheus и Grafana

Для мониторинга VPS удобно разделить систему на три компонента: Node Exporter собирает системные показатели сервера, Prometheus периодически забирает эти метрики и сохраняет их, а Grafana используется для визуализации данных и построения дашбордов.

Такая схема позволяет не только видеть текущее состояние сервера, но и анализировать изменение нагрузки во времени. Например, можно определить, в какой момент начал расти расход памяти, когда закончилось свободное место на диске или насколько изменилась сетевая активность после обновления приложения.

За что отвечает Node Exporter

Node Exporter — это экспортер метрик для Linux-систем. Он работает на сервере и предоставляет Prometheus информацию о состоянии операционной системы и оборудования.

После запуска Node Exporter собирает данные о процессоре, памяти, файловых системах, дисковых устройствах, сетевых интерфейсах, времени работы системы и других параметрах. По умолчанию метрики доступны через HTTP endpoint /metrics.

Например: http://127.0.0.1:9100/metrics

В ответ Node Exporter возвращает набор метрик в формате Prometheus. Среди них можно встретить:

node_cpu_seconds_total

node_memory_MemAvailable_bytes

node_filesystem_avail_bytes

node_network_receive_bytes_total

node_network_transmit_bytes_total

Сам Node Exporter не хранит историю. Его задача — предоставить текущее состояние сервера в момент обращения.

Как Prometheus собирает и хранит метрики

Prometheus работает по pull-модели: он самостоятельно обращается к указанным targets через заданный интервал и получает от них метрики.

В нашем случае Prometheus будет обращаться к Node Exporter: 127.0.0.1:9100

Адрес задается в конфигурационном файле prometheus.yml:

scrape_configs:

  - job_name: "node"

    static_configs:

      - targets:

          - "127.0.0.1:9100"

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

Для запросов используется язык PromQL. Например, получить объем доступной оперативной памяти можно через: node_memory_MemAvailable_bytes

А среднюю загрузку CPU можно рассчитать на основе изменения счетчиков node_cpu_seconds_total за заданный промежуток времени.

Продолжительность хранения данных задается параметрами retention. Это позволяет ограничить объем диска, который Prometheus использует для истории метрик.

Как Grafana визуализирует данные

Grafana не собирает системные метрики самостоятельно. Вместо этого Prometheus подключается к ней как Data Source, после чего Grafana выполняет PromQL-запросы и отображает полученные результаты на графиках, таблицах и других панелях.

Один дашборд может одновременно показывать:

• Загрузку CPU;
• Использование оперативной памяти;
• Свободное и занятое место;
• Нагрузку на дисковые устройства;
• Сетевой трафик;
• Load Average;
• uptime VPS.

Для Node Exporter существуют готовые Grafana-дашборды. Поэтому необязательно вручную создавать десятки панелей и PromQL-запросов: достаточно импортировать подходящий шаблон и связать его с нашим Prometheus Data Source.

Какие метрики VPS будем отслеживать

В рамках руководства сосредоточимся на показателях, которые позволяют быстро оценить состояние VPS.

Для CPU будем отслеживать процент загрузки и Load Average. Длительная высокая нагрузка может указывать на нехватку вычислительных ресурсов, слишком тяжелые процессы или проблемы в приложении.

Для оперативной памяти важны общий объем RAM, доступная память и доля занятой памяти. При постоянном дефиците RAM система может начать активно использовать swap, что заметно снижает производительность.

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

Сетевые метрики покажут объем входящего и исходящего трафика по интерфейсам. Они помогают выявлять резкие скачки нагрузки, необычную активность и изменение характера трафика.

Дополнительно Prometheus будет следить за доступностью самого Node Exporter. Если target перестанет отвечать, это станет отдельным условием для оповещения.

Подготовка VPS к мониторингу

Перед установкой компонентов обновим систему, проверим доступные ресурсы и заранее определим, какие сетевые порты понадобятся системе мониторинга.

Обновление системы и проверка ресурсов сервера

В примере используется VPS под управлением Ubuntu. Сначала обновим индекс пакетов и установленные пакеты:

sudo apt update

sudo apt upgrade -y

После обновления можно проверить версию системы: lsb_release -a

Посмотрим количество процессорных ядер: nproc

Объем оперативной памяти: free -h

И свободное место на дисках: df -h

Prometheus хранит историю метрик локально, поэтому при выборе retention важно учитывать доступное дисковое пространство. Чем больше targets, метрик и срок хранения, тем быстрее будет увеличиваться каталог данных Prometheus.

Для одного VPS с Node Exporter требования относительно небольшие, однако оставлять дисковое пространство без контроля все равно не стоит.

Какие порты используют Prometheus, Grafana и Node Exporter

По умолчанию компоненты используют следующие TCP-порты:

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

Prometheus будет получать метрики Node Exporter локально, а Grafana — обращаться к локальному Prometheus.

Из интернета понадобится открыть только SSH для администрирования и HTTP/HTTPS для веб-доступа через Nginx.

Почему порты мониторинга нельзя оставлять общедоступными

Node Exporter предоставляет достаточно подробную информацию о сервере: файловых системах, сетевых интерфейсах, нагрузке, памяти и других системных характеристиках.

Prometheus, в свою очередь, предоставляет веб-интерфейс и API для работы с собранными метриками. Открывать такие интерфейсы всему интернету без необходимости не стоит.

В нашем варианте Node Exporter и Prometheus будут использоваться только локально. Они будут доступны на VPS для других компонентов системы мониторинга, но не будут опубликованы как внешние сервисы.

Grafana также изначально работает на собственном порту 3000, однако прямой внешний доступ к нему оставлять не будем. В конце настройки разместим Grafana за Nginx и будем обращаться к ней через HTTPS.

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

Установка и настройка Node Exporter

Первым компонентом развернем Node Exporter. После этого Prometheus сможет начать получать реальные системные метрики VPS.

Создание отдельного пользователя Node Exporter

Node Exporter не требует root-доступа для обычного сбора системных метрик, поэтому запустим его от отдельной системной учетной записи.

Создадим пользователя без домашнего каталога и возможности интерактивного входа:

sudo useradd \

  --no-create-home \

  --shell /usr/sbin/nologin \

  node_exporter

Проверим учетную запись: id node_exporter

Такой подход отделяет сервис мониторинга от административной учетной записи VPS и уменьшает объем привилегий процесса.

Установка Node Exporter как systemd-сервиса

Скачаем архив Node Exporter и распакуем его. В примере номер версии указан явно:

cd /tmp

wget https://github.com/prometheus/node_exporter/releases/download/v1.9.1/node_exporter-1.9.1.linux-amd64.tar.gz

Распакуем архив: tar xvf node_exporter-1.9.1.linux-amd64.tar.gz

Переместим бинарный файл: sudo cp node_exporter-1.9.1.linux-amd64/node_exporter /usr/local/bin/

Назначим владельца: sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

Проверим установку: /usr/local/bin/node_exporter --version

Теперь создадим systemd-unit: sudo nano /etc/systemd/system/node_exporter.service

Добавим:

[Unit]

Description=Prometheus Node Exporter

After=network-online.target

Wants=network-online.target

[Service]

User=node_exporter

Group=node_exporter

Type=simple

ExecStart=/usr/local/bin/node_exporter \

  --web.listen-address=127.0.0.1:9100

Restart=on-failure

RestartSec=5s

[Install]

WantedBy=multi-user.target

Параметр:

--web.listen-address=127.0.0.1:9100

сразу ограничивает Node Exporter локальным интерфейсом. Поэтому порт 9100 не будет слушать публичный IP VPS.

Применим конфигурацию и запустим сервис:

sudo systemctl daemon-reload

sudo systemctl enable --now node_exporter

Проверка работы экспортера и доступных метрик

Проверим состояние: sudo systemctl status node_exporter --no-pager

Сервис должен находиться в состоянии: Active: active (running)

Теперь убедимся, что endpoint действительно отвечает локально: curl http://127.0.0.1:9100/metrics | head

В ответ появятся метрики в формате Prometheus, например:

# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.

# TYPE node_cpu_seconds_total counter

node_cpu_seconds_total{cpu="0",mode="idle"} ...

Проверить, на каком интерфейсе слушается сервис, можно командой: sudo ss -lntp | grep 9100

Ожидаемый адрес: 127.0.0.1:9100

Это подтверждает, что Node Exporter работает и доступен Prometheus локально, но его порт не опубликован напрямую в интернет.

Установка и настройка Prometheus

После запуска Node Exporter можно установить Prometheus. Он будет регулярно обращаться к локальному endpoint 127.0.0.1:9100, сохранять полученные метрики и предоставлять их Grafana.

Создание пользователя и каталогов Prometheus

Как и Node Exporter, Prometheus лучше запускать от отдельной системной учетной записи без возможности интерактивного входа.

Создадим пользователя:

sudo useradd \

  --no-create-home \

  --shell /usr/sbin/nologin \

  prometheus

Для конфигурации и хранения данных понадобятся отдельные каталоги:

sudo mkdir -p /etc/prometheus

sudo mkdir -p /var/lib/prometheus

Назначим владельца каталога с данными: sudo chown prometheus:prometheus /var/lib/prometheus

Каталог /etc/prometheus будет использоваться для основного конфигурационного файла и дополнительных правил, а /var/lib/prometheus — для базы временных рядов Prometheus.

Установка Prometheus

Скачаем архив Prometheus в каталог /tmp:

cd /tmp

wget https://github.com/prometheus/prometheus/releases/download/v3.5.0/prometheus-3.5.0.linux-amd64.tar.gz

Распакуем его: tar xvf prometheus-3.5.0.linux-amd64.tar.gz

Перейдем в каталог: cd prometheus-3.5.0.linux-amd64

Скопируем бинарные файлы: sudo cp prometheus promtool /usr/local/bin/

Перенесем стандартную конфигурацию и каталоги веб-интерфейса:

sudo cp prometheus.yml /etc/prometheus/prometheus.yml

sudo cp -r consoles console_libraries /etc/prometheus/

Назначим владельца:

sudo chown prometheus:prometheus /usr/local/bin/prometheus

sudo chown prometheus:prometheus /usr/local/bin/promtool

sudo chown -R prometheus:prometheus /etc/prometheus

Проверим установленную версию: prometheus --version

Теперь создадим systemd-unit: sudo nano /etc/systemd/system/prometheus.service

Добавим:

[Unit]

Description=Prometheus Monitoring

Wants=network-online.target

After=network-online.target

[Service]

User=prometheus

Group=prometheus

Type=simple

ExecStart=/usr/local/bin/prometheus \

  --config.file=/etc/prometheus/prometheus.yml \

  --storage.tsdb.path=/var/lib/prometheus \

  --web.listen-address=127.0.0.1:9090

Restart=on-failure

RestartSec=5s

[Install]

WantedBy=multi-user.target

Параметр:

--web.listen-address=127.0.0.1:9090

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

Добавление Node Exporter в prometheus.yml

Теперь укажем Prometheus, откуда нужно получать системные метрики.

Откроем конфигурацию: sudo nano /etc/prometheus/prometheus.yml

Оставим базовую конфигурацию и добавим отдельный job для Node Exporter:

global:

  scrape_interval: 15s

  evaluation_interval: 15s

scrape_configs:

  - job_name: "prometheus"

    static_configs:

      - targets:

          - "127.0.0.1:9090"

  - job_name: "node"

    static_configs:

      - targets:

          - "127.0.0.1:9100"

Параметр scrape_interval: 15s означает, что Prometheus будет получать новые значения метрик каждые 15 секунд.

Перед перезапуском проверим синтаксис: sudo promtool check config /etc/prometheus/prometheus.yml

При корректной конфигурации появится сообщение: SUCCESS: /etc/prometheus/prometheus.yml is valid prometheus config file syntax

Применим изменения:

sudo systemctl daemon-reload

sudo systemctl enable --now prometheus

Проверим статус: sudo systemctl status prometheus --no-pager

Сервис должен находиться в состоянии active (running).

Проверка target в Prometheus

Так как веб-интерфейс Prometheus доступен только локально, проверить targets можно через его HTTP API: curl -s http://127.0.0.1:9090/api/v1/targets

Для более удобной проверки можно отфильтровать вывод: curl -s http://127.0.0.1:9090/api/v1/targets | grep -o '"health":"[^"]*"'

Для работающего Node Exporter должно отображаться: "health":"up"

Позже, когда Grafana будет подключена к Prometheus, все эти данные станут доступны через графический интерфейс.

Настройка хранения метрик Prometheus

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

Как работает retention в Prometheus

Retention определяет, как долго Prometheus сохраняет исторические метрики.

Чем дольше история, тем больше данных можно использовать для анализа. Например, недельная история позволяет сравнивать нагрузку между днями, а месячная — выявлять более длительные тенденции.

При этом объем данных зависит от нескольких факторов:

• Количества targets;
• Числа собираемых метрик;
• Интервала scrape;
• Продолжительности хранения;
• Активности временных рядов.

Для одного VPS с Node Exporter объем обычно остается умеренным, однако даже в таком случае полезно установить явные ограничения.

Ограничение срока хранения метрик

Срок хранения задается параметром: --storage.tsdb.retention.time

Например, для хранения истории в течение 15 дней: --storage.tsdb.retention.time=15d

Откроем unit: sudo nano /etc/systemd/system/prometheus.service

Добавим параметр к ExecStart:

ExecStart=/usr/local/bin/prometheus \

  --config.file=/etc/prometheus/prometheus.yml \

  --storage.tsdb.path=/var/lib/prometheus \

  --storage.tsdb.retention.time=15d \

  --web.listen-address=127.0.0.1:9090

После изменения unit-файла необходимо перечитать конфигурацию systemd:

sudo systemctl daemon-reload

sudo systemctl restart prometheus

Теперь Prometheus будет удалять данные старше установленного периода.

Ограничение объема хранилища

Дополнительно можно ограничить максимальный объем локального TSDB: --storage.tsdb.retention.size=5GB

Тогда итоговый блок запуска будет выглядеть так:

ExecStart=/usr/local/bin/prometheus \

  --config.file=/etc/prometheus/prometheus.yml \

  --storage.tsdb.path=/var/lib/prometheus \

  --storage.tsdb.retention.time=15d \

  --storage.tsdb.retention.size=5GB \

  --web.listen-address=127.0.0.1:9090

Таким образом, хранение будет ограничено одновременно по времени и объему.

Проверим состояние сервиса: sudo systemctl status prometheus --no-pager

А фактические параметры запуска: ps aux | grep '[p]rometheus'

В выводе должны присутствовать:

--storage.tsdb.retention.time=15d

--storage.tsdb.retention.size=5GB

Установка и настройка Grafana

Теперь установим Grafana. Она будет использовать Prometheus как источник данных и предоставит удобный веб-интерфейс для просмотра метрик VPS.

Установка Grafana на VPS

Сначала установим необходимые пакеты: sudo apt install -y apt-transport-https software-properties-common wget

Добавим ключ репозитория Grafana: sudo mkdir -p /etc/apt/keyrings

wget -q -O - https://apt.grafana.com/gpg.key | \

  gpg --dearmor | \

  sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null

Добавим официальный репозиторий:

echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | \

  sudo tee /etc/apt/sources.list.d/grafana.list

Обновим индекс пакетов: sudo apt update

Установим Grafana: sudo apt install -y grafana

Проверить установленную версию можно командой: grafana-server -v

Запуск Grafana через systemd

Включим автоматический запуск и запустим сервис: sudo systemctl enable --now grafana-server

Проверим состояние: sudo systemctl status grafana-server --no-pager

По умолчанию Grafana слушает порт 3000.

Проверим: sudo ss -lntp | grep 3000

На этом этапе интерфейс можно использовать для первоначальной настройки, однако в итоговой конфигурации прямой публичный доступ к 3000 оставлять не будем. Позже Grafana будет опубликована через Nginx и HTTPS.

Добавление Prometheus как Data Source

Откроем Grafana в браузере по адресу: http://203.0.113.10:3000

Для первого входа используются стандартные учетные данные:

Login: admin

Password: admin

После первого входа Grafana предложит изменить пароль администратора.

Чтобы подключить Prometheus, откроем: Connections → Data sources → Add data source → Prometheus

В поле URL укажем: http://127.0.0.1:9090

Поскольку Grafana и Prometheus работают на одном VPS, обращаться к Prometheus через публичный или внутренний IP не требуется.

Сохраним источник данных и выполним проверку подключения. Grafana должна подтвердить успешное соединение с Prometheus.

После этого Grafana сможет выполнять PromQL-запросы к Prometheus и использовать собранные Node Exporter метрики для построения дашбордов.

Импорт готового дашборда для Node Exporter

После подключения Prometheus к Grafana можно перейти от отдельных запросов к полноценному дашборду. Это удобнее, чем вручную собирать с нуля десятки панелей для CPU, памяти, диска и сети.

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

Выбор дашборда Node Exporter

Для мониторинга одного VPS удобно использовать готовый дашборд, который уже содержит основные панели для Linux-сервера.

Один из самых популярных вариантов — дашборд Node Exporter Full. Его часто используют как базовый шаблон, поскольку он уже включает:

• Загрузку CPU;
• Использование RAM;
• Load Average;
• Активность дисков;
• Файловые системы;
• Сетевой трафик;
• Uptime;
• Базовые показатели по I/O и inode.

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

Импорт дашборда в Grafana

В интерфейсе Grafana откройте: Dashboards → New → Import

Если используется ID из библиотеки Grafana, его можно вставить в поле импорта. Для Node Exporter часто используют: 1860

После загрузки Grafana предложит выбрать Data Source. Укажите созданный ранее источник: Prometheus

Далее подтвердите импорт.

После этого в Grafana появится готовый дашборд с набором панелей для VPS. На начальном этапе удобно оставить его почти без изменений, а затем при необходимости адаптировать под конкретный сервер — например, скрыть лишние панели или переименовать заголовки.

Проверка поступления метрик

После импорта откройте дашборд и убедитесь, что панели не пустые. Если Prometheus уже получает данные от Node Exporter, Grafana сразу начнет строить графики.

Для быстрой проверки достаточно убедиться, что на дашборде отображаются:

• Текущая загрузка CPU;
• Объем занятой и доступной памяти;
• Свободное место на файловых системах;
• Сетевой трафик по интерфейсам;
• Показатели дисковой активности.

Если панели остаются пустыми, следует проверить три точки цепочки:

1. Работает ли Node Exporter;
2. Видит ли его Prometheus как target UP;
3. Подключен ли в Grafana правильный Data Source.

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

Мониторинг основных ресурсов VPS

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

Загрузка CPU и Load Average

По CPU обычно отслеживают два связанных, но не одинаковых показателя: процент загрузки и Load Average.

Процент загрузки CPU показывает, какую долю процессорного времени занимают полезные вычисления, а какую — простой. Если загрузка долго удерживается на высоком уровне, это может указывать на тяжелые фоновые процессы, неэффективный код приложения, периодические пики нагрузки или недостаток ресурсов VPS.

Load Average показывает среднее количество задач, которые выполняются или ожидают выполнения. Этот показатель особенно полезен в связке с числом процессорных ядер.

Например, если на VPS два vCPU и load стабильно выше 2, это уже может означать перегрузку. Кратковременные скачки не всегда критичны, но постоянный высокий Load Average — хороший повод проверить процессы, использование CPU и общую нагрузку на приложение.

Использование оперативной памяти

Для памяти важно смотреть не только на общий процент использования, но и на структуру потребления RAM.

На Linux часть памяти активно используется под page cache и buffers, поэтому сама по себе высокая цифра занятой памяти еще не означает проблему. Более показательны:

• Объем доступной памяти;
• Доля реально свободной памяти;
• Использование swap;
• Изменение памяти во времени.

Если память постепенно убывает и не освобождается, это может указывать на утечку памяти в приложении. Если при этом начинает активно использоваться swap, производительность VPS обычно ухудшается.

Поэтому на практике полезно отслеживать и общую загрузку RAM, и тенденцию: растет ли использование памяти стабильно, скачками или остается на обычном уровне.

Свободное место и заполнение файловой системы

Одна из самых частых проблем на VPS — заполнение диска. Когда заканчивается место, могут перестать работать приложения, резервное копирование, база данных, логирование и обновления системы, даже вход по ssh может быть недоступен.

На дашборде стоит отслеживать:

• Общий размер файловой системы;
• Доступное свободное место;
• Процент заполнения;
• Распределение места по основным mount points.

Особенно важно контролировать системный раздел, а также каталоги, где хранятся:

• Логи;
• Файлы приложения;
• База данных;
• Резервные копии;
• Метрики Prometheus.

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

Дисковый ввод-вывод

Дисковый I/O помогает понять, насколько активно VPS читает и записывает данные. Эти показатели особенно важны для серверов с базой данных, логированием, очередями задач и частыми файловыми операциями.

На практике обычно смотрят:

• Скорость чтения и записи;
• Количество операций чтения и записи;
• Время ожидания I/O;
• Загрузку устройства.

Если CPU и память выглядят нормально, но приложение тормозит, причина может быть именно в дисковой подсистеме. Повышенный I/O и длительные задержки часто говорят о том, что сервер упирается в диск, а не в процессор.

Сетевой трафик

Сетевые метрики показывают объем входящего и исходящего трафика по интерфейсам. Они помогают заметить:

• Рост нагрузки на веб-приложение;
• Интенсивную фоновую синхронизацию;
• Аномальную активность;
• Последствия обновлений или миграций.

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

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

Настройка оповещений

Графики удобны для анализа, но для оперативной реакции на проблему нужны оповещения. В этом руководстве настроим три базовых alert rule в Grafana на основе данных Prometheus:

• Заполнение диска;
• Высокая нагрузка;
• Недоступность Node Exporter.

Такой набор закрывает наиболее частые сценарии: нехватку места, перегрузку VPS и потерю самого источника системных метрик.

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

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

Оповещение о заполнении диска

Первое оповещение предупредит о том, что свободного места на файловой системе становится слишком мало.

В качестве условия удобно использовать процент свободного места. Например, если доступно менее 15%, правило должно сработать.

В Grafana откройте: Alerts & IRM → Alert rules → New alert rule

В качестве выражения можно использовать:

(

  node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}

  /

  node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}

) * 100 < 15

Такой запрос вычисляет долю свободного места в процентах и исключает временные файловые системы вроде tmpfs и overlay, которые обычно не используются для хранения постоянных данных.

Назовите правило, например:

DiskSpaceLow

И задайте небольшую задержку срабатывания, например for 5m, чтобы избежать реакции на слишком короткие колебания.

Оповещение о высокой нагрузке

Второе правило будет следить за высокой загрузкой CPU.

Для этого можно использовать выражение на основе node_cpu_seconds_total, рассчитывающее долю времени, когда процессор не находится в idle:

100 - (

  avg by(instance) (

    rate(node_cpu_seconds_total{mode="idle"}[5m])

  ) * 100

) > 80

Если результат превышает 80, это означает, что CPU в среднем загружен более чем на 80% за последние 5 минут.

Назовите правило: HighLoad

И также задайте окно подтверждения, например for 5m.

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

Оповещение о недоступности Node Exporter

Третье правило должно срабатывать, если Prometheus перестал получать метрики от Node Exporter.

Для этого используем стандартную метрику доступности up: up{job="node"} == 0

Если target недоступен, Prometheus запишет 0, и правило перейдет в состояние alert.

Назовите его: NodeExporterDown

Это оповещение особенно важно, потому что при остановке Node Exporter или потере связи с ним все остальные системные метрики перестанут обновляться. В результате отсутствие этого правила могло бы создать ложное ощущение, что сервер просто «в норме», хотя данные на самом деле перестали поступать.

Проверка правил оповещений

После создания правил Grafana покажет их в общем списке alert rules. На этом этапе стоит убедиться, что:

• Все три правила сохранены;
• В качестве источника выбран Prometheus;
• Выражения выполняются без ошибок;
• Начальное состояние правил — Normal.

Список должен содержать как минимум:

DiskSpaceLow

HighLoad

NodeExporterDown

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

Проверка срабатывания оповещений

После создания alert rules нужно убедиться, что они действительно переходят в состояние тревоги при выполнении заданного условия. Для этого лучше использовать контролируемый тестовый сценарий, который не создает реальную проблему для VPS.

Искусственное создание тестового условия

Самый простой вариант — временно остановить Node Exporter. В этом случае Prometheus перестанет получать метрики от target node, и правило NodeExporterDown должно сработать.

Остановим сервис: sudo systemctl stop node_exporter

Проверим состояние: sudo systemctl status node_exporter --no-pager

Сервис должен отображаться как остановленный.

Prometheus продолжит выполнять scrape по расписанию, но запрос к:

127.0.0.1:9100

начнет завершаться ошибкой.

Если для правила задано условие: up{job="node"} == 0

то после очередной оценки Prometheus передаст Grafana значение, соответствующее недоступности target.

Проверка перехода alert из Pending в Firing

Если для правила установлен период подтверждения, например: for 5m. Оно обычно не переходит в Firing мгновенно.

Сначала состояние изменяется на: Pending

Это означает, что условие уже выполняется, но заданный период еще не истек.

Если Node Exporter остается недоступным достаточно долго, состояние становится: Firing

Откройте в Grafana: Alerts & IRM → Alert rules

и найдите правило: NodeExporterDown

При успешном тесте оно должно отображаться в состоянии Firing.

Аналогичным способом можно тестировать и другие правила, но искусственно заполнять системный диск или создавать длительную высокую нагрузку на рабочем сервере обычно не требуется. Для проверки базовой логики достаточно безопасно отключить Node Exporter.

Возврат системы в нормальное состояние

После проверки снова запустим Node Exporter: sudo systemctl start node_exporter

Убедимся, что сервис работает: sudo systemctl status node_exporter --no-pager

Через несколько циклов scrape Prometheus снова увидит target как доступный.

Проверить это можно через API: curl -s http://127.0.0.1:9090/api/v1/targets | grep -o '"health":"[^"]*"'

В ответ должно появиться: "health":"up"

После восстановления target правило NodeExporterDown вернется в состояние Normal.

Защита интерфейсов мониторинга

На этом этапе система мониторинга уже работает, но важно убедиться, что служебные интерфейсы не доступны напрямую из интернета.

Node Exporter и Prometheus должны использоваться только локально, а Grafana будет опубликована через Nginx по HTTPS.

Закрытие портов 9090 и 9100 от внешнего доступа

Node Exporter и Prometheus мы уже запустили с параметрами 127.0.0.1:9100 и 127.0.0.1:9090

Это означает, что сервисы слушают только loopback-интерфейс VPS.

Проверим: sudo ss -lntp | grep -E '9090|9100'

Ожидаемый результат:

• 127.0.0.1:9090
• 127.0.0.1:9100

Если используется UFW, дополнительно убедимся, что наружу разрешены только необходимые порты:

sudo ufw allow OpenSSH

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw enable

Проверим правила: sudo ufw status

Порты 9090, 9100 и 3000 отдельно открывать не нужно.

Доступ к Grafana через Nginx

Установим Nginx: sudo apt install -y nginx

Для Grafana понадобится домен, например: grafana.example.com

DNS-запись типа A должна указывать на публичный IP VPS.

Создадим конфигурацию: sudo nano /etc/nginx/sites-available/grafana

Добавим:

server {

    listen 80;

    server_name grafana.example.com;

    location / {

        proxy_pass http://127.0.0.1:3000;

        proxy_http_version 1.1;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

    }

}

Активируем сайт: sudo ln -s /etc/nginx/sites-available/grafana /etc/nginx/sites-enabled/grafana

Проверим конфигурацию: sudo nginx -t

Если синтаксис корректен, перезагрузим Nginx:

sudo systemctl reload nginx

Теперь Grafana будет доступна через Nginx по домену, а прямое обращение к Prometheus и Node Exporter по-прежнему останется закрытым.

Настройка HTTPS для Grafana

Установим Certbot: sudo apt install -y certbot python3-certbot-nginx

Запросим сертификат: sudo certbot --nginx -d grafana.example.com

Certbot получит TLS-сертификат и автоматически обновит конфигурацию Nginx.

После этого Grafana станет доступна по адресу: https://grafana.example.com

Проверим конфигурацию: sudo nginx -t

И статус Nginx: sudo systemctl status nginx --no-pager

Проверка доступности сервисов после ограничения портов

В браузере Grafana должна открываться только через HTTPS: https://grafana.example.com

При этом обращения к публичному IP VPS на служебных портах не должны давать доступ к интерфейсам:

http://203.0.113.10:9090

http://203.0.113.10:9100

http://203.0.113.10:3000

Локально же все сервисы продолжат взаимодействовать друг с другом:

curl http://127.0.0.1:9100/metrics | head

curl http://127.0.0.1:9090/-/healthy

Так Grafana остается доступной пользователю, а внутренние компоненты мониторинга не публикуются напрямую в интернет.

Обслуживание системы мониторинга

После первоначальной настройки система не требует постоянного вмешательства, но периодически стоит проверять состояние сервисов, журналы и доступность targets.

Проверка состояния сервисов

Быстро проверить все основные компоненты можно отдельными командами:

sudo systemctl status node_exporter --no-pager

sudo systemctl status prometheus --no-pager

sudo systemctl status grafana-server --no-pager

sudo systemctl status nginx --no-pager

Для более компактной проверки можно использовать: systemctl is-active node_exporter prometheus grafana-server nginx

Для всех работающих сервисов система должна вернуть: active

Просмотр логов Prometheus, Grafana и Node Exporter

Журналы systemd помогают быстро понять причину ошибки запуска, недоступности target или проблемы с конфигурацией.

Node Exporter: sudo journalctl -u node_exporter -n 50 --no-pager

Prometheus: sudo journalctl -u prometheus -n 50 --no-pager

Grafana: sudo journalctl -u grafana-server -n 50 --no-pager

Для просмотра новых сообщений в реальном времени используется параметр -f: sudo journalctl -u prometheus -f

Это особенно удобно после изменения конфигурации или перезапуска сервиса.

Обновление компонентов мониторинга

Grafana, установленную из APT-репозитория, можно обновлять стандартными средствами системы:

sudo apt update

sudo apt upgrade

Node Exporter и Prometheus в нашем примере установлены из архивов. Для обновления нужно скачать новую версию, заменить бинарный файл и перезапустить соответствующий systemd-сервис.

Перед заменой Prometheus желательно сохранить текущую конфигурацию: sudo cp /etc/prometheus/prometheus.yml /etc/prometheus/prometheus.yml.bak

После обновления проверяйте конфигурацию: sudo promtool check config /etc/prometheus/prometheus.yml

И только затем перезапускайте сервис: sudo systemctl restart prometheus

Сам каталог TSDB удалять при обычном обновлении не требуется.

Что делать, если Prometheus перестал получать метрики

Если Grafana перестала обновлять данные, сначала стоит проверить всю цепочку от Node Exporter до визуализации.

Проверим Node Exporter: curl http://127.0.0.1:9100/metrics | head

Если endpoint не отвечает, проверим сервис: sudo systemctl status node_exporter --no-pager

Если Node Exporter работает, проверим состояние target в Prometheus: curl -s http://127.0.0.1:9090/api/v1/targets

После этого проверим конфигурацию: sudo promtool check config /etc/prometheus/prometheus.yml

И журналы: sudo journalctl -u prometheus -n 50 --no-pager

Также важно убедиться, что Prometheus действительно слушает локальный порт: sudo ss -lntp | grep 9090

Если Prometheus получает метрики, но Grafana показывает No data, проблема обычно находится уже на уровне Data Source, PromQL-запроса или самого импортированного дашборда.

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

Заключение

Prometheus, Grafana и Node Exporter позволяют собрать на VPS полноценную систему мониторинга без подключения внешнего SaaS-сервиса. Node Exporter предоставляет системные метрики Linux, Prometheus регулярно собирает и хранит их, а Grafana превращает временные ряды в понятные графики и дашборды.

В результате настройки мы получили мониторинг CPU, оперативной памяти, файловых систем, дискового ввода-вывода и сетевого трафика, импортировали готовый дашборд, ограничили срок и объем хранения метрик, а также настроили базовые оповещения о заполнении диска, высокой нагрузке и недоступности Node Exporter.

Отдельное внимание уделили безопасности: Prometheus и Node Exporter слушают только локальные интерфейсы, а Grafana доступна через Nginx по HTTPS. Благодаря этому служебные порты мониторинга не приходится публиковать напрямую в интернет.

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

FAQ

Нужно ли устанавливать Node Exporter на каждый VPS?

Да, если требуется собирать системные метрики с нескольких Linux-серверов, Node Exporter обычно запускают на каждом из них. Prometheus затем опрашивает все указанные targets и сохраняет полученные временные ряды. Node Exporter специально предназначен для экспорта аппаратных и системных метрик Unix-подобных систем.

Можно ли использовать Grafana без Prometheus?

Да. Grafana поддерживает множество источников данных, включая Prometheus, различные SQL-базы, Loki и другие backend-системы. В этой конфигурации именно Prometheus отвечает за сбор и хранение системных метрик, а Grafana используется для их визуализации.

Нужно ли открывать порт 9100 в интернет?

Нет, если Prometheus работает на том же VPS. В этом случае Node Exporter можно привязать к 127.0.0.1:9100, и Prometheus будет получать метрики локально. Это уменьшает поверхность атаки и соответствует схеме, использованной в руководстве.

Если Prometheus находится на другом сервере, доступ к 9100 потребуется организовать через приватную сеть, VPN или ограниченные firewall-правила, а не публиковать порт для всего интернета.

Чем отличается Prometheus от Grafana?

Prometheus собирает метрики, хранит временные ряды и позволяет выполнять запросы к ним через PromQL. Grafana подключается к Prometheus как Data Source и использует полученные данные для построения панелей и дашбордов.

Как долго Prometheus хранит метрики?

Срок зависит от настроенного retention. Prometheus позволяет ограничивать хранение по времени и по занимаемому объему. При планировании размера локального хранилища разработчики Prometheus рекомендуют оставлять запас дискового пространства, а не разрешать TSDB занимать весь доступный диск.

Почему alert сначала переходит в Pending, а не сразу в Firing?

Если для правила задан pending period, условие должно оставаться истинным в течение указанного времени. Пока этот период не истек, правило находится в состоянии Pending. Если условие продолжает выполняться, оно переходит в Firing. Такая задержка помогает не реагировать на кратковременные пики. Grafana позволяет задавать evaluation interval и pending period для правил оповещений.

Что делать, если после импорта дашборда отображается No data?

Сначала стоит проверить всю цепочку:

1. Node Exporter отвечает на /metrics.
2. Prometheus видит target со статусом UP.
3. Grafana подключена к правильному Prometheus Data Source.
4. Импортированный дашборд использует подходящие метрики и выбран нужный источник данных.

Grafana поддерживает импорт готовых дашбордов и позволяет при импорте выбрать соответствующий Data Source.

Можно ли использовать эту схему для нескольких VPS?

Да. В prometheus.yml можно добавить несколько Node Exporter targets. После этого Prometheus будет регулярно опрашивать каждый сервер, а Grafana сможет фильтровать и сравнивать показатели по instance.

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

Список источников

1. Prometheus Documentation — Overview
2. Prometheus Documentation — Monitoring Linux host metrics with the Node Exporter
3. Prometheus Documentation — Storage
4. Grafana Documentation — Prometheus data source and alerting