Prometheus vs VictoriaMetrics vs Netdata в 2026: что выбрать для VDS

Мониторинг на VDS давно перестал быть роскошью для больших команд. Даже один сервер с Nginx, PHP-FPM, PostgreSQL или Docker быстро превращается в «черный ящик», если вы не видите память, диск, latency, ошибки приложений и поведение процессов во времени. В 2026 году у администратора есть несколько популярных путей: поставить Prometheus с node exporter, заменить или дополнить его VictoriaMetrics, либо начать с Netdata как максимально быстрого способа увидеть, что происходит на Linux-сервере прямо сейчас.

В этой статье сравним Prometheus, VictoriaMetrics и Netdata именно с точки зрения VDS: ограниченные CPU и RAM, дисковая квота, необходимость простого бэкапа, алерты без лишней сложности, интеграция с Grafana и нормальная эксплуатация без отдельной SRE-команды. Это не инструкция по установке, а практичный обзор: какой стек выбрать для маленького проекта, интернет-магазина, API, нескольких VDS или self-hosted monitoring в небольшой инфраструктуре.

Короткая версия: Prometheus хорош как стандарт и язык экосистемы, VictoriaMetrics сильна как экономная TSDB и long-term storage, Netdata удобна как быстрый интерактивный мониторинг и диагностика «что горит прямо сейчас».

Что именно сравниваем

Все три продукта работают с метриками, но решают задачу по-разному. Prometheus — это система сбора, хранения и запросов по time series, построенная вокруг pull-модели: сервер сам ходит к endpoints и забирает метрики. Обычно на Linux-хостах рядом ставят node exporter, а для Nginx, MySQL, PostgreSQL, Redis, PHP-FPM и Docker добавляют отдельные exporters. Поверх Prometheus часто ставят Grafana для дашбордов и Alertmanager для уведомлений.

VictoriaMetrics — это высокопроизводительное хранилище метрик и набор совместимых компонентов. Для одного VDS чаще всего интересен single-node вариант: один бинарник, простой запуск, хорошая компрессия, совместимость с PromQL-подобными запросами MetricsQL, поддержка remote_write от Prometheus и собственный агент сбора vmagent. На практике VictoriaMetrics часто используют как замену Prometheus TSDB, как долгосрочное хранилище или как центральную точку для метрик с нескольких серверов.

Netdata — другой класс опыта. Он ориентирован на автообнаружение, мгновенную детализацию и большое количество готовых графиков без длительной настройки. Установили агент — и через минуту видите CPU, память, диск, сеть, systemd units, контейнеры, базы данных и веб-серверы, если они доступны для сбора. Netdata умеет отдавать метрики в Prometheus-совместимом формате и отправлять данные во внешние хранилища, но его главная сила — live troubleshooting.

Критерии выбора для VDS

На выделенных кластерах можно позволить себе тяжелые observability-платформы, но на VDS цена ошибки выше. Мониторинг не должен съедать ресурсы, которые нужны сайту или базе данных. Поэтому я бы сравнивал инструменты не только по возможностям, но и по эксплуатационным вопросам: сколько памяти занимает агент, как быстро растет диск, легко ли ограничить retention, можно ли пережить всплеск cardinality, насколько удобно восстанавливать данные после сбоя и получится ли разобраться в алерте ночью без трехчасового чтения документации.

Для одного VDS с сайтом на Linux обычно важны базовые сигналы: загрузка CPU, steal time, память и swap, iowait, заполнение диска и inode, скорость записи, сетевые ошибки, количество соединений, 5xx на веб-сервере, время ответа upstream, состояние systemd-сервисов, репликация и slow queries для базы данных. Если мониторинг это показывает, хранит историю хотя бы 7–30 дней и умеет предупредить до аварии, он уже приносит пользу.

Для нескольких VDS требования меняются. Нужна централизация, единые labels, нормальная навигация по инстансам, контроль retention и возможность не потерять производительность при добавлении exporters. Здесь Prometheus без федерации или remote storage может стать тесным, VictoriaMetrics начинает выглядеть привлекательнее, а Netdata лучше рассматривать как агент диагностики или быстрый слой визуализации, а не как единственную долговременную TSDB.

