Snizeni rezie sitoveho provozu generovaneho Zabbixem

[split-brain]

Zdravim mistni odborniky!

Jelikoz jsem nebyl schopny najit odpoved na moje otazky, zkusim se zeptat tady:

1 - Jaka je ocekavatelna rezie sitoveho provozu generovaneho Zabbixem pri pouziti obecnych sablon a defaultniho nastaveni pro X monitorovanych hostu?
Jedna se mi o obecnou kalkulaci, na zaklade ktere budeme moci odvozovat dopad optimalizaci, tykajici se omezeni datoveho toku
(a pripadne poctu tcp sessions), vytvareneho Zabbix monitoringem.

2 - O kolik realne muzeme snizit mnozstvi dat prenasene Zabbix serverem pomoci snizeni cetnosti dotazu, pripadne snizenim poctu itemu?
Zadani je zredukovat datovy tok z/do zabbix serveru. V soucasne dobe mame aktivnich cca 700 hostu a 29000 itemu a datovy tok cca 3 Mb/s IN a 1 Mb/s OUT
(dat. tok jsme meli puvodne cca dvojnasobny).

Jedna se o mix VM (win, lin), fyz. serveru, webu a docker kontejneru. Samozrejme chceme zachovat realne funkcni a pouzitelny monitoring, nechceme snizovat rezii za kazdou cenu.
Budu rad za Vas pohled na vec, pripadne za nasmerovani, jak o tomto premyslet, dekuji.

Jakub

[hermanekt]

Zdravim,

obecna kalkulace neexistuje, ma to moc moznosti. Treba log, je neco jineho nez 1 item posilajci 1/0 jednou za minutu. Mam ale jinou radu, resp. 2. Pokud se jedna o usetreni co vejvetsiho sitoveho provozu, tak Zabbix Agent 2 pro vsechny aktivni checky pouziva kompresi dat. Takze to zasila do Zabbixu zabalene zde se jedna o pokles datove komunikace cca 10x. Dalsi moznosti je proxy, ktera take zasila data zabalene. Dival jsem se ted u zakaznika, kde je proxy v aktivnim rezimu a je tam 7Mbit/s odchozi, jenze to nema oddelene sitovky, takze cast je prave ten lokalni monitoring. Je tam 1200hostu 125000 itemu a 1550NVPS. Podle me tak tretina je odesilana do Zabbix serveru kdyz budu prisnej a ostatni je monitoring a rezie.

Tom

[split-brain]

Dekuji za odpoved, Tome.

Aktivni agenty (a pripadne proxy) mame u vzdalenych klientu, v nasi siti vyuzivame klienty pasivni. Ma aktivni klient nejake nevyhody, oproti pasivnimu? Resp. co vsechno zvazovat pri rozhodovani, zda prejit na aktivni klienty? Napr. vetsina sablon, ktere vyuzivame, byla v dobe, kdy jsme je nasazovali, dostupna pouze pro pasivni klienty.

Jakub

[gofree]

aktivni agenti maju podla mna 2 vyhody:

1. odlahcia zabbix server/proxy - pri predstave 1000+ pasivnych agentov kde iniciuje komunikaciu zabbix server/proxy je mi zle eg vacsinou byva problem otvorit komunikaciu zabbix server/proxy > 1000 x IP:10050. V pripade aktivnych agentov je komunikacia smerom na zabbix/proxy - inciuje ju agent a je lahsie presvedcit siete na otovrenie tejto komunikacie ( "many to one" oproti "one to many" ) Nepotrebujes vela pollerov ( cpu, ram, load , etc ). Staci ze snmp, http agent, jmx, simple check a dalsie ine su pasivne.
2. bezpecnost - pasivny agent pocuva na serveri port 10050 - bezpecaci nemaju radi sluzby co pocuvaju na serveri

PS zmenit formu item z agent passive na agent active je pomerne jednoduche - staci to zmenit v template ( Type )
PS2 je to vecny boj https://www.google.com/search?client...g+push+vs+pull

[split-brain]

Ahoj,

ozivuju stary post, jelikoz je to stale tema - lze snizit objem sessions v monitoringu prechodem z pasivnich agentu na aktivni?

Soucasny stav:

• Hostů: 1 049
• Itemů: 70 253
• Load proxy: 612.59 values/sec
• Sessions: 10.5 milionu / 24h
• Data: ~20 GB / 24h

Nejde tedy jen o zmenu smeru zahajovani komunikace (one-to-many vs. many-to-one) ale i o cetnost sessions.
ChatGPT tvrdi, ze cetnost active agent sessions se da upravit na agentovi pres BufferSend, BufferSize
a tim se da snizit celkovy objem sessions (v ramci monitoringu) pry az o rad.

Je tento odhad realny?

[Rudlafik]

Rada od NASA: udělej si výpočet a analýzu pak testuj. Až budeš mít hotovo testuj znovu a pak znovu a znovu až budeš mít relevantní tvrdá data. Tohle co řešíš je abstrakce, reálné testy Ti řeknou víc. Blížíš se k tzv: Paralýza analýzou (Prokrastinace maskovaná přípravou ), Don't let perfect be the enemy of good a Fail Fast nebo se zamyslet jestli to neni Overengineering - opravdu je nutné na tom pálit tolik času?.

[hermanekt]

Ahoj,

obecne ano, protoze ten aktivni dela to ze si to veci uklada do bufferu s lokalnim timestampem a bud to posle jednou za 5s a nebo kdyz je buffer plny hned driv to bylo 100 hodnot, ted je to 1000, takze to spis das tim casem. Takze ano muze to umoznit+ benefit pokud mas agent 2, tak to bezi komprimovane.

Muzes natahnout ten cas a melo by se ti to zlepsit ale pozor, ovlivni to vsecny casove triggery.

Jinak jak pise Rudlafik, vse je treba testovat vuci tvemu env.

Tom