Самостоятельно размещаемые альтернативы PRTG и SolarWinds для мониторинга Windows-сети

PRTG берёт плату за сенсор — одну отслеживаемую метрику на одном устройстве, а не за само устройство. Собственные тарифы Paessler задают рабочее соотношение примерно десять к одному: 500 сенсоров покрывают около 50 устройств, 10 000 — около 1 000. Добавьте стек коммутаторов и начните следить за пропускной способностью по портам — счётчик растёт быстрее, чем парк. SolarWinds считает иначе и приходит к тому же.

Для сети с преобладанием Windows я бы включил в шорт-лист две самостоятельно размещаемые альтернативы PRTG и SolarWinds: Zabbix или стек на базе Prometheus, если ваша команда уже его эксплуатирует. Выбор между ними зависит от того, что каждый из них видит на Windows-хосте и что ему для этого нужно.

Одна оговорка прежде всего. Если ни у кого в команде нет свободных часов, PRTG и SolarWinds остаются правильным ответом. Их простота использования — это продукт, который вы покупаете осознанно, и он стоит своих денег. Описанный здесь переход тратит часы вместо лицензионных платежей, и это обмен, а не апгрейд.

Кратко (TL;DR)

• Вариант по умолчанию — Zabbix. Zabbix объединяет опрос по SNMP, агенты для Windows, шаблоны и оповещения в одной платформе мониторинга. Сервер Zabbix, базу данных и веб-интерфейс по-прежнему обслуживаете вы, но вам не нужно собирать отдельные компоненты мониторинга только для того, чтобы начать.
• Исключение — команда, которая уже использует Grafana и Prometheus для метрик приложений и хостов. Расширить то, что вы уже поддерживаете, дешевле, чем поднимать вторую систему мониторинга.
• Prometheus сам по себе не опрашивает сетевые устройства. snmp_exporter закрывает этот пробел; его конфигурация по умолчанию охватывает многие распространённые коммутаторы и маршрутизаторы, а для объектов конкретных вендоров или нестандартного опроса могут потребоваться генератор и дополнительная работа с MIB.
• Безагентный сбор видит только то, что хост или устройство решает публиковать. В Zabbix журналы событий Windows, состояние служб и детальные счётчики производительности — это ключи элементов данных агента.
• Подбирайте сервер по метрикам, а не по устройствам. Zabbix считает одну метрику как один элемент данных плюс один триггер плюс один график и размещает примерно 1 000 метрик на 2 ядрах CPU и 8 ГиБ памяти, примерно 10 000 — на 4 ядрах и 16 ГиБ.

За что берут деньги PRTG и SolarWinds

Paessler publishes its PRTG tiers publicly, priced by sensor count and billed annually, starting from a few hundred dollars a month as of September 2026. Check the current figures yourself before budgeting. There is no perpetual-licence option in the current lineup. The freeware edition stops at 100 sensors, which Paessler describes as roughly 10 devices.

SolarWinds считает другую единицу, и это правило легко упустить, пока не придёт счёт на продление. Модель лицензирования NPM от SolarWinds гласит, что NPM «лицензируется по наибольшему числу среди следующих типов отслеживаемых сетевых элементов: узлы, интерфейсы, тома». Не по сумме. По наибольшему из трёх. Сеть с 80 узлами и 900 отслеживаемыми портами коммутаторов лицензируется по 900, а не по 80, а тарифы идут от SL100 до SLX. Один опрашивающий движок ограничен 12 000 элементов (сумма узлов, интерфейсов и томов, а не наибольшее из них) независимо от тарифа, после чего вы добавляете ещё один лицензированный опрашивающий движок.

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

Два самостоятельно размещаемых пути, которые стоит рассматривать

Zabbix — это единая платформа мониторинга, построенная вокруг центрального сервера, базы данных и веб-интерфейса. Сервер опрашивает устройства по SNMP, получает данные от агентов Windows и применяет шаблоны, триггеры и оповещения внутри одного продукта. По сравнению со сборкой стека сетевого мониторинга на базе Prometheus отдельных компонентов, которые нужно интегрировать самому, меньше. Вы устанавливаете его, указываете хосты и подключаете шаблоны — переиспользуемые наборы элементов данных, триггеров и графиков для одного класса устройств.

Начните с лицензии. Страница лицензии Zabbix сообщает, что каждая версия начиная с 7.0 выпускается под GNU Affero General Public License версии 3, а всё до 6.4 было под GPLv2. Лицензионной платы за программное обеспечение нет ни в каком масштабе. Zabbix продаёт техническую поддержку как отдельную необязательную подписку и просит коммерческих пользователей купить какой-то её уровень, но ничто в продукте не заперто за этой покупкой.

