QUIP: uz je to strasne davno, co jsme to takle zkouseli, ale rozdil v tom byl docela velkej. Musel jsem mit nastartovany hodne tech polleru a ty docela zatezovali CPU. Jenze tenkrat to bezelo na vyrazne starsim HW a byla to 2.x verze zabbixu. Takze prime srovnani nemam.

Timto si nejsem 100% jisty:
Jeden poller dokaze myslim obsluhovat jeden host a jeden item v case, takze v zasade potrebujes tolik polleru, kolik mas values per seconds.

SIRSPOOK: Diky za info. S MySQL si pohrat dokazu. Reseni problemu s vykonem MySQL je cast moji prace :) Takze ocenuju hlavne ten prehled o tom, jak se k te DB chova Zabbix, jak moc to narusta atd.

Jaky je vykonovy rozdil v tom, kdyz se Zabbix dotazuje jednotlivych agentu na data a v tom, kdyz agent ty data cpe na server? Zkousel jste to nekdo porovnavat?

RATTKIN: jeden stroj, zadna proxy. Je v tom jeden Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz, 2x samsung evo 850. V tomhle stavu to bezi uz asi 2 roky bez jedineho problemu. tuk tuk.
Verze zabbixu je stale jeste 3.2. Load 0.50. Snad by to slo jeste vyladit lip, ale nechtelo se mi tim uz ztracet vic casu...
Kdyz se pusti housekeeper, tak tam nejaky iowait naskoci. Stejne jako kdyz clovek da nejakou hloupou podminku do "latest data".

SIRSPOOK: dobře ty. Je to jen jeden server, bez proxy nebo databázových serverů? jaký cpu?

QUIP: uzitecny clanek: https://www.percona.com/blog/2014/11/14/optimizing-mysql-zabbix/

SNIPERCZE: innodb_file_per_table mam zapnuty, bez toho by to bylo uplne v haji, protoze pak se musi udelat jedine restore cele databaze, aby se misto uvolnilo. Ale ani takhle to neni idealni, jeste premyslim, ze zkusim table partitions po mesicich, abych pak mohl jen smazat starou partition (starou historii) a nemusel delat OPTIMIZE TABLE, ktery ve skutecnosti dela kopii cele tabulky a trva to silene dlouho.

QUIP: Autoregistrace funguje krasne, agent se ohlasi serveru a ten si ho ulozi, pripadne prida do skupin a temmplate (nastavujes akce stejne jako u triggeru). U zabbixu je problem (hlavne u mysql na innodb) ze jak uklada data a maze je, vznikaj hodne deravy tabulky - roste velikost. Urcite doporucuju zapnout v mysql innodb_file_per_table.

QUIP: databaze mohla mit kolem 50GB. Drzim vzdycky data za 7 dni a pak rok trendy. Kazdej stroj mohl v prumeru mit 50 itemu, mozna 100. Vzorkovaci frekvence od 30s do 4 hodin (median tak 5min)

SNIPERCZE: SNMP uz jsem zavrhnul a testuju to ted pres agenta a vlastni skripty. So far so good.
U SNMP se mi stala takova vec, ze autodiscovery naslo asi 500x polozku "memory" a pro kazdou sledovalo celkove, vyuzita, volna ... vygenerovalo to okolo 2000 items na jednom hostu a pak me docela prekvapilo, jak rychle roste objem databaze.

Takze se te zeptam - jak velka byla DB pro tech 300 serveru a kolik sledovanych polozek jsi tam mel? :)

QUIP: Hlavni vyhoda agenta je, ze vidi do systemu. Muze poustet skripty, tahat si data co nejsou k dispozici pres SNMP apod. Osobne servery hlidam agentem, routery/tiskarny apod. SNMP.

QUIP: Zabbix proxy se hodi pokud mas vic lokalit. V jedny lokalite nema moc vyznam, nejvetsi moje nasazeni zabbixu bylo asi 300 serveru (fyzicky, virtualy i kontejnery, vsude agent) + nejaky dalsi veci (switche, routery, par tiskaren) a bez problemu. Jenom jsem oddelil zabbix-server, databazi a webksicht na vlastni stroje. Plus doporucuju u velkejch instalaci rovnou nasadit postgresql.

QUIP: my proxy nemáme. kdyby nestačil výkon pro třech našich 300 agentů, tak první by bylo přidat třetí CPU nebo to dát z 7.2k HDD na něco rychlejšího.

Delal jste nekdo realne porovnani dopadu na vykon pri sifrovanem spojeni vs nesifrovane (mezi agentem a serverem)?
Pripadne i rozdily aktivni / pasivni checky?

SAMGARR: no tak o ne prijdes, kdyz bude mit vypadek proxy :)

QUIP: Nejde jen o vykon, zabbix-proxy ti umozni treba pseudo HA. Pri maintenance/vypadku zabbix-serveru neprijdes o data protoze je cachuje proxy.

SAMGARR: Zrovna to UI mi prijde jako to lepsi z toho, co jsem u podobny produktu videl, takze tady jsem uplne v miru. Jestli to bude na 30 stroju chtit zabbix-proxy, tak to pujde z domu. :) O tech proxy ctu v usecasech pri tisicich stroju a stovkach tisic sledovanych hodnot

QUIP: pokud ses v miru s desnym UI a horsi moznosti konfigurace config managementem tak Zabbix funguje. Doporucuju nepodcenit skalovani databaze a zabbix agenty nastrkat za zabbix-proxy... A na grafy a dashboardy Grafanu ;)

QUIP: už nás nebavilo řešit chybějící místo na disku a neproběhlé úlohy.

instalace zabbixe je jednoduchá a agent se instaluje taky jednoduše. frkneš tam defaultní template na operační systém, stáhneš z marketu nějakou template na databázi a za pár hodin uvidíš grafy.

Zacinam ted zkoumat moznosti Zabbixu (ted mam monitoring v Pandore, velmi zakladni), procitam spoustu dokumentace a how to, ale rad bych nejake info, cemu se vyhnout, nebo naopak, jak to udelat od nekoho, kdo ho v praxi nasazoval, konfiguroval a pouziva ho. Idealne v prostredi, kde se tim nesleduji sitove prvky, ale web servery, DB servery, mail servery. Je to nekolik desitek stroju, vsechno na FreeBSD

Takhle na zacatku stojim hlavne pred otazkou, jestli vsude instalovat Zabbix Agenta, nebo servery sledovat pres SNMP?

FreeBSD ma v zakladu bsnmpd, ktery toho moc neumi, jen nejake zakladni info o systemu, sitovem provozu a da se tam zapnout HOSTRES modul. Coz mi ale porad neresi treba sledovani Disk IOPS, provoz databaze, statistiky z antispamu, nebo monitoring ZFS (obsazenost, fragmentace), SMART status disku atp. Takze bych asi stejne vsude musel instalovat Net-SNMP.

Dokazal by mi teda nekdo nejak shrnout pro a proti pouziti Zabbix Agenta vs SNMP?
A jak do toho pak jeste naroubovat ty veci, co jsem schopen zjistit nejakym prikazem / shellscriptem, ale jak je pak cpat skrz SNMP?