Prometheus: стандарт, который все понимают

Prometheus остается базовым языком мира метрик. Если вы открываете документацию к новым сервисам, вероятность увидеть endpoint /metrics, готовые recording rules и Grafana dashboard очень высока. Для администратора VDS это большой плюс: не нужно изобретать сбор для каждого компонента. Поставили node exporter, добавили exporters для нужных сервисов, прописали scrape jobs — и получили понятную модель.

Сильная сторона Prometheus — экосистема. PromQL знают многие инженеры, готовых правил алертинга много, Grafana работает с Prometheus из коробки, Alertmanager закрывает маршрутизацию уведомлений, группировку и silence. Если вы планируете расти от одного VDS к нескольким десяткам узлов, навыки Prometheus не пропадут: они пригодятся и в Kubernetes, и в bare metal, и в гибридной инфраструктуре.

Но у Prometheus есть особенности, которые важно учитывать на маленьком VDS. Локальная TSDB чувствительна к cardinality: большое число уникальных labels увеличивает память, размер индекса и нагрузку на диск. Частая ошибка — собирать метрики с labels вроде user_id, request_path с параметрами, container_id без нормализации или произвольные статусы задач. Пока сервер один, проблема может быть незаметна, но через пару недель вы получите неожиданный рост диска и медленные запросы.

Вторая особенность — Prometheus сам по себе не является идеальным long-term storage. Для 7–15 дней локальной истории он удобен, для месяцев и лет лучше подключать remote storage или строить отдельную архитектуру. Можно увеличить retention, но на VDS это быстро упирается в место и I/O. Если вам нужны метрики за год, Prometheus как единственное хранилище — не лучший выбор.

Когда Prometheus хорош на VDS

• Нужны стандартные exporters, Grafana dashboards и понятный путь развития.
• Команда уже знает PromQL или планирует использовать его дальше.
• История метрик нужна на короткий срок: например, 7–30 дней.
• Важны зрелые алерты через Alertmanager.
• Есть готовность следить за cardinality и retention.

Типичный хороший сценарий: один VDS для мониторинга и 2–10 рабочих VDS, на каждом node exporter и сервисные exporters, центральный Prometheus опрашивает targets, Grafana показывает дашборды, Alertmanager шлет уведомления. Это понятная и предсказуемая схема, если не пытаться хранить бесконечную историю и не собирать все подряд.

VictoriaMetrics: экономия ресурсов и длинная история

VictoriaMetrics особенно интересна для VDS из-за экономного хранения и простой single-node установки. В реальной эксплуатации она часто показывает меньший расход диска на тот же объем метрик и лучше переносит большие потоки записей. Для небольших команд это означает простую вещь: можно хранить больше истории на том же тарифе и реже заниматься чисткой TSDB.

Вариантов использования несколько. Первый — полностью заменить Prometheus на связку vmagent плюс victoria-metrics. Агент собирает метрики с targets, хранилище принимает и обслуживает запросы, Grafana подключается как к Prometheus-совместимому источнику. Второй — оставить Prometheus как привычный сборщик и отправлять данные в VictoriaMetrics через remote_write. Третий — использовать VictoriaMetrics как центральное long-term storage для нескольких Prometheus-инстансов.

Для VDS single-node VictoriaMetrics выглядит особенно аккуратно: один процесс, простой retention, хорошая скорость запросов, совместимость с Grafana. При этом MetricsQL расширяет возможности запросов, но требует небольшой адаптации, если вы привыкли только к классическому PromQL. Большинство базовых dashboards работают без боли, однако сложные выражения и recording rules стоит проверять отдельно.

Где подвох? VictoriaMetrics не отменяет дисциплину labels. Если вы зальете в нее миллионы уникальных рядов, она продержится дольше, чем многие альтернативы, но физику не обманет: память, индекс и диск все равно конечны. Также при переходе с Prometheus нужно внимательно посмотреть на алертинг. Можно использовать vmalert, можно оставить Prometheus/Alertmanager, можно строить гибридную схему. Главное — заранее решить, где живут правила и кто отвечает за уведомления.