Второй путь — Grafana, Prometheus и VictoriaMetrics. Это правильный выбор ровно в одной ситуации: вы уже используете этот стек для метрик приложений и хостов, и кто-то уже его поддерживает. Если это про вас, полная сборка на одном VPS — это решённая задача, и вы расширяете что-то знакомое. Никому не нужно изучать новую модель данных.

ЧИТАТЬ

Настройка стека мониторинга Grafana + Prometheus на вашем VPS (руководство по Docker Compose)

Пробел на этом пути — сетевые устройства. Prometheus собирает данные с HTTP-эндпоинтов; напрямую по SNMP он не работает. Сетевое оборудование обычно обслуживается через snmp_exporter, который опрашивает устройство и отдаёт результаты для сбора Prometheus. Его конфигурация по умолчанию включает такие модули, как if_mib, поэтому стандартный мониторинг интерфейсов на многих коммутаторах и маршрутизаторах не требует генерации собственной конфигурации. Генератор становится дополнительной работой, когда вам нужны объекты конкретного вендора, нестандартные обходы или MIB, не включённые по умолчанию. Таким образом, у пути с Prometheus больше частей для сопровождения, чем у Zabbix, но генератор обязателен не для каждого устройства.

LibreNMS — третье имя в этой области, построенное вокруг автоматического обнаружения: он обходит сеть по SNMP, CDP, LLDP, OSPF, BGP и ARP, чтобы найти всё, что в ней есть. Это разумный вариант, когда обнаружение в приоритете. Но он не меняет вопрос сбора данных с Windows, а именно там и решается этот выбор.

Как каждый путь видит Windows-хост

Мониторинг Windows может идти через SNMP, удалённый WMI или установленный агент. Какой путь применяется, зависит от продукта мониторинга и собираемой метрики. Конкретно в Zabbix встроенные проверки WMI выполняются через агент для Windows.

SNMP

SNMP-запрос просит у устройства текущее значение пронумерованного объекта, адресуемого через OID — позицию в MIB устройства. В ответ приходит то, что устройство публикует, и ничего больше. Для управляемого коммутатора, межсетевого экрана или ИБП этого обычно достаточно: счётчики интерфейсов, состояние портов, доля ошибок, температура, состояние шасси.

В Windows картина беднее. Уведомление Microsoft об устаревании SNMP и WMI SNMP Provider подтверждает, что обе функции устарели, поэтому я бы рассматривал SNMP в Windows как унаследованный путь совместимости, а не как вариант по умолчанию для нового развёртывания. Zabbix по-прежнему поставляет шаблон Windows by SNMP, но нативный агент даёт значительно больше видимости операционной системы.

WMI

WMI можно опрашивать удалённо без установки агента мониторинга на целевую машину, поэтому такие продукты, как PRTG, могут использовать его как безагентный способ сбора данных с Windows. Zabbix работает иначе. Его встроенные проверки WMI, wmi.get и wmi.getall, — это ключи элементов данных агента для Windows, поэтому эти запросы на отслеживаемой машине выполняет агент Zabbix или агент 2.

Удалённый WMI также предъявляет свои сетевые требования, когда продукт мониторинга использует его напрямую. В современных системах Windows RPC начинается с TCP-порта 135 и обычно согласует соединения через динамический диапазон верхних TCP-портов, как правило от 49152 до 65535. Межсетевой экран и права WMI на целевой машине должны разрешать соединение.

Для этого сравнения различие важнее самого протокола: PRTG может использовать удалённый WMI без установленного агента мониторинга, тогда как Zabbix получает свою специфичную для Windows видимость WMI через агент.

Нативный агент

Именно в агенте живёт вся специфичная для Windows глубина. Документация Zabbix перечисляет ключи, специфичные для Windows: eventlog для мониторинга журнала событий Windows, perf_counter для любого счётчика производительности Windows, service.discovery и service.info для состояния служб. Все они — ключи элементов данных агента.

Цена — развёртывание. Агент на каждом Windows Server и каждой важной вам рабочей станции — это пакет, который нужно раскатать, версия, которую нужно поддерживать актуальной, и правило межсетевого экрана, которое нужно сопровождать. Это постоянное эксплуатационное обязательство, и оно уравновешивает экономию на лицензии.

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

Бок о бок

