Hálózat nyilvátartó és monitorozó rendszer, segítség...

Hálózatok általános

Sziasztok.

Azt, hogy milyen rendszerről van szó, egy blogban írtam le, mert egy kicsit hosszú : http://hup.hu/node/109290
Szóval beszállna-e valaki a projektbe.
Arról is érdekelnének a vélemények, hogy szerintetek érdemes-e. Számomra ugyan hasznosnak bizonyult az előző verzió, de eddig bárkinek ajánlottam, még megnézni sem volt hajlandó (mondjuk sokat nem erősködtem én se).

Átírtam a címet, mert úgy tűnik a lényeg kimaradt.

  • 5593 megtekintés

( neutrino v | 2011. 11. 30., sze – 13:24 )

Nagios + SIM kártya és meg van oldva amivel görcsölsz... Nem lelohasztani akarom a lelkesedésed, de tényleg vannak kiforrt projectek erre a célra...
-------------------------
127.0.0.1 SWEET 127.0.0.1
AMD Athlon X2 245E@3,1 GHz OC, MSI Radeon 6770 1 Gb GDDR5, Seagate Barracuda, Windows 7 Enterprise

A nagios az egy jó dolog, de.
Szerintem a konfigurálása, főleg nagyobb rendszerek esetén enyhén szólva is barátságtalan. Ez még akkor is megérne egy misét, ha a nagios lefedné az általam részben megvalósított rendszer funkcionalitását.
Az első LanView verzió nem a riasztásra koncentrált (ez egy hiányossága volt, épült rá egy riasztó rendszer, de teljesen más szempontok alapján), a hálózatok monitorozását nem csak a szerverek szempontjából végezte. Az aktív eszközök folyamatos lekérdezésével rögzítette, a gépek (munkaállomások is) milyen címeket kaptak, milyen VLAN kiosztás van a hálózaton, a switch-ek hogyan kapcsolódnak egymáshoz, a switch-ekre kapcsolódó megfigyelt munkaállomások valóban jelen vannak-e. A hálózatban lévő eszközök (ez munkaállomásoknál lényeg) hol vannak. A szerverek, switsh-ek portjain mekkora forgalom van (mint a munin, csak az ennyi végpont ellenőrzésére alkalmatlan) A változásokat nem utolsó sorban loggolta szintén az adatbázisba.
Az új verzióban pontosítva lett (vagy lenne) a helymeghatározás (nem csak az derül ki, hogy melyik porton látszik a gép, de az is (mivel a patch-elések is az adatbázisban vannak), hogy melyik szobában. A topológia vagy annak egy része több módszerrel is lekérdezhető lessz, így az adatrögzítési hibáknak legalább egy része kiderül. A riasztást (ami a régi rendszernek nem vagy nem úgy volt része. mint a nagios-nak) pontosan a nagios-ban látott ötletek alapján szeretném megvalósítani (az adatbázisban ez már megvan, de program még nincs rá), praktikusan úgy, hogy a nagios pluginjeit is lehessen használni. Ugyanígy a forgalmi adatok lekérdezésénél az 50 portos switch-en egyedi program gyűjti az adatot, ahol pedig használható, ott a munin-node tenné ugyanezt. És persze egy kicsit ésszerűsíteni kell a grafikonrajzolást is, mert a munin módszerével nagy portszám esetén már egy erőmű kellene.
A rendszer egy lényeges része a hálózati topológia nyilvántartása, ki hol van. Riasztások szempontjából az sem érdektelen, hogy megjelent-e olyan gép a védett szegmensekben, aminek nincs ott helye, és még sorolhatnám azokat a funkciókat, amihez a nagios még csak köze sincsen.

Most ránéztem. Úgy tűnik ez ugyanúgy a szerverek és a nyújtott szolgáltatások szempontjából nyújt segítséget. Ha foglakozik a hálózat topológiájával, ez is mint az eddig látott rendszerek csak a logikai topológiával foglalkozik.
Nem tudok olyan rendszerről (ezért kezdtem bele a megírásába) ami foglalkozna a fizikai topológiával, és komolyabb információval szolgálna a kliens eszközökkel kapcsolatban. Nálam van egy pár tucat szerver, 40 egynéhány switch ezek menedzselésére sok kiváló eszköz létezik, de van itt még több száz munkaállomás, vagy ezer aktív végpont, patch panelek, fali csatlakozók (több mint 100 iroda, tanterem ahol végpontok vannak). A fizikai topológiáról fregmentált, részben papír alapú, felesem igaz dokumentációk vannak, azokkal sem ártana valamit kezdeni.
Nekem ez a rendszer (mármint az általam megvalósítani próbált LanView2) nagyon kéne, lehetőleg tegnapra. Kicsit hihetetlen, hogy eddig mindenki szerint felesleges. Az értem, hogy eddig miért nem fogott bele senki, elég nagy falat.

Valóban elég pontatlan meghatározások.
A logikai topológián azt azt értem, amit pl. a ProCurve Manager is fel szokott rajzolni, vagyis hogyan kapcsolódnak egymáshoz az aktív eszközök. Tehát leírja, hogy AA switch 1-es portja kapcsolódik a BB switch 1-es portjához.
A VLAN-ok figyelembevételével egy másik logikai topológiát lehet készíteni, de erre is vannak eszközök.
A logikai topológia általában felderíthető, lekérdezhető. Viszont semmit sem árul el arról, hogy a valóságban fizikailag ez hogyan valósul meg. A két eszköz össze lehet kötve egy patch kábellel. De lehet közte néhány patch panel, vagy fali csatlakozó, és lehet trükközni is, ha nincs rendesen, bekábelezve a helyiség (elfogytak a madzagok). Semmi nem derül ki arról, hogy ez az eszköz hol van fizikailag.
Persze ez csak ott lényeges, ahol kellően nagy a fizikai kiterjedése a hálózatnak, ill. elég sok végpont van. Itt a főiskolán ~1000 végpont van, és ha el kell mennem a nagy előadóba a szobámból, az oda-vissza közel 1km épületen belül. És kétlem, hogy ez valami különlegesen nagy hálózat lenne, én is láttam nagyobbat.
És mivel a monitorozó eszközök általában nem foglalkoznak a munkaállomásokkal vagy más végberendezésekkel, azok a topológiából is kimaradnak.

És a fizikai topológiát hogy szeretnéd kezelni? A zabbixnak (is) vannak térképei, amik tartalmazhatnak több féle elemet, pl. térképet is. Tehát fel lehet rá tenni a campus térképét, azon belül az egyes épületekét, és azon belül az egyes előadók és egyéb helyiségek térképeit is.
Sajnos a többi rendszert nem igazán ismerem, nem tudom, hogy milyen más megoldások léteznek.

A térképek, legalábbis számomra mellékes dolgok, de szükség volt rá.
Kétféle riasztás típus van. Ez nem feltétlenül jelent a rendszer szempontjából logikai különbséget, de a felhasználás szempontjából különböző.
Vannak azok a riasztások amik a rendszergazdának, vagy a menedzsmentnek szólnak. Nem megy egy szerver, nem érhető el valamilyen szolgáltatás, stb..
A másik típus az ami viszont a diszpécsernek szól, és nem levél vagy sms-ként jelenik meg, hanem egy weblapon kezd el valami pittyogni. (Mik ezek: pl.: ellopták (ill. nem érzékelhető a jelenléte) egy munkaállomásnak, vagy bármi másnak, az egyik Rack-ban 50 fok van, stb..) Ezeknél a riasztásoknál fontos, hogy ami pittyog az egy térképen pittyogjon.
Jelenleg, ami meg van valósítva: Van egy helyiség adattábla, egy saját táblára mutató idegen kulccsal fa struktúrába szervezve. Minden helyhez, vagy helyiséghez hozzá lehet rendelni egy térképet (ami egy kép), és/vagy egy koordináta sorozatot, ami pozicionálja a szülőhöz (vagy annak szülőjéhez) rendelt térképen.
És minden eszközöket leíró táblában van egy idegen kulcs a helyek/helyiségek táblára, ennyi. Ebből lehet tudni, melyik térképet kell előkapni, és azon hol van az eszköz.
A LanView2-nek jelenleg nincs felhasználói felülete, mert még hozzá sem kezdett senki, ill. a karbantartó program el lett kezdve. Aminek ilyenje van az az IndAlarm és mint írtam az zárt. Ami ebből megvan a LanView2-ben, az az adatbázis, az import-al fel lehet tölteni ezt is, és a karbantartó GUI-ban ennek karbantartása az egyedüli dolog ami készen van.
Egyébként én a fizikai topológián azt értettem (ahogy ezt már máshol kifejtettem), hogy nem csak azt írjuk le ami lekérdezhető, tehát hogyan kapcsolódnak az aktív eszközök, hanem minden fizikai, nem aktív eszköz kapcsolatát is (patch panel, patch kábel, fali csatlakozók). A fizikai topológia estén persze egy jó csicsázási lehetőség, ha ezt egy térképen is meg lehet jeleníteni.

Igen, a zabbix "csak" egy monitorozó, és az egyik legsokoldalúbb, de egyben a legszarabb is ami talán létezik.

Olvastam a "blogod".. és meg tudom érteni azokat akik nem vetettek rá egy pillantást sem, ugyanis már az alapokkal baj van.

Egyrészt az adatbázis szinten érdekességek lehetnek, ha egy fejlesztő az "örökléssel" jön.. főleg, ha piaci célod van,
ahol nem jó, ha bonyolult, specifikált az adatbázis, mert akkor leragadhatsz egynél, főleg, ha nincs elég fejlesztői kapacitásod.

Másrészt a Qt, meg egyáltalán a GUI elég meredek.. ha valamiben érdemes lenne GUI-t csinálni hozzá az Java.. de egyébként manapság azért
már elég sok mindent meg lehet csinálni web-es felületen.

Harmadrészt, szerintem egy már jól megírt monitorozó szoftvert kellett volna kiegészítened saját fejlesztéssel ( ha jól értettem nem ezt csináltad)
és összekötni valamiképp az egészet egy nyilvántartó rendszer alatt.

Bocs, de szerintem ezt az egészet az alapoktól kellene elkezdeni újratervezni, figyelembe véve az eddigi tapasztalatokat, mert egyébként egy malomkerékbe őrölsz.

Már éppen hiányzott, hogy valaki megmondja a frankót, és tudassa, hol a helyem :I. De félre az iróniával, bizonyára sok igazság van abban amit írsz, de ahhoz hogy kukázzam évek munkáját egy kicsit több kell.
Azt, hogy meg tudod érteni, hogy egy pillantást se vetett senki a rendszerre, abban én érzek egy kis logikai bukfencet. Hogy a pics@ba lehet eldönteni valamiről, hogy érdektelen, ha egy pillantást sem vetünk rá??? Én inkább a következő gondolatot érzem a dolog mögött: "Nehogy már ez a pöcs jobb rendszerrel álljon elő mint a nagy XY cég?! Ráadásul milyen promóció várható ettől, ha az egész ingyen van?" El ne felejtsük kérem, hogy ez itt közszféra.
Azt, hogy az adatbázisban milyen problémákat okozott az öröklés, azt tudom. Az is igaz, hogy hozzáláncoltam egy konkrét adatbázis kezelőhöz a rendszert. Ezek ha úgy tetszik hibák, de nem hinném hogy az ördögtől valóak. Valószínűleg elestem a lehetőségtől, hogy én írjam meg a világ első tökéletes rendszerét. Jelenleg az elölről kezdés többet árt megítélésem szerint, mintha együtt élek a tervezési hibákkal.
Nem látom be, hogy mi a meredek a Qt GUI-ban. Az ebben megírt program futtatható minden lényeges platformon, a karbantartó program lenne abban megírva, azt meg nem kell akárhonnan elérni. A web-es felület mag a java egy nagyon divatos dolog. Én azért még számítok rá, hogy egy pár évig nem hal ki a PC, legalábbis a hálózatadminisztrátoroknak még jó darabig lesz olyanjuk. A döntés hátterében az áll, hogy Qt GUI-ban meg tudom írni a karbantartó progit, web-es tökmindegy miben meg nem. Azonnal dobom a kukába az egész GUI-izémet, ha valaki jelentkezik és megcsinálja divatosan.
Harmadrészt én is jó sokáig abban gondolkoztam, hogy egy jól működő monitorozó rendszert egészítek ki a vacakjaimmal. De arra jutottam, hogy jobb, ha csak ötleteket veszek ezektől a rendszerektől, és lehetővé teszem a pluginek használatát. Egyetlen dolgon lenne igazán jó pl. a nagios ütemezője, cserébe igazodnom kellene egy merőben más alapokon nyugvó, más szempontok alapján megtervezett, rendszerhez, és máris meg lenne oldva a gondok mondjuk 5%-a. Melyik monitorozó rendszer segít a nyilvántartási részben, csak mert ez a nagyobbik darab. A jóval bővebb adatbázis következtében keletkező új lehetőségek kihasználásában sem hiszem hogy bármelyik kész rendszer segítene bármit is.

Sorry, nem akartalak megsérteni, mert becsülöm, ha valaki X évet foglalkozik valamivel és kitartó.
No és hogy, hogy a picsába lehet eldönteni? XX év fejlesztési tapasztalata alapján, azért sokaknak van szimatuk..

Nem is azt mondtam, hogy kukázni kell a munkád, hanem azt, hogy át kell nézni/tervezni ami rossz benne.
Te is elismerted az adatbázis egy ilyen pont és hidd el egy rossz tervezésű adatbázissal csak szopás van és gányolás.. hosszabb távon meg kész katasztrófa.
Egyébként is sok rendszerben eleve változik a struktúra az igények és/vagy a fejlesztők fejlődése alapján.
Ebben, ha gondolod, tudok segíteni vagy csak véleményezni a struktúrát.
Akárki is ír Neked esetleg webes felületet a dologhoz, ha van esze ezzel fogja kezdeni és bele sem kezd, ha nem "normális" az adatbázis.

QT GUI.. lehet minden platformon fut, de alapvetően olyanra van elsősorban igény, ami egyszerűen futtatható.. a java sem feltétlenül ilyen.
No és a szemléleted.. nem hal ki a PC tény, de a hely és gép független hálózati és egyéb menedzsment manapság alap.. és ha nem a valós igényeknek megfelelően
fejlesztesz, akkor csak egy nagyon szűk réteget fog érdekelni amit csinálsz.. mint fejlesztési, mint használati szempontból, pedig lenne igény egy normális rendszerre,
mert a Nagios, Cacti, Zabbix és a legtöbb egy nagy szarkupac, amit sokan csak azért használnak, mert nincs más, vagy ami van és jobb (mert azért van ilyen is) abban ezt-azt nem csináltak meg.

Sajnos fejlesztéskor sok esetben nem a jó vagy a rossz közül kell választanunk, hanem a rendelkezésre álló kompromisszumok közül.
Te bizonyára jól látod a problémák egy (szerintem kis) részét.
Ezt most zárjuk le azzal, hogy én talán jobban átlátom a konkrét helyzetet, és jobban el tudom dönteni melyik ujjamat harapjam meg hogy a legkevésbé fájjon.
A gányolásról meg annyit, hogy eddig kevés olyan rendszerrel találkoztam, amiben ne lett volna több kevesebb. Persze nem cél a gányolás, de néha hasznosabb, mint a soha el nem készülő tökéletes rendszer.
Nem vagyok ellensége a web-es fejlesztéseknek, de egyrészt nem nagyon értek hozzá, másrészt nem hiszem, hogy ami nem web-es az egyben halott is.
Érdekes továbbá, hogy a piacon jócskán vannak olyan rendszerek, amik nem web-esek, vagy használják ugyan ezeket a divatos technológiákat, de akárhonnan mégsem érhetőek el.

Hát nem vagy egy szószátyár, szájbarágós fajta :).
Kár hogy ezt a NeDi-t eddig nem ismertem, mert ez van eddig legközelebb ahhoz amit én is szeretnék.
Sok szempontból hasonlít a LanView előző verziójához, igaz annál átgondoltabbnak tűnik, és profibbnak is.
Ha ezt előbb megtalálom lehet, nem kezdek el fejleszteni. Mondjuk annyira azért nem ugyan az, mint az enyém, hogy ejtsem a saját projektemet.

