Rendszer/hálózat üzemeltetés - Milyen monitoring rendszer legyen?

Hálózati eszközök

Sziasztok!

 

Régóta rágodom, de lassan lépni kellene valamit NMS ügyben. Jelenleg Observium CE-t használok, de kezdem kinőni. Teljesen jó, áttekinthető.

Voltam egyszer egy online képzésen, ahol beszéltek egy olyan rendszerről, aminek sajnos nem emlékszem a nevére. Elvileg olyat tudott, hogy rácsatlakoztatom a hálózat egy vagy több pontjára, ahol a switchportot monitor/mirror módba rakom és az átfutó adatok alapján képes elemezni a hálózati forgalmat. Így pl. kideríthető egy php kérésnél, hogy az IIS szerver válaszol lassan, vagy az adatbázis lassú. Illetve forgalmak mennyiségét, típusát, csomó mindent lát és elemez. Nem mlékszem a nevére.

Lenne egy olyan igényem is, hogy van néhány aktív hálózati elemem. Nagyjából 90 switch és olyan 10 router. Jó lenne, ha az snmp write communityt is tudnám használni. Ha tehát valahol látom a használatban lévő portokat, akkor azt tudjam már minimum letiltani vagy felengedni de ha további lehetőségek is lennének pl. portsec vagy vlanok, trönkök kezelése az nagyon jó lenne. (hogy ne kelljen emiatt egyesével az eszközökre bejelentkezni) Tehát lényegében központosítot managementre használnám, rw módban mert az Observium az csak Read-only.

A nagyságrend miatt: Hozzávetőleg 400 Ip-telefonom van, 1200 munkaállomás, 20-25 szerver (néhány linux, nagyobb része win.), kb. 50-60 nyomtató. Kb. 10-15 VLAN és nagyjából 10 telephely.

Icingát nézegettem, de kicsit idegen a felület nekem. Nagiost, Zabbixet nézegettem még, de nem tudom, hogy létezik-e olyan rendszer egyáltalán ami tudja egyben azokat a képességeket, amikre szükségem lenne. "Természetesen" free verzió kéne, mert az infrastruktúra üzemeltetés nem egy jól eladható folyamat a cégen belül.

( junior013 | 2023. 06. 15., cs – 14:42 )

Az Icinga, Nagios, Zabbix trióból szerintem messze a Zabbix a leghasználhatóbb és -felhasználóbarátabb, de az általad vázolt igényekhez szerintem mindegyik hiányos. (forgalom elemzést és SNMP rw management-et nem tudnak - tudtommal)

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Nem akartam nagyon rémisztgetni. Láttam olyan Nagios clustert amiben több ezer host és 100k service volt. Volt hozzá valami nagconf forkja a cégnek, amit még évekkel korábban csináltak a saját igényeikre alakítva. Na ott az percekbe telt mire a keresővel megtaláltad a hostot amit keresni akartál.

Aláírás _Franko_ miatt törölve.
neut @

Azért nem egészen. A Zabbix 1 évvel idősebb mint a Nagios. Bár ha a Netsainttől nézzük (én amúgy még azzal kezdtem, te jó ég, de rég volt...), akkor 2 évvel fiatalabb. De lényegében mindegyik esetben 20+ éves matuzsálemekről beszélünk, szóval nincs ennek nagy jelentősége.

Köszi, ezt nem tudtam. Aszittem, a Zabbix valami 10 éves termék, nasgios meg ősidők óta nagios (3.x)
Mondjuk mindigis nagiost használtam (auztán mostanában icinga2), azért leeht, hoyg a zabbix ennyire kimaradt.
(és minden rendszeren "nagios-plugins" a neve, szóval nagios csomag a plugins, icinga2-nél is)

http://www.micros~1
Rekurzió: lásd rekurzió.

Van némi különbség a kettőben, de én őszintén szólva nem látom az eget rengető koncepcionális különbséget egy normálisan összerakott hostgroup/servicegroupos nagios kialakításhoz képest (és épp emiatt, a sorok száma nem is olyan izgi imho fentebb sem)

Ha arra akarod kihegyezni, hogy ahhoz csak 24 sor konfig kell, az meg teljesen fals, egyszerűen a zabbix a dbben tartja az ilyen típusú konfigját.

Szerintem jelentősen eltérő koncepció, mert nem csak abból áll, hogy máshol/máshogy tárolja. Nyilván a gui-n klikkelgetve is te hozod létre kinfigot, de a háttérben levő automatizmusok miatt (templatek, host level/item level discovery, stb..) azért mégsem annyi eltérésről van csak szó, hogy ki szeret jobban klikkelni meg ki gépelni. Az utólagos (akár tömeges) módosításokról, kereshetőségről meg ne is beszéljünk. Természetesen lehet a config fileokat is mindenféle toolal, scripttel generálni/managelni akár db-be tenni, csak akkor az már adminisztrációs overhead, külső eszköz bevonását, karbantartását jelenti, amire Zabbix esetén nincs szükség.