Когда VictoriaMetrics лучше Prometheus

• Нужно хранить метрики дольше месяца на ограниченном диске VDS.
• Есть несколько серверов, и хочется центральное экономное хранилище.
• Prometheus уже есть, но локальная TSDB стала узким местом.
• Важно снизить расход CPU, RAM или диска на ingestion и queries.
• Нужна совместимость с Grafana без тяжелой observability-платформы.

На практике я часто выбираю VictoriaMetrics для инфраструктуры, где метрик уже больше, чем удобно держать в одном Prometheus, но полноценный кластерный стек еще избыточен. Для маленькой команды это хороший компромисс: self-hosted monitoring остается простым, а история не исчезает через неделю.

Netdata: быстрый рентген Linux-сервера

Netdata хорош тем, что почти не требует периода «сначала спроектируем мониторинг». Он сам находит много источников метрик и сразу показывает живые графики с высокой детализацией. Для администратора, который зашел на VDS с жалобой «сайт тормозит», это бесценно: можно быстро увидеть, что уперлось в iowait, какой процесс ест CPU, растет ли swap, не забит ли backlog, нет ли пиков по диску или сети.

В отличие от Prometheus и VictoriaMetrics, Netdata ощущается не как конструктор observability, а как готовый диагностический интерфейс. Он полезен даже тогда, когда у вас уже есть Grafana: глобальный дашборд показывает тренды, а Netdata помогает провалиться в конкретный хост и посмотреть подробности в момент инцидента. Особенно хорошо это работает на одиночных VDS, где хочется быстро получить максимум видимости без настройки десятков exporters.

Ограничение Netdata — долгосрочная аналитика и сложные алертовые политики. Да, у него есть алерты, streaming и интеграции, но если нужно строить SLO, burn rate, сложные запросы по labels, единые dashboards на десятки сервисов и хранить историю за месяцы, Prometheus/VictoriaMetrics с Grafana обычно удобнее. Netdata лучше не противопоставлять им напрямую, а использовать там, где важна интерактивность и автообнаружение.

Когда Netdata — лучший старт

• Есть один или несколько VDS, и нужно быстро понять нагрузку без долгой настройки.
• Вы хотите живую диагностику Linux, systemd, контейнеров, диска и сети.
• Нужен простой интерфейс для дежурного администратора или владельца проекта.
• Долгая история метрик пока не критична.
• Netdata планируется как дополнение к Prometheus или VictoriaMetrics.

Для небольшого проекта Netdata может быть первым мониторингом, который реально начнут смотреть. Это важный фактор: идеальная архитектура бесполезна, если ее никто не открывает. Но когда появятся требования к отчетам, ретроспективе и сложным алертам, стоит добавить Prometheus или VictoriaMetrics.

Сравнение по ресурсам на VDS

Точные цифры зависят от scrape interval, количества targets, exporters, labels, retention и железа, поэтому честнее говорить о типичных тенденциях. Netdata агент обычно заметен, но оправдан своей детализацией и автообнаружением. Prometheus на малом наборе targets достаточно легкий, но при росте cardinality и retention начинает активно потреблять память и диск. VictoriaMetrics часто выигрывает по хранению и ingestion, особенно когда метрик становится много.

Для VDS с 1 vCPU и 1–2 ГБ RAM я бы был осторожен с центральным Prometheus, Grafana и базой данных на том же сервере, где работает production-сайт. Мониторинг должен помогать, а не конкурировать с приложением. На таком тарифе разумнее поставить легкий агент на рабочий сервер, а центральное хранилище вынести на отдельный VDS. Если сервер один и нагрузки мало, Netdata или минимальный Prometheus с коротким retention допустимы, но следите за диском.

Для VDS с 2–4 vCPU и 4–8 ГБ RAM уже можно комфортно разместить Grafana, Prometheus или VictoriaMetrics, Alertmanager или vmalert, плюс несколько exporters. Но даже здесь важно ограничивать retention и не собирать высокочастотные метрики без необходимости. Интервал 15 секунд удобен для инфраструктуры, но для части сервисов 30–60 секунд вполне достаточно.

