classic.ISPforum.cz

Takyto vystup je zo zabixum to iste...

Smutný je, že hodně lidí tady na fóru investovalo do ISPadmina, který neumí monitorovat ani půlku toho co Zabbix/LibreNMS/aj., který je zadarmo.

Taky máme librenms.Teď dodělávám podporu pro alcomu a ray.

Taky jsmev minulosti meli jen mrtg a smoke spolu se stary Nagiosem.
Ted provozujeme Dude a Zabbix. Vedle toho i loganalyzer.
Zabbix si sam vybral technik po rocnim hledani vhodneho nastroje.
Mame pomerne velkou sit fttb a an koncich zase AP s mikrotikama.
Dohledujeme zabbixem ping, trafik, silu signalu siwtchu, serveru, ap. Vybrane clienty monitorujeme take.

Viktor Novotný píše:Zdravicko ve spolek, prosim podelte se co pouzivate za dohled a nejlepe i proc doposud mame klasiku smokeping a mrtg, byly nejake snahy udelat to cele nove, ale moc se nedari. Tak hledam co uz by bylo hotove a dobre ...

diiky

diky, vypada to fakt dobre hlavne ten LibreNMS
jak silny stroj musi byt na cca 4500 cilu pingu, a cca 2500 cilu snmp .. jde zrejme hlavne o kresleni grafu na tom se stroj nejvic nadre ?

Viktor Novotný píše:diky, vypada to fakt dobre hlavne ten LibreNMS
jak silny stroj musi byt na cca 4500 cilu pingu, a cca 2500 cilu snmp .. jde zrejme hlavne o kresleni grafu na tom se stroj nejvic nadre ?

Největší problémy jsou dva:
1) Zajistit, aby doběhl polling strojů za menší dobu než je interval jeho spouštění (dostatečný počet threadů na rozumném procesoru, rychlá MySQL, dostatečná linka do sítě a bod 2)
2) Aby se stíhalo zapisovat RRD na disk (dost pomůže rrdcached)

Samotné prohlížení (kreslení grafů do png z rrd) je nárazové (až když uživatel vyžádá stránku s grafem) a nemá cenu ho významně řešit.

hmm a jak toto mohu zajistit ? da me treba LibreNMS na vyber kolik cilu bude pingat v jednom "vlaknu" ?

Viktor Novotný píše:hmm a jak toto mohu zajistit ? da me treba LibreNMS na vyber kolik cilu bude pingat v jednom "vlaknu" ?

Jistě, cronem se spouští poller-wrapper.py, který bere za argument počet threadů, mezi které rozumným způsobem rozděluje práci (začíná se zařízenimi, které potřebují nejvíce času). Obvyklý počet threadů je počet jader CPU x 2. Samozřejmě neplatí nepřímá úměra mezi počten threadů a časem běhu, chce to hledat optimum v závislosti právě na rychlosti CPU, disk I/O a MySQL : -)

Taky nagios. Spousta vlastnich scriptu a checku, tak i sprava je celkem uchopitelna. Bez udelatek si ale neumim predstavit provoz a udrzbu. Aktualne sledujeme asi 400 prvku a jednou tolik sluzeb na nich. To se uz rucne konfigurovat fakt neda.

Moznosti notifikaci cehokoliv prakticky bez omezeni. A skoro vse se da grafovat. Je to ucelena platforma, kde si lze cokoli stahnout nebo rucne nascriptovat s vyuzitim standardnich prikazu linuxu nebo modulu perlu. Proste parada.

Ovsem hlidat tim jen ping a vypadky, to je jak kanonem na vrabce.

dokáže LibreNMS alebo Zabbix monitorovať parametre pripojenia klientskych zariadení bez toho, aby šahal na tieto zariadenia, iba z informácií z APčka?

Shakal píše:dokáže LibreNMS alebo Zabbix monitorovať parametre pripojenia klientskych zariadení bez toho, aby šahal na tieto zariadenia, iba z informácií z APčka?

Neskusal som ale popravde asi to nepojde, neviem si predstavit ako sa daju vycitat info z registration table pripojenych zariadeni, dalsia vec nemas ako pingat tieto zariadenia.

Gemb píše:

Shakal píše:dokáže LibreNMS alebo Zabbix monitorovať parametre pripojenia klientskych zariadení bez toho, aby šahal na tieto zariadenia, iba z informácií z APčka?

Neskusal som ale popravde asi to nepojde, neviem si predstavit ako sa daju vycitat info z registration table pripojenych zariadeni, dalsia vec nemas ako pingat tieto zariadenia.

Data o pripojenych STA samozrejme pres SNMP lze zjistit (mluvim o AirOS a RouterOS). Nejsou dokonala (treba u UBNT nelze zjistit signal per chain, nejsem si jist rozliseni Tx a Rx signalu), ale pro zakladni monitoring urcite staci. Jestli ale existuje modul pro nejaky NMS pro jejich monitoring, to nevim. Minimalne u LibreNMS si umim jen tezko predstavit jejich kvalitni dohled a hlavne alerting - predevsim z pohledu struktury DB a znacne variabilite dat o STA (vymeny zarizeni, ruzne pocty chainu, menici se hostname, casta nedostupnost zarizeni (uzivatele obcas dobrovolne radio vypinaji) atp.) a z toho vychazejici narocnost urceni "primary klice" daneho zarizeni/zachovani konzistence historie/poradi zarizeni atd.

na ten základný monitoring klientov nám ešte stále beží upravené Rosinfo (SNMP trap), ale chcelo by to niečo viac.
A niečo, čo by robilo synchro dát pomocou rádiusu ( klienti sú cez PPPoE)?