Arra gondoltam, hogy szerkezetileg kb ugyanazt kell összerakni. Ha a nagios jól van csinálva, akkor nagyon hasonló szerkezetben dolgozol, mint a templatekkel. Vannak service groupok, azokba szépen összeszeded, hogy mit akarsz figyelni, ráaggatod a hostgroupokra, meg a notificationokre. Így kb minden egy helyen van meg. Természetesen tök jó a zabbix, (nyilván a nagios alap webfelületét hagyjuk is), kényelmes, tök jó, ad struktúrát, ezért nehezebb elbaszni, mint a nagiost, ahol sokkal szabadabb kezed van. Meg alapból vannak grafikonok és dasboardok. És persze segít is. Bár ezek egy része olyan, ami a saját hiányosságait kerülgeti tulajdonképp, a bulk change legtöbbször nem is kéne, mint mondtam (használtunk egyszer egy nagiosra épített terméket, amikor már nem volt jó a többi shortcommingja a simának, ott pl kimaradt az ilyen groupozás, a bulk change utána sajtreszelő érzés :) ). De igen, az tök jó, hogy van készen egy rakat template,  nem neked kell összerakni. A discvery is, bár azt esete válogatja, én többnyire olyan helyen dolgoztam, ahol tudtuk mit teszünk le, és abban mi van, meg egyébként is volt valami deployment processz, szóval nem hiányzott, cserébe értem, hogy random ITn, ahol hoznak még valami lófaszt megint, ott nagy könnyebbség, hogy rátolod a discoveryt, aztán gyorsan kapsz vmi dashboardot.

De ettől még alapjaiban az, amit a konfigba kell tenni/tárolni, az kb ugyanaz a koncepció. Igen, a zabbix segít adott esetben gyorsabban összerakni.

( _ventura_ v | 2023. 06. 15., cs – 14:44 )

Természetesen" free verzió kéne, 

Plusz a  fenti igényeket figyelembe véve 5ös lottó esélyesebb. :D

Fedora 38, Thinkpad x280

Nem értek egyet. Az első HSZ az Icinga Nagios Zabbix triót említi. Mivel mindegyikben lehet egyedi metrikákat definiálni, grafikonozni, riasztani, így bármelyikkel bármi megoldható. És mindhárom ingyenes.
Kérdés, hogy rendszerenként milyen meredek letőn indul a szopóroller (amin nincsen fék, mint az köztudott).
Az pedig nyilván a helyi sajátosságoktól függ.
Nincs abszulút jobb és rosszabb. A követelményrendszer és az egyes eszközök képességrendszerének mátrixa van. :)

"A megoldásra kell koncentrálni nem a problémára."

( Ozvego | 2023. 06. 15., cs – 15:30 )

Esetleg cacti? Bár azért a zabbix kiforttabb

Cacti-nál mára minden kiforrottabb.

Pl. LibreNMS-től kapok 3 értesítést, hogy egy eszköz elérhetetlen, majd újra elérhető (mondjuk 1+ percig esett csak ki alkalmanként), miközben a Cacti nem veszi észre egyszer sem, hogy kiesett kis időre az eszköz - úgy, hogy mindkettő jól van konfigolva és mindkettő 1 perces PING poll time-ot tart az elérhetőség figyelésre (minden mást 5 perces poll time-mal gyűjtenek).

( godot v | 2023. 06. 15., cs – 15:35 )

Szerkesztve: 2023. 06. 15., cs – 15:35

Ha kifejejezetten hálózati eszközökre kell akkor az Observium(vagy Librenms) után az autodiscovery fájóan fog hiányozni...

Erre érdemes ránézni.

https://www.opennms.com/opennms-feature-list/

Mondjuk egy monster, és nem állítom, hogy doktori disszertáció nélkül be lehet állítani az open source verzióját,de elég sokat tud, ettől függtelenül én nem ajánlom ezért, de hátha megtetszik :)

Hát, a Zabbix elég jó autodiscovery-ben, és messze nincs olyan teljesítmény igénye, mint a tisztán PHP-ben írt LibreNMS-nek.

Utóbbival monitorozunk egy ügyfélnél ~2100 db hálózati eszközt, és 3 combosabb VM kell distributed polling üzemmódban (mindegyik 50-70% folyamatos CPU terheléssel), hogy minden eszköz beleférjen az 5 perces poll time-ba... Maga a szoftver (LibreNMS) egyébként szuper, de az összes általuk ajánlott (és más által kitalált) optimaliálást használva is óriási teljesítmény igénye van, ha sok a monitorozott eszköz.

A Zabbix ezzel szemben sokkal barátibban áll az általa igényelt erőforrásokhoz. Sajna jelenleg sem kapacitás sem pénz nincs lecserélni a LibreNMS-t (amit elsősorban emiatt kellene cserélni, egyébként tökéletes arra, amire használják).

Ez nagyon karcsú:

https://www.zabbix.com/documentation/current/en/manual/config/templates…

Ehhez képest:

https://docs.librenms.org/Support/Features/#supported-vendors

 

Egyébként a 100G-s interfészek korában az 5 perces poll time önmagában vicc kategória. Ráadásul hiába kérdeznéd le gyarkabban, néhány (gagyi) switch internally sem frissíti az snmp adatokat. Futottam már bele olyanba, hogy 10mp-ként akartunk lekérdezni (csak bizonyos interfészeket) és kiderült hogy ugyanazat az adatot adja vissza 30mp-ig :)

És úgy általában is az SNMP maga egy kataszrófa, sajnos hálózati eszköökre nem nagyon van jobb.

Bár Cumulus whitebox switchen futtattam már prometheus node_exportert.

És úgy általában is az SNMP maga egy kataszrófa, sajnos hálózati eszköökre nem nagyon van jobb.

This, bár őszintén szólva kb minden monitoringra használt protokoll/megoldás valahogy elég fos.

De az snmp v3 kedvencem, rájöttek, hogy az auth* egy rakás fos a v2c-ben, és hosszas gondolkozással oda jutottak, hogy egy szinte kizárólag M2M használt protokollban legyen az authentikáció user/pass :D 

 Sajna jelenleg sem kapacitás sem pénz nincs lecserélni a LibreNMS-t (amit elsősorban emiatt kellene cserélni, egyébként tökéletes arra, amire használják).

