Saját üzemeltetésű alternatívák a PRTG és a SolarWinds helyett Windows-hálózatok monitorozásához

A PRTG szenzoronként számláz, vagyis egy eszköz egy monitorozott metrikája után, nem maga az eszköz után. A Paessler saját csomagjai nagyjából tíz az egyhez arányt adnak: 500 szenzor körülbelül 50 eszközt fed le, 10 000 körülbelül 1000-et. Tegyél hozzá egy switch-stacket, és kezdd el figyelni a portonkénti átvitelt, és a számláló gyorsabban nő, mint az eszközpark. A SolarWinds másképp számol, és ugyanoda jut.

Egy Windows-túlsúlyos hálózathoz két saját üzemeltetésű alternatívát tennék a listára a PRTG és a SolarWinds helyett: a Zabbixot, vagy egy Prometheus-alapú stacket, ha a csapat már üzemeltet ilyet. A kettő közötti választás azon múlik, hogy melyik mit lát egy Windows-hoston, és mire van szüksége ahhoz, hogy lássa.

Egy kikötés mindenekelőtt. Ha a csapatban senkinek nincs szabad órája, a PRTG és a SolarWinds marad a helyes válasz. A könnyű kezelhetőségük olyan termék, amit tudatosan vásárolsz meg, és megéri a pénzét. Az itt leírt váltás órákat költ licencdíjak helyett, és ez csere, nem fejlesztés.

Röviden

• Az alapértelmezett választás a Zabbix. A Zabbix egyetlen monitorozó platformba foglalja az SNMP-lekérdezést, a Windows-ügynököket, a sablonokat és a riasztást. A Zabbix-szervert, az adatbázist és a webes felületet továbbra is te üzemelteted, de nem kell külön monitorozó komponenseket összerakni csak azért, hogy elindulj.
• A kivétel az a csapat, amelyik már futtat Grafanát és Prometheust alkalmazás- és hostmetrikákhoz. Bővíteni azt, amit már karbantartasz, olcsóbb, mint felállítani egy második monitorozó rendszert.
• A Prometheus önmagában nem kérdezi le a hálózati eszközöket. snmp_exporter tölti be ezt a rést; az alapértelmezett konfigurációja sok elterjedt switchet és routert lefed, míg a gyártóspecifikus objektumok vagy az egyedi lekérdezés a generátort és további MIB-munkát igényelhet.
• Az ügynök nélküli gyűjtés csak azt látja, amit a host vagy az eszköz közzétesz. A Zabbixban a Windows eseménynaplói, a szolgáltatások állapota és a részletes teljesítményszámlálók ügynök-elemkulcsok.
• A szervert metrikák szerint méretezd, ne eszközök szerint. A Zabbix egy metrikát egy elem plusz egy trigger plusz egy grafikonként számol, és nagyjából 1000 metrikát tesz 2 CPU-magra és 8 GiB memóriára, nagyjából 10 000-et 4 magra és 16 GiB-ra.

Miért kér pénzt a PRTG és a 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.

A SolarWinds más egységet számol, és a szabályt könnyű elnézni, amíg meg nem érkezik a megújítási árajánlat. A SolarWinds NPM licencmodellje kimondja, hogy az NPM „a következő monitorozott hálózati elemtípusok közül a legnagyobb darabszám szerint kerül licencelésre: csomópontok, interfészek, kötetek”. Nem az összeg. A három közül a legnagyobb. Egy 80 csomópontból és 900 monitorozott switchportból álló hálózat a 900 után licencelendő, nem a 80 után, a csomagok pedig SL100-tól SLX-ig terjednek. Egyetlen lekérdező motor csomagtól függetlenül 12 000 elemnél tetőzik (a csomópontok, interfészek és kötetek összege, nem a legnagyobb közülük), utána újabb licencelt lekérdező motort kell hozzáadni.

A két modell gyakorlati hatása ugyanaz. A licenccsomag dönti el, mi kerül monitorozásra. Nem a hálózat. Interfészek, amelyeket szívesen figyelnél, figyelés nélkül maradnak, mert a figyelésük átlépne egy határt, és ez a költség sosem jelenik meg a számlán.

A két saját üzemeltetésű út, amelyet érdemes végigjárni