Сравнение сводится к четырём вещам: опрашивает ли инструмент сетевые устройства по SNMP вообще, есть ли у него агент для Windows, насколько глубоко он видит Windows-хост и сколько сборки отделяет вас от работающей системы. Лицензирование стоит рядом, потому что именно из-за него началась эта оценка.

Если требование звучит как «сообщи мне в течение минуты, когда служба перестанет отвечать», монитор доступности — инструмент подходящего размера, а два других для этого избыточны. Чего он не сделает — не опросит коммутатор о пропускной способности интерфейса и не прочитает счётчик производительности Windows, так что он не заменяет PRTG или SolarWinds. Это другая задача, которую иногда принимают за ту же самую.

ЧИТАТЬ

Как настроить Uptime Kuma на VPS

Что выбрать

Выбирайте Zabbix. Для сети с преобладанием Windows без существующих вложений в Prometheus это с большим отрывом более короткий путь. У вас по-прежнему есть сервер, база данных и веб-интерфейс, которые нужно обслуживать, но модель мониторинга, шаблоны и оповещения живут в одном продукте, а не собираются из нескольких компонентов мониторинга.

Для долгоживущего развёртывания мониторинга используйте текущую LTS-ветку Zabbix, а не краткосрочный стандартный релиз. Жизненный цикл LTS Zabbix даёт каждому релизу три года полной поддержки и затем два года ограниченной, что здесь важнее погони за самым новым релизом с функциями.

Исключение узкое и конкретное. Если ваша команда уже использует Grafana и Prometheus в продакшене для метрик приложений и хостов и у этого стека уже есть владелец, тогда snmp_exporter — это дополнение к чему-то поддерживаемому, а не вторая система, которую нужно поддерживать. Это условие составное: должны выполняться обе половины. Заброшенный экземпляр Grafana, который кто-то поднял в прошлом году, не считается.

А если часов ни у кого нет — продлевайте. Это не увиливание. Это другая ситуация с другим правильным ответом. Переход превращает счёт за лицензию в эксплуатационный: раскатка агентов, работа с шаблонами, обновления и человек, который понимает систему достаточно, чтобы починить её в 2 часа ночи. Команда, уже работающая на пределе, сделает эту работу плохо или не сделает вовсе, а необслуживаемый мониторинг хуже дорогого, потому что отказывает молча.

Гибрид реален: оставьте текущий продукт на сужающемся ядре критичных систем, переведите всё остальное на Zabbix и дайте лицензионному тарифу со временем снизиться. Это работает. Но это также означает две системы мониторинга и сверку их оповещений, поэтому относитесь к этому как к переходному состоянию с датой окончания.

Что не переживёт переезд

Собственное руководство Zabbix по миграции содержит раздел с заголовком «Что НЕ мигрируется», и этот список длиннее, чем подразумевает слово «миграция». Исторические данные и показания сенсоров не переносятся. Пользовательские уведомления и зависимости PRTG — тоже. Карты и дашборды — тоже, потому что два продукта моделируют их настолько по-разному, что перестроить проще, чем перевести. Сами сенсоры — тоже, поскольку Zabbix работает с совершенно другим понятием.

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

Одна команда задокументировала, во что это обходится на практике: около 500 ВМ и физических серверов, около семи лет на PRTG, перестроено с нуля за шесть месяцев проектного времени с низким приоритетом. Их 2 500 сенсоров PRTG превратились в 43 000 элементов данных Zabbix — наглядная иллюстрация того, насколько по-разному считают две системы.

«Начинайте с нуля. Кнопки „нажми и мигрируй“ с PRTG на Zabbix не существует, а если бы и существовала, такой переход — хороший повод не повторять прежние ошибки проектирования».

Отчёт о миграции от Digital Dilemma

Это опыт одной организации, а не эталон. Меньший парк таких цифр не даст. Переносится только допущение для планирования: закладывайте время на перестройку, а не на миграцию.

Выстраивайте перестройку вокруг того, без чего нельзя обойтись. Если вас волнует непрерывность оповещений, сначала пересоберите правила уведомлений, а дашборды пусть отстают. Если важна история отчётов, экспортируйте нужное до истечения старой лицензии. С собой она не уйдёт.

Подбор сервера

Аппаратные требования Zabbix относят малую установку примерно на 1 000 отслеживаемых метрик к 2 ядрам CPU и 8 ГиБ памяти, а среднюю установку примерно на 10 000 метрик — к 4 ядрам и 16 ГиБ. Именно эти цифры и стоит закладывать в заявку.