És 2000+ végpontnál akkora katasztrófa három VM, hogy érdemes legyen gondolkozni a cserén? Lecseréled mondjuk két feleakkorára, sok sok engineering óráért, hogy nyerj egy kis vasat? 

Szerintem több HW is elfogyhatna ekkora rendszer monitorozására, az sem lenne igazán sok/felesleges, de ez a magyar vidéki valóságban nem ilyen egyszerű... Jött az igény, hogy csökkentsük a szerverek fogyasztását, mert a villanyár elszabadulásával 70 ezerről 380 ezerre ment fel a számla a szerveres helyszín esetében (igazából tényleg sok, mert ez egy kis lokális wireless ISP, és sok helyen fogyasztanak összesen sok áramot, ami a hirtelen többszörösére nőtt kWh árakkal durva fizetendő számokat eredményezett), és a csökkentés után megmaradt fogyasztásban már jelentős tétel a LibreNMS generálta terhelés. Mondjuk objektíven már nem lenne érezhetően kevesebb a fizetendő, ha még 50-100W-tal kevesebb villany fogyna.

Ez persze nevetséges informatikai szemmel nézve, de a cégvezető a fizetendő számlákat nézi elsősorban.

Bocs, ezt elfejetettem lereagálni.

Nem, ez egy tök valid érv, imho egyáltalán nem nevetséges. Mi is töltöttünk ilyesmivel időt (igaz, végül nem kellett, gondolom majd novemberben újra műsorra tűzzük). Az más kérdés, hogy imho önmagában az ilyen centrál rendszerek cseréjére fogyasztás miatt ráfókuszálni szinte biztosan nem fogja kiadni a matekot a mérnökórához képest, ahogy te is írod. Iszonyú komplex, cserébe nincs sok gain, sokkal jobban megéri kitalálni, hogy kell a tömegében jelenlevő leafeken optimalizálni.

Ez gondolom havi 70 -> 380, szorozd fel gyorsan 12-vel és gondolj bele, hogy ezt ki kell termelni, és te is szeretnél fizuemelést, akár csak 5%-ot...

Ismerve az anno újonnan leszállított szerverek általános konfigját simán lehet jelenleg már fillérekből átépíteni, amivel jelentős áramdíj spórolható, különösen akkor, hogy ha több gépet lehet mondjuk úgy revitalizálni.

Én teljesen átéreztem a dologot. Sőt, én régebben is mondtam már bizonyos cserék létjogosultságát, de akkor nem volt fontos.

A hirtelen áram ár emelkedés azonnal szükségessé tette néhány régebbi szerver cseréjét a fogyasztás okán (addig ugye nagyjából nem számított ez). Így kikerült 3 db, egyenként kettő darab 1 magos Xeon használó kövület (a rajta futó ősi, de le nem cserélhető rendszereken virtualizálás áldozatai lettek), így kapásból 1 kW-tal csökkent a fogyasztás és a klímaberendezés is jobban érzi magát. Aztán a mellettük lévő két R710 helyére jött két R720, az elérhető legalacsonyabb 60W-os TDP-jű CPU-kkal, ami további átlagosan 200W spórolást eredményezett. Így az összes többi hálózati elemmel együtt mért fogyasztás kb. a harmadára esett vissza.

A további fejlesztési megjegyzésem arra vonatkozott, hogy ha a LibreNMS VM-ek által igényelt teljesítményt ki tudnám venni a képből (mondjuk Zabbix-ra váltással, ami nagyságrendekkel spórolósabb a CPU-n), akkor további 50-100W spórolható lenne, de ez nem áll arányban azzal a munka mennyiséggel (és ennek árával), ami a 2000+ eszközös LibreNMS rendszer Zabbix-ra cserélése kívánna.

A két L-es CPU helyett, egy darab erősebb jobb választás, mert a 2 cpu alapfogyasztása még több is lehet, mint egy picit erősebb normál CPU. A másik dolog, hogy törekedni kell a minnél hatékonybab tápokra, és nem túlméretezni. HP-nál lepődtünk meg, biztosan nem a hatásfokon nyertünk csak a tápcserével 30W-ot... Abba se vagyok biztos, hogy a két régi gépből nem lehetne egy újat csinálni, hacsak nincs cluster jelleg vagy tartalékolás.

50-100W-ért önmagában nem biztos, hogy megéri teperni, az igaz.

A két L-es CPU helyett, egy darab erősebb jobb választás, mert a 2 cpu alapfogyasztása még több is lehet, mint egy picit erősebb normál CPU.

 

Mindez addig igaz, ameddig nincs szükséged sok ramra. 2CPU arra kell, hogy az összes bankot tudja használni, nem csak 1-et.

Aláírás _Franko_ miatt törölve.
neut @

Szerk: Ahol kraft kell, ott nem az L-es CPU-ra lőnek, és már rég nem a belépőfronton vannak.

Már egy 10 éves szerver is 4 csatornás RAM vezérlővel bírt, jellemzően 8 vagy akár 12 slot per foglalattal. Teszemazt azt egy 2x 2620/2630 -as régi gyári konfigot (v1 > v4) szerinted nem lehet kiváltani, persze ha engedi a terhelés (bár még családon belül is létezik olyan, ami mindkettőt kiválthatja), de azért látom, hogy hány szerver megy kb. üresjáratban, 1x 2680-nal mondjuk, és 4x 16G vagy akár 8x 16GB RAM-mal...

Jellemző tapasztalat, hogy a 90-130W-os alapjárati fogyasztás olyan 60W-70W-ra tornázható le, és a a csúcsfogyasztás is csökken valamennyit, de ha esetleg. 2x 80W TDP helyett lesz 1x 110-130W-od, és HP szerver esetén még ventik is elhagyhatóak a nemhasznált CPU socketből.

