Zabbix som naposledy skúšal pred niekoľkými rokmi a narazil som vtedy na viaceré problémy, ktoré ho robili z môjho pohľadu v porovnaní s "Nagios klonmi" horšie použiteľným. Spomínam si na nasledovné:
1. Nemožnosť upravovať frekvenciu testovania v prechodných stavoch.
U Nagiosu som bol zvyknutý na to, že testujem dostupnosť povedzme 1x za 10 minút a keď nastane error, tak to pretestujem ešte povedzme 2x v odstupe 1 minúta a ak sa chyba opakuje, tak generujem notifikáciu. Takto mám istotu, že nebudem zbytočne notifkovaný pri náhodnom jednorazovom zlyhaní testu (zlyhania musia byť minimálne 3), testovať mi normálne stačí iba raz za 10 minut a aj tak sa o poruche dozviem najneskôr do 12 minút od jej vzniku.
V Zabbixe toto možné nebolo a buď som teda testoval každú minútu stále (čo je zbytočný load) alebo ak som testoval iba každých 10 minút, tak som sa o probléme dozvedel až po 30 minútach, alebo som ho musel hlásiť už po jednom zlyhaní (čo zvyšovalo riziko falošných poplachov).
2. Veľmi obskurný jazyk na definíciu alertov so spústou obmedzení
Napríklad si pamätám, že ak mi dva testy (data sources) vracali údaj typu string (napríklad serial number nejakého deploynutého datasetu) tak nebolo možné zapísať alert ktorý by sa aktivoval na základe zhody/nezhody týchto reťazcov, porovnávať sa dali len numerické hodnoty.
A už vôbec nebolo možné napísať podmienku toho typu, že "aktivuj alert ak sa tieto dva údaje nezhodujú dlhšie ako 5 minút".
3. Limitované možnosti offloadovania testov na agenta
Štandardne všetky testy robil Zabbix server, bola aj možnosť nechať testy vykonávať agenta s tým, že ich výsledky iba "reportuje" na Zabbix. Problém ale bol, že tieto testy nevedel agent vykonávať paralelne, čiže ak sme ho nechali robiť viacero testov a jeden z nich z nejakého dôvodu trval dlho (čakalo sa na timeout), tak aj vykonávanie všetkých ostatných testov na danom agentovi bolo zastavené a "nestíhalo".
Toto sú hlavné problémy, čo si z testovania Zabbixu pamätám. Budem rád, ak niekto, kto pozná súčasné verzie Zabbixu, potvrdí, či to stále platí, alebo to už bolo nejako vyriešené.
Ad 1.
Zabbix resi obdobny problem jinak.
Sbira se normalne s periodou 1 minuta, pricemz na item je aplikovany preprocessing step "Throttling - Discard unchanged with heartbeat", takze hodnota je pollovana fyzicky co minutu, zapis do historicke DB co 10 minut, kdyz dojde k problemu, automaticky se ukladaji zmenene hodnoty s periodou minuta. Preprocessing i vlasni mereni se deji na proxy, server dostane uz predzvykany vysledek.
Tento mechanismus odhali chybu po 3 minutach, namisto 12, pri stejnych pozadavcich na historickou DB.
Jinak s nasazenim TimescaleDB time-series extension do postgresu spolu se zapnutou kompresi se vykonove dostavame uplne jinam, velka radu vykonnostnich omezeni uz neni potreba resit.
A pokud je precejen nutno pouzit vyse popsany mechanismus z duvodu omezeni loadu na merenem prvku, mozno lokalne naskriptovat a metriky zasilat asynchronne senderem, tak bych to resil ja. Dalsi alternativa je custom plugin v GO do Zabbix Agent2.
Aktivovat alert pokud se dve metriky neshodovaly vice nez 5 minut, slo vicemene vzdycky. Bud krapet neohrabane, ze se porovnavaly shody retezce ve vzorku LAST && LAST-1 && LAST-2, az se pokrylo cele pozadovane okno, nebo se udelal dodatecny computed item (nastaveny aby se neukladal do historic DB, jenom se bral z cache), s informaci 0/1 ok/bad a ten se vyhodnotil min(5m)=1.
Ad 2. Porovnavat stringy slo vzdycky, nyni je uz primo mozno aplikovat preprocessing step "Regex substr", vyparsovat ho cislo a ulozit jej numericky.
Ad 3. Zabbix agent1 psany v C mel v defaultni konfiguraci povolene 4 processing thready, po vycerpani threadu ostatni checky staly. Zabbix agent 2 je psany v GO a vsecko sere paralelne do gorutin. To ovsem nic nemeni na faktu, ze UserParameter skripty maji byt rychle a jednoduche, mely by skoncit do 5 sec, jinak je vhodne pouzit neco jineho. Typicky dlouhe checky nechat agentem jenom invokovat a vysledek posilat asynchronne zabbix senderem (pouziva stejny TCP port jako Zabix Agent v active modu, takze zde neni problem s firewall rules) Pripadne, nyni je moznost jednoducheho dopsani pluginu v GO do agenta2, ten pak muze uplne cokolivek. Treba novy Oracle monitoring je napsany jako modul do agent2 - sam si drzi session spojeni a provadi SQL dotazy do session views.
35 Odpovědí
15170 Zhlédnutí