Ошибки подбора начинаются с единицы измерения. Zabbix определяет одну отслеживаемую метрику как один элемент данных плюс один триггер плюс один график. Метрика — это не устройство и не хост. Один Windows Server даёт столько метрик, сколько элементов данных вы настроите: CPU, память, каждая файловая система, каждая служба, каждый счётчик, который вы снимаете. Число устройств — плохой ориентир для нужной машины. Парк, который звучит небольшим, может оказаться в средней категории без каких-либо необычных действий.

Две вещи разгоняют число быстрее, чем количество хостов. Первая — частота опроса: сокращение интервала обновления вдвое удваивает скорость записи для каждого элемента данных с этим интервалом. Вторая — хранение истории, поскольку база данных растёт вместе со сроком хранения сырых значений. Число устройств важно в основном через количество отслеживаемых элементов данных, которые даёт каждое устройство.

Если ваш парк держится около примера с 1 000 метрик при обычных интервалах обновления и скромном хранении, малая категория — разумная отправная точка. Если вы снимаете счётчики производительности каждые тридцать секунд и храните год сырой истории — нет. Zabbix прямо говорит, что опубликованные цифры — это «примеры размера и конфигурации оборудования для начала», и рекомендует провести тестирование в тестовой среде, прежде чем закладывать продакшен-оборудование. Это оговорка самого вендора. Понимайте её буквально.

Zabbix поддерживает свой серверный компонент только на Linux и UNIX; в Windows поддерживается только агент.

Метрики — это не устройства, и именно множитель между ними определяет размер машины.

Где разместить сервер мониторинга

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

В частной сети прокси Zabbix может находиться внутри площадки и собирать данные с окружающих систем. Прокси может локально выполнять проверки SNMP и агентов, отправлять собранные данные на центральный сервер и буферизовать данные мониторинга, пока связь между ними недоступна. Это позволяет центральному серверу оставаться за пределами площадки, не требуя, чтобы каждый частный коммутатор, межсетевой экран и Windows-хост были напрямую доступны из интернета.

VPS — удобное место для такого центрального сервера. Cloudzy предлагает Сервер Zabbix как развёртывание в один клик на Ubuntu Server 24.04 LTS, если вы хотите пропустить первоначальную установку и сразу перейти к настройке хостов и шаблонов.

Часто задаваемые вопросы

Zabbix действительно бесплатный?

Да. Начиная с версии 7.0 Zabbix выпускается под GNU Affero General Public License версии 3, и лицензионной платы за программное обеспечение нет независимо от того, сколько устройств или метрик вы отслеживаете. Zabbix продаёт техническую поддержку как отдельную необязательную подписку, но ни одна функция продукта за ней не заперта. Стоимость работы Zabbix — это сервер, на котором он работает, и часы, которые вы тратите на его эксплуатацию.

Нужно ли ставить агент на каждый Windows Server?

Не на каждую Windows-машину, но если вам нужна нативная глубина мониторинга Windows в Zabbix, планируйте установку агента на самые важные для вас серверы. SNMP может дать грубые безагентные данные, хотя функция SNMP в Windows у Microsoft устарела. Встроенные проверки WMI в Zabbix тоже выполняются через агент для Windows, так что WMI в Zabbix — не прямой безагентный путь сбора. Используйте агент для журналов событий, обнаружения служб, запросов WMI и детальных счётчиков производительности; безагентный SNMP оставьте в основном для сетевого оборудования и унаследованных случаев с Windows.

Можно ли запустить сервер мониторинга на Windows?

С Zabbix — нет. Документация Zabbix по требованиям указывает, что серверный компонент поддерживается только на Linux и других платформах UNIX, и утверждает, что «UNIX — единственная операционная система, способная стабильно обеспечивать необходимую производительность, отказоустойчивость и живучесть». Поддержка Windows охватывает агент Zabbix и агент 2 — то, что вы устанавливаете на отслеживаемые машины. Сервер мониторинга находится на Linux-хосте; Windows-парк — это то, за чем он наблюдает.

Умеет ли Prometheus мониторинг по SNMP?

Сам по себе нет. Prometheus собирает данные с HTTP-эндпоинтов и использует snmp_exporter для сбора с SNMP-устройств. Его конфигурация по умолчанию охватывает многие распространённые коммутаторы и маршрутизаторы, а для объектов конкретных вендоров или нестандартного опроса могут потребоваться дополнительная настройка MIB и генератор.