A 2620/2630-as CPU-kat a gyári konfigokhoz szórták régen, ezért ezt hoztam példának. Jelenleg pedig használtan tényleg olcsón megvehetőek az erősebb (és még a RAM sebesség is jóval nagyobb...) 2660/2667/2680/2690-es darabok, szintén v1-től v4-ig nézve. E mellett jellemzően tudsz mondjuk v1-ről v2-re gyorsítani, vagy v3-ról v4-re.

A másik kedvencem, hogy szórták veszettül a 750W-os gold hatásfokú tápokat, esetleg a 460-asat (más gyártónál az ehhez hasonló teljesítményűt), viszont 460W-500W-osból már létezett platinás hatásfok. Egyrészt jóval közelebb lesz a működési tartomány az optimumhoz, másrészt valami egyéb történet is van, mert találtunk már 30W-ot a goldról platinásra váltással.

Ahol nagyon kell a kraft, ott már valszin rég váltottak újabb szerverre... :)

A HP-nél papíron (és elvben) lehet hotswapként cserélni, de nem voltunk ilyen bátrak, meg nem is érdemes kísérteni, hogy reseteljen, meg pánikoljon az ILO. G8-as szervernél volt a semmiből jött 30W-unk egyébként. Ilyen kis apróságokból (második CPU elfelejtés included) 250-300W-ot szedtünk össze. Ez nekünk jelen árakon 330k nettó évente, és nem mellesleg kitettség csökkentő hatású.

Másutt egyszerűen a HDD > SSD és újabb szervereken (dual cpu és sokram... :), kevesebb vas lett végülis ) fogott meg havi 1 MWh-t (nem elírás, 1 000 kWh, épp az előző héten jöttek meg a számok). Az igazsághoz hozzátartozik, hogy szerencsésen összeért egy fejlesztési ciklus a villanyszámla parával, és tudtunk annak megfelelően reagálni. Ugyanitt 4-6db G7-es eléggé full kiépítésű HP szerver eladó. :)

( ggallo | 2023. 06. 15., cs – 15:47 )

Elsőként a "lehetőleg ingyen"-re reagálnék: szerintem nagy butaság "szabadidőben" kitanulni és megvalósítani egy komplett monitorozó rendszert egy ekkora cég, ekkora hálózatára. Aztán vállalni is érte a felelősséget. Mert ugye ha már monitorozunk, és valamiről nem úgy vagy nem időben szól, akkor már a Te felelősséged. Amíg nem monitorozunk, addig a főnök baja, hogy miért nem vett monitorozó rendszert.
Ha 5-10 fős kis cégről beszélnénk, meg nagyon érdekel a téma, akkor még talán oké az ingyen munka. De ahol 1200 munkaállomás van, az eléggé tőkeerős, hogy kifizessen egy normális rendszert. Merthogy ha Te csinálod, akkor jó eséllyel pont annyit kapsz majd érte, mint amibe az ingyenes nyílt forrású szoftver kerül...
Más oldalról Te tudod, hogy akarsz-e ekkora munkát ingyen csinálni nekik...

A monitorozás meg a hálózat központi konfigurálás azért két teljesen külön terület. Vannak szoftverek, amelyek mindkettőt nyújtják, de jellemzően gyártó specifikus, nem univerzális. És fizetős. Legalábbis én még pénzért sem láttam olyan univerzális központi management szoftvert, ami ilyen vezérlési lehetőségeket tartalmazott...

"Univerzális" monitorozásra szerintem jelenleg a legkényelmesebb a Zabbix. Nagyon sok adatot gyűjt alapból, és könnyen bővíthető. Mi kb. 2 éve álltunk át Nagios-ról, amit kb. 15 évig használtunk. Most szerintem jobb a Zabbix (~20 éve jobb volt a Nagios, csak az kb. ott is maradt, ahol akkor volt). Pláne, ha sok az SNMP eszköz.

Az alkalmazás teljesítmény mérés és elemzés megint egy más terület, oda meg jobbak a time series adatbázisok (InfluxDB, Prometheus a két legismertebb), és azokra lehet saját (pl. Grafana) dashboard-ot összerakni, amin majd látható (ha jó a dashboard), hogy valószínű mi okozza a lassulást.

Alapvetően azért csináltam annó az Observiumot is, mert amikor megállt valami a hálózaton, akkor mindig ment a vakarózás hogy mivan. Így viszont rengeteg időt és energiát megspórolok. Syslog szerverként is üzemel. Ennek az adminisztrációjára külön ember kellene mert azért mozognak a cuccok a hálózaton néha. :) Sőt, a topolomógia naprakészen tartása, mindenféle dokumentáció is külön embert igényelne. Ez állami cég. Ide nemhogy jönnek, hanem inkább mennek el az emberek. Szóval jah... most nem a legoptimálisabb a helyzet.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

+1 a zabbixra es, hogy a monitoring meg az eszkozok konfigja/managementje - foleg nem homogen infraban - kulon dolog.

