(Ehhez kapcsolódik: https://hup.hu/node/186393)
Beállítottam 5 routert így monitorozásra, és hát elég kiszámíthatatlan módon működik...
Pár perc után jön az első, hogy NO SNMP data, majd a második, majd a harmadik. A maradék kettő, ami "megy", az meg olyan hogy bizonyos adatok frissülnek, bizonyosak meg nem.
Itt van például ez, ugyanahhoz a routerhez tartozik, az egyik CPU utilization frissül, a másik nem.
Ha nyomok egy zabbix-server restartot, akkor pár percig megint jó az összes, aztán ugyanezt elkezdni, bejön az egyik hogy NO SNMP data, majd a másik, majd a harmadik, és a maradék kettőről is így jönnek (vagyis hát inkább nem jönnek) az adatok.
A zabbix server konfigjában nem láttam az snmp-vel vonatkozóan külön olyanokat, hogy hány feldolgozó legyen, milyen timeout legyen vagy hasonló.
Mi okozza ezt?
Hozzászólások
A zabbix-server.conf-ban van egy "Timeout" rész:
Érdemes lehet felemelni, hátha megoldódik a probléma.
A konfig elején van mód debug level állításra (emelésre), ezt megemelve talán látni lehetne a logban, mi a hiba:
4s a timeout nálunk.
Ha a debug levelt felveszem 4-re, akkor kb. annyi infó kezd el a logba fosódni, hogy nem tudok rajta elmenni... (van a zabbixban 262 host, 40000+ itemmel...)
"Sose a gép a hülye."
Én felemelném a maximális 30-ra a timeoutot. SNMPv3-on nagyon lassú tud lenni a kommunikáció - és nagyon tudja terhelni a monitorozandó eszközt, ezért nem is szeretik nagyon a hálózatos kollégák az SNMPv3-on való monitorozást.
Proxyt nem is használtok, az összes hostot a Zabbix szerver monitorozza közvetlenül? Ha nem, tennék egy próbát: csinálnék egy külön Zabbix proxyt ezekre a hálózatos eszközök monitorozására. Így a szerver újraindítgatása / konfig módosítgatása nélkül lehetne finomhangolni az SNMPv3-as eszközökhöz a beállításokat ( a proxy-n ). A logok elemzése is könnyebb lenne a proxyn, ha csak ez a néhány eszköz termeli a logot.
De, vannak proxyk.
"Sose a gép a hülye."
Felvettem 10s-re, nem változott semmi.
Egyébként ilyenek vannak logokba:
1137116:20241007:164005.559 SNMP agent item "system.net.uptime[sysUpTime.0]" on host "xxxxxxx" failed: first network error, wait for 15 seconds
...
1137211:20241007:164020.095 resuming SNMP agent checks on host "xxxxxxx": connection restored
"Sose a gép a hülye."
snmpwalk-kal nem nézted esetleg a Zabbix szerverről? Érdemes lenne, egész jól lehet látni, hogy mennyi idő múlva fut le egy lekérdezés, elakad-e abban is, ilyesmi... Sokszor az eszköz tud annyira belassulni, hogy nagyon lassan adja csak vissza a választ, olykor nem is válaszol teljesen végig (eszköz/eszköz terheltség függő).
snmpv2-n mennek amúgy szépen?
Hmm.. Hát igen.
time snmpwalk....
real 0m44.474s
user 0m0.299s
sys 0m0.198s
Persze, azon mentek eddig, csak a belső hálón mögöttük lévő proxykon keresztül. Pont azért akartam átrakni így direktben, hogy ne függjenek a proxytól meg úgy egyáltalán a belső hálótól, pontosabb képet adjon a monitoring.
Ez így valszeg... Bukó lesz.
"Sose a gép a hülye."
egy tcpdump/ngrep a monitorozon szűkítve a túloldalra, legalábbis én ezzel kezdeném:
# tcpdump -i eth0 host 1.2.3.4 and port 162 and udp
Bőven lehet, hogy a query packet elkószál valamerre és valóban nem érkezik válasz
// Happy debugging, suckers
#define true (rand() > 10)
162 a trap. Az nincs belőve. De 161 megy nyilván, nem hálózati hiba, mert egy ideig jön adat.
"Sose a gép a hülye."
mert egy ideig jön adat. vs nem hálózati hiba : UDP, 1 csomag veszett, onnantol csesz7ed :D
egy valag MT, snmpv2-vel, local networkben proxykkal, MT-n tuzfal/ACL smnp-re. 40-50 eszkoz kb, vegyesen. nincs gond veluk.
bulk request on pl. tud segiteni esetleg.
Megpróbálhatod kikapcsolni a bulk lekérdezést Zabbix szerver/proxy oldalon. Sok berendezés nem támogatja, vagy nem korlátlan OID-re, vagy nem korlátlan response méretre a bulk lekérdezéseket.
Meg a timeout eléggé kevés 4s-nak. A legtöbb SNMP-s hálózati eszköz nem ilyen gyors SNMP válaszban, pláne ha bulk a lekérdezés, pláne ha v3 a forgalom.
Én v2-n próbálnám, proxy-t használnék a célhelyen, hogy ne legyen gond a titkosítatlanság, 15 vagy 30s timeout-tal és elsőre bulk kikapcsolva. Vagy, ha csak a szerver/proxy jöhet át a tűzfalon IP-re szűrve az SNMP klienshez, akkor pláne felesleges a v3. Szerintem a v3-nak akkor van értelme (akkor is a hitelesítési résznek), ha set is megy, nem csak get.
bulk ki/be próbálva, semmit nem számít
v1/v2-vel mennek szépen, eddig úgy voltak monitorozva.
"Sose a gép a hülye."
Akkor a v3 plusz a direkt szerver kapcsolat miatti nagyobb késleltetés fogja meg? A monitorozott eszközön tudsz CPU-t/core-t nézni (nem Zabbix-ban :-), hogy nem az limitel-e a v3 titkosítása vagy egyéb baja miatt?
Egyébként mi úgy monitorozunk, hogy mindent a proxy gyűjt helybenm minden távoli helyszínen (SNMP esetén v2-n), és a Zabbix szerverről csak a proxy-t monitorozzuk közvetlenül, és az adott távoli hely internetes elérhetőségét (meg persze van trigger arra is, ha nem jön a proxy-tól adat), mert általában nem a gateway a proxy. Ha a proxy kapcsolata elmúlik a szerverrel, akkor valószínű a proxy-n túl lévő eszközök sem tudnak a szerverrel beszélni internet hiányában, így a proxy kihagyása nem segít. Ha csak a proxy múlik el (ilyen igen ritkán van nálunk), akkor meg jön az értesítés, hogy a proxy nem küld adatot, pedig a netkapcsolat él.
De bevallom, anno Nagios-sal évekig monitoroztam távoli SNMP eszközöket (v1/v2-vel, v3 sose volt) sima publikus oldalra kirakott portokon, és soha semmi gondom nem volt belőle. Persze IP alapú szűrés volt azért.
De a Zabbix és a proxy-k óta ilyenre nincs szükség.
Megnéztem ugyanígy snmp3-al, "belső" proxyval, ami valójában egy másik telephelyen van és VPN-en vannak összekapcsolva.
real 0m24.725s
user 0m0.368s
sys 0m0.127s
Ami jobb mint a 44, de azért szerintem még így is nagyon sok.
[szerk] Közben átraktam a proxyra a monitorozást, maradt snmp3 minden ugyanazzal a beállítással... És így úgy tűnik hogy megy. Egyébként a proxijainkon is ugyanúgy 4s a timeout mindenhol, úgyhogy nem értem. o.O
"Sose a gép a hülye."
nem lehet h logolashoz csinal rev.dns lookupot vagy ilyesmi?
Nem.
Eddig ment, most a proxykról is elkezdte hogy no snmp data. Szóval ~ugyanaz.
Mindegy, így leszarom, akkor marad proxyn keresztül v2, ahogy eddig is volt.
Csak így nem tudom mi értelme ennek az snmpv3-nak....
"Sose a gép a hülye."
lehet belso halon stabilabb az udp? ;)
Nem, fentebb írtam.
De egyébként nem tudom ez honnan jön, szerintem legalább 15-20 éve nem láttam olyat, hogy udp csomag csak úgy "elveszett".
"Sose a gép a hülye."
nem is nagyon fogsz, hisz az udp lenyege, hogy kinemszarjale ha elvesz par csomag :)
Valszeg nem nagyon értesz a hálózathoz, de maradjunk annyiban, hogy egy rendes hálózatban nem vész el UDP. Ahol UDP elvész, ott elvész ICMP is, meg TCP is (meg minden egyéb), aminek érezhető és látható következménye van. (Nem mintha az UDP-nek amúgy nem lenne, pl. elég csak a DNS-re vagy a HTTP3-ra gondolni.)
"Sose a gép a hülye."
maradjunk annyiban, hogy rendes LAN halozatban nem szokott elveszni csomag. kiveve ha pl doglodik egy SFP, koszos az optikai csati, megtort vagy megragta az eger az optikai kabelt, kontakthibas az rj45 csati, olcso CCA-s patchkabelt vettek stb... en 25 eve uzom ezt az ipart, mar mindent is lattam, hidd el.
WAN halozatban meg azert vesznek el csomagok, foleg ha nem optikan megy. mikron alap a csomagvesztes foleg esos idoben, de dsl-en, docsis-en is megesik, foleg hosszu kabel vagy szar kotesek eseten.
csak mig tcp-nel maga a tcp layer kezeli a csomagvesztest ujrakuldessel (ha nincs ack), udp-nel altalaban az alkalmazas gondja ez (pl. dns, dhcp ujrakuldi a kerest ha nem kap rovid idon belul valaszt). egyiknek sincs lathato kovetkezmenye, hacsak nem wireshark-al nezed...
Ami nálunk még előjött UDP esetén az a rossz sysctl beállítás ami miatt a cél szerver dobálta el a csomagokat ha jött egy nagyobb spike.
Szintén sysctl, de érint mindent, amikor kifutsz a conntrack táblából és jön a conntrack table full, dropping packet üzenet a dmesgben.
Ha rendes a hálózat és minden faszán van beállítva akkor persze minden rendben működik, de akkor meg nem lesz róla HUP fórumtopik sem...
legyunk pontosak, a tcp-t is ugyanugy dobja el ilyen esetben, csak ott a retransmit/reorder megmentheti a sejhajod :D
Mikrohullámú összeköttetéseknél okozhat problémát az időjárás, és okoz is időnként, de a jól megtervezett összeköttetéseknél ritkán van gond. Az ilyen összeköttetések ellensége a fading, ami ellen komoly tartalékot kell betervezni, általában 30 dB-t vagy annál is többet. Az ügyfél által igényelt rendelkezésre állás mértékétől függ, hogy mekkora legyen a tartalék nagysága. Nagyobb értéket úgy lehet elérni, hogy növelni kell az adó teljesítményét és/vagy az antenna/antennák nyereségét. Az adott berendezés maximális adóteljesítményének elérése esetén már csak az antennaméret növelése segít, az antennák meg drágák, minél nagyobb, nyilván annál többe kerül. A nagyobb teljesítményt tudó adó is sokkal drágább a normál adónál, szóval kérhet az ügyfél komoly rendelkezésre állást, csak tudja megfizetni.
Alapesetben az idő 99.9...%-ában nincs probléma egy jól megtervezett összeköttetéssel, így ekkor egyáltalán nincs csomagvesztés, szóval nem, a csomagvesztés nem alap a mikrós linkeknél. A berendezések maguk mérik a link "jóságát", bármilyen hiba esetén azonnal jelzést küldenek (pl. SNMP-n). Nyilván ezek a linkek nem olcsók, a rádióengedélyért is fizetni kell, ezeket nem szabad hasonlítani azokkal a linkekkel, amiket szabad sávokban létesítenek (pl. 5 GHz-es sávban), mert ott nincs garancia arra, hogy a linkek nem zavarják egymást.
Amikor annyira szakad az eső, hogy az autósok félreállnak az úton, mert nem látnak előre 50 m-t sem, akkor bármilyen mikrohullámú link megszakad. Kisebb-nagyobb esők esetén csak visszaléptetnek egy vagy több lépcsőt a modulációs módban (pl. 1024QAM-ről lemennek 512QAM-re, 256QAM-re vagy akár QPSK-ra), de a teljes megszakadáshoz nagyon nagy esőre van szükség, ami ritkán fordul elő. Komoly havazások esetén is lehet baj, főleg akkor, ha a hó meg tud tapadni a radome-on (ami az antenna belsejét védi elölről).
valszeg te sem lattal mostansag ip halozatot kozelebbrol, vagy fingod sincs hogy mukodik. nem, az ip layer nem biztosit neked lofaszt sem ilyen szempontbol. ahogy az udp sem, arra tartjuk a tcp-t :D
nezd! :D
Ez amugy ilyenkor rendes halozatnak szamit, vagy rendetlennek? :D
Nem megyek bele veled ugyanabba az értelmetlen vitába, mint a telekomosnál.
Ez amugy ilyenkor rendes halozatnak szamit, vagy rendetlennek? :D
3,5% packet loss az elég sok, ilyenkor mi már bőven kapjuk az ügyfelektől a jelzéseket, hogy nem megy meg lassú, mi meg nyilván dobjuk tovább a szolgáltató felé. Úgyhogy ez már inkább a rendetlen.
"Sose a gép a hülye."
Nem megyek bele veled ugyanabba az értelmetlen vitába > nem velem vitazol, az UDP RFC-jevel...
nem megy meg lassú > dehat megy es nem lassu, gigabit. az, hogy nem erted mitol van packetloss es ez miert nem erdekes (TCP, meg olyan UDP stream ahol kutyat nem erdekel par packet eldobasa), az mar mas kerdes. :)
amugy azt mondjak kb 3%-ig elfogadhato a packetloss utana lesz eszreveheto lassulas, szoval ez eleg hatareset...
de a 3.5% az sok szerintem is, bar mikros WAN eseten esos idoben siman van ennyi, es megse panaszkodnak az userek, csak a monitoring jelez be ra, mondjuk az mar 2%-ra is.
es megse panaszkodnak az userek > tehat job's done. a modern high speed tcp/ip es routing implementacio megoldja neked ezt a kerdest. giga koruli uplinknel (megfelelo round trip time mellett) a par % retransmit nem okoz "erezheto" valtozast. azt hamarabb eszreveszed, ha "laggol a wifi" :)
Szóval, egyelőre konklúzió:
1. Az SNMP3-nak nagyobb az erőforrás igénye az autentikáció és a titkosítás miatt, így a kis gyenge routereknél ez azonnal látszik, hogy lassabban válaszol, lassabban adja az adatot.
2. Ha kívülről monitorozom, akkor a 0,3-0,4ms-es válaszidő helyett lesz min. 4ms, ami így alapból 10x-es delay.
3. És amúgy is történt valami ettől függetlenül is a hálózatban (azt még nem tudom mi), mert most visszarakva snmp2-re, ami mögött a zabbix proxy van, annak a routernek az snmpwalk-ja 4s fölött van (tehát itt nincs vpn meg semmi, max 1-2 switch).
"Sose a gép a hülye."
Milyen tűzfalak vannak az eszközök közt? Nagyon hasonlót tapasztalok én is, asa/ftd és pl wlc közt, de v3 vagy v2c az néha mindegy. Volt, hogy nem volt allow rule, de kerek 50%-ban működött, majd lett szabály és jó lett.
Alapvetően a zabbix az ami az első meg nem érkező item value esetén már bajosnak érzékeli. Ha jól sejtem, kb minden Cisco.