A Zabbix egyetlen monitorozó platform, amely egy központi szerver, egy adatbázis és egy webes felület köré épül. A szerver lekérdezi az SNMP-eszközöket, fogadja a Windows-ügynökök adatait, és ugyanabban a termékben alkalmazza a sablonokat, triggereket és riasztásokat. Egy Prometheus-alapú hálózatmonitorozó stack összerakásához képest kevesebb különálló komponenst kell magadnak integrálnod. Telepíted, ráirányítod a hostokra, és sablonokat csatolsz hozzá, amelyek egy eszközosztályt lefedő, újrahasználható elem-, trigger- és grafikoncsomagok.

Kezdd a licenccel. A Zabbix licencoldala kimondja, hogy a 7.0-tól kezdve minden verzió a GNU Affero General Public License 3-as verziója alatt jelenik meg, és hogy a 6.4-ig minden GPLv2 volt. A szoftverért semmilyen méretben nem kell licencdíjat fizetni. A Zabbix a technikai támogatást külön, opcionális előfizetésként árulja, és kéri a kereskedelmi felhasználókat, hogy vegyék meg valamelyik szintjét, de a termékben semmi sincs e vásárlás mögé zárva.

A második út a Grafana, a Prometheus és a VictoriaMetrics. Pontosan egy helyzetben ez a helyes választás: már futtatod ezt a stacket alkalmazás- és hostmetrikákhoz, és már van, aki karbantartja. Ha ez rád illik, a teljes felépítés egyetlen VPS-en megoldott probléma, és valami ismerőset bővítesz. Senkinek sem kell új adatmodellt tanulnia.

OLVASD

Grafana + Prometheus monitorozó stack beállítása a VPS-eden (Docker Compose útmutató)

Ennek az útnak a hiányossága a hálózati eszközök. A Prometheus HTTP-végpontokat olvas be; közvetlenül nem beszél SNMP-t. A hálózati eszközöket általában a snmp_exporter kezeli, amely lekérdezi az eszközt, és közzéteszi az eredményeket, hogy a Prometheus beolvashassa. Az alapértelmezett konfigurációja olyan modulokat tartalmaz, mint az if_mib, így a szabványos interfészmonitorozás sok switchen és routeren nem igényel egyedi konfiguráció generálását. A generátor akkor válik pluszmunkává, amikor gyártóspecifikus objektumokra, egyedi bejárásokra vagy alapból nem tartalmazott MIB-ekre van szükséged. A Prometheus-útnak tehát több karbantartandó része van, mint a Zabbixnak, de a generátor nem kötelező minden eszközhöz.

A LibreNMS a harmadik név ezen a területen, az automatikus felderítésre épül: SNMP, CDP, LLDP, OSPF, BGP és ARP alapján bejárja a hálózatot, hogy megtalálja, mi van benne. Észszerű választás, ha a felderítés a prioritás. A Windows-adatgyűjtés kérdésén nem változtat, pedig ez a döntés ott dől el.

Hogyan lát egy Windows-hostot az egyes utak

A Windows monitorozása történhet SNMP-n, távoli WMI-n vagy telepített ügynökön keresztül. Hogy melyik út érvényes, az a monitorozó terméktől és a gyűjtött metrikától függ. Konkrétan a Zabbixban a beépített WMI-ellenőrzések a Windows-ügynökön keresztül futnak.

SNMP

Egy SNMP-lekérdezés egy számozott objektum aktuális értékét kéri az eszköztől, amelyet egy OID címez meg, ami egy pozíció az eszköz MIB-jében. Az jön vissza, amit az eszköz közzétesz, és semmi más. Menedzselt switchen, tűzfalon vagy szünetmentes tápon ez általában elég: interfészszámlálók, portállapot, hibaarányok, hőmérséklet, a ház állapota.

Windowson a kép soványabb. A Microsoft SNMP-re és WMI SNMP Providerre vonatkozó elavulási közleménye megerősíti, hogy mindkét funkció elavult, ezért a Windows SNMP-t örökölt kompatibilitási útnak tekinteném, nem pedig új telepítés alapértelmezésének. A Zabbix továbbra is ad Windows by SNMP sablont, de a natív ügynök lényegesen mélyebb betekintést ad az operációs rendszerbe.

WMI

A WMI távolról is lekérdezhető anélkül, hogy monitorozó ügynököt telepítenél a célgépre, ezért használhatják az olyan termékek, mint a PRTG, ügynök nélküli Windows-gyűjtési módszerként. A Zabbix másképp működik. A beépített WMI-ellenőrzései, wmi.get és wmi.getall, a Windows-ügynök elemkulcsai, így a Zabbix-ügynök vagy a 2-es ügynök hajtja végre ezeket a lekérdezéseket a monitorozott gépen.