Nem kell ezt amugy tulspilazni, le kell szepen irni, hogy 0 koltsegraforditas (eszkoz, szoftver, kepzes, HR...) == 0 preemptiv monitoring/automatization, aka: kis penz, kis foci. :(
Majd a vezetoseg eldonti, hogy neki mekkora kieses mennyit er es mennyit szan arra, hogy ez mitigalva legyen, onnan meg lehet kalkulalni abbol mit lehet kihozni.

Szoval hatradolsz, olvasod a hupot, aztan ha valahol megall valakinek valamije, azok meg addig olvashatjak nepsportot vagy mi az, amire volt penz megvenni amig kiderititek mi volt es megoldjatok :D

( msandor v | 2023. 06. 15., cs – 15:59 )

"Természetesen" free verzió kéne, mert az infrastruktúra üzemeltetés nem egy jól eladható folyamat a cégen belül.

Én a helyedben kipróbálnám a zabbixot, ha van legalább egy dockert futtató géped, akkor pár perc alatt meg is lehet csinálni, minden szükséges infó fent van a docker hubon.

Viszont, ha ennyire nehéz "eladni", akkor ne is mond el, csak csináld meg a magad kedvéért. Bőven elég, ha neked küld értesítéseket a problémákról.

Amikor csináljuk az éves DR tesztet, a zabbix az első, amit bebikázok, mert anélkül vakon repülök :-)

A képességei töredékét használom, de a 15 év alatt még nem csalódtam benne.

( PunishR v | 2023. 06. 15., cs – 17:19 )

Szerintem az ntopng-t lattad, de vannak egyeb alternativak is.

( fairlane | 2023. 06. 15., cs – 17:57 )

Amit láthattál az valószínűleg egy NPB (Network Packet Broker) és egy NPM (Network Performance Management) megoldás lehetett.
Egyszerűen leírva: az NPB eszközök felelnek a hálózati csomagok tükrözéséért és az NPM-hez való eljuttatásukért, az NPM pedig ebből számol mindenféle szép dolgokat, grafikonokat mutat, stb.

Az áruk elég magas, de van ahol egy perc kiesés többe kerül, mint az egész rendszer.

Az snmp write community használatát a végső esetre tartanám, előtte megvizsgálnám, hogy lehet-e máshogy programozni az eszközöket (ssh, api).
Nem lehetetlen, de egy ansible használatával sok dolgot lehet automatizálni.

A többit meg a többiek leírták. :)

...úgyis jönnek...

( Adamyno | 2023. 06. 15., cs – 19:38 )

Sok plusz infót adtatok most. SNNP write csak azért jutott eszembe, mert vannak macerás dolgok. Csináltam egy táblázatot excelben, amiben benne vannak soronként a switchportok és minden porton látható a description, a megnevezése, port státusza(az is ha tiltva van), speed, Duplex, vlan (vagy ha trönk módban van), portsecurity státusza (mennyi az engedélyezett/megtanult cím, portsec tiltva van vagy sem, illetve engedélyezve van-e a porton a portsec). Ezeknek a paramétereknek a nagy részét snmp write paranccsal írni is lehet + menteni a running configot az eszközben. Ezek mellé pedig felírható a fali port száma, átkérő ha van, user neve, mac address, megjegyzés mező. Ezek már opcionális adatok. Ez sokat segít, mert 1-1 eszköz gyorsan áttekinthető, illetve adott esetben egy végpont teljes nyomvonala a switchportig. Ha valami nem volt jó, akkor a kollégák mindig hivogattak, ezért fejlesztettem le a write részét mert egy Cisco eszköznek adott esetben a webes felülete ha van is, nem sokat ér. Konzolhoz nem igazán értenek, viszont ha eléjük teszem a gombokat és a fontosabb funkciókat, akkor elboldogulnak nagyjából 1 hét után.

A problema az, hogy eszközönként változnak az oid-ek és elég melós mindent lefejeszteni. Pl egy 9200-as sorozatú switchnek már sok oid-je különböző pl egy 3650-hez képest. És akkor nem beszéltünk arról, hogy akad néhány HP, 3com, mikrotik, stb.. a hálózat soha nem lesz teljesen homológ. Igazából a fejemben megvan minden. Meg tudnám csinálni, csak semmi időm nincs rá. Jelenleg makró fut mögötte. Már elég sok :) 

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Ugyan brutál üzemben nem csináltam ilyen tisztán hálózatos dolgokat (volt azért olyan, amikor szerintem olyan 50-100 környéki network eszköz is volt a közvetlen üzemeltetésünkben, de sok minden mással együtt, meg még egy fasztudja, ezres másodkézből, még monitoroztuk őket, meg ha kellett, akkor support rugdosta), de én nem nagyon hallottam még olyat az elmúlt sok évben, hogy valaki snmpt használt volna írni. Szarabb esetben expect, vagy valami cli wrapper eszköz vmi config api lib köré, de inkább netconf, meg vmi ansible vagy hasonló.

Igazából úgy jött az ötlet, hogy ha már van, akkor használjuk :D

VÉgülis olvasásra azt használom, akkor kézenfekvő, hogy ugyanott ugyanazt használjam írásra is. Az oid egyezik, nagyjából más követelmény nincs is csak ismerni kell az rw communityt. Eredetileg webes felületre terveztem, de ott csak az olvasás ment. Egyszerűen nem találtam vagy nem működött (már nem emlékszem) az snmp write php alatt. Ilyen mindenféle egyéb scriptek, mint java és hasonlók, nekem már magas. Én csak a C-t és testvéreit értem :D

Valószínűleg ssh-t is lehetne beágyazni több helyre vagy telnettel operálni. Az Ansible bár sokat tud, de szerintem ide pont felesleges, mert + 1 réteg, de alatta/neki ugyanúgy meg kell adni minden egyes paramétert. Nem automatizálni akarok, hanem monitorozni és a felhasználótársaim (rendszergazdák vagy valami ilyesmi) elé tenni egy UI-t, amit tudnak nyomogatni. 

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

 