Для мониторингового VDS под несколько десятков targets VictoriaMetrics single-node часто дает лучший запас по диску. Prometheus при этом можно оставить как совместимый сборщик и вычислитель правил, если команда привыкла к нему. Netdata в такой схеме можно развернуть на ключевых узлах как инструмент быстрой диагностики.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Grafana: общий слой визуализации

Grafana остается удобным универсальным интерфейсом для Prometheus и VictoriaMetrics. В обоих случаях вы получаете dashboards, переменные, аннотации, alert rules и единый способ смотреть инфраструктуру. Для Netdata Grafana не является обязательной: у него сильный встроенный UI. Но если вы строите единый observability-портал, часть метрик Netdata можно отдавать в Prometheus-совместимый контур или использовать Netdata рядом с Grafana как отдельную консоль.

Главное правило для Grafana на VDS — не превращать dashboards в генератор тяжелых запросов. Красивый экран с сотней панелей может создавать большую нагрузку на TSDB, особенно если открывать его с широким диапазоном времени. Лучше иметь несколько практичных dashboards: обзор всех VDS, подробности по Linux-хосту, веб-сервер, база данных, контейнеры, алерты и capacity planning.

Хороший dashboard для VDS отвечает на конкретные вопросы: есть ли CPU steal, не растет ли memory pressure, почему увеличился latency, хватает ли disk I/O, где заканчивается место, какой сервис перезапускается, сколько 5xx отдает Nginx или приложение. Если панель не помогает принять решение, ее лучше удалить или спрятать.

Алерты: где чаще ошибаются

Многие ставят мониторинг ради графиков, но реальная ценность начинается с алертов. При этом плохие алерты хуже их отсутствия: если система шумит каждую ночь, ее быстро начинают игнорировать. В Prometheus классическая схема — Alertmanager. В VictoriaMetrics — vmalert плюс совместимая доставка уведомлений. В Netdata — встроенные health checks и уведомления.

Для VDS я бы начинал с небольшого набора: диск заполнен более чем на 85–90%, inode заканчиваются, memory pressure высокий длительное время, swap активно используется, сервис недоступен, systemd unit в failed, база не отвечает, веб-сервер отдает много 5xx, TLS-сертификат скоро истечет, backup давно не проходил. Если важен внешний контроль HTTP, TCP или ICMP, посмотрите отдельный разбор про blackbox-мониторинг в Prometheus. Для уведомлений полезно заранее продумать маршрутизацию, silence и шаблоны — об этом есть практичная инструкция по Alertmanager.

CPU сам по себе не всегда авария: 90% CPU во время плановой задачи может быть нормой, а вот высокий iowait или steal time часто важнее. Отдельно контролируйте срок действия TLS: если на проекте используются платные SSL-сертификаты или автоматическое продление, алерт должен сработать раньше, чем браузеры начнут пугать пользователей.

У Prometheus и VictoriaMetrics сильнее выразительность правил: можно считать rate, percentile, error budget, burn rate, агрегировать по labels. У Netdata проще путь до первых рабочих уведомлений. Поэтому выбор зависит от зрелости процесса. Если алерты нужны «сегодня вечером» и сервер один — Netdata выглядит привлекательно. Если нужны SLO и аккуратная маршрутизация по сервисам — Prometheus/VictoriaMetrics будут надежнее.

Практические сценарии выбора

Один VDS с сайтом или приложением

Если у вас один VDS, а главная задача — быстро видеть состояние Linux и сервисов, начните с Netdata. Он даст много пользы за минимальное время. Если уже есть опыт с Prometheus, можно поставить Prometheus плюс node exporter и короткий retention, но не забывайте про расход диска. VictoriaMetrics в одиночном сценарии тоже уместна, если вы хотите хранить историю дольше или сразу строите стек с Grafana.

Несколько VDS без Kubernetes