A távoli WMI saját hálózati követelményeket is hoz, ha egy monitorozó termék közvetlenül használja. A jelenlegi Windows-rendszereken az RPC a 135-ös TCP-porton indul , és a kapcsolatokat általában a dinamikus magas TCP-porttartományon, jellemzően 49152 és 65535 között egyezteti. A célgép tűzfalának és WMI-jogosultságainak engedélyeznie kell a kapcsolatot.

Ehhez az összehasonlításhoz a különbség fontosabb magánál a protokollnál: a PRTG telepített monitorozó ügynök nélkül használhatja a távoli WMI-t, míg a Zabbix az ügynökén keresztül kapja a Windows-specifikus WMI-rálátását.

A natív ügynök

Az ügynökben lakik a Windows-specifikus mélység. A Zabbix dokumentációja felsorolja a Windows-specifikus kulcsokat: eventlog a Windows-eseménynapló monitorozásához, perf_counter bármely Windows-teljesítményszámlálóhoz, service.discovery és service.info a szolgáltatások állapotához. Mindegyik ügynök-elemkulcs.

Az ár a bevezetés. Egy ügynök minden Windows Serveren és minden fontos munkaállomáson: egy kiosztandó csomag, egy naprakészen tartandó verzió és egy karbantartandó tűzfalszabály. Ez állandó üzemeltetési kötelezettség, és ez az ellensúlya a licencmegtakarításnak.

Az ügynök nélküli gyűjtést az korlátozza, amit a host vagy az eszköz közzétesz, és a Zabbixban az eseménynaplók és a részletes teljesítményszámlálók ügynök-elemkulcsok mögött ülnek.

Egymás mellett

Az összehasonlítás négy dolgon múlik: lekérdezi-e az eszköz egyáltalán a hálózati eszközöket SNMP-n, van-e Windows-ügynöke, milyen mélyen lát bele egy Windows-hostba, és mennyi összeszerelés áll közted és egy működő rendszer között. A licencelés ezek mellett áll, mert ez volt az oka, hogy az értékelés elkezdődött.

Ha a követelmény az, hogy „egy percen belül szólj, ha egy szolgáltatás nem válaszol”, akkor a rendelkezésre állási figyelő a megfelelő méretű eszköz, a másik kettő pedig túlméretezett hozzá. Amit nem tud: switchet lekérdezni interfész-átvitelért vagy Windows-teljesítményszámlálót olvasni, így nem helyettesíti a PRTG-t vagy a SolarWindst. Ez más feladat, amit néha ugyanannak néznek.

OLVASD

Az Uptime Kuma beállítása egy VPS-en

Melyiket futtasd

Futtasd a Zabbixot. Egy Windows-túlsúlyos hálózathoz, meglévő Prometheus-befektetés nélkül, messze ez a rövidebb út. Továbbra is van egy szerver, egy adatbázis és egy webes felület, amit üzemeltetni kell, de a monitorozási modell, a sablonok és a riasztás egyetlen termékben él, ahelyett hogy több monitorozó komponensből kellene összerakni.

Hosszú életű monitorozó telepítéshez a Zabbix aktuális LTS-ágát használd, ne egy rövid életű standard kiadást. A Zabbix LTS-életciklusa minden kiadásnak három év teljes támogatást ad, amit két év korlátozott támogatás követ, és ez itt többet számít, mint a legújabb funkciókiadás hajszolása.

A kivétel szűk és konkrét. Ha a csapatod már élesben futtatja a Grafanát és a Prometheust alkalmazás- és hostmetrikákhoz, és már van gazdája annak a stacknek, akkor az snmp_exporter egy karbantartott dolog kiegészítése, nem egy második karbantartandó rendszer. Ez a feltétel együttes: mindkét félnek teljesülnie kell. Egy elhagyott Grafana-példány, amit valaki tavaly állított fel, nem számít.

És ha senkinek sincs rá órája, újíts meg. Ez nem kibúvó. Ez más helyzet, más helyes válasszal. A váltás a licencszámlát üzemeltetési számlává alakítja: ügynökkiosztások, sablonmunka, frissítések, és valaki, aki elég jól érti a rendszert ahhoz, hogy hajnali 2-kor megjavítsa. Egy már kapacitáshatáron lévő csapat ezt a munkát rosszul vagy sehogy sem végzi el, és a karbantartatlan monitorozás rosszabb a drága monitorozásnál, mert csendben hibásodik meg.