Ugye állami cég. Kellene ember aki ért hozzá. Nincs, mert nem fizetik meg. Van/volt helyette oktatás drága pénzekért. Kellene kolléga aki nem alussza végig ezt. Ismét ott tartunk, hogy valamiért nem az ilyenek álltak az első sorban a felvételi során. Ha pénz kell, hogy legyen ember, vas, szolgáltatás, stb. Az meg sosincs. Szóval nyilván ezt a legkönnyebb puffogtatni, hogy olyan ember kell. Ezt mindenki tudja. Azt is, hogy miért nincs. Így a körülményekhez mérten kezelni kell a feladatokat. Hiába állnék oda valamelyik miniszter vagy maga a mindenkori miniszterelnök elé. Valószínűleg nem is értenék, hogy miről beszélek. Egyébként ez privát cégekre is jellemző. A technológiára sajnálják a pénzt. Talán a tech cégek az egyedüli kivételek és néhány innovatívabb szektor, de minél nagyobb egy cég, annál nehezebben mozdul. Viszont annak bármi lesz az eredménye, egy jó darabig úgy marad :D A legtöbb kkv, és állami cég az erősen korlátozott. A multiknál van ami könnyebben megy úgy vettem észre. Főleg ha mondjuk egy új telephelyet kell építeni mondjuk. Nálunk amíg az agyoniskolázott építész (aki nem érti a különbséget a nettó és bruttó fizetés között) kedvére húzogat le a tervekről fali RJ45 aljzatokat, addig nem tudunk csodát tenni. Építkezés közben fél tetőteret vissza kellett bontani mert "elfelejtették" kiépíteni a gyengeáramú hálózatot. Csak az a vicc, hogy mindig elfelejtik, vagy ha mégsem, akkor nem kérdeznek senkit és annyit is ér. Hogy ég el az állami pénz ugye...

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Azzal nem oldod meg a problémát, ha te dolgozol meg a kollégáid helyett a fizetésükért.
Alájuk rakhatod a legfaszább hálózati menedzsment eszközt ami csak lehet kapni, de ha te kiesel akkor garantáltan rájuk dől az egész.

Önálló munkára képtelen társaság helyett még azzal is jobban járnátok, ha tehetséges és motivált kezdőket alkalmaztok, akik miután kitanulták a szakmát lelépnek valami menőbb helyre. Ha jól kezelitek a rotációt, akkor a társaság fele mindíg elfogadható szinten fog érteni a dolgokhoz...

egyébként meg te vagy a példa rá, hogy azért nem teljesen lehetetlen ilyen helyre is képzett munkaerőt találni....

Pontosan :) A fiatal munkaerő váltotta az eddigieket. Ott más problémák vannak, de legalább nincsenek berögzült faszságok, amikkel nehéz megküzdeni. Igazából én is léptem volna már, de most változtak a dolgok a magánéletemben, így egy kis időt még adok magamnak, aztán meglátjuk.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Euromillárdos éves forgalmú multi. Az eddig a csapat részére a használhatatlanság határán egyensúlyozó korlátoltan "elérhető" azure laborkörnyezetet 24 órás villámfigyelmeztetés leteltével ma délután dózerolta földszintig a belsős azure IT csapat. Helyette másik azure subscription természetesen nem van, mindenki oldja meg ahogy akarja. Nagy fejőstehén fizetős kuncsaft dolgait is itt próbálta ki kolléga mai napig, mielőtt élesen dolgozna rajta. A szarevőség etalonja eddig ez a munkahely.

elé tenni egy UI-t, amit tudnak nyomogatni.  > na, abbol mondjal majd changelogot mi valtozott, mikor elnyomkodjak :D szerintem inkabb ne. kepezni kell azokat a kollegakat, hogy ertsenek is ahhoz, ami a dolguk.
amugy ha konfigokat/changelogot szeretnel, erdemes ranezned erre is: https://github.com/ytti/oxidized faszan tudja kuldeni gitbe mi/mikor valtozott.

Az Ansible-t ne vesd el (nem monitoringra, hanem konfigurálás automatizálásra), nagyon nem mindegy, hogy neked kell kitalálni mindent 0-ról vagy csak meg kell hívni a megírt modult.

https://docs.ansible.com/ansible/latest/network/index.html

VÉgülis olvasásra azt használom, akkor kézenfekvő, hogy ugyanott ugyanazt használjam írásra is. 

A gondolat teljesen logikus, valamiért mégis az van, hogy ezt senki nem nagyon csinálja. Hogy a függőség milyen irányú, az passz, de úgy fest, hogy azért/amiatt, mert elég fos mind a kliens mind az eszköz oldali támogatottsága. Vagy legalábbis ez a "közhiedelem". Vagy csak aki ilyet csinál, az úgyis alaposabban managel. 

Az Ansible bár sokat tud, de szerintem ide pont felesleges, mert + 1 réteg, de alatta/neki ugyanúgy meg kell adni minden egyes paramétert. Nem automatizálni akarok, hanem monitorozni és a felhasználótársaim (rendszergazdák vagy valami ilyesmi) elé tenni egy UI-t, amit tudnak nyomogatni. 

Szóval tulajdonképpen automatizálni szeretnél. :) Értem, hogy adná magát, hogy a monitoring és a konfiguráció management legyen egyben, általában nem szokott jól elsülni, szerintem még nem láttam olya kombi eszközt, amiben valamelyik ne lett volna fos. Persze értem, hogy ha csak kevés ilyesmi van, akkor ágyúval verébre érzés van az emberben, nem is alaptalanul. Ráadásul ha tényleg kb portot, vlant meg descriptiont akarsz írni, az azért egyébként talán menni fog a random eszközökkel.

Ezzel együtt azért nem feltétlen vetném el az ansiblet, te összekalapálod a playbookot egy-egy operációra, a kollégáknak már csak azt a pár paramétert kell bepasszolni, ami valóban releváns. Enni igazából nem kér, csak helyet, egyébként akkor fut, ha valaki gombot nyom. És hát azért ahhoz van egy vödör modul mindenféle nw eszközre is, meg előrelépési lehetőség.

