network ping monitor

Hálózatok általános

Sziasztok!

200+ eszköz monitorozására keresek olyan tool-t, ami folyamatos ping alapján figyelmeztet, loggol. A legjobb lenne egy "aktív history" képernyő, amin megjelennek a legfrissebb események. Akár web-based is lehet...

Üdv,

  • 3836 megtekintés

( dentzol | 2018. 03. 29., cs – 21:56 )

A Google első pár találati oldalán levő eszközökkel mi a gond? :)

( mauzi v | 2018. 03. 29., cs – 22:24 )

> folyamatos ping alapján figyelmeztet, loggol

Milyen mintavételezési sűrűségre gondolsz? A kutyaközönséges ping ugye ~ másodpercenként mintavételez, a "tipikus" monitorozó eszközök jellemzően 1-5 percenként szoktak, már csak azért is, merthogy 200+ eszköz...

Többségében másodperceseket tervezek. Jelenleg a mikrotik netwatch funkcióját használom, de mostanában megnőttek a véletlenszerű 1 ping hibák olyan eszközöknél is, ahol kizárnám a hálózati hibát. Arra gyanakszom, hogy a hardver miatt, amin fut (3011).
Kipróbálnék linux x86 alatt valami másik szoftvert...

+1

en pythonban irtam ilyet ami cronbol lefut percenkent, es a statusz valtozasokrol kuld emailt, de nagyon sok igy is a fals riasztas:

out = os.system("/bin/ping -q -c1 -w2 "+ip+" >/dev/null")
if out==0:
# host up!
return 0;
if out!=256:
# system error
return -1;
# try again
out = os.system("/bin/ping -q -c3 -w5 "+ip+" >/dev/null")
if out==0:
return 0 # ha 3 ping mind megjon akkor OK
out = os.system("/bin/ping -q -c10 "+ip+" >/dev/null")
if out==0:
return 1 # ha 10 pingbol legalabb 1 megjott akkor WARN, kulonben ERR
return 2

es a statusz valtozasokrol kuld emailt, de nagyon sok igy is a fals riasztas

hat pont errol beszeltem :-) Btw. ha mar ajanlgatod a nagios-t, akkor miert nem hasznalod (legalabb azt)? Abban legalabb van flap detection (bar azert tulzasba nem viszik)...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

mert utalom :) iszonyu kenyelmetlen a konfigolasa, foleg ha van par 100 hostod fa strukturaban (egymastol is fuggenek). amugy eredetileg ahhoz kezdtem irni egy konfig generalot, de aztan rajottem hogy a pingeleshez tok felesleges a nagios, azt en is meg tudom csinalni... 93 sorban. jo, flap detect nelkul, de mint irtad az a nagiosban sem az igazi. raadasul a nagiost akarhogy reszeltem, min 5 perc delay volt mire riaszt egy host leallasakor, nekem meg elobb kellett.

A GUI akkor működik jól, ha alapból abban csinálod meg 0-ról. Én anno egy custom configot örököltem, próbáltam belefaragni, de a végén inkább ráhagytam. Most van már működő nagconf amit használok és teljesen kényelmes.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Az "elírsz valamit" megkeresésére a legfapadosabb verziókezelő is segítség lehet. Az egy módosítás - indítsd újra az egészet működés (örökség, szerintem nagyon sokat kéne reszelni a kódon hogy ne így legyen) elég gáz, pláne, hogy elég könnyű elbökni a beállításokat úgy, hogy elinduljon, de egyik-másik check mégse működjön.

Érdekes, amikor írtam egy hálózat monitorozó rendszert, ami mellékesen a hálózat dokumentálását is segíti, van vagyonvédelmi része is, akkor mindenki azt írta rá, hogy minek, felesleges, ott a Nagios, meg a többiek.
Most meg kiderül, hogy a Nagios a legjobb, de mégsem egy tuti rendszer?
(Én ezt használom, és fejlesztem: https://github.com/csikfer/lanview2 lehet vele elvileg másodpercenként pingelni, de az szerintem is rossz ötlet.)

A restart talán tényleg nem az a rettenet (az én rendszeremnél is újra kell indítani modulokat, ha változás van), de szerintem a text konfig egy bizonyos host és szolgáltatás szám után nagyon nyűgös tud lenni. Azonkívül a hálózat menedzsment nem abból áll, hogy megye, vagy nem valami. Néha az is feladattá növi ki magát, hogy az ember eligazodjon a rendszerben.

A nagios felépítéséből adódóan ilyen, hiába teszel mögé akármilyen adatbázist - tök mindegy, hogy fájlból olvas _egyszer_ vagy adatbázisból. Ezt a működést meg tényleg nem lenne egyszerű kigyógyítani belőle - nem is kell, hogy cél legyen - cserébe el kell fogadni, hogy a nagy, sokezer figyelt érték/állapot monitorozására, pláne ha az infrastruktúrában gyakori változások, módosítások vannak erősen szuboptimális az, ahogy a Nagios működik.
Nem véletlen, hogy az általam látott nagyobbacska rendszerekben, főleg ahol a "megy/nem megy" szinten túl kellett lépni, ott nem a Nagios-családból választottak/választottunk eszközt.

Évekkel ezelőtt volt Nagios a kezeim között, de tudtommal ezek a problémák már akkor is meg voltak? oldva benne:

https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/con…

Az use_retained_scheduling_info=1,retain_state_information=1 beállítások nem ezt a problémakört oldják meg?

Ha csak ping kell akor meg:

https://oss.oetiker.ch/smokeping/

OFF: megneztem (ujra, anno lattam mar egy korabbi verziojat) ezt a lanview-et. en is fejlesztek hasonlot mar 15 eve, ami az ARP tablat es a switch adatokat veti ossze a sajat adatbazisaval es gyujt adatokat az eszkozokrol. beleneztem kivancsisagbol a portmac implementaciodba (mivel ezzel szoptam en is a legtobbet), de ugy latom nincs tulbonyolitva :) es csak a teljesen szabvanyos, snmp+lldp eszokokkel mukodik. nekem pont azzal ment el rengeteg ido hogy a mindenfele gagyi sw-ket (tplink es dlink csodai, de a web-only managementes linksys-cisco is ide tartozik) implementaljam. egyelore ugyfelenkent reszelem a kodot, jo lenne egy generalis megoldas ami mindennel mukodik (legalabb ami snmp-s), de egyre inkabb ugy tunik, hogy ez kb lehetetlen :( az olcsobb eszkozokon annyira tojnak az snmp-re hogy ha implementalnak is valamit, az kb teljesen random, hianyoznak mib-ek vagy epp custom mib-ben van a lenyeg, valtozo formatumu a port neve, es sw model/firmware verziotol is fuggoen valtozik. persze leheten mondani hogy vegyen mindenki enterprise hp/cisco switcheket, de nem vesznek... es meg ott sem egyseges a vlanok kezelese ugye.

( uid_6201 v | 2018. 03. 30., p – 10:19 )

5 perces fping (több IP címet megadva) és az egyes HOST-ok sikeres pingszáma alapján a Nagios-nak felküldeni a "0" (oké) "1" (warning) "2" (critical) jelzést, üzenetben pedig a százalékos veszteséget.

( sj | 2018. 03. 30., p – 21:23 )

mivel csucsu bajtars nem mondott tobbet arrol, hogy mi az a 200+ eszkoz, igy eljunk azzal a feltetelezessel, hogy halozati eszkozok: leginkabb router-ek, switch-ek. Ha megsem ezek, akkor majd finomitunk :-)