A hibrid létezik: tartsd meg a jelenlegi terméket a kritikus rendszerek egyre szűkülő magján, költöztess mindent mást a Zabbixra, és hagyd, hogy a licenccsomag idővel csökkenjen. Működik. Azt is jelenti viszont, hogy két monitorozó rendszert futtatsz, és egyeztetned kell a riasztásaikat, ezért kezeld átmeneti állapotként, záró dátummal.

Mi nem éli túl a költözést

A Zabbix saját migrációs útmutatója tartalmaz egy „Mi NEM kerül migrálásra” című részt, és a lista hosszabb, mint amit a „migráció” szó sejtet. A historikus adatok és a szenzorértékek nem jönnek át. Az egyedi PRTG-értesítések és függőségek sem. A térképek és irányítópultok sem, mert a két termék annyira eltérően modellezi őket, hogy az újraépítés jobb a fordításnál. Maguk a szenzorok sem, mivel a Zabbix teljesen más fogalommal dolgozik.

Az eszköznevek, IP-címek és interfésztípusok átvihetők. Még ez is egyedi export- és importszkripteken keresztül megy, mindkét API ellen. Az útmutató világosan kimondja, hogy nincs hivatalos eszköz a két platform közötti közvetlen migrációhoz.

Egy csapat dokumentálta, mibe kerül ez a gyakorlatban: nagyjából 500 virtuális gép és fizikai szerver, körülbelül hét év PRTG-n, a nulláról újraépítve hat hónapnyi alacsony prioritású projektidő alatt. A 2500 PRTG-szenzorukból 43 000 Zabbix-elem lett, ami jól mutatja, mennyire másképp számol a két rendszer.

„Kezdd a nulláról. Nincs »nyomd meg ezt a gombot és migrálj« lehetőség PRTG-ről Zabbixra, és ha lenne is, egy ilyen váltás jó alkalom arra, hogy ne ismételd meg a korábbi tervezési hibákat.”

A Digital Dilemma migrációs beszámolója

Ez egyetlen szervezet tapasztalata, nem viszonyítási alap. Egy kisebb eszközpark nem hoz ilyen számokat. Ami átvihető, az a tervezési feltevés: újraépítési időt tervezz be, ne migrációs időt.

Az újraépítést aszerint sorold, mi nélkül nem lehetsz meg. Ha a riasztás folytonossága aggaszt, először az értesítési szabályokat építsd újra, az irányítópultok jöhetnek később. Ha a jelentések előzményei, exportáld, amire szükséged van, mielőtt a régi licenc lejár. Nem jön veled.

A szerver méretezése

A Zabbix hardverkövetelményei egy körülbelül 1000 monitorozott metrikás kis telepítést 2 CPU-magra és 8 GiB memóriára tesznek, egy körülbelül 10 000 metrikás közepes telepítést pedig 4 magra és 16 GiB-ra. Ezek azok a számok, amelyek alapján igényelni kell.

Az egység az, ahol a méretezés félremegy. A Zabbix egy monitorozott metrikát egy elem plusz egy trigger plusz egy grafikonként definiál. A metrika nem eszköz és nem host. Egyetlen Windows Server annyi metrikát ad, ahány elemet beállítasz hozzá: CPU, memória, minden fájlrendszer, minden szolgáltatás, minden számláló, amit mintavételezel. Az eszközszám rossz iránymutató a szükséges géphez. Egy kicsinek hangzó eszközpark a közepes sávba kerülhet anélkül, hogy bárki bármi szokatlant tenne.

Két dolog növeli a számot gyorsabban, mint a hostok száma. Az első a lekérdezési gyakoriság: egy frissítési intervallum felezése megduplázza az írási sebességet az adott intervallumon lévő minden elemnél. A második az előzmények megőrzése, mivel az adatbázis annál nagyobb, minél tovább tartod meg a nyers értékeket. Az eszközszám főleg azon keresztül számít, hogy hány monitorozott elemet ad az egyes eszközök.