Ha kell a web, akkor akár mellé oda lehet csapni egy awxet, bár azért az már nagyobb szívás, és hát nem állítanám egyenes arccal, hogy a világ legjobban használható felülete. Vagy van az ansible-runner, amit tulképp a glue az akármi és az ansible közé, azt is lehetne piszkálni akár a saját web izédről (Vagy ilyen komplexitásban az ansible-t is direktben cli-t hivogatva, nem akkora katasztrófa az. Mondjuk command line snmpt se)

valamiért mégis az van, hogy ezt senki nem nagyon csinálja

Mivel én írtam olyan szoftvert, ami ezt csinálja, így el tudom mesélni a történet hátterét: azért nem csinálja szinte senki, mert egy kibaszott nagy szopás már maga az SNMP read is, de a write meg aztán pláne. Eleve értelmesen szinte semmit nem tudsz megcsinálni berendezés struktúra felderítés és cachelés nélkül, majdhogynem semmilyen berendezésen. Különösen nem, ha az eszköz bármilyen mértékben dinamikus struktúrájú tud lenni (ha cserélhető kártyák vannak benne, akkor eleve no-go a dolog, de ha csak vlan-okat, tunneleket, dinamikus subinterfészeket lehet létrehozni, már akkor is kell a struktúra). A legtöbbször azonban még egy fix konfigurációjú kicsi switch esetében sem kiszámíthatóak az interfészindexek (pl. sw verziót váltasz, és elmásznak az indexek). A következő szopatás, hogy a lehető legritkább esetben van akkora cpu az snmp agent mögött, ami bírja, ha nem esetileg, nagyritkán nyúlsz csak hozzá az eszközhöz, hanem folyamatosan basztatod. Nagyon sokszor nem is ütésálló az agent sw, ez fokozottan igaz, amennyiben nem csak a read, hanem a write is képbe jön. Pl. amikor az ügyfél 6500-as Ciscoja attól elcrashelt, mert átírtuk egy interfész description mezőjét SNMP-ből, hát nem voltak boldogok (erre még mi sem számítottunk, teljes főműsoridőben sikerült eljátszani). Egy rendes oprendszeren max. egy snmp daemon crashelne csak ilyen esetben, ugye. A read szemantika általában egyszerű (elküldöd a GET parancsot, és megkapod a választ), a write szemantika viszont sokszor nem ilyen egyszerű: még ha szimplán egy darab SET parancs elég is a kliens oldaláról, a berendezés maga sokszor több dolgot is csinál a háttérben (pl. a konfig sokszor szövegesen van tárolva). És vannak azok a műveletek, amik aszinkron módon hajtódnak végre: elküldöd a paramétereket, a SET elindítja a folyamatot, majd figyelni kell valami státusz mezőben, hogy hol tart a feldolgozás - ilyenkor az is egy gond, hogy egyszerre jellemzően egy folyamatot lehet végeztetni a géppel, külön oda kell figyelni, hogy nem küldheted be a következőt, amíg tart az előző feldolgozás.

"A problema az, hogy eszközönként változnak az oid-ek és elég melós mindent lefejeszteni. Pl egy 9200-as sorozatú switchnek már sok oid-je különböző pl egy 3650-hez képest. "

Hátugye kérdés, mit nézel... Az alap oid az minden hálózati eszközön ugyanaz (interfacek), mert RFC-ből jön. 

http://www.micros~1
Rekurzió: lásd rekurzió.

Vannak apróbb eltérések a portszámok miatt is. Pl. ha jól emlékszem, egy 3650-esnél a Gi1/0/1 az az X.X.X.8 OID. Utána már megvan a sor, mert a 2-es a 9. oid és így tovább. Az SFP portok ezután jönnek sorban. Virtuális portok vannak előtte. Na ez pl. nem egyezik már a 9200-asokban sem. Nehezíti a problémát ha stackelt switchről beszélünk vagy még egy régebbi típusról. Egyébként oid adatbázisokból gyönyörűen ki lehet szedni a szükséges infókat, csak néha keresni kell utána meg tesztelés tesztelés...

Az általunk használt kevesebb, mint 10 féle eszközre szűrve simán meg lehetne csinálni mindegyiket. Ha jó kedvem lesz valamikor télen lehet megcsinálom. Viszont valami crossplatformos megoldás kéne mert én inkább linuxozom, a makróm pedig eléggé windowshoz köt. Valószínű, hogy egy webes felületet heggesztek ha nem találok semmit. Még egy kicsit keresek előtte.

Azt vettem észre egyébként, hogy SNMP-vel a legapróbb dolgokat is lehet monitorozni vagy vezérelni. Nekem tetszik.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Benéztem, az ap interface dolgok ugyanazok. De pl. a vlan-tagság és hasonlók már nem.
A fentiből következően ugyanaz az interface két oid-n is elérhető: egy a default, ami minden eszközön van és egy, ami a cisco-oid.