Для 3–20 серверов хороша схема: exporters на каждом VDS, центральная VictoriaMetrics или Prometheus, Grafana для dashboards, отдельный компонент для алертов. Если важна простота и стандартность — Prometheus. Если важна экономия хранения и длинная история — VictoriaMetrics. Netdata можно поставить на проблемные или критичные узлы как live-диагностику.

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

Когда появляются десятки сервисов, контейнеры, очереди, базы, фоновая обработка и бизнес-метрики, Prometheus как стандарт сбора и VictoriaMetrics как хранилище хорошо дополняют друг друга. Важно заранее нормализовать labels: job, instance, env, service, role. Не добавляйте в labels высококардинальные значения вроде ID пользователя, полного URL с query string или уникального имени задания.

Нужен мониторинг для клиента или небольшой команды

Если мониторингом будут пользоваться не только админы, интерфейс имеет значение. Netdata проще показать владельцу проекта: «вот CPU, вот диск, вот процесс». Grafana мощнее, но требует аккуратной подготовки dashboards. Prometheus UI полезен инженеру, но не является удобной витриной для бизнеса. VictoriaMetrics UI тоже скорее технический; для повседневной работы почти всегда нужна Grafana.

Типовые архитектуры на 2026 год

Первый вариант — минимальный: Netdata на каждом VDS. Подходит для одиночных серверов, pet-проектов, небольших сайтов и быстрой диагностики. Плюсы: скорость запуска, автообнаружение, подробные live-графики. Минусы: не лучший вариант для долгой истории, сложных SLO и централизованной аналитики.

Второй вариант — классический: Prometheus, node exporter, сервисные exporters, Grafana, Alertmanager. Подходит для команды, которая хочет стандартный стек self-hosted monitoring и готова следить за качеством метрик. Плюсы: огромная экосистема, PromQL, готовые dashboards и rules. Минусы: требования к дисциплине cardinality и ограниченная удобность long-term storage на одном VDS.

Третий вариант — экономный центральный: vmagent или Prometheus собирает метрики, VictoriaMetrics хранит, Grafana показывает, vmalert или Alertmanager уведомляет. Подходит для нескольких VDS и истории за месяцы. Плюсы: эффективное хранение, хорошая производительность, простота single-node. Минусы: чуть больше архитектурных решений на старте и необходимость проверить совместимость сложных запросов.

Четвертый вариант — гибридный: VictoriaMetrics для истории, Prometheus для привычных rules или локального сбора, Netdata для live troubleshooting на важных узлах. Это не самый минималистичный путь, но для production-проектов на нескольких VDS он часто оказывается удобным: каждый инструмент делает то, в чем силен.

Итоговая рекомендация

Если выбирать один инструмент для старта на VDS в 2026 году, ответ зависит от вашей боли. Хотите быстро понять, почему сервер тормозит, и не тратить вечер на настройку exporters — берите Netdata. Хотите стандартную observability-базу, совместимую почти со всем, с сильными алертами и Grafana dashboards — берите Prometheus. Хотите хранить много метрик экономно, централизовать несколько VDS и не упереться в диск через месяц — смотрите в сторону VictoriaMetrics.

Мой практический выбор для небольшого production без Kubernetes: VictoriaMetrics single-node как центральное хранилище, node exporter и сервисные exporters на VDS, Grafana для dashboards, аккуратные алерты через vmalert или Alertmanager. Если команда уже живет в Prometheus, я бы не ломал стек, а добавил VictoriaMetrics через remote_write для долгой истории. Netdata оставил бы как инструмент быстрой диагностики на самых важных серверах.

Главное — не начинать с максимальной сложности. Хороший мониторинг VDS должен отвечать на простые вопросы раньше, чем пользователи напишут в поддержку: заканчивается ли диск, хватает ли памяти, не вырос ли iowait, не падает ли база, не деградирует ли latency, не сломались ли backup и сертификаты. Prometheus, VictoriaMetrics и Netdata могут помочь с этим, но лучший стек — тот, который вы реально поддерживаете, регулярно смотрите и улучшаете после каждого инцидента.