0. Úvod
Na Habré jsem nenašel žádný článek o NetXMS, i když jsem hledal. A právě z tohoto důvodu jsem se rozhodl napsat toto dílo, abych věnoval pozornost tomuto systému.
Je to jak tutoriál, tak návod a povrchový přehled možností systému.
Tento článek obsahuje povrchovou analýzu a popis možností systému. Do hloubky jsem se do možností nezatápěl z několika důvodů. A popsání veškeré funkčnosti by zabralo rozhodně více než jeden článek.
Jelikož jsem v podstatě pracoval pouze se Zabbixem, bude v článku často zmiňován právě tento systém pro srovnání s předmětem. Navíc se tak nějak stalo, že vše je porovnáváno s něčím obecně uznávaným.
1. Co a proč?
Monitorovací systém, jak je vidět z definice, je systém, který umožňuje kdykoli získat aktuální informace o nějakém uzlu síťovém zařízením routerem nebo napsat potřebné.
Proč je to potřeba – to je také očividné. Abychom byli informováni o tom, co se děje.
Často může monitorovací systém poskytnout velmi vyčerpávající informace o stavu jak infrastruktury jako celku, tak jednotlivých jejích částí. Navíc, pokud nastavíte upozornění (a bez toho nemá žádný monitoring cenu), pak máme na výstupu vážný nástroj, který nám umožňuje nejen včas reagovat na již vzniklé havarijní situace, ale v mnoha případech také tyto havárie předejít.
2. Proč NetXMS?
Trochu offtopic pro ty, kdo mají rádi hodně písemného obsahu.Když jsem byl mladý a nezkušený... Tak obvykle začínají všechny pohádky?.. Když jsem byl maximalista, studoval jsem otázku monitorování infrastruktury a výsledkem těchto "výzkumů" bylo zjištění, že lepší než Zabbix nic není. A v té době se mi skutečně líbil, protože umí hodně, může mnoho a jeho funkce lze rozšířit vlastním skripty, takže se dá říct, že může vlastně všechno, když máte správné ruce. Ale Zabbix je poměrně složitý nástroj. Abych se s ním více či méně vyznal, trvalo mi to téměř dva týdny. A to byla jen fáze zavedení. Poté jsem strávil další pár týdnů nastavováním monitorování všeho, co jsem tehdy potřeboval. A jak s jeho pomocí sledovat stav portů na routerech, to jsem si přečetl, vyděsil jsem se a rozhodl se, že to vlastně ani moc nepotřebuji... Ne, tam je to opravdu děsivé pro nepřipravenou mysl hned po institutu...
A tak po několika letech, když jsem vyzrál a zestárl, jsem se rozhodl, že nastal čas osvěžit si znalosti o monitorovacích systémech. A konečně udělat normální, stabilní monitorování sítě, protože tento problém se stal aktuálním v souvislosti s růstem segmentů, připojením pobočky a dalšími drobnostmi. Všechno teče, všechno se mění. A začal jsem testovat různé nástroje. Nainstaloval jsem tento systém, vyzkoušel ho, pak ten. A ve všech něčeho chybělo, všude něco nevyhovovalo. Buď rozhraní bylo nepohodlné, nebo se to nedalo nastavit bez práce, nebo ještě něco. A pak mi padl do oka NetXMS. Mimochodem: tam, kde jsem se s Zabbixem vyznával dva týdny, s NetXMS to šlo během pár hodin. Možná to byla zkušenost s prací se Zabbixem, nebo možná za to mohl samotný NetXMS... těžko říct.
NetXMS se ukázala jako poměrně jednoduchý systém k instalaci a nastavení. Má verze serveru a administrační konzole jak pro Windows, tak pro Linux, generátory grafů, vestavěný "prohlížeč", který umožňuje, aby se z administrátorské konzole připojil k těm samým routerům pomocí http/https protokolů, a rozhraní je intuitivně srozumitelné, a také agent pro jakýkoliv operační systém. Jinými slovy, tento systém se ukázal jako jednoduchý a pohodlný. Na první pohled.
Dokumentace je, mimochodem, na 8 z 10. Hlavní věci jsou v ní uvedeny, ale abyste se dostali do detailů, musíte trochu pohledat.
Hlavní výhody uvedené vývojářemHluboké monitorování sítě
Automatické detekce, vizualizace a vyhledávání připojených komponent na úrovni 2 a 3
Plná podpora SNMPv3
Aktivní detekce pomocí skenovacích „sond“
Pasivní detekce na základě informací od sledovaných zařízení — ARP a směrovacích tabulek, rozhraní
Monitorování aplikací a serverů
Všechny hlavní metriky, které očekáváte: procesor, souborové systémy, vstup-výstup, paměť, provoz
JMX most pro monitorování Java aplikací
Rozšíření pro konkrétní aplikace: Oracle, MySQL, PostgreSQL, MongoDB, DB2, Tuxedo a mnohé další
API pro integraci vlastních aplikací
Určeno pro velké sítě
Jeden server může sledovat stovky metrik na tisících zařízení
Plná podpora distribuovaného monitorování a horizontálního škálování
Monitorování překrývajících se IP podsítí
Flexibilní kontrola přístupu pro operátory a zákazníky
3. Ponoříme se hlouběji
Jak nainstalovat systém — existuje celý administrátora, dostupný na , a není na tom nic složitého, takže se na tom dále nezastavím. Nejtěžší na instalaci je připojení systému k databázi… Zde bude rozdíl pouze ve výběru DBMS a operačního systému serveru. Zvolil jsem Windows (dále-dále-zadat údaje-hotovo) a MSSQL, protože jsem ho již měl.
3.1. Aktivujeme automatické objevování
Automatické objevování uzlů sítě lze zapnout při instalaci. Pokud to z nějakého důvodu nebylo provedeno, lze ho vždy zapnout v „Configuration-Network Discovery“ nebo kliknutím na ikonu se stejným názvem. V pracovním prostoru se objeví vlastnosti objevování. Je třeba ho zapnout přepnutím do pasivního nebo aktivního režimu a označit další vlastnosti, jako jsou dotazované podsítě. Také zde lze nastavit filtry, a to jak voleb, tak i doladění vestavěných v systému, ale i napsání vlastních skriptů. Upřímně řeknu — filtry jsem nepotřeboval. Ale nastavení vypadá docela přátelsky a srozumitelně.
Zde lze také uvést výchozí SNMP community a jeho přihlašovací údaje (čti autorizaci).
3.2. Přidávání uzlů
Při zapnutém automatickém detekování budou koncové uzly (PC, tiskárny) automaticky přidány a rozděleny do podsítí. S aktivním síťovým zařízením je to o něco složitější.
Nejprve je potřeba zapnout na síťovém zařízení SNMP a nastavit komunitu. Pokud ve vlastnostech automatického objevování uzlů sítě nebyla změněna výchozí hodnota pro SNMP komunitu, systém používá veřejnou komunitu, přičemž toto nastavení lze změnit pro každý uzel ve vlastnostech přidaného uzlu (node).
Pro pohodlí lze zařízení seskupit podle jakéhokoli vhodného principu, k tomu je možné ve stromě vytvářet kontejnery ve větvi Služby infrastruktury a přiřazovat k nim uzly z Celkové sítě.
Po zapnutí a nastavení SNMP na směrovačích a přidání do seznamu sledovaných zařízení se systém s nimi sám spojí, zjistí, o jaké zařízení se jedná, aplikuje šablony, začne sběr dat a zobrazí přední panel pro každý směrovač. Sám. Z krabice. Když jsem nastavoval Zabbix, mohl jsem o něčem takovém jen snít.
Všechna svá síťová zařízení jsem přidával ručně, protože se pro nějaký důvod sama neobjevila. Tady je to jednoduché. Vytvoříme kontejner v Službách infrastruktury s libovolným vhodným názvem (například switche), a PKM-vytvořit-uzel, uvést zobrazené jméno uzlu, jeho IP adresu a je lepší zaškrtnout "vypnout používání agenta NetXMS", protože jej stejně není možné nainstalovat na síťové zařízení a zbytečné balíčky nejsou potřeba.
Vestavěný prohlížeč. Můžete jednoduše kliknout pravým tlačítkem myši na potřebný směrovač a otevřít webové rozhraní zařízení. To mi připadalo pohodlnější, než každý čas hledat svou poznámku a hledat potřebnou IP. Pravda, prohlížeč není nic moc.
3.3. Vytvoření mapy sítě
Nejprve je potřeba vytvořit mapu sítě jako objekt. Jak obvykle - ve větvi Mapa sítí pravým tlačítkem myši, vytvořit, vybrat typ mapy, nastavit parametry, a systém to pak udělá sám.
Typy map jsou následující:
- Vlastní. Toto je mapa určená k manuálnímu vytvoření, podle přání uživatele.
- Topologie vrstvy 2. Toto je mapa, která umožňuje automaticky udělat vše za uživatele, opírající se o 2. úroveň modelu OSI (v podstatě vytváří mapu na základě mac adres zařízení).
- Topologie IP, také vrstva 3. To samé, co v případě vrstvy 2, pouze mapa se vytváří na základě 3. úrovně modelu OSI (IP adresy).
Při výběru ručního sestavování mapy je potřeba přetahovat uzly ze stromu na mapovou vrstvu, spojovat je atd. Obvyklé kreslení.
Ve dvou jiných případech je třeba vybrat referenční bod, od kterého systém začne mapu vytvářet. Například uzel nějakého směrovače. Systém čte z něj data o připojených zařízeních a portech, ke kterým jsou připojena, poté čte data z následujícího směrovače, porovnává to a tak dále. Po analýze všech zařízení systém NetXMS sám vykreslí vazby mezi zařízeními sítě s uvedením portů, kam co je připojeno. Lze také určit, aby systém umístil na mapu i koncová zařízení (tiskárny, PC, servery), jednoduše kliknutím na příslušnou položku v vlastnostech mapy.PKM — vlastnosti — vlastnosti mapy.Také v této položce lze při přání nebo potřebě nastavit «poloměr detekce».
Malá doporučení. Zapněte vlastnost Always fit layout to screen, aby při každé aktualizaci mapy sítě nebylo třeba posouvat pracovní prostor a pracovat se zoomem.
Při distribuované topologii sítě je možné umístit objekty na mapu terénu. Také lze jako pozadí použít například fotografii racku s vybavením v serverovně a na něj překrýt potřebné objekty. Tímto způsobem lze rychle určit stav jakéhokoli zařízení v racku. Podle mého názoru je to velmi užitečná věc v případě potřeby předat záležitosti nástupci nebo novému kolegovi vysvětlit stav věcí. Přehledné, pohodlné, samozřejmé.
3.4. Agenti
Agenti existují jak pro Windows, tak pro Linux. Princip fungování je stejný jako u agentů Zabbix: nainstalují se na stroj, ze kterého je třeba získávat metriky, a přenášejí data na monitorovací server. Agenta je možné nainstalovat jak před přidáním uzlu do systému, tak i po. Po zřízení agenta na uzlu začne systém po nějaké době přijímat data od něj, přičemž použije standardní šablonu. Sledované parametry lze přidávat jak pro jeden uzel, tak připojit k němu jednu nebo více předdefinovaných šablon. Doporučuje se samozřejmě pracovat se šablonami, protože toto nastavení je flexibilnější.
Seznam sledovaných parametrů pro agenty je dost rozsáhlý. Kompletní seznam lze zobrazit v
Jakmile systém zjistí, že agent funguje na uzlu, okamžitě přiřadí tento uzel k některé z výchozích šablon — Windows, Linux, HP-UX, Generic UNIX, AIX, podle operačního systému uzlu.
Standardní šablona pro Windows hosty:
Přidat parametr pro sledování konkrétnímu uzlu lze kliknutím na „Pravé tlačítko myši - Parametr sběru dat«, poté „Pravé tlačítko v pracovním prostoru — Nový parametr«, a vybrat požadované z seznamu. Zde lze také nastavit a spouštěče pro sledovaný parametr.
Důležité je, že agenty, stejně jako u Zabbixu, umí spouštět uživatelské skripty.
Jak nainstalovat?Tohle je offtopic, protože každý… hmmm… jak chce.
Otázka je, zda rozšiřovat agenty pouze na servery nebo na všechna zařízení v síti? Pokud na servery a je jich málo — nejjednodušší je to udělat ručně. Pokud jich je hodně — doménové politiky, KIX, PoSh. Cokoli. Agenti mají klíč /SILENT, který umožňuje „vysadit“ ho průhledně pro uživatele (pokud mluvíme o rozšíření na všechna zařízení v síti). Upřednostňuji skripty, protože lze nastavit podmínku a vytvořit jakýsi flag, na rozdíl od politik, které instalují program pokaždé, když se PC zapne. Takže napíšeme skript v sérii „zkontrolovat existenci souboru-flag, pokud ne — spustit instalátor s klíčem /SILENT a po úspěšné instalaci vytvořit soubor-flag“. Zisk.
3.5. Spouštěče
Spouštěče lze nastavit na reakci na určité události v shromážděných datech. Například překročení určité hodnoty ping-pong k routeru. Způsob upozornění pro každý spouštěč se také nastavuje (pro některé stačí ikona v konzoli, jiné okamžitě posílají upozornění kamkoli). Reakce na událost se vybírá z přednastavených v konfiguraci akce.
Pro vytvoření spouštěče: přejít do konfigurace sběru dat uzlu nebo šablony, dvojitým kliknutím na zajímavý parametr (jestliže neexistuje, je třeba ho nejprve vytvořit), a v jeho vlastnostech přejít na kartu Prahy, kliknout na tlačítko přidat.
«Funkce» — kterou nebo které hodnoty brát pro výpočet podmínky. Může přijímat následující hodnoty (počet používaných pro kontrolu hodnot je uveden v poli Vzorky):
— Poslední hodnoty: poslední/poslední získaná hodnota/hodnoty
— Průměrná hodnota: průměrná hodnota z posledních
— Průměrné odchylky: průměrné odchylky
— Rozdíl od předchozí hodnoty: rozdíl od předchozí hodnoty
— Chyba při shromažďování dat: chyba při získávání dat
— Součet hodnot: součet hodnot
— Skript: hodnota získaná v důsledku práce uživatelského skriptu
«Operace» — podmínka spuštění spouštěče. Může nabývat hodnot (hodnota se uvádí v příslušném poli Value):
— <: menší než: menší než
— <=: menší nebo rovno: menší nebo rovno
— == rovná se: rovno
— >=: větší nebo rovno: větší nebo rovno
— >: větší než: větší než
— !=: není rovno: není rovno
— like: přiblíženo k
— not like: nepřiblíženo k
Co se týče dvou posledních parametrů, nejsem si jistý, jak fungují. Proto ani nebudu hádat, jaké hranice v nich jsou zapuštěny.
Jednoduše řečeno, všechno jako v Zabbixu, jen není třeba ručně zapisovat vzorce, bát se chyby nebo překlepu. Pro obnovení spouštěče (deactivation event) systém automaticky vloží hodnotu. (V Zabbixu zase je třeba psát a neopakovat se).
3.6. Šablony
Pravým tlačítkem myši - vytvořit šablonu, zadat název šablony. Pravým tlačítkem myši - Konfigurace shromažďování dat.
Trochu teorieShromažďované informace mohou pocházet z několika zdrojů. Může to být agent NetXMS, pracující na stroji, může to být „jednoduchý dotaz“ nebo „Interní«, odesílaný samotným serverem (například stejný ping), „SNMP«, «kontrolní bod SNMP«, «Push«, «Windows Performance Counters«, «SM-CLP«, nebo uživatelský „skript«. U každého typu informace lze zvolit typ, který systém očekává při příjmu. Například ping vrátí cel číslo (integer), množství volného diskového prostoru v bajtech také bude integer, zatímco teplota bude již typu reálné číslo (real).
Pro shromažďování informací přes SNMP má NetXMS obrovský seznam předdefinovaných parametrů, to znamená, že není třeba uvádět konkrétní OID, ale lze jej najít ve stromu MIB, což je ve skutečnosti dost problematické… Ale. Nakonec musíte zkoumat dokumentaci výrobce a hledat IOD hodnoty pro každé zařízení samostatně. Můžete strávit spoustu času nastavením čtení informací z zařízení, narážejíc na hlášení systému „UNSUPPORTED“, a nakonec se ukáže, že toto konkrétní zařízení prostě neumí poskytnout požadované informace. Zbývá jen pročíst manuály a doufat.
Například pro shromažďování informací o čase odezvy uzlu (ping) je potřeba přidat nový parametr (PKM-nový parametr), v poli Origin vybrat Internal, kliknout na tlačítko Select a zvolit Ping Time. Je tam vyhledávání, o kterém jsem v Zabbixu jen snil. Také má smysl změnit interval dotazování uzlu (výchozí je 60 sekund, takže pokud router přestane odpovídat těsně po tom, co byl dotazován monitorovacím systémem, uplyne téměř celá minuta, než systém zjistí, že se něco děje, a spustí alarm).
Seznam Internal dat, která lze zpracovávat:
Jakmile byly do šablony přidány všechny potřebné nastavení, je třeba kliknout na PKM-aplikovat a vybrat všechny uzly, ke kterým by měla být tato šablona aplikována (ctrl-levé tlačítko myši). A to je vše. Poté se v hierarchii pod šablonou objeví větev, jejímž rozbalením je možné vidět všechny uzly, na které byla tato šablona aplikována.
Při odpojení uzlu od šablony shromážďované údaje přestávají být shromažďovány, aby bylo možné zrušit jejich shromažďování, je nutné pro každý uzel vstoupit do konfigurace shromažďování dat a vše ručně odstranit, nebo nejprve odstranit parametry ze šablony a až poté odstraňovat uzly. Nevím, proč je to uděláno tímto způsobem, ale podle mého názoru je to velice zvláštní. Ale... jak to je.
Ve šabloně lze vybrat požadovaná shromážděná data a zkopírovat je do jiné šablony. Hromadně. A není potřeba kopírovat z jedné šablony do druhé ručně… Už začínám nenávidět Zabbix.
3.7. Dashboards
Jak podivné, ale NetXMS Wiki k tomu obsahuje pouze jeden odkaz na youtube: , neexistuje ani seznam a popis prvků, které lze na dashboard přidat. Principiálně je to tam stále intuitivní. Štítek — to je prostě… no… štítek… Ani nevím, jak to přeložit. Zkrátka, pole s nápisem, slouží k označení a oddělení prvků, protože samy prvky názvy neobsahují. Čárový graf — to je čárový graf. Sloupcový graf — to je diagram. Alarm Viewer — seznam upozornění pro vybraný/é uzel/y. Zkrátka, názvy mluví samy za sebe.
Dále je třeba otevřít vlastnosti dashboardu a nastavit zobrazení. Zajímá nás karta Prvky dashboardu. Počet sloupců — to je počet sloupců, prvků, které budou umístěny horizontálně. Každý objekt má své vlastnosti a doporučil bych zrušit zaškrtnutí položky Layout-Grab excessive vertical space, abychom minimalizovali velikost každého prvku.
3.8. Konfigurace akcí
(Configuration-Actions Configuration)
Ve skutečnosti jsou to akce v reakci na spuštění spouštěčů.
NetXMS dokáže posílat e-mail, sms, xmpp zprávu v reakci na aktivaci spouštěče. Tady je to triviální — stačí vyplnit potřebná pole.
Také lze:
— Přenést upozornění na jiný server NetXMS
— Provedení příkazu na serveru administrace NetXMS
— Provedení příkazu na uzlu pomocí agenta NetXMS
— Provedení skriptu NXSL (NSXL — to je vlastní )
Po vytvoření akce je možné nastavit zpoždění provedení a také aplikovat makro pro vykonání. Zpoždění je potřebné, aby se operátor zbytečně neobtěžoval, pokud se problém vyřeší sám (například doba odpovědi na ping byla delší než stanovená hodnota, ale při další kontrole se může vrátit k normálu, tak proč obtěžovat s takovými maličkostmi?).
3.9. Ověření práv přístupu
Pro každý objekt lze nastavit svá práva přístupu. Pro každý objekt uvnitř jiného objektu lze také nastavit práva přístupu. To umožňuje velmi flexibilně rozdělit povinnosti a možnosti monitorování pro různé skupiny uživatelů. To je všechno, co jsem chtěl říct.
4. Závěr
Chtěl bych zpochybnit název svého vlastního článku. NetXMS není pro lenochy. Vývojáři pouze nedůraznili funkčnost, jako to dělají někteří, ale kromě toho se postarali o uživatelské rozhraní.
Takto, používal jsem Zabbix a NetXMS. Proto prostě napíšu své pocity z obou těchto systémů.
Tak tedy.
NetXMS se mi jeví jako velmi uživatelsky přívětivý systém. No... pro administrátora... ano, pro administrátora. Má to, čemu se říká intuitivní rozhraní, a to je skvělé. Není třeba psát vlastní výpočty, číst spoustu dokumentace, abyste zapnuli kontrolu pingů před switchem nebo nějakou jinou základní věc. Ale. V Zabbixu je tato základní věc velmi podobná něčemu skutečně složitému, takže když to zvládnete, uděláte stejně snadno i všechno ostatní. V NetXMS jsou nápovědy, většinu parametrů lze najít v rozhraní, vybrat myší a nastavit. V Zabbixu musíte zjistit, zda systém umí to či ono, a pokud ano, tak jak se to píše a jaké parametry to vrací. Zabbix vyhrává v komunitě a v množství šablon pro všechny případy... pokud se v této hromadě odpadu podaří najít to, co potřebujete... Na druhou stranu má NetXMS také spoustu příznivců a dodatků, které vytvořili. A samotný systém z krabice umí monitorovat nejoblíbenější aplikace, o čemž je zmínka na hlavní stránce projektu.
Hlavní výhodou NetXMS oproti Zabbix pro mě byla možnost spustit skript na problémovém uzlu jako reakci na aktivaci spouštěče. Teplota CPU vzrostla nad práh – sama vypne hostitele. A pak už se budeme zabývat tím, v čem je problém. Možná, že v Zabbixu je také taková věc, ale já jsem to nedokázal najít. Stejně jako monitorování portů na směrovačích. A tady se to prostě... No, jako prostě... Musíte se naučit skriptovací jazyk, a to je vše...
Práva přístupu v NetXMS umožňují velmi flexibilně rozdělovat možnosti různých uživatelů systému. Ale abyste to všechno nastavili, musíte se opravdu něco naučit.
Celkově jsou systémy dost podobné a jejich možnosti se na první pohled zdají minimálně srovnatelné. I když je cítit, že Zabbix může více, ale tyto možnosti leží hluboko pod povrchem a pro obyčejného administrátora jsou "vše v jednom" nedosažitelné. NetXMS se mi však jeví jako jednoduchý, srozumitelný, přívětivý a příjemný.
Zabbix má vynikající dokumentaci, wiki, návody, F.A.Q., nejlepší praxe a také různé fóra atd., kde lze najít odpovědi téměř na všechny otázky. A pokud ne, můžete se zeptat sami.
Shrnutí, chtěl bych doporučit NetXMS pro lidi, kteří právě začínají, nebo pro ty, kteří nepotřebují hluboce pronikat do monitorování všeho a všude. Jsem přesvědčen, že pokud se do toho ponoříte hlouběji, můžete v něm nastavit velmi podrobné sledování.
Ale přesto vidím hlavní výhodu v opravdu příjemném rozhraní a jednoduchosti nastavení.
5. Použité materiály
youtube kanál
Zdroj: habr.com
