Egy hálózat monitorozó és nyilvántartó rendszer befejezetlen története

 ( csfeco | 2011. november 30., szerda - 12:33 )

Kb. 7 éve elkezdtem írni egy hálózat monitorozó rendszert.
Anno, egy kis IT cégnél dolgoztam, és felhívtak egy főiskolából, hogy szeretnék korszerűsíteni a hálózatukat, és kérnek tőlünk ajánlatot. Nem igazán vettem komolyan a dolgot, mert majd pont tőlünk fognak egy ekkora projektet megrendelni, de azért lett belőle ajánlat, és csodák csodája megrendelés is. Aztán úgy alakult, hogy olcsóbban sikerült a kivitelezés (kiderült, hogy mindenhol megfelelően működik az olcsóbb GBIC) és a fennmaradó pénzből lett egy karbantartási megállapodás. Én meg, ennek keretében összelapátoltam egy monitorozó rendszer szerűséget. Akkor ez még nem volt más mint néhány Linux program: MRTG, arpwatch, meg pár Perl script, meg egy igen puritán weblap.
Aztán tartós lett a kapcsolat, és mivel kedvet kaptam a dologhoz az egészet átírtam egy összefogottabb valamivé LAMP alapon. Eddig gyakorlatilag hobbiból készült az egész, de kiderült, hogy a főnököm szempontjából is van egy hasznos funkciója: képes érzékelni a hálózati eszközök jelenlétét, vagyis ha elvisznek/eltulajdonítanak egy hálózati eszközt akkor jelezhet.
Vagyis erre az ekkor már általam LanView-nek nevezett rendszerre ráépült egy riasztó rendszer (IndAlarm) ami nem az én művem volt, és üzleti alapon készült.
Mivel ez a LanView életem első PHP-s próbálkozása, szinte nulla adatbázis gyakorlattal, voltak hiányosságai. Mint szabad programot közzé akartam tenni, de sosem készült el olyan szinten, hogy más is tudja használni, meg a jogállása is bizonytalan volt (egy részét azért munkaidőben írtam), ezért ebből sosem lett semmi.
Időközbe munkahelyet változtattam, és a fentebb említett főiskolán (ill. most már csak Főiskolai Karon, mert az összevonások során kaptunk egy „gyámot”) vagyok rendszergazda.
Munkám során határozottan hasznosnak tűnt a LanView, de a hiányosságai is egyre bosszantóbbak voltak. Ezért elhatároztam, hogy az egészet újraírom. Hozzá is láttam, és készült is mint a Luca széke, vagy ha pontos akarok lenni sehogy. Próbáltam támogatást szerezni a főnökségtől, mert ha az egész főiskolán és nem csak a karon használnák a programot, akkor talán a fejlesztés is nagyobb lendületet kaphatna, de az okosok látatlanul is tudták, hogy ez egy használhatatlan szar, és nem voltak rá kíváncsiak. Ez persze alaposan „fellelkesített”, és egy jó ideig pihentettem a projektet.
Így évekig a LanView2 projekt nem igazán fejlődött, volt egy jó pár kukázott próbálkozás, meg egy keretrendszer, vagy API szerűség Qt-ben megírva, és halvány elképzelések az adatbázis szerkezetére. Majd jelentkezett valaki (egy HUP-ra feltett kérdés alapján), hogy beszállna a fejlesztésbe, és Ő a felhasználói felületet csinálná Djangó-ba. Az Ő őtlete volt, hogy legyen az adatbázis kezelő Postgresql, és milyen jó, hogy van abban öröklődés. Az ürge persze jó hamar eltűnt, de lett egy többé kevésbé kitalált adatbázis, öröklődéssel, amit valójában egyáltalán nem támogat a Postgresql, csak úgy benne van, de most már bementem a csőbe.
Újabb lendületet adott, az IndAlarm továbbfejlesztése, amit nem akartam a régi rendszerre ráépíteni. Így nyár óta írom mint a mérgezett egér a rendszert. De egyre nyilvánvalóbbá válik, hogy én ezt egyedül nem tudom megcsinálni.
Jelenleg mi készült el:
Van egy adatbázis, ami úgy tűnik szinte minden információt (amire én eddig gondoltam) képes tárolni egy hálózat topológiájáról, és a benne lévő, ill. a kiszolgált eszközökről.
Többé kevésbé le van programozva az adatbázis logika (persze a mérgezett egér stílusú programozás miatt bizonyára tele hibával).
Van egy API szerűség a Qt-ben (C++) megírva. A programrendszernek van zárt része, mégpedig amik IndAlarm-al kapcsolatosak (HW fejlesztés, érzékelők, nem hálózati eszközök pl. monitor védelmére, egy Web-es kezelő felület django-ban).
Van egy nem interaktív import program, ami alapján feltölthető az adatbázis (ez SNMP eszközöknek a konfigurációját le tudja kérdezni).
Van néhány lekérdező daemon:
Egy „fő” daemon, ami a lekérdező daemonokat futtatja (nagyon félkész, minimális funkcionalitással, de működik)
SNMP-n keresztüli port állapot lekérdezések (egyenlőre csak a státuszok lekérdezése).
Az import is képes daemon módban futni, ha például távolról szeretnénk megadni feldolgozandó scriptet az adatbázison keresztül.
Elkezdtem írni egy GUI-s karbantartó programot Qt-ben, de ez igencsak kezdetleges állapotban van. Bár nem nagy kihívás Qt-ben GUI-t írni, de ha meg kel tervezni sok tucat dialógus ablakot, és megírni több száz függvényt, akkor hiába egyszerű, ha sok van, az nagyon sokáig eltart. (A django-s rész is tartalmaz karbantartó részt, de ez nem az én művem, és jócskán hiányos is.)
Szóval most itt tartok. Jó lenne valami GPL szerű licenc alatt közzétenni, de ahhoz el kéne jutni valami alap verzióig, amire egyedül nem sok esélyt látok.