Ha az eszközparkod az 1000 metrikás példa közelében marad, szokásos frissítési intervallumokkal és szerény megőrzéssel, a kis sáv észszerű kiindulópont. Ha harminc másodpercenként mintavételezel teljesítményszámlálókat, és egy évnyi nyers előzményt tartasz meg, akkor nem az. A Zabbix kifejezetten kimondja, hogy a közzétett számok „kiindulási méret- és hardverkonfigurációs példák”, és azt javasolja, hogy staging környezetben mérd a teljesítményt, mielőtt éles hardver mellett döntesz. Ez maga a gyártó fenntartása. Vedd szó szerint.

A Zabbix a szerverkomponensét csak Linuxon és UNIX-on támogatja; Windowson csak az ügynök támogatott.

A metrikák nem eszközök, és a kettő közötti szorzó határozza meg a gép méretét.

Hová kerüljön a monitorozó szerver

Ha a monitorozásnak túl kell élnie egy teljes telephelyi kiesést, tartsd a központi Zabbix-szervert a telephely hibatartományán kívül. A telephely feltöltő kapcsolatának elvesztése így lekapcsolhatja a monitorozott hálózatot anélkül, hogy a monitorozó szervert is magával rántaná.

Privát hálózatban egy Zabbix-proxy ülhet a telephelyen belül, és gyűjthet a körülötte lévő rendszerekről. A proxy helyben kezeli az SNMP- és ügynökellenőrzéseket, visszaküldi a gyűjtött adatokat a központi szervernek, és puffereli a monitorozási adatokat, amíg a kettő közötti kapcsolat nem elérhető. Így a központi szerver a telephelyen kívül maradhat anélkül, hogy minden privát switchnek, tűzfalnak és Windows-hostnak közvetlenül elérhetőnek kellene lennie az internetről.

Egy VPS praktikus hely ennek a központi szervernek. A Cloudzy a Zabbix kiszolgáló egykattintásos telepítését kínálja Ubuntu Server 24.04 LTS-en, ha ki akarod hagyni az első telepítést, és rögtön a hostok és sablonok beállításával kezdenél.

Gyakran ismételt kérdések

Tényleg ingyenes a Zabbix?

Igen. A Zabbix a 7.0-s verziótól a GNU Affero General Public License 3-as verziója alatt jelenik meg, és a szoftverért nincs licencdíj, akárhány eszközt vagy metrikát monitorozol. A Zabbix a technikai támogatást külön, opcionális előfizetésként árulja, de a termék egyetlen funkciója sincs mögé zárva. A Zabbix futtatásának költsége a szerver, amin fut, és az órák, amiket az üzemeltetésére fordítasz.

Minden Windows Serverre telepítenem kell ügynököt?

Nem minden Windows-gépre, de ha a Zabbix natív Windows-monitorozási mélységét akarod, tervezz ügynöktelepítést a számodra legfontosabb szerverekre. Az SNMP adhat durva, ügynök nélküli adatokat, bár a Microsoft Windows SNMP-funkciója elavult. A Zabbix beépített WMI-ellenőrzései szintén a Windows-ügynökön futnak, így a WMI a Zabbixban nem közvetlen, ügynök nélküli gyűjtési út. Az ügynököt használd eseménynaplókhoz, szolgáltatásfelderítéshez, WMI-lekérdezésekhez és részletes teljesítményszámlálókhoz; az ügynök nélküli SNMP-t főleg hálózati hardverre és örökölt Windows-esetekre tartsd meg.

Futtathatom a monitorozó szervert Windowson?

Zabbixszal nem. A Zabbix követelmény-dokumentációja a szerverkomponenst csak Linuxon és más UNIX-platformokon támogatottként sorolja fel, és kimondja, hogy „a UNIX az egyetlen operációs rendszer, amely következetesen képes biztosítani a szükséges teljesítményt, hibatűrést és ellenálló képességet”. A Windows-támogatás a Zabbix-ügynökre és a 2-es ügynökre terjed ki, vagyis arra, amit a monitorozott gépekre telepítesz. A monitorozó szerver Linux-hoston ül; a Windows-eszközpark az, amit figyel.

Tud a Prometheus SNMP-monitorozást?

Önmagában nem. A Prometheus HTTP-végpontokat olvas be, és az snmp_exporter segítségével gyűjt az SNMP-eszközökről. Az alapértelmezett konfigurációja sok elterjedt switchet és routert lefed, míg a gyártóspecifikus objektumok vagy az egyedi lekérdezés további MIB-konfigurációt és a generátort igényelhet.