(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 :)
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."