Dohledový systém

Re:Dohledový systém
« Odpověď #30 kdy: 11. 01. 2021, 12:17:12 »
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é.



Re:Dohledový systém
« Odpověď #31 kdy: 11. 01. 2021, 13:53:30 »
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.

Re:Dohledový systém
« Odpověď #32 kdy: 11. 01. 2021, 14:35:03 »
Záleží na velikosti a dynamice prostředí.
Sám provozuju monitoring nad nižšími stovkami nodů (fyzické, virtuály, kontejnery) v Icinga2. S integrovanými metrikami v Graphite, správou přes Ansible (při deploy služby se automaticky doplní i příslušné checky) a notifikacemi přes PagerDuty je to prostředí s jednoduchou správou, rychlou učící křivkou a dostatečným výkonem.
« Poslední změna: 11. 01. 2021, 14:37:33 od lazywriter »

Re:Dohledový systém
« Odpověď #33 kdy: 11. 01. 2021, 14:41:59 »
Ad 2. Porovnavat stringy slo vzdycky

Tak to teda rozhodne nešlo, keď som to ja testoval, tak vyhodnocovať v trigeroch nenumerické hodnoty nebolo možné.

Pozrel som si teraz dokumentáciu a práca so stringami je novinka verzie 5.0 vydanej pred pol rokom, viď. druhy odstavec v nasledovnom texte:
https://www.zabbix.com/documentation/5.0/manual/introduction/whatsnew500

A to stále jediná operácia, čo sa dá so tringami spraviť, je porovnať dva stringy na zhodu/nezhodu, nič komplikovanejšie ako napr. porovnanie substringov možné nie je.

A presne takto si ten Zabbix pamätám, že ten jazyk/syntax na definíciu trigerov bol značne obmedzený a plný nepochopiteľných absurdít.


Re:Dohledový systém
« Odpověď #34 kdy: 12. 01. 2021, 13:23:13 »
Zatím jsme dospěl k závěru, že se podívám na Zabbix.

Ve čtvrtek je webinář na téma Poznejte Zabbix Agent 2 a v pátek Quick introduction to Zabbix, tak se na ně podívám a zkusím si s tím pak pohrát.

Potvrdili jste mi můj pocit, že od dob Nagiosu přece jen k nějakým posunům došlo, dám jim tedy šanci. A Nagios si nechám jako fallback řešení.

Děkuji Vám za dosud poskytnuté konzultace a pohledy.


Re:Dohledový systém
« Odpověď #35 kdy: 13. 01. 2021, 12:15:41 »
Ad 2. Porovnavat stringy slo vzdycky

Tak to teda rozhodne nešlo, keď som to ja testoval, tak vyhodnocovať v trigeroch nenumerické hodnoty nebolo možné.

Pozrel som si teraz dokumentáciu a práca so stringami je novinka verzie 5.0 vydanej pred pol rokom, viď. druhy odstavec v nasledovnom texte:
https://www.zabbix.com/documentation/5.0/manual/introduction/whatsnew500

A to stále jediná operácia, čo sa dá so tringami spraviť, je porovnať dva stringy na zhodu/nezhodu, nič komplikovanejšie ako napr. porovnanie substringov možné nie je.

A presne takto si ten Zabbix pamätám, že ten jazyk/syntax na definíciu trigerov bol značne obmedzený a plný nepochopiteľných absurdít.
To, že máte nějaká očekávání a ono to nejde podle nich neznamená, že to nejde nějak jinak. Níže odkaz na dokumentaci Zabbix 2.0, Example 6, kde se přímo testuje na konkrétní substring (funkce str()).
https://www.zabbix.com/documentation/2.0/manual/config/triggers/expression

P.S.: Většina vašich výtek jsou nesmysly, jediné s čím souhlasím je, že zápis je nepřehledný. Možnosti konfigurace triggerů v Zabbixu většinou dalece převyšují schopnosti jiných systémů (i komerčních).