( tompos v | 2011. 11. 30., sze – 14:10 )

Miben mas, mint a mar meglevo versenytarsai?

Hol erheto el rola a demo, amit nem nezett megg senki?

t

Fentebb próbáltam felvázolni néhány funkciót, amiből talán kiderül, hogy miben más (ha más, mert nem ismerem az összes hasonló rendszert).
Demók általában kész rendszerekről készülnek, ennek meg még az előző verziója sem nevezhető késznek. A mi működik, az az éles rendszer. A régit akár mutogatni is lehetne, csakhogy tele van olyan információkkal a hálózatról, amit nem lenne bölcs dolog közkincsé tenni. Az újon meg még mutogatni való is alig van (pgadminnal lehet örömködni, hogy mi minden hasznos dolog van az adatbázisban).
Igazándiból csak a főiskolán belül próbáltam propagálni, van több kar is, de senkit nem érdekelt.

( lzskiss | 2011. 12. 01., cs – 10:02 )

hello.
irj egy privatot, kerlek.

OpenBSD 5.0/i386 theo for the prezident:D

( azin | 2011. 12. 02., p – 22:31 )

A netviz nevű software talán ad további ötleteket. http://www.netviz.co.uk/products/netviz_pro.htm. Ha jól tudom szinte minden nyilvántartható benne. Amit viszont nem sikerült vele sehogy sem megcsinálni az a gyors (rész)topológia generálás, exportálás vagy nyomtatás. Pl. L2-es topológia (vlanok, vtp domainek, stb). Lehet hogy tudja, és csak én nem szántam rá elegendő időt.
Amit majdnem hiánypótlónak éreznék monitorozás terén az a QoS jó monitorozása, amely hierarchikus QoS-t is támogat.:)

Üdv és sok sikert!

( csfeco | 2011. 12. 07., sze – 13:59 )

Nincs egy időmilliomos sem, aki hobbiból GUI, vagy web-es programokat akar írni :)
Ez egy tök jó projekt, lehet hogy egy kicsit unalmas, de alig hurrogták le :)
Egyszóval: UP!