De ilyen alap dolgok, mint if neve, küldött/fogadott packet/byte, eldobott byte, etc, az az IF RFC-ből jön és minden hálózati eszközön megvan. Csak ezek nagyjából olyan dolgok, amiket nem ír az ember,  csak olvas (mondjuk én még semmilyen hálózati eszközön nem akartam semmit írni snmp-vel, igaz, van külön hálózatos kollega. Én max. mentem a swithek/routerek configját:
https://shrubbery.net/rancid/
Meg van figyelő cucc is, kb. szomszédságot meg egyebet térképez fel, esetleges elcseszéseket:
http://netdisco.org/

http://www.micros~1
Rekurzió: lásd rekurzió.

A problema az, hogy eszközönként változnak az oid-ek

Ezért írtam fentebb, hogy epilepsziás roham gyötör amikor SNMP közelébe küldenek.
Elméletileg ez egy szabvány. De nincs az a gyártó, aki a szalagról egymás után leküldött két tök egyforma eszköznek ugyanazon metrikájit 100%-ban ugynazokra az oid-okra tenné. WHY????!!!!

"A megoldásra kell koncentrálni nem a problémára."

Tapasztalat alapján még szoftver verziónként is különböznek az OID-ek (updateled a szoftvert, és pl. elmásznak az indexek). Ha nincs meg hozzá a definiciós leírás, akkor meg akkora meló reverse enginerelni, mintha a processzor tervrajzát akarnánk létrehozni egy legyártott készre tokozott eszközt kézből nézegetve 

"azermermondjuka" PC is szabvanyos, de mikor latsz ket egyformat belole? kb. akkor ha veszel egyszerre ket egyformat.
az snmp annyira szabvany, mint mondjuk egy xml vagy json vagy fokonyv vagy html oldal vagy egy relacios DB... azt teszel bele kb. amit akarsz.

Ezt én mind értem.

De ha a w.x.y.z FW verzióban jó volt a 19-es port "bits sent" értéke az iso. [sokvalami].23 oid-on, akkor a w.x.y.(z+1) FW verióban miért kell hogy 47-re kerüljön ugyanez???????

"A megoldásra kell koncentrálni nem a problémára."

mert ez van. azt csinalnak amit akarnak es amig ez igy van, addig az is lesz. ha szerencsed van, odaadjak neked az oid/mib listet az eszkozodhoz/firmware-edhez es azt csinalsz te is vele amit akarsz.
minden eszkoz, midnen FW mas, nem is lehet rahuzni ugyanazt, ez van :)

( freeoli v | 2023. 06. 16., p – 10:14 )

A céljaidnak két eszköz fog megfelelni.

... monitor/mirror módba rakom és az átfutó adatok alapján képes elemezni a hálózati forgalmat ...

Erre valamilyen netflow analyser fog kelleni, más lehetőség nincs. Vannak ingyenesek és nagyon fizetősek, de alapvetően elegendő az external portot figyelni, vagy ha kell valami mást, de ha minden cisco akkor elvileg bármelyik port bárhova mirrorozható.

Erre csak a zabbix lesz a megoldás, főleg mert nagyon biztonságosan és hatékonyan kezeli a sok telephelyes felépítést. Dicovery, LLD .. eszközeivel gyakorlatilag teljesen automatizálni tudod a switchek és eszközök monitoringját.

... nagyjából 10 telephely ...

Ezt nem tudja így, de általában a legtöbb érték csak RO-ban van kiadva, meg a cisco snmp implementációi amúgyis bugosak a saját doksijaikkal sem egyeznek néha, de a cisco már csak ilyen.

Erre van egy nagyon megoldás lehetőség. Támogatja a scriptelési lehetőséget amit a GUI-ról lehet indítani, pl katt és már SSH-n be is csatlakozott a switchre, de a port ettől hogy lesz letiltva azt nem tudom, talán az is átadható értékként valahogy.

... snmp write communityt is tudnám használni ...

( n.balazs v | 2023. 06. 17., szo – 13:51 )

A többiek már nagyon sok hasznos dolgot leírtak, így csak pár apróságot tennék hozzá.

Monitoring vs. netflow analysis (+security analysis) vs. config management. Legalább 2-3 külön szoftverre lesz szükséged. Nem csak a heterogén környezet miatt, hanem a szoftverek másban erősek. Pl: Zabbix tökéletes monitoringra, de nem network monitoringra lett kitalálva csak.

Config mgmt részhez: Nem biztos, hogy az SNMP a legjobb megoldás. Kollégáimmal többször csináltunk olyat, hogy SSH/API-n keresztül kezeltük a hálózati eszköz konfigurációját, amit verziókezelve tároltunk. Az így tárolt szöveges formátumú konfiguráción végeztük el a módosítást, amelyet ellenőrzés után feltöltöttünk és élesítettünk az eszközön. A szöveges formátum miatt piszkosul egyszerű volt a változáskezelés és ellenőrzés. Hiba esetén könnyen vissza tudtunk állni az előző verzióra.
Ha találsz / készítesz egy webes toolt, ami ezt a szöveges konfigurációt feldolgozza, értelmezi, módosítja, akkor kész is egy alapszintű GUI level1 számára. GUI-ra meg csak azt vezeted ki, amit szeretnél, hogy a kollégák módosíthassanak. Ezzel nem kötöd magad XY gyártó bugos, kezelhetetlen GUI-jához.

Ötletnek, amit most találtam: https://github.com/slub/switchconfig

Netflow analysis:Ezt a vonalat én a helyedben egyelőre elengedném. Vannak opensource próbálkozások (pl: https://github.com/akvorado/akvorado, https://github.com/pavel-odintsov/fastnetmon), de enterprise cuccok fizetősek (pl: Qradar, Solarwinds, Noction, Wazuh). Keményen. Mondjuk azokkal már protokoll szintig lehet menni, elemezni és akár ki is szűrni a nem kívánt forgalmat.
Esetleg el lehet gondolkodni valami központi loggyűjtő (Syslog, Nxlog) alkalmazásán és abból kinyerni a szükséges információkat. Persze általában itt is a fizetős az, ami többet tud, több protokollt ismer (pl: https://nxlog.co/community-edition-vs-enterprise-edition).