Javítottam a címet, azt hiszem egy kicsit félrevezető volt, amit én próbálok megvalósítani az nem csak monitorozás.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szerintem kezdd teljesen elolrol, tisztazd le, mik azok az alap dolgok, amiket feltetlenul tudnia kell a rendszernek. Ezutan nezz valami alap keretrendszert a dolognak (ehhez persze elobb dontsd el, hogy web vagy gui, en az elobbit ajanlom, kevesbe idorablo), ha PHP, akkor nezd meg a Yii-t es a CodeIgnitert, ha Python, akkor Django. Ezutan epitsd fel darabonkent a modulokat, ne akarj egyszerre egy-ket kepessegnel tobbet fejleszteni, es utana szep lassan be fog indulni az egesz.

Ket dolgot nem szabad csinalni
- ha nincs kedved hozza, akkor is programozni
- egyszerre sokmindent csinalni

Ezek tapasztalatok, nekem a hobbiprojektjeim igy mennek. Es en mar leszoktam a verziozasrol, az elso valoban mukodo verziok azok ilyen 123.2-esek lennenek a sok ujrairas miatt.

Licenc: en altalaban CreativeCommons BY-NC-SA alatt hozok letre mindent, ez majdnem olyan, mint a GPL, csak egyreszt ertem is, hogy mirol szol, masreszt pedig nincsenek benne hulye megkotesek, csak amit valoban szeretnek.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A kezd teljesen elölről dolgon már túl vagyok több mint egy éve. Azokat a dolgokat terveztem bele a rendszerbe, amik az előzőből hiányoztak. És ennek az az eredménye, hogy elég bonyolult lett. Ha több funkcionalitást akarok, mint a meglévő hasonló rendszerek, akkor sajnos nem lesz egyszerű, ha csak ugyanannyit vagy kevesebbet, akkor pedig az egész okafogyott.
Ráadásul, ugyan nem emeltem ki, de a történetből kiderül. Sikeresen csőbe húztam magam a projekttel, ugye rá épül egy termék, így nem dobhatom ki, vagy ebből hozom ki amit lehet, vagy karbantarthatok egy túlbonyolított rendszert ami nem arra lett tervezve amire használják, és pont az a rész hiányzik belőle, amit szívesen csinálnék.
A web vagy GUI kérdésnél engem is meggyőztek, hogy a Webes fejlesztés a jó. És a rá épülő IndAlarm djangóban lett megírva, de eddig úgy tűnik ez hiba volt. A kollégám aki ezt írta hasonló kvalitású programozó mint én ugyanúgy minimális webprogramozási tapasztalattal, nem igazán tudta lekódolni a feladat által megkövetelt logikát. Ebben persze jelentős szerepe volt annak, hogy az adatbázis a djangó korlátainak a figyelembevétele nélkül lett megtervezve, vagy más irányból közelítve az általam kihasznált a progresql-ben meglévő lehetőségekből a django szinte semmit sem támogat.
Mivel a remélt django-s karbantartó rendszerből nem lett semmi (vagy legalábbis nem sok), ezért kezdtem az egészet Qt GUI-ban megcsinálni, mert a rendszer ezen része elég nehezen nélkülözhető.
Nem az a baj, hogy nem csinálom szívesen. Egyszerűen túl sok munka van vele ahhoz, hogy belátható időn belül elkészüljön. Szeretném azt hinni, hogy az eddig befektetett munka ér annyit, hogy ha van szándék, akkor más is hozzátegye a magáét, és hamarabb és többek örömére kikerekedjen valami az egészből.
Ezen túl a munkámhoz is nagyon kellene, ha ez az egész nem csak a fejemben létezne, hanem működne is.

Lehet, hogy a LanView és az IndAlarm viszonya egy kis magyarázatra szorul:
A LanView (mostmár LanView2-nek hívom) egy adatgyűjtő rendszer, ami egyrészt megvalósítaná a nagios és a munin funkcionalitását, de ennél jóval több adatot gyűjt a hálózatról. A működésére vonatkozó információkat, a gyűjtött adatokat adatbázisban tárolja, ill. működése során a hálózat állapota az adatbázisban folyamatosan megjelenik. Ez az a rendszer amit én megakarok csinálni, amihez segítség kéne, és amit szabad szoftverként terjeszteni is lehetne, ha van rá igény.
Az IndAlarm egy rá épülő "modul", ami a LanView által feltöltött adatbázis alapján riasztásokkal zaklatja a diszpécsert, ha az adatok alapján valamit elvittek (pontosabban aminek nem érzékeli a jelenlétét). Ez kiegészül hardver elemekkel, amit szintén a LanView kérdez le, és ami alapján nem hálózati eszközök is megvédhetőek (monitor, projektor). Ez az a program rész, amiben volt főnököm is fantáziát lát (kihangsúlyozva, hogy a LanView őt nem érdekli), és ami persze az ő tulajdonát is képezi, mivel a HW fejlesztést és a IndAlarm Web felületét is ő finanszírozta, ill. íratta meg.

Az a kerdes, hogy db vagy API alapjan kapcsolodik az IndAlarm a LanView-hez. Ha az elobbi, akkor a db szerkezet fix, azzal nem sokat tudsz varialni, de cserebe letisztazhatod egy frameworkben a dolgokat, es elkezdheted a pillanatnyilag hianyzo feature-ket. Legfeljebb parhuzamosan hasznalod a ket rendszert, amig a meglevo rendszert atportolod.

Az sosem jo, ha egy atlathatatlan rendszert kell menedzselni, hibaforras, az pedig mindig veszelyes.

Alternativ megoldas, hogy ha a LanView2 ugyis az elozo fonokode, akkor legyen boldog vele, de uj feature kereseket mar ne fogadj el, reszben mert nem fonokod, reszben pedig ha jol sejtem nincs semmilyen support szerzodes koztetek. A LV3 meg mar lehet akar total untouched projekt is, az IndAlarm meg el lesz magaban, mint a befott, anelkul, hogy neked barmit boknod kene rajta (hiszen azt mar nem te supportalod).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az IndAlarm és az LanView lényegében DB szinten kapcsolódik. Illetve van egy démon, ami használja a LanView API-ját, és az egyedi IndAlarm hardver elemeket kérdezi le. Ezek az elemek készen vannak, és működnek is.
Az általam vélt tulajdonviszonyok: Az IndAlarm volt főnökömé. A LanView vitatható kié, mert részben munkaidőben írtam, minimális támogatottság mellet.
A LanView2-t viszont teljesen önállóan írtam/írom szintén komolyabb támogatás nélkül (hagyják, hogy csináljam, most már mint közalkalmazott).
A dolgok letisztázása az egy jó dolog, de még egyszer mondom, ezen már túl vagyok. Az adatbázis nem azért lett bonyolult, mert elcsesztem (vagy ha mégis, az eddig még nem derült ki :), hanem azért, mert megpróbál egy bonyolult rendszert leképezni. Ha kihagyom azokat a flik-flakkokat ami elbonyolítja, akkor egyszerűen nem lesz alkalmas a jelenleg általam menedzselt hálózat leírására.
A blog megírására nem az késztetett, hogy rájöttem valamit rosszul csinálok (ez is kiderülhet, de ezt majd mások megmondják :), hanem az, hogy túl nagy fába vágtam a fejszémet, és ehhez egyedül kevés vagyok. Valamint az a (talán tév)hit, hogy egy ilyen eszközre másnak is szüksége lehet.
Lásd a fórum témát is: http://hup.hu/node/109293 , ha rossz ötlet volt ketté osztani az egészet, akkor bocs, nem akartam a fórumba tenni egy túl hosszú lére eresztett írást.

A tulajdoni hatter egy dolog, itt inkabb az a kerdes, hogy neked mennyire kell supportalnod az IndAlarm-ot (irod, hogy nem akarod eltorni a kompatibilitast).

En azt mondom, tord el nyugodtan. Mivel a LanView elso verzioja fixen mukodik, azzal gond nincs. A LanView2-vel meg gyakorlatilag azt csinalsz amit akarsz.

