← Вернуться к оглавлению
📊 Мониторинг VPS: выбор инструмента
Версия 1.0 | 12 сентября 2026
Сравнение трёх систем мониторинга — Netdata, Prometheus + node_exporter + Grafana и Zabbix — применительно к конкретному серверу: Docker-стек веб-проектов + VPN-панель 3x-ui. В конце — рекомендация.
📋 Исходные данные и требования
Сервер
- VPS: Ubuntu 24.04, 2 vCPU, 4 GB RAM, 40 GB SSD, 100 Mbps
- План масштабирования: апгрейд до 8 GB RAM + 80 GB SSD
Что работает (кандидаты на мониторинг)
VPS 193.32.179.138
├── Nginx Proxy Manager (:80, :443, :81)
├── Portainer (:9443)
├── Dozzle (:9999) # логи контейнеров
├── Watchtower # автообновление образов
├── Uptime Kuma (:3001) # доступность
├── 3x-ui (VPN) # порты 20000–20100 TCP/UDP, панель vpn.avk27.ru
├── Main Site (avk27.ru)
└── Проекты (go / php / node.js + БД)
Требования к мониторингу
- Диск — занято/свободно по разделам, алерты при 80–90%. Критично: 40 GB съедают бэкапы (
/opt/backups), образы Docker, БД проектов
- Нагрузка — CPU, load average, RAM, swap
- Сеть — суммарный трафик и трафик именно VPN-контейнера 3x-ui
- Контейнеры — CPU/RAM каждого, включая 3x-ui
- История — видеть динамику, а не только «прямо сейчас»
- Уведомления — Telegram при выходе за пороги
- Безопасность — панель мониторинга не должна торчать в интернет (сервер с VPN регулярно сканируется)
🔍 Что уже есть и чего не хватает
| Инструмент |
Диск (место) |
CPU / нагрузка |
История и алерты |
| Portainer |
❌ только объём образов/томов Docker |
⚠️ по контейнерам, в реальном времени |
❌ |
| Uptime Kuma |
❌ |
❌ |
⚠️ только доступность (HTTP/TCP/ping) |
| Dozzle |
❌ |
❌ |
❌ только логи |
Вывод: хостовых метрик (диск, load average, RAM) с историей и уведомлениями нет ни у одного установленного сервиса. Нужен отдельный инструмент.
🛡️ Специфика: сервер с 3x-ui
💡 Разделение ответственности: статистику трафика по каждому inbound и клиенту показывает сама панель 3x-ui (раздел статистики в веб-интерфейсе). Ни одна из трёх сравниваемых систем этого не заменяет — они работают на уровне хоста и контейнеров и дополняют панель.
Что добавляет хостовый мониторинг именно для VPN-части:
- Трафик контейнера 3x-ui — сколько реально проходит через VPN в сумме, отдельно от веб-проектов. Всплеск ночью = повод проверить, не утёк ли ключ клиента;
- CPU контейнера — шифрование/расшифровка Xray (VLESS-Reality) при активных клиентах заметно грузит ядра;
- Диск — логи Xray и растущая БД статистики 3x-ui тоже занимают место;
- Суммарный трафик eth0 — контроль лимита трафика хостера, если он есть.
⚠️ Безопасность: диапазон 20000–20100 открыт всему интернету, сервер регулярно сканируется. Панель мониторинга публикуем
только через Nginx Proxy Manager с SSL и Basic Auth (схема из
инструкции, шаг 13), порт в ufw не открываем.
1️⃣ Netdata
Что это: один Docker-контейнер, мониторинг в реальном времени с разрешением до 1 секунды. Конфигурация после запуска не нужна — метрики собираются автоматически.
Покрытие требований
- ✅ Диск по разделам + inodes, включая прогноз заполнения (алерт «диск кончится через N часов») — из коробки;
- ✅ CPU, load average, RAM, swap, диск I/O — из коробки;
- ✅ Каждый контейнер отдельно (cgroups), включая 3x-ui: его CPU, RAM и сетевой трафик видны без дополнительных экспортеров;
- ✅ Сеть по интерфейсам (eth0, входящий/исходящий);
- ✅ Алерты из коробки + уведомления в Telegram (настраивается одним файлом);
- ⚠️ История: по умолчанию часы–дни локально; можно увеличить до недель за счёт диска (dbengine).
Ресурсы и эксплуатация
- RAM: ~200–400 MB, диск: ~1–2 GB под метрики;
- 1 контейнер, 0 дополнительных компонент;
- Развёртывание: 15–30 минут;
- Обслуживание: минимальное (следить за обновлениями образа — Watchtower сделает сам).
Слабые стороны
- Длинная история (месяцы) — не его профиль без настройки retention;
- Специфический интерфейс, дашборды хуже кастомизируются, чем в Grafana;
- На парк из многих серверов без Netdata Cloud смотрится хуже конкурентов;
- Активно зовёт в облако Netdata Cloud (регистрация опциональна, локально всё работает и без неё).
2️⃣ Prometheus + node_exporter + Grafana
Что это: конструктор из компонентов: node_exporter собирает метрики хоста, cAdvisor — контейнеров, Prometheus хранит временные ряды (TSDB) и вычисляет алерты на языке PromQL, Grafana рисует дашборды. Промышленный стандарт: именно этот стек чаще всего встречается в вакансиях и продакшене.
Покрытие требований
- ✅ Диск, CPU, load average, RAM, сеть — через node_exporter;
- ⚠️ Контейнеры (включая 3x-ui) — только после добавления cAdvisor в стек;
- ✅ История: месяцы и годы, retention настраивается (например,
--storage.tsdb.retention.time=180d);
- ⚠️ Алерты: нужно писать правила PromQL + настраивать Alertmanager (ещё один компонент) или Grafana Unified Alerting;
- ✅ Telegram — через Alertmanager;
- ✅ Готовые дашборды из каталога: Node Exporter Full (id 1860), cAdvisor (id 14282) и тысячи других.
Ресурсы и эксплуатация
- RAM: ~400–800 MB суммарно (Prometheus + Grafana + экспортеры);
- Диск: ~1–3 GB в месяц на TSDB (зависит от интервала сбора и числа серий, регулируется);
- 3–5 компонент: prometheus, grafana, node-exporter, cadvisor (+ alertmanager);
- Развёртывание: 2–4 часа до рабочего состояния с дашбордами и первым алертом;
- Обслуживание: среднее — обновления компонент, правки scrape-конфигов и правил.
Слабые стороны
- Больше всего ручной работы из трёх кандидатов: «собери сам»;
- Каждый компонент — отдельная точка отказа и обновления;
- Для чтения дашбордов и написания алертов нужен PromQL.
3️⃣ Zabbix
Что это: всеохватывающая платформа мониторинга «всё в одном»: сервер + база PostgreSQL + веб-интерфейс + агент. Шаблоны, триггеры, зависимости, эскалации, SLA-отчёты. Создан для парков серверов и сетевого оборудования.
Покрытие требований
- ✅ Диск, CPU, RAM, сеть — по готовому шаблону «Linux by Zabbix agent»;
- ✅ Контейнеры (включая 3x-ui) — через Zabbix Agent 2 с плагином Docker (доступ к docker.sock);
- ✅ История: месяцы/годы в БД, housekeeping настраивается;
- ✅ Алерты: триггеры с зависимостями, эскалации на несколько уровней, Telegram из коробки;
- ✅ Гибкость: можно мониторить почти что угодно (сервисы, логи, web-сценарии).
Ресурсы и эксплуатация
- RAM: ~600 MB – 1.2 GB суммарно (сервер + PostgreSQL + PHP-фронтенд + agent2);
- Диск: ~2–5 GB стабильно под БД истории при настроенном housekeeping;
- 4 контейнера: zabbix-server, postgresql, zabbix-web, zabbix-agent2;
- Развёртывание: 3–6 часов (стек + хост + шаблоны + первые триггеры);
- Обслуживание: выше среднего — обновления БД и фронтенда мажорных версий нетривиальны.
Слабые стороны
- Самый тяжёлый из трёх по ресурсам и числу компонент;
- Самый долгий путь до первого графика: хосты, item'ы, триггеры настраиваются вручную;
- Для одного сервера — избыточен: его сила раскрывается на десятках машин;
- Интерфейс функционален, но тяжеловесен.
⚖️ Сравнительная таблица
| Критерий |
Netdata |
Prometheus + Grafana |
Zabbix |
| Диск, CPU, RAM, сеть хоста |
✅ из коробки |
✅ node_exporter |
✅ шаблон |
| Контейнеры (вкл. 3x-ui) |
✅ из коробки (cgroups) |
⚠️ нужен cAdvisor |
✅ agent2 + Docker-плагин |
| Разрешение метрик |
1 секунда |
15–60 секунд |
~1 минута |
| Прогноз заполнения диска |
✅ из коробки |
⚠️ писать правило PredictLinear |
✅ forecast-функции в триггерах |
| История |
часы–дни (до недель) |
месяцы–годы |
месяцы–годы |
| Алерты + Telegram |
✅ минимальная настройка |
⚠️ правила + Alertmanager |
✅ триггеры, эскалации |
| Дашборды |
готовые, слабо кастомные |
⭐ лучшие (Grafana) |
функциональные |
| RAM (ориентир) |
200–400 MB |
400–800 MB |
600 MB – 1.2 GB |
| Диск (ориентир) |
1–2 GB |
1–3 GB/мес |
2–5 GB |
| Компонентов |
1 |
3–5 |
4 |
| Развёртывание |
15–30 мин |
2–4 часа |
3–6 часов |
| Один сервер |
⭐ идеально |
ради истории и дашбордов |
избыточен |
| Парк серверов |
слабее |
⭐ стандарт индустрии |
⭐ сильнейший |
📈 Учет масштабирования до 8 GB / 80 GB
С апгрейдом до 8 GB RAM + 80 GB SSD ресурсы перестают быть ограничением: все три стека помещаются с запасом рядом с текущими сервисами и 3x-ui. Выбор становится вопросом не «влезет ли», а «сколько времени и внимания вы готовы вкладывать» и «что будет дальше»:
| Сценарий |
Лучший выбор |
| Один сервер, закрыть вопрос за вечер |
Netdata |
| Красивые дашборды, история за месяцы, интерес к DevOps-практикам |
Prometheus + Grafana |
| Несколько серверов, регламенты, эскалации, SLA |
Zabbix (сервер — на отдельной, более мощной машине, на этом VPS только agent2 ~30 MB) |
🏆 Рекомендация
Вердикт: Netdata — сейчас, Prometheus + Grafana — на вырост, Zabbix — не для этого сервера.
Netdata закрывает все семь требований из раздела «Требования» за полчаса, без единой строчки конфигурации: место на диске с прогнозом заполнения, нагрузка, и — отдельно от всего остального трафика — CPU и сеть контейнера 3x-ui. При текущих 4 GB он занимает вдвое-втрое меньше конкурентов, при апгрейде до 8 GB это перестаёт быть важно, но простота остаётся.
Если со временем серверов станет несколько и захочется дашбордов уровня «как в больших компаниях» — имеет смысл собрать Prometheus + Grafana: экспортеры на узлах лёгкие, а знания PromQL окупаются. Апгрейд до 8 GB / 80 GB даёт этому стеку комфортный запас и для истории за месяцы.
Zabbix для одного VPS не рекомендуем независимо от ресурсов: столько же метрик дадут дешевле по времени и обслуживанию. Его ниша — парк машин с регламентами и эскалациями.
В любом варианте per-client статистика VPN остаётся в панели 3x-ui, Uptime Kuma продолжает следить за доступностью, Portainer — за контейнерами, Dozzle — за логами.
🚀 Быстрый старт: Netdata за 15 минут
Шаг 1: compose-файл
Создайте файл /opt/infrastructure/netdata.yml:
version: '3.8'
services:
netdata:
image: netdata/netdata:stable
container_name: netdata
restart: unless-stopped
cap_add:
- SYS_PTRACE
- SYS_ADMIN
security_opt:
- apparmor:unconfined
pid: host
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /etc/os-release:/host/etc/os-release:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./netdata/config:/etc/netdata
- ./netdata/lib:/var/lib/netdata
- ./netdata/cache:/var/cache/netdata
expose:
- "19999"
networks:
- webproxy
networks:
webproxy:
external: true
Шаг 2: запуск
cd /opt/infrastructure
docker compose -f netdata.yml up -d
# Проверка
docker ps | grep netdata
docker logs netdata 2>&1 | tail -5
Шаг 3: доступ через NPM
- Откройте админку NPM: http://193.32.179.138:81
- Hosts → Proxy Hosts → Add Proxy Host
- Domain:
netdata.avk27.ru, Scheme: http, Forward Hostname: netdata, Forward Port: 19999
- Вкладка SSL: сертификат
*.avk27.ru, Force SSL, HTTP/2
- Вкладка Advanced — Basic Auth по схеме из шага 13 инструкции
⚠️ Порт 19999 в ufw НЕ открываем — используется expose вместо ports, наружу панель выглядит только через NPM с SSL и паролем.
Шаг 4: уведомления в Telegram (опционально, ~10 минут)
- Создайте бота через @BotFather, получите токен
- Узнайте свой chat_id (например, через @userinfobot)
- Впишите их в файл
/opt/infrastructure/netdata/config/health_alarm_notify.conf: TELEGRAM_BOT_TOKEN и TELEGRAM_CHAT_ID, выставите role_recipients_telegram
- Перезапустите:
docker restart netdata
💡 Облако: регистрация в Netdata Cloud опциональна — локальная панель, метрики и алерты полностью работают и без неё. Просто не выполняйте claim.
🔐 Безопасность (общие правила для любого из трёх стеков)
- Панели мониторинга — только через NPM: SSL + Basic Auth, никаких открытых портов в ufw;
- Exporter'ы (node_exporter :9100, cAdvisor :8080) и Zabbix agent (:10050) не имеют собственной авторизации — не публикуйте их наружу вообще, только во внутренней Docker-сети;
- Prometheus (:9090) тоже держать только внутри сети webproxy;
- Доступ к docker.sock (Netdata, cAdvisor, Zabbix agent2) — только read-only (
:ro);
- Помните: у VPN-сервера повышенный «интерес» извне — лишняя открытая панель = лишняя точка входа.
🎉 Готово. Сравнение обновляйте при изменении конфигурации сервера или появлении новых узлов.