Самостійно розміщувані альтернативи 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 і генератор.