0. Bevezetés
Nem találtam egyetlen cikket sem a NetXMS-ről a Habr-on, pedig nagyon kerestem. Csak emiatt döntöttem el, hogy megírom ezt a művet, hogy figyelmet szenteljek ennek a rendszernek.
Ez egy tutorial, egy how to, és egy felületes áttekintése a rendszer lehetőségeinek.
Ez a cikk egy felületes elemzést és a rendszer lehetőségeinek leírását tartalmazza. Nem mélyedtem el a lehetőségekben számos okból. Ráadásul az összes funkció leírása egy cikkben is messze túlterhelt lenne.
Mivel én elsősorban csak a Zabbix-szal dolgoztam — a cikkben gyakran említeni fogom ezt a rendszert a téma összehasonlítására. Valahogy úgy alakult, hogy mindent valami elismert dologgal hasonlítanak össze.
1. Miért és mire?
A megfigyelő rendszer, ahogy a definícióból látható, — egy rendszer, amely lehetővé teszi, hogy bármikor aktuális információt kapjunk egy adott csomópont állapotáról a hálózati gépeken/ routereken.
Miért van erre szükség — ez is nyilvánvaló. Hogy naprakészen tudjunk a történésekről.
Gyakran a megfigyelő rendszer rendkívül részletes információt adhat az infrastruktúra állapotáról, valamint annak egyes részeiről. Ráadásul, ha beállítunk értesítéseket (mert nélküle semmire sem megyünk), akkor végül egy komoly eszközt kapunk, amely lehetővé teszi nemcsak a már bekövetkezett vészhelyzetek időben történő kezelését, hanem a legtöbb esetben lehetőséget nyújt ezen vészhelyzetek megelőzésére is.
2. Miért a NetXMS?
Egy kis off-topic azoknak, akik szeretik a hosszú szövegeketFiatal és tapasztalatlan koromban… Így kezdődnek a mesék, igaz?.. Szóval, amikor maximalista voltam, a monitorozási infrastruktúrával foglalkoztam, és azoknak a "kutatásoknak" az eredménye az volt, hogy a Zabbixnál jobb nincs. Akkoriban valóban tetszett, mert sok mindent tud, sokat képes megvalósítani, és a funkcionalitását lehet bővíteni saját írású szkriptekkel, így mondhatni, hogy szinte mindent tud, ha a kéz a megfelelő helyről nő. De a Zabbix egy eléggé bonyolult eszköz. Ahhoz, hogy valamennyire megértsem, majdnem két hét ment el. És ez csak a bevezetési szakasz. Aztán újabb pár hét kellett a szükséges monitoring beállításához. A routersportok állapotának figyelésére vonatkozóan sokáig olvastam, megijedtem, és úgy döntöttem, hogy ez talán nem is annyira szükséges… Nos, ez tényleg félelmetes a tapasztalatlan elméknek közvetlenül az egyetem után…
És így évekkel később, felnőve és megérve, úgy döntöttem, hogy itt az ideje felfrissíteni a tudásomat a monitorozó rendszerekről. Végre stabil, normális hálózati monitorozást akartam készíteni, mivel ez a probléma aktuálissá vált a szegmensek növekedésével, fiókok csatlakoztatásával és egyéb apróságokkal. Minden változik. Így elkezdtem mindenféle eszközt tesztelni. Egyszer ezt a rendszert Telepítem, megpróbálom, egyszer azt. És mindenhol hiányzik valami, mindenhol valami zavar. Vannak, ahol a felület kényelmetlen, másutt beállítani nehézkes, vagy valami más. Aztán rátaláltam a NetXMS-re. Ahol a Zabbixnál két hétig próbálkoztam, ott a NetXMS-szel minden ment, mint a karikacsapás pár órán belül. Lehet, hogy a Zabbixnál szerzett tapasztalat tehette, vagy talán magában a NetXMS-ben van a titok… nehéz megmondani.
A NetXMS viszonylag egyszerűen telepíthető és beállítható rendszer. Van Windowsra és Linuxra is szerver- és adminisztrációs konzol verziója, grafikonok létrehozása, beépített "böngésző", amely lehetővé teszi, hogy az adminisztrációs konzolból közvetlenül csatlakozzak ugyanazon routerekhez httphttps protokollokon keresztül, és az interface intuitív módon érthető, valamint minden operációs rendszerhez van ügynöke. Szóval ez a rendszer első ránézésre egyszerűnek és kényelmesnek tűnik.
A dokumentációjuk, hogy a szót mondjam, 8-as a 10-ből. Az alapvető dolgok benne vannak, de a részletekbe való betekintéshez kicsit bele kell ásni.
A fejlesztő által megjelölt fő előnyökMélyhálózati megfigyelés
Automatikus észlelés, vizualizálás és a 2-es és 3-as szintű csatlakoztatott komponensek keresése
Teljes SNMPv3 támogatás
Aktív észlelés „szondák” segítségével
Passzív észlelés az ellenőrzött eszközöktől származó információk — ARP és routing táblák, interfészek alapján
Alkalmazások és szerverek megfigyelése
Az összes alapvető metrika, amire számíthat: CPU, fájlrendszerek, I/O, memória, forgalom
JMX híd Java alkalmazások megfigyeléséhez
Speciális alkalmazásbővítmények: Oracle, MySQL, PostgreSQL, MongoDB, DB2, Tuxedo és még sok más
API integrációs saját alkalmazásokhoz
Nagy hálózatok számára készült
Egy szerver több száz metrikát követhet nyomon ezernyi eszközön
Teljes támogatás elosztott megfigyeléshez és vízszintes méretezéshez
Átfedő IP-alhálózatok megfigyelése
Rugalmas hozzáférés-vezérlés üzemeltetők és ügyfelek számára
3. Mélyebben belemegyünk
A rendszer telepítése — van egy teljes elérhető a , és semmi nehézség nincs benne, ezért nem állok meg ennél. A telepítés legnehezebb része a rendszer csatlakoztatása az adatbázishoz... Itt a választás csak az adatbázis-kezelő rendszeren és a szerver operációs rendszerén múlik. Én a Windows-t választottam (tovább-tovább-adja meg az adatokat-kész) és az MSSQL-t, mivel már volt.
3.1. Automatikus észlelés bekapcsolása
A hálózati csomópontok automatikus észlelését telepítéskor lehet bekapcsolni. Ha ez valamilyen okból nem történt meg, akkor mindig aktiválható a „Configuration-Network Discovery” vagy kattintással az azonos nevű ikonra. A munkaterületen megjelennek az észlelési beállítások. Ez aktiválható passzív vagy aktív módra, és más jellemzők is megadhatók, például a lekérdezett alhálózatok. Itt szűrőket is be lehet állítani, választhatóan testreszabhatók a rendszerbe beépített szűrők, valamint egyedi szkriptek is írásra kerülhetnek. Őszintén szólva, nekem a szűrők nem voltak szükségesek. De a beállítás meglehetősen barátságosan és érthetően néz ki.
Itt meg lehet adni az alapértelmezett SNMP közösséget és annak hitelesítő adatait (értsd: azazonosítást).
3.2. Csomópontok hozzáadása
A bekapcsolt automatikus észlelés esetén a végberendezések (számítógépek, nyomtatók) automatikusan hozzáadódnak és eloszlanak az alhálózatok között. Az aktív hálózati eszközökkel minden kicsit bonyolultabb.
Először is be kell kapcsolni az SNMP-t a hálózati eszközökön és beállítani a közösségi nevet. Ha a hálózati csomópontok automatikus észlelésének tulajdonságaiban nem változott meg az alapértelmezett érték az SNMP közösségi névhez, akkor a rendszer a nyilvános közösséget használja, ezt a beállítást pedig módosíthatja minden csomópontnál annak hozzáadott tulajdonságaiban.
A kényelem érdekében bármilyen kényelmes elv szerint csoportosíthatjuk az eszközöket, ehhez konténereket hozhatunk létre az Infrastructure Services ágon, és hozzáköthetjük hozzájuk az Entrie Network csomópontjait.
Az SNMP bekapcsolása és beállítása után az útválasztókon, és azok hozzáadása után a megfigyelt eszközök listájához a rendszer automatikusan kapcsolatba lép velük, lekérdezi azokat, meghatározza, hogy milyen eszközökről van szó, alkalmazza a sablonokat, megkezdi az adatok gyűjtését és megjeleníti az egyes routerekhez tartozó front panelt. Automatikusan. Kész dobozból. Amikor a Zabbixot állítottam be, ilyesmiről csak álmodozhattam.
Mivel a hálózati eszközeim nem jelentek meg valamiért, kézzel adtam hozzá az összeset. Itt minden egyszerű. Készítünk egy konténert az Infrastructure Services-ben bármilyen kényelmes névvel (például switchek), és jobb klikk — új csomópont létrehozása, megadjuk a csomópont megjelenített nevét, IP-címét, és jobb, ha bejelöljük a «NetXMS ügynök használatának letiltása» lehetőséget, mivel ezt úgysem lehet telepíteni a hálózati eszközökre, így felesleges csomagok nem kell.
Beépített böngésző. Egyszerűen jobb klikk a megfelelő routeren és nyisd meg az eszköz webes felületét. Ez számomra kényelmesebbnek tűnt, mint minden alkalommal megnézni a feljegyzéseimet és megkeresni a szükséges IP-t. Igaz, a böngésző nem a legjobb.
3.3. Hálózati térkép építése
Elsősorban a hálózati térképet kell létrehozni objektumként. Mint általában — a Networks Map ágban, jobb klikk, létrehozás, a térkép típusa, paraméterek megadása, és a rendszer továbbra is mindent automatikusan elvégez.
A térképtípusok a következők:
- Egyedi. Ez a térkép a felhasználó kívánságai szerint manuálisan készül.
- Layer 2 topológia. Ez a térkép lehetővé teszi, hogy minden automatikusan történjen a felhasználó helyett, az OSI modell 2. szintje alapján (alapvetően a térkép a készülékek MAC-címei alapján épül fel).
- IP topológia, más néven Layer 3. Ugyanaz, mint a Layer 2 esetében, csak itt a térkép a 3. szint alapján épül fel az OSI modell szerint (IP-címek). 2. réteg, csak a térkép az OSI-modell 3. szintje (IP-címek) alapján készül.
Kézi térkép készítésekor a fában lévő csomópontokat a térképszóra kell húzni, összekötni őket stb. Szokványos rajzolás.
Két másik esetben ki kell választani a kiindulópontot, ahonnan a rendszer megkezdi a térkép építését. Például egy router csomópontját. A rendszer beolvassa ezeket az eszközökről és a csatlakoztatott portokról szóló adatokat, majd ezután a következő router adatait is beolvassa, összehasonlítja, és így tovább. Az összes eszköz elemzése után a NetXMS automatikusan ábrázolja a hálózati eszközök közötti kapcsolatokat a csatlakoztatott portok megjelölésével. Arra is van lehetőség, hogy a térképhez végső eszközöket (nyomtatók, PC-k, szerverek) is hozzáadjuk, egyszerűen a térkép beállításainál a megfelelő pontba kattintva.Jogi kattintás — beállítások — térképbeli beállítások.Itt megadhatjuk a „észlelési radiust” is, ha szükséges.
Kis ajánlás. Kapcsolja be az Always fit layout to screen (Mindig illessze a tervezést a képernyőhöz) opciót, hogy a hálózat térképének frissítésekor ne kelljen mindig görgetni a munkaterületet és használni a nagyítást.
Elosztott hálózati topológia esetén lehetőség van az objektumok térképre helyezésére is. Háttérként például használhatunk egy fényképet egy szerverhelyiségben található berendezéstartóról, és ráhelyezhetjük a szükséges objektumokat. Így gyorsan meghatározhatjuk bármelyik eszköz állapotát a tárolóban. Véleményem szerint ez nagyon hasznos dolog, ha szükséges, hogy átadja a feladatokat a utódjának, vagy hogy egy új kollégának elmagyarázza a helyzetet. Átlátható, kényelmes, magától értetődő.
3.4. Ügynökök
Az ügynökök elérhetők Windows és Linux számára is. A működés elve ugyanaz, mint a Zabbix ügynökeinek: telepítjük az eszközre, ahonnan a metrikákat le akarjuk kérdezni, és előrehozott adatokat küld a megfigyelő szerverre. Az ügynök telepíthető a csomópont rendszerbe való felvétele előtt vagy után. A kiszolgálón megjelenő ügynökkel a rendszer egy idő után elkezdi fogadni az adatokat, alkalmazva a standard sablont. Megfigyelhető paramétereket adhatunk hozzá egy csomóponthoz vagy egy vagy több előre definiált sablont is csatlakoztathatunk hozzá. Természetesen ajánlott sablonokkal dolgozni, mivel ez a beállítás rugalmasabb.
Az ügynökök által nyomon követett paraméterek listája meglehetősen kiterjedt. A teljes lista megtekinthető a
Amint a rendszer meghatározza, hogy egy csomóponton ügynök működik, azonnal hozzárendeli ezt a csomópontot egy alapértelmezett sablon egyikéhez — Windows, Linux, HP-UX, Generic UNIX, AIX, a csomópont operációs rendszerétől függően.
Alapértelmezett sablon Windows hosztokhoz:
Egy paraméter hozzáadásához a konkrét csomóponthoz kattintsunk az "Jobb gomb – Adatgyűjtési paraméter" lehetőségre, majd választjuk az "Jobb gomb a munkaterületen – Új paraméter" opciót, és válasszuk ki a szükségeset a listából. Itt azonnal beállíthatók a nyomon követett paraméterhez kapcsolódó riasztások is.
Fontos megjegyezni, hogy az ügynökök, akárcsak a Zabbix esetében, képesek felhasználói szkriptek futtatására.
Hogyan telepítsük?Ez off-topik, mert mindenki… hmm… ahogy akarja.
Itt a kérdés az, hogy csak a szerverekre kell-e terjeszteni az ügynököket, vagy minden gépre a hálózatban? Ha csak a szerverekre, és azok száma kicsi — a legegyszerűbb kézzel. Ha sok, akkor domain házirendek, KIX, PoSh. Bármivel. Az ügynökök rendelkeznek /SILENT kulccsal, amely lehetővé teszi az „átlátszó” telepítést a felhasználó számára (ha a teljes hálózatra terjesztésről beszélünk). Én a szkripteket részesítem előnyben, mivel beállítható egy feltétel, és létrehozható egy flag, ellentétben a házirendekkel, amelyek a programot minden egyes alkalommal telepítik a PC bekapcsolásakor. Tehát írunk egy szkriptet a következő sorozatból: „ellenőrizni a flag fájl létezését, ha nem létezik — elindítani az telepítőt /SILENT kulccsal, és sikeres telepítés után létrehozni a flag fájlt”. Profit.
3.5. Riasztások
A riasztások beállíthatók úgy, hogy reagáljanak a gyűjtött adatokban bekövetkező bizonyos eseményekre. Például, ha a ping-pong meghalad egy adott értéket az útválasztó felé. A riasztás értesítési módja is beállítható minden riasztáshoz (némelyeknek elegendő egy ikon a konzolon, míg mások azonnal értesítéseket küldenek, ahová csak lehet). Az eseményre adott reakció az Action Configuration előre beállított lehetőségeiből választandó.
Riasztó létrehozásához: lépjünk be a csomópont vagy sablon Adatgyűjtési konfigurációjába, dupla kattintás az érdeklődő paraméterre (ha nincs, akkor először létre kell hozni), és a tulajdonságoknál lépjünk a Thresholds fülre, majd kattintsunk a hozzáadás gombra.
«Funkció» — milyen vagy milyen értékeket vegyünk figyelembe a feltétel számításához. A következő értékeket vehetjük figyelembe (a vizsgálathoz használt értékek száma a Samples mezőben adható meg):
— Utolsó lekérdezett érték: az utolsó/-ak kapott érték/-ek
— Átlag érték: az utolsó értékek átlaga
— Átlagos eltérés: az átlagos eltérés
— Különbség az előző értékkel: a különbség a korábbi értékkel
— Adatgyűjtési hiba: adatgyűjtési hiba
— Értékek összege: az értékek összege
— Script: az érték, amelyet a felhasználói script végrehajtása eredményezett
«Művelet» — A trigger aktiválási feltétele. A következő értékeket vehet fel (az érték a megfelelő Value mezőben van megadva):
— < : kevesebb mint: kevesebb mint
— <= : kevesebb vagy egyenlő: kevesebb vagy egyenlő
— == : egyenlő: megfelel
— >= : nagyobb vagy egyenlő: nagyobb vagy egyenlő
— > : nagyobb mint: nagyobb mint
— != : nem egyenlő: nem felel meg
— hasonló: közelítőleg
— nem hasonló: nem közelítőleg
A két utolsó paraméter működése iránt nincs bizonyosságom. Ezért nem is szeretnék találgatni, hogy milyen határok vannak beépítve.
Szóval, minden olyan, mint a Zabbixban, csak itt nem kell manuálisan beírni a képleteket, félve a hibázástól vagy elírástól. A trigger (deactivation event) helyreállításakor a rendszer automatikusan megadja az értéket. (A Zabbixban megint csak be kell írni, és nem hibázhatsz).
3.6. Sablonok
Jobb klikk - új sablon létrehozása, sablon név megadása. Jobb klikk - Adatgyűjtési konfiguráció.
Egy kis elméletA gyűjtött információ több forrásból is származhat. Ezek lehetnek NetXMS ügynök, amely a gépen fut, lehet egy „egyszerű lekérdezésvagy „Belsőüzenet, amelyet a szerver maga küld (például ping), „SNMP«, «ellenőrzési pont SNMP«, «Push«, «Windows Teljesítmény Számlálók«, «SM-CLPvagy egy felhasználói „script. Minden információtípushoz ki lehet választani azt a típust, amelyet a rendszer vár a fogadás során. Például a ping egész számot (integer) ad vissza, a szabad lemezterület mennyisége bájtban szintén egész szám, de ugyanakkor a hőmérséklet már nem lesz egész szám, hanem valós (real).
Az SNMP-n keresztüli információgyűjtéshez a NetXMS-ben hatalmas felsorolás található az előre meghatározott paraméterekből, így nem szükséges konkrét OID-t beírni, hanem megtalálható a MIB fába, ami valójában meglehetősen problémás… De végül is a gyártó dokumentációját kell átnézni, és az egyes eszközökhöz keresni az OID értékeket. Rengeteg időt lehet elvesztegetni az eszközöktől történő információolvasás beállítására, találkozva a rendszer üzenetével „TÁMOGATATLAN”, és végül kiderül, hogy az adott eszköz egyszerűen nem képes a kért információt biztosítani. Itt csak a használati útmutatókat kell olvasni, és remélni.
Például, hogy be tudjuk gyűjteni a node válaszidejéről (ping) szóló információkat, hozzá kell adnunk egy új paramétert (Jobb kattintás - új paraméter), az Origin mezőben válasszuk az Internal-t, nyomjuk meg a Select gombot, és válasszuk a Ping Time-ot. Ott van keresés, amiről a Zabbixban csak álmodtam. Érdemes megváltoztatni a node lekérdezési periódusát is (alapértelmezés szerint 60 másodperc, tehát ha az útválasztó azonnal leáll a monitoring rendszer által történt lekérdezés után, majdnem egy teljes perc telik el, mire a rendszer észleli, hogy valami nincs rendben, és riasztást küld).
A feldolgozható Internal adatok listája:
Miután a sablonba hozzáadtuk az összes szükséges beállítást, nyomjuk meg Jobb kattintás - alkalmazni és válasszuk ki az összes node-ot, amelyre ezt a sablont alkalmazni kell (ctrl+bal kattintás). Ennyi. Ezt követően a sablon alatt megjelenik egy ágazat, amelynek kibővítésével láthatjuk az összes node-ot, amelyhez ez a sablon kapcsolódik.
A sablonhoz való leválasztáskor a gyűjtött adatok nem állnak le, hogy megszüntessük a gyűjtést, minden node esetében be kell lépni az Adatgyűjtési konfigurációba és manuálisan törölni mindent, vagy először törölni kell a paramétereket a sablonból, és csak utána eltávolítani a node-okat. Nem tudom, miért így van, de véleményem szerint ez nagyon furcsa dolog. De... Amilyen az élet.
A sablonban kiválaszthatjuk a szükséges gyűjtött adatokat, és tömegesen átmásolhatjuk őket egy másik sablonba. Nem szükséges kézzel másolni az egyiket a másikba... Már kezdtem utálni a Zabbixot..
3.7. Műszerfalak
Bár furcsa, a NetXMS Wiki ezzel kapcsolatban csupán egy YouTube linket tartalmaz: , nincs még lista és leírás azokról az elemekről, amelyeket hozzáadhatunk a Műszerfalhoz. Alapvetően minden olyan intuitív, mint eddig. Címke — ez egyszerűen... nos... Címke... Nem is tudom, hogyan fordítsam. Szóval egy feliratmező, amely az elemek megnevezésére és elhatárolására használatos, mivel maguk az elemek nem tartalmaznak neveket. Vonalgrafikon — ez vonaldiagram. Oszlopdiagram — ez egy diagram. Riasztás megjelenítő — a kiválasztott node/-ok számára készült figyelmeztetések listája. Szóval, a nevek beszélnek magukért.
Ezután meg kell nyitni a műszerfal tulajdonságait, és beállítani a nézeteket. Minket a Dashboard Elements fül érdekel. A számok oszlopainak száma az az elemeknek a mennyisége, amelyek vízszintesen helyezkednek el. Minden objektumnak saját beállításai vannak, és azt javaslom, hogy vegyünk ki a pipát a Layout-Grab excessive vertical space opcióról, hogy minimalizáljuk minden egyes elem méretét.
3.8. Művelet Konfiguráció
(Konfiguráció-Művelet Konfiguráció)
Lényegében ezek a műveletek a trigger-ek aktiválására adott válaszok.
A NetXMS képes e-mailt, sms-t, xmpp üzenetet küldeni a trigger aktiválására válaszul. Itt minden egyszerű — csak ki kell tölteni a szükséges mezőket.
Ezen kívül lehet:
— Átadni az értesítést egy másik NetXMS szervernek
— Parancsot végrehajtani a NetXMS adminisztrációs szerveren
— Parancsot végrehajtani egy node-on a NetXMS ügynöke segítségével
— Végrehajtani egy NXSL szkriptet (NSXL — ez a NetXMS saját )
A művelet létrehozása után beállítható a végrehajtás késleltetési ideje, valamint alkalmazható makró a végrehajtáshoz. A késleltetési idő szükséges, hogy ne zavarjuk az operátort, ha a probléma önmagától megoldódik (például, ha a ping-válaszideje meghaladja a megadott értéket, de a következő ellenőrzésnél visszatérhet a normális szintre, így miért zavarnánk ilyesmikkel?).
3.9. Jogkörök megosztása
Minden objektumhoz beállíthatók saját hozzáférési jogok. Minden objektumon belül is beállíthatók hozzáférési jogok. Ez nagyon rugalmasan lehetővé teszi a feladatok és a monitoring lehetőségek elosztását a különböző felhasználói csoportok számára. Ez minden, amit mondani akartam.
4. Következtetés
Szeretném megcáfolni a saját cikkem címét. A NetXMS nem a lusták számára készült. Egyszerűen a fejlesztők nem helyeztek akkora hangsúlyt a funkcionalitásra, mint mások, de emellett az interfészről is gondoskodtak.
Legyen így. Használom a Zabbix-ot és a NetXMS-t. Ezért egyszerűen leírom a két rendszer bennem maradt érzéseit.
Tehát.
A NetXMS számomra rendkívül felhasználóbarát rendszernek tűnik. Hát... az adminoknak... igen, az adminoknak. Van benne egy úgynevezett intuitív felhasználói felület, ami igazán nagyszerű. Nincs szükség saját képletek írására, sokáig tartó dokumentáció olvasására, hogy aktiváljam a ping ellenőrzést egy switch előtt vagy valami hasonló egyszerű dolgot. De. A Zabbixban ez a hasonló egyszerű dolog alig különbözik valami tényleg bonyolulttól, tehát ha ezt elsajátítottad, akkor minden mást is meg tudsz csinálni. A NetXMS-ben vannak tippek, a legtöbb paramétert megtalálhatod a felületen, egérrel kiválasztva és beállítva. A Zabbixnál meg kell tudnod, hogy a rendszer tudja-e ezt vagy azt, és ha igen, akkor hogyan írják le és milyen paramétereket ad vissza. A Zabbix a közösségi támogatásban és a rengeteg sablonban nyer, ami minden eshetőségre készen áll... ha abban a rengeteg hulladékban sikerül megtalálni azt, amire szükséged van... Másrészt a NetXMS-nek is van egy csomó támogatója, akik bővítményeket készítettek ehhez a rendszerhez. A rendszer pedig alapból is képes figyelni a legnépszerűbb alkalmazásokat, amiről a projekt főoldalán is olvashatsz.
A NetXMS legnagyobb előnye a Zabbixszal szemben számomra az a lehetőség, hogy egy problémás csomóponton szkripteket futtathatok, válaszként egy riasztás aktiválására. Ha a CPU hőmérséklete a küszöbérték fölé emelkedik — a rendszer automatikusan leállítja a hosztot. Aztán majd foglalkozunk a problémával. Lehetséges, hogy a Zabbixban is létezik ilyen funkció, de én nem tudtam megvalósítani. Ahogyan a portmonitorozás a routereken is. Itt meg megoldja magát... Nos, ahhoz, hogy ezt megvalósítsd, meg kell tanulnod a szkriptnyelvet, és ennyi...
A NetXMS jogosultsági rendszer rendkívül rugalmas lehetőségeket biztosít a felhasználók jogainak kezelésére. Azonban mindezek beállítása időigényes feladat.
Összességében a rendszerek meglehetősen hasonlóak, és úgy tűnik, hogy a lehetőségeik első pillantásra legalábbis összehasonlíthatók. Bár érződik, hogy a Zabbix többre képes, de ezek a lehetőségek mélyen a motorháztető alatt rejtőznek, és egy egyszerű halandó admin számára a „mind egyben” elérhetetlen. A NetXMS viszont egyszerűnek és érthetőnek, barátságosnak és kellemesnek tűnik.
A Zabbixnak kiváló dokumentációja, wiki-ja, útmutatói, F.A.Q.-ja, legjobb gyakorlatai, valamint a különféle fórumok találhatók, ahol szinte minden kérdésre választ találhatsz. Ha pedig valami nem világos — felteheted a saját kérdésedet.
Összefoglalva, szeretném ajánlani a NetXMS-t azoknak, akik most kezdik, vagy akiknek nincs szükségük mélyrehatóan monitorozni mindent. Biztos vagyok benne, hogy ha jobban belemerülünk, nagyon részletes megfigyeléseket is végezhetünk benne.
Mégis, a legnagyobb előnynek tekintem a nagyon kellemes felhasználói felületet és a könnyű beállítást.
5. Használt anyagok
YouTube csatorna
Forrás: habr.com