Amit a forumban is felvazoltak: erdemes lenne elvinni a dolgot valamilyen osszekapcsolodasi iranyba, peldaul Nagios-sal, Cacti-val valo kommunikacio fele. Ekkor egy jo nagy programresz menedzsmentje lekerulne a valladrol, hiszen gyakorlatilag iparagi szabvanyokkal dolgoztatnal. Igy raadasul eleg lenne csak azokra a reszekre koncentralni, amiben a projekt tobb ezeknel a szoftvereknel - ez kevesebb munkaval jar, es kezelhetobb mennyisegu feladatot general.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Akkor most elszámolok tízig ...
Végül is az, hogy én értem amit itt összehordtam, az még nem jelenti azt, hogy valóban érthető :(.
Javítottam a címet is, hátha ez is előbbre visz.
Nem abban rejlik a rendszer bonyolultsága, hogy újra implementálok olyan dolgokat, amiket már mások kicsit máshogy megtettek. Ezeknek a részeknek az újra implementálását részben az előző rendszerben is megtettem, nem egy nagy durranás. Egyetlen egy dolog van, amit egyenlőre nem tudom, hogy hogyan csináljak és kéne a nagios-ból, az az ütemezés. De szerintem ez sem olyan kardinális kérdés, hogy ennek érdekében szétrúgjam minimum egy éves (igaz, nem túl tempós) munkámat, mint tyúk a töreket.
A rendszer igazi erőssége az, hogy egybegyúrja a nyilvántartást, ás a monitorozást, ezzel bővítve a monitorozható, és monitorozni érdemes dolgok körét is. És a nyilvántartási rész is a probléma, és igazán nem is a bonyolultsága miatt, hanem a munkaigényesség okán.
Ha én egy (egyszerűbb) objektum nyilvántartásához a GUI adott részét minimum egy hét alatt szülöm meg (nincs tesztelve, csak első ránézésre ok), akkor az objektumok számából már adódik egy igen kellemetlen előrejelzés arra, hogy ez mikorra lesz kész, ha egyedül csinálom. És ez csak a GUI, ami ráadásul nem igazán a szívem csücske.
Ráadásul, ha az IndAlarm-al elrontom a kompatibilitást, akkor vagy ahhoz is kell egy karbantartó programot írni, vagy nagyon kicseszek az üzemeltetővel, vagyis saját magammal. Egyébként volt főnököm sem igazán képes megérteni, hogy kirúgni az IndAlarm segge alól a sámlit (a lamView(1/2)-t) az nem jó ötlet, sőt az sem jó ha nem rakjuk alá.

(Nem tartozik ide, de nehogy ez is összezavarjon valakit. Volt főnökömmel jó a kapcsolatom, néhány projektje megvalósításában rész is veszek. Az, hogy nem támogatja minden ötletemet, az az ő dolga.)

Ahh... most mar ertem a problemat.

Azt nem tudtam, hogy te is hasznalod az IndAlarmot, en azt hittem, hogy az csak az elozo melohelyeden van hasznalatban, tekintve, hogy az az o fejlesztesuk volt, nem a tied.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

huh. nincs ez egy kicsit tulbonyolitva??
en is fejlesztgetek kb 10 eve egy hasonlot, mar a 3. verzional tart de elesben megy egy egyetemen es par nagyobb cegnel is. meg ilyen lopasgatlo szeruseg is van benne, ami eszreveszi ha a WoL-os PC-k (amik kikapcsolva is fenntartjak az ethernet linket) eltunnek a halozatrol es sms-ben riaszt.
az eredeti celja a fejelsztesemnek egyebkent az volt, hogy ha uj eszkozt kapcsolnak a halozatra azt azonnal eszrevegyuk, es emellett automatikusan korlatozva legyen a hozzaferese a halozathoz (pl. sajat laptopok stb).

de az egesz cucc par bash/python scriptbol es filerendszeren tarolt text file-okkkal megoldhato volt, es van egy egyszeru cgi alapu webfelulet is hozza.

nekem ez az oroklodeses adatbazis meg Qt stb enyhen atommal verebre esetnek tunik.

A'rpi

Igaz a rendszer eléggé bonyolultra sikeredett. De ebből még nem feltétlenül következik, hogy el van bonyolítva. Az persze lehet, hogy sokat markoltam.
Ha a te rendszered ugyan azt valósítja meg, amit én próbálok, akkor zseniálisan egyszerű, ha nem, akkor csak egyszerűbb rendszer egyszerűbb célokkal.
Fogalmam sincs hol lehetne lényegesen egyszerűsíteni anélkül, hogy általam fontosnak vélt funkciókról nem kellene lemondani. Szerintem szöveg fájlok helyett adatbázis használata elkerülhetetlen egy bizonyos méret fölött.
Az előző verzió jóval egyszerűbb volt. Ott nem foglalkoztam csak a logikai topológiával, de egyre kevésné tetszik a hiányos, papír alapú, vagy execel táblában meglévő kábelezési dokumentáció (ebből egyébként annyi már megvan, hogy az importtal felvihetők az adatok, automatikusan előáll a felvitt fizikai topológiából levezethető logikai topológia, meg néhány apróság, de kéne valami megjelenítés, és szerkesztési lehetőség sem ártana).
A LanView (az előző) volt életem első adatbázisos projektje (nem ezt tanultam, bár régóta vagyok a szakmában, és sikeresen kerültem az adatbázis témát) így nem korlátoztak a konvenciók :). Akkor olyan adatbázist terveztem, ami ugyan relációs volt, de nem voltak benne ID-k, hanem helyette nevek, így kiválóan lehetett a phpmyadmin-nal karbantartani, és nem kellet ágyúval verébre lődözni. Ezt a "technikát" nem akartam alkalmazni, mert nagyon csúnya dolog. De egy klasszikus relációs adatbázist mivel lehet karbantartani? Az általános adatbázis adminisztrátor programokkal ez elég kényelmetlen.

> Ha a te rendszered ugyan azt valósítja meg, amit én próbálok, akkor zseniálisan egyszerű, ha nem, akkor csak egyszerűbb rendszer egyszerűbb célokkal.

Sajnos a fenti leirasodbol szamomra legalabbis nem derult ki igazan, hogy a te rendszered pontosan mit es hogyan csinal, inkabb csak, hogy azt hogy valositottad meg. Jo lenne egy leiras illetve inkabb feature list, hogy mit tud, milyen inputok es milyen outputok vannak.

Adatbazissal egyetertek, tenyleg jo lenne migralni ra, de mivel eleinte bash-ban fejlesztettem eleg korulmenyes lett volna sql-t bizgetni, es meg ma is a fel rendszer shell scriptebol all.

Adatbaziskezelos kerdesed passz, en is sikeresen elkerultem eddig az adatbazisokat a sajat projektjeimben :)

A'rpi