Многие админы и DevOps привыкли начинать мониторинг с Zabbix или классического стека Prometheus + Grafana. Но всё чаще появляются требования:
— быстро поднять мониторинг на одном VDS;
— не разворачивать тяжёлый zoo из десятка контейнеров;
— иметь современную визуализацию, алерты и долгосрочное хранение метрик.
В этом контексте связка Netdata + VictoriaMetrics (и опционально Prometheus) — очень интересный вариант для self‑hosted мониторинга, особенно на небольших и средних проектах, которые живут на VDS или виртуальном хостинге.
Задача: простой, но не примитивный self‑hosted мониторинг
Когда вы арендуете VDS под прод, к нему обычно добавляются ещё несколько задач:
- Следить за нагрузкой по CPU, RAM, диску и сети.
- Мониторить сервисы: Nginx, PHP‑FPM, базы (MySQL/PostgreSQL), очереди, кэш.
- Хранить историю метрик хотя бы за полгода‑год.
- Получать алерты в Telegram/Slack/почту.
- Иметь понятные дашборды для быстрой диагностики инцидентов.
При этом не всегда хочется тянуть весь классический стек: Prometheus, Alertmanager, Grafana, Loki, exporters, logger‑агенты и т.д. Часто нужен:
- один «универсальный агент» для ноды (Node Exporter + куча интеграций из коробки);
- лёгкое, но эффективное хранилище time series;
- возможность роста: от одного VDS до нескольких десятков.
Здесь на сцену выходит Netdata как универсальный агент и UI, а VictoriaMetrics как гибкое хранилище метрик в формате Prometheus.
Краткий обзор: Netdata, Prometheus, VictoriaMetrics, Loki, Zabbix
Netdata
Netdata — это:
- агент, который сам собирает метрики системы и многих сервисов;
- встроенный веб‑интерфейс с интерактивными графиками;
- «из коробки» автообнаружение кучки демонов: Nginx, MySQL, Redis, PostgreSQL, systemd‑units, контейнеры и т.д.
Важно понимать: Netdata может работать полностью автономно — без Prometheus, без внешней БД метрик. Но его историческое хранение на одном узле ограничено ресурсами, а централизованный сбор для десятков серверов менее прозрачен.
Prometheus
Prometheus — де‑факто стандарт для метрик:
- pull‑модель (scrape endpoints);
- label‑based метки;
- PromQL для запросов;
- Alertmanager для алертов.
Минус для маленьких инсталляций — относительно тяжёлый и требовательный к памяти, плюс сложность масштабирования, если проект быстро растёт. Это и подтолкнуло к появлению альтернативных хранилищ, совместимых с протоколом Prometheus.
VictoriaMetrics
VictoriaMetrics — TSDB, совместимая с экосистемой Prometheus:
- понимает remote_write/remote_read;
- умеет принимать метрики по протоколу Prometheus (ingestion API);
- оптимизирована по памяти и диску (часто потребляет меньше ресурсов, чем Prometheus TSDB при той же нагрузке);
- поддерживает как single‑node режим, так и кластер.
В контексте этой статьи нас интересует single‑node режим на одном VDS: достаточно малый overhead, простая конфигурация и совместимость с привычными инструментами визуализации и алертинга.
Loki
Loki — это про логи, а не про метрики, но его часто упоминают в одном ряду с Prometheus и VictoriaMetrics, потому что:
- подход к меткам похож на Prometheus (labels);
- к логам можно применять похожую логику запросов и корреляций с метриками.
Для небольшой self‑hosted инсталляции Loki — опция, если вы хотите единый стек для логов и метрик в стиле Grafana. Но Loki не решает задачу TSDB, это отдельный компонент. Про метки и пайплайны в Loki у нас есть отдельный материал: как устроены labels и pipelines в Loki.
Zabbix
Zabbix — старый и проверенный конь, но со своими особенностями:
- монолитная архитектура с сервером, агентами, веб‑интерфейсом, БД (MySQL/PostgreSQL);
- богатый функционал триггеров и алертов, автообнаружение, карты, сценарии;
- сложность настройки и поддержки для небольшой команды, особенно без опыта;
- нагрузка на БД, необходимость грамотного тюнинга, чтобы не утонуть в IOPS.
Поэтому многие современные проекты ищут более лёгкий и гибкий стек, особенно если инфраструктура строится вокруг Prometheus‑совместимой экосистемы.
Почему именно связка Netdata + VictoriaMetrics
Если говорить просто, роли можно описать так:
- Netdata — умный агент и UI на каждом сервере.
- VictoriaMetrics — центральное хранилище метрик (single node на VDS).
Основные плюсы такого подхода:
- Netdata из коробки собирает гораздо больше метрик, чем базовый node_exporter.
- Есть свой дашборд, которым можно пользоваться даже без внешнего TSDB.
- VictoriaMetrics даёт эффективное, экономное хранилище метрик с PromQL.
- Можно подключить Grafana и/или использовать VMUI/VictoriaMetrics‑клиенты.
- Гибкая архитектура: от одного VDS (всё в одном месте) до схемы «агенты Netdata на нодах, центральный VictoriaMetrics плюс отдельный Prometheus/Alertmanager».
В результате получается современный self‑hosted мониторинг, который по ощущениям легче, чем Zabbix, и при этом полностью совместим с экосистемой Prometheus.
Архитектурные варианты для небольшого VDS
1. Только Netdata на каждой ноде
Минимальный вариант: вы ставите Netdata на каждый VDS, логинитесь в его веб‑интерфейс по HTTPS или через SSH‑туннель и смотрите графики.
Подходит для одиночных серверов, стендов, временных проектов или когда достаточно ретенции в несколько дней и нет требований к централизованным алертам.
Плюсы:
- полчаса от нуля до рабочих графиков;
- нет отдельного «центрального сервера мониторинга»;
- мгновенный доступ к очень детализированным метрикам.
Минусы:
- нет единой точки для алертов и сводной картины;
- ограниченная история (съедается диск/память);
- неудобно коррелировать события между разными нодами.
2. Netdata + VictoriaMetrics без Prometheus
Здесь вы используете Netdata как источник метрик, а VictoriaMetrics — как TSDB. Схема зависит от того, каким способом вы забираете метрики:
- через Prometheus‑совместимый endpoint Netdata;
- через экспорт в Prometheus remote_write (в новых версиях Netdata есть интеграция).
Вариант без отдельного Prometheus подразумевает:
- Netdata отправляет метрики прямо в VictoriaMetrics (remote write);
- вы используете VictoriaMetrics как endpoint для запросов (PromQL) через Grafana или другие клиенты;
- алерты можно строить либо в Netdata (у него есть собственный алертинг), либо в Grafana (через alerting на промкъюэлях).
Такой сценарий хорош тем, что избавляет от отдельного Prometheus, но при этом сохраняет все плюсы TSDB и PromQL.
3. Netdata + Prometheus + VictoriaMetrics
Более сложный, но гибкий вариант:
- Netdata отдаёт метрики в формате Prometheus (scrape или push);
- Prometheus собирает их и использует VictoriaMetrics как remote_write хранилище для долгосрочной ретенции;
- Alertmanager и Grafana работают поверх Prometheus/VictoriaMetrics.
Смысл: VictoriaMetrics используется как «долгая память», а Prometheus отвечает за сбор, локальный кэш и алерты. Такой стек уже ближе к классическому enterprise‑подходу, при этом хранение метрик остаётся экономным.
Сравнение с Zabbix и «чистым» Prometheus
Против Zabbix
Частый сценарий: у вас есть десяток VDS, раньше вы использовали Zabbix, но упёрлись в:
- нагрузку на БД и медленные отчёты;
- сложные шаблоны, которые трудно поддерживать;
- ограниченную гибкость запросов к метрикам.
Переход к Netdata + VictoriaMetrics даёт:
- меньше компонентов (нет тяжёлой БД общего назначения под метрики);
- PromQL и гибкие лейблы вместо громоздких item/trigger;
- лёгких агентов, которые сами много чего умеют автообнаруживать.
Минус — вам придётся переосмыслить подход к алертам: от «магии триггеров» Zabbix к декларативным правилам в Prometheus/Grafana или встроенным алертам Netdata. Если вы уже работаете с Alertmanager, пригодится шпаргалка по роутингу и подавлению: как настраивать маршрутизацию и silence в Alertmanager.
Против чистого Prometheus
Если взять чистый Prometheus c node_exporter и кучей экспортёров, то возникают типичные боли:
- для каждого сервиса нужен свой exporter или custom‑endpoint;
- auto‑discovery ограничен (особенно в bare‑metal/VM‑инфра, без Kubernetes);
- поиск проблем на конкретной ноде требует многократных прыжков по дашбордам.
Netdata решает это тем, что работает как «all‑in‑one» агент ноды:
- видно сразу всё: CPU, диски, IO, процессы, systemd‑юниты, Docker, Nginx, базы;
- есть хороший drill‑down прямо на ноде, даже если Prometheus/TSDB недоступны;
- сбор множества метрик можно настроить в одном месте, без зоопарка экспортёров.
VictoriaMetrics в этом стек уделывает стандартное TSDB Prometheus по экономии ресурсов, особенно при длинной ретенции и большом количестве меток.
Практические сценарии использования
1. Один продовый VDS с web‑приложением
Небольшой проект, один VDS, стек: Nginx + PHP‑FPM + MariaDB/PostgreSQL. Задачи:
- видеть пиковую нагрузку (CPU, RAM, диск, сеть);
- отлавливать 502/504 и долгие запросы;
- иметь историю за 3–6 месяцев, чтобы планировать апгрейд ресурсов.
Решение:
- Netdata ставится на этот VDS и сразу даёт вам дашборд по всему стеку;
- VictoriaMetrics на том же или отдельном VDS — для долгосрочного хранения метрик;
- Grafana (при желании) — для красивых дашбордов и алертов.
Такой сетап спокойно влезает в небольшой инстанс, а пользы приносит гораздо больше, чем условный Zabbix на том же железе.
2. Несколько VDS: прод, стейджинг, CI
Распространённый кейс: есть три‑пять виртуалок под разные задачи (prod, stage, CI, тестовые стенды). Хочется видеть всё в одном месте.
Вариант:
- на каждом VDS — Netdata;
- на отдельном мониторинговом VDS — VictoriaMetrics и, возможно, Grafana;
- Netdata либо отправляет метрики через remote_write напрямую в VictoriaMetrics, либо их собирает Prometheus (если он у вас уже есть).
Дальше над этим строится:
- дашборды по окружениям (prod vs stage);
- алерты по SLA (ошибки HTTP, задержки БД, исчерпание места на диске);
- сравнение нагрузки до и после релизов.
3. Гибрид с Loki или другим log‑хранилищем
Логи и метрики хорошо дополняют друг друга. Типичная связка для небольшого проекта:
- Netdata + VictoriaMetrics для метрик;
- какой‑нибудь стек для логов: Loki, ELK, ClickHouse‑based решения;
- Grafana в качестве общей точки входа.
Метрики позволяют понять, когда и на чём случилась проблема (CPU, latency, ошибки), логи — что именно пошло не так. При грамотной настройке можно быстро прыгать из дашборда метрик в соответствующие фрагменты логов.
Ресурсные требования и тюнинг под VDS
Главный вопрос: сколько ресурсов «съест» такой мониторинг на VDS?
Netdata
На средней по размеру VDS (2–4 vCPU, 4–8 ГБ RAM) Netdata обычно:
- занимает сотни мегабайт RAM (зависит от числа включённых collectors и истории в памяти);
- производит незначительную нагрузку по CPU при типичной частоте сбора;
- даёт умеренную нагрузку на диск, если вы не держите чрезмерно длинную локальную историю.
Из практических рекомендаций:
- ограничьте глубину локального хранения, если у вас есть внешняя TSDB;
- отключите ненужные collectors (особенно те, что опрашивают тяжёлые сервисы);
- следите за метриками самого Netdata, он умеет «следить за собой».
VictoriaMetrics
VictoriaMetrics, даже в single‑node‑режиме, очень неплохо живёт на VDS‑ах среднего размера. При тонкой настройке можно:
- хранить миллионы таймсерий с умеренным потреблением RAM;
- оптимизировать retention (например, 3–6 месяцев в деталях, потом downsampling);
- контролировать I/O через ограничение частоты флашей и компакций.
При размещении VictoriaMetrics и боевых сервисов на одном VDS следите за:
- IOPS и latency диска (особенно если используется HDD или медленный сетевой диск);
- memory‑pressure: мониторьте page cache и swap;
- ограничениями через cgroups/systemd, чтобы TSDB не «выдавила» веб‑приложение.
Алертинг: где его лучше держать
В self‑hosted мире у вас есть несколько вариантов:
- алерты Netdata (встроенные);
- Prometheus + Alertmanager (если он уже используется);
- Grafana alerting, работающий по запросам к VictoriaMetrics;
- гибрид: критичные алерты в Prometheus, дополнительные — в Netdata.
Что удобно именно в контексте Netdata:
- много готовых health‑checks, не нужно всё писать с нуля;
- осмысленные дефолтные пороги (например, для CPU, RAM, диска);
- алерты остаются даже если внешнее хранилище или Prometheus временно недоступны.
Если вы строите стек вокруг VictoriaMetrics без отдельного Prometheus, разумно вынести большую часть алертинга в Grafana, особенно если нужно сложное условие по нескольким метрикам.
Пути развития и масштабирования
Хорошая новость: стек Netdata + VictoriaMetrics неплохо масштабируется без полной перестройки архитектуры.
- Начало: один VDS, на нём и приложение, и Netdata, и VictoriaMetrics. Всё компактно.
- Рост: выносите VictoriaMetrics и Grafana на отдельный мониторинговый VDS, а на боевых — только Netdata.
- Дальше: подключаете Prometheus (если нужен более продвинутый алертинг, service discovery, federation), оставаясь в рамках тех же форматов и протоколов.
- Ещё дальше: переключение VictoriaMetrics в кластерный режим при росте нагрузки и объёма метрик.
Важно, что нигде по пути вам не нужно выкидывать всё и начинать с нуля. Агент тот же, формат метрик тот же, визуализация совместима.
Когда лучше остаться на Zabbix или «чистом» Prometheus
Несмотря на все плюсы, бывают сценарии, где Netdata + VictoriaMetrics — не лучший выбор.
Имеет смысл остаться на Zabbix, если:
- у вас уже отлаженная инсталляция с десятками/сотнями хостов;
- команда хорошо знает Zabbix, а ценой за миграцию будет явный регресс по удобству;
- привязаны внешние системы, для которых уже написаны скрипты и интеграции под API Zabbix.
«Чистый» Prometheus без Netdata оправдан, если:
- у вас Kubernetes‑кластер и уже отстроенный service discovery;
- метрики сервисов стандартизированы, а node_exporter и несколько экспортёров полностью покрывают потребности;
- вы не хотите держать дополнительный агент с веб‑интерфейсом на каждой ноде по соображениям безопасности или минимализма.
Во всех остальных случаях стоит хотя бы протестировать связку Netdata + VictoriaMetrics на одном тестовом VDS — часто этого хватает, чтобы понять, что такой подход удобнее и легче в сопровождении. А если инфраструктура ещё только планируется, можно сразу выбирать подходящий тариф и купить хостинг под будущий стек мониторинга.
Итоги
Связка Netdata + VictoriaMetrics — мощный и при этом достаточно лёгкий вариант self‑hosted мониторинга для VDS:
- Netdata закрывает сбор метрик и оперативный UI на каждой ноде;
- VictoriaMetrics обеспечивает эффективное хранение и PromQL‑совместимый доступ к данным;
- стек хорошо масштабируется от одного сервера до небольшой фермы;
- поддерживается интеграция с Prometheus, Alertmanager, Grafana и системами логирования вроде Loki.
Если вам нужен современный мониторинг без тяжёлых монолитов и при этом с возможностью роста, стоит рассмотреть именно такой self‑hosted вариант на VDS и сравнить его в бою с привычными Zabbix и «голым» Prometheus.