Amint fentebb irtam, nem az icmp echo request - reply (aka ping) fele mennek el, bar lehet ez is egy teszt (mondjuk a szokasos 5 percenkent 10-20 csomagot elkuldeni), de csak erre nem alapoznek riasztasokat. Emellett ugy is lehetne az eszkozok elerhetoseget vizsgalni, hogy pl. snmp-n lekerdezed az uptime erteket. Az snmp okos - abban az ertelemben, hogy - van benne retry (ha hasznalod), ill. a kinyert ertekbol azt is tudod, hogy miota mukodik. Ha mar snmp, akkor erdemes a portok forgalmat is merni, ill. figyelni, hogy nincs-e huzamosabb ideig kitomve az adott link (mert ha igen, akkor sanszos, hogy az icmp csomagjaid mennek a levesbe). Emellett lehet hibas csomagokat szamolni (van ra snmp oid), whatever. Vegul lehet azt is figyelni, hogy elered-e ssh-n az adott eszkozt. Nem kell belepni, ha megjon az ssh prompt az eszkoztol, akkor koser. Ill. amikor a nemzetkozi vonalaink sla-jat mertem, akkor csinaltam egy olyat is, hogy lekerdeztem a verisign webszerverenek az ip-cimet. Ez azert volt mokas, mert a www.verisign.com ttl-je 1 perc volt, tehat garantaltan friss eredmeny jott - meg a dns cache-tol is.

Szoval a lenyeg az, hogy lehet azert finomitani a "masodpercenkent 1 ping nalunk a monitorozas" koncepciojan...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

meg ott tartunk, hogy router-ek/switch-ek a celkozonseg. Azokon meg jellemzoen nem openssh van, nincs ez a fail2ban hulyeseg sem, ill. eleve nyilvan ugy kell megtervezni a monitorozast, hogy ne utana legyen siras, hogy mi ez az 5 percenkenti nem felepitett ssh kapcsolat, mert valakinek bantja a feng shui-jat...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

Köszönöm a hozzászólásokat!

A másodperces pingek azért lennének fontosak, mert többnyire mikrohullámú linkek lennének a végpontok. Egy-egy ping kimaradásából is lehet következtetni olyan átviteli problémákra, amiket más paraméterekből nem lehet egyértelműen leszürni.

Egy-egy ping kimaradásából is lehet következtetni olyan átviteli problémákra, amiket más paraméterekből nem lehet egyértelműen leszürni.

igen, a masodperces pingekbol leginkabb arra lehet kovetkeztetni, hogy fingod nincs a monitorozasrol...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

igen de arra jobb ha nem riaszt minden kimaradt csomagra, mivel mikros linken gyakori a 0.1-1% koruli allando packet loss, ami raadasul a csomag meretetol es idojarastol is erosen fugg. ott inkabb merni kene a packet losst es ha atlep egy hatarerteket (mondjuk 3%) akkor riasszon. persze van ahol atm/l2tp/ppp/openvpn vagy ilyesmi tunnelben megy a data a mikron at ami elfedi a packetlosst (ujrakuldi) ezeknel a valaszido fog nagyon ingadozni.

pl: http://arp.interoot.hu/cgi-bin/ping.py?time=1522000723&zoom=72&w=1200&i…

A jelenlegi rendszerrel, amit összeraktam a netwatch-ból, egész idáig jól elvoltam. Szerintem a sok host miatt hozza a hibákat, mert egy másik eszközről megfigyelve nincs hiba.
Egyébként a vonalainkon egyátalán nem jellemző az állandó packet loss. Időjárás miatt pedig pláne nem.

( csucsu | 2018. 04. 05., cs – 11:16 )

Összeraktam egy perl scriptet a feladatra, de ezzel is ugyanaz a problémám. Ha pár host-ot figyelek jól működik. Ha rátöltök 150 host-ot, a terhelés felugrik 30% környékére (CPU E31220) és elkezd fals hibákat hozni...

Nem hiszem, hogy 150 pingnek ennyire le kéne terhelni a procit...

Nem kifejezetten értek a perl-hez, de ezt tudtam összehozni más forrásokból:

#! /usr/bin/perl
# to check ping from a file of IPs using threads

use strict;
use warnings;
use threads;
use threads::shared;
use Net::Ping;
use Time::HiRes qw(usleep);
use Time::Piece;

my $timeout = 2;

open CFILE, "./netwatch.conf" ;
my @host_array = ;
close CFILE ;

my @screen_array = ();

my @threads;

foreach my $addr(@host_array){
chomp($addr);
my $thr = threads->new(\&sub_ping,$addr);
push(@threads,$thr);
usleep(5);
}

my $thr = threads->new(\&sub_scr,1);
push(@threads,$thr);

foreach (@threads){
my $val = $_->join();
print "Trying to ping $val complete\n";
}

sub sub_scr {
while (1) {
# print "screen1\n";
sleep(1);
}
return 1;
}

sub sub_ping {
my $host = shift; #to get $ARGV[0]
my $status = '';
my $ping_handle = Net::Ping->new("icmp",$timeout) or die "\n ping unsuccessful. $!";;
# $ping_handle->hires();
while (1) {
my ($ret, $lat, $ip) = ($ping_handle->ping($host));

if ($ret) {
# printf "$host \($ip\) responds to pings at %.2f msec.\n", ($lat//0)*1000;
if ( $status ne 'up') {
$status = 'up';
print localtime->strftime('%Y-%m-%d %H:%M:%S '); printf "$host is %s!!!\n", $status;
}
}
else {
if ( $status ne 'down') {
$status = 'down';
print localtime->strftime('%Y-%m-%d %H:%M:%S '); printf "$host is %s!!!\n", $status;
}
}
#$ping_handle->close();
sleep(1);
}
return $host;
}

mar irtam neked, hogy egyreszt maga a koncepcio fucked by design, masreszt 150 allandoan futo thread, ami gyakorlatilag sose megy sleep-be (es itt visszaternek a koncepciod elbaszottsagara) siman okozhat nagy load-ot. Tovabbi kellemes letolt gatyas rohangalast a faszerdoben... :-)

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

hat de miert kell kulon thread mindegyikhez?
az en (igaz c-ben irt) pingelom (most probaltam ki 350 hosttal) is csak 0.9% cpu eszik (igaz Intel(R) Xeon(R) CPU E5607 @ 2.27GHz, de nem egy mai vas ez se)

nalam ugy mukodik hogy 1mp-kent kikuldi az osszes hostra a pinget aztan varakozik a bejovo csomagokra: http://thot.banki.hu/arpi/pingstat3.c

( lcsaszar v | 2018. 04. 06., p – 12:13 )

Broadcast addressre is lehet pinget küldeni. A ping csomagméretet is lehet minimalizálni. Én azonban snmp get-et küldenék.

Pontosan, minimális kiindulási alapként ifInErrors, ifOutErrors, ifOutQLen, ifInDiscards, ifLastChange, és még az a többtíz paraméter, amik érdekesek lehetnek. Aztán ezzel összhangban lehet a mikró beltériket kérdezgetni a rádiós átvitel paramétereiről, jelszintekről, javított és javíthatatlan hibákról stb.

Ezen felül meg még ott van a BFD is, erre (is) lehet alkalmazni.

"többnyire mikrohullámú linkek lennének a végpontok"
Amúgy ezek licencelt, vagy bárki által szabadon használható frekvenciasávban üzemelő mikrók? Mert ha jól értem az eddigiekből, ez a packetloss/frameloss jelenség rendszeresen és tömegesen fordul elő, ami lehet, hogy "normális", ha más is bezavarhat.

ping csomagmeret: hat eppenseggel mikronal a csomagmerettel exponencialisan no a hibak szama. mivel hibajavitas nincs, nagyobb csomagnal nagyobb valoszinuseggel lesz bithiba ami miatt eldobja az egeszet. en emiatt 1460-al pingelek, egesz mas eredmenyt ad ki mikros vonalaknal mint a kis csomagmerettel.