Příští konference HighLoad++ se bude konat 6. a 7. dubna 2020 v Petrohradu Podrobnosti a vstupenky . HighLoad++ Moskva 2018. Hala “Moskva”. 9. listopadu, 15:00. Teze a .
* Monitoring – online a analytika.
* Základní omezení platformy ZABBIX.
* Řešení pro škálování analytického úložiště.
* Optimalizace serveru ZABBIX.
* Optimalizace uživatelského rozhraní.
* Zkušenosti s provozem systému při zatížení více než 40 XNUMX NVPS.
* Stručné závěry.
Michail Makurov (dále jen MM): - Ahoj všichni!
Maxim Chernetsov (dále jen MCH): - Dobré odpoledne!
MM: – Dovolte mi představit Maxima. Max je talentovaný inženýr, nejlepší síťař, kterého znám. Maxim se zabývá sítěmi a službami, jejich rozvojem a provozem.
MCH: – A rád bych vám řekl o Michailovi. Michail je vývojář v jazyce C. Pro naši společnost napsal několik řešení pro zpracování vysoce zátěžového provozu. Žijeme a pracujeme na Uralu, ve městě drsných mužů Čeljabinsk, ve společnosti Intersvjaz. Naše společnost je poskytovatelem služeb internetu a kabelové televize pro jeden milion lidí v 16 městech.
MM: – A stojí za to říci, že Intersvyaz je mnohem víc než jen poskytovatel, je to IT společnost. Většinu našich řešení vytváří naše IT oddělení.
A: od serverů zpracovávajících provoz až po call centrum a mobilní aplikace. IT oddělení má nyní asi 80 lidí s velmi, velmi různorodými kompetencemi.
O Zabbixu a jeho architektuře
MCH: – A teď se pokusím vytvořit osobní rekord a během jedné minuty říct, co je Zabbix (dále jen „Zabbix“).
Zabbix se staví jako hotový monitorovací systém na podnikové úrovni. Má mnoho funkcí, které usnadňují život: pokročilá pravidla eskalace, API pro integraci, seskupování a automatickou detekci hostitelů a metrik. Zabbix má tzv. škálovací nástroje – proxy. Zabbix je open source systém.
Krátce o architektuře. Můžeme říci, že se skládá ze tří složek:
- Server. Napsáno v C. S poměrně složitým zpracováním a přenosem informací mezi vlákny. V něm probíhá veškeré zpracování: od příjmu až po uložení do databáze.
- Všechna data jsou uložena v databázi. Zabbix podporuje MySQL, PostreSQL a Oracle.
- Webové rozhraní je napsáno v PHP. Na většině systémů je dodáván se serverem Apache, ale funguje efektivněji v kombinaci s nginx + php.
Dnes bychom chtěli vyprávět jeden příběh ze života naší společnosti související se Zabbixem...
Příběh ze života společnosti Intersvyaz. Co máme a co potřebujeme?
před 5 nebo 6 měsíci. Jeden den po práci...
MCH: - Míšo, ahoj! Jsem rád, že se mi tě podařilo chytit - je tu rozhovor. Opět jsme měli problémy s monitorováním. Při velké havárii bylo vše pomalé a nebyly žádné informace o stavu sítě. Bohužel to není poprvé, co se to stalo. Potřebuji tvou pomoc. Zajistěte, aby naše monitorování fungovalo za všech okolností!
MM: - Ale nejdřív se synchronizujte. Už jsem se tam pár let nepodíval. Pokud si pamatuji, opustili jsme Nagios a přešli na Zabbix asi před 8 lety. A nyní se zdá, že máme 6 výkonných serverů a asi tucet proxy. pletu něco?
MCH: - Skoro. 15 serverů, z nichž některé jsou virtuální stroje. Nejdůležitější je, že nás to nespasí ve chvíli, kdy to nejvíc potřebujeme. Jako nehoda - servery se zpomalí a nic nevidíte. Snažili jsme se optimalizovat konfiguraci, ale to neposkytlo optimální zvýšení výkonu.
MM: - To je jasné. Díval jsi se na něco, už jsi něco vyhrabal z diagnostiky?
MCH: – První věc, se kterou se musíte vypořádat, je databáze. MySQL se neustále načítá, ukládá nové metriky, a když Zabbix začne generovat hromadu událostí, databáze přejde doslova na pár hodin do provozu. Už jsem vám říkal o optimalizaci konfigurace, ale doslova letos aktualizovali hardware: servery mají více než sto gigabajtů paměti a diskových polí na SSD RAIDech – nemá smysl to dlouhodobě lineárně zvyšovat. Co děláme?
MM: - To je jasné. MySQL je obecně LTP databáze. Zřejmě se již nehodí pro ukládání archivu metrik naší velikosti. Pojďme na to přijít.
MCH: - Pojďme!
Integrace Zabbix a Clickhouse jako výsledek hackathonu
Po nějaké době jsme získali zajímavá data:
Většinu místa v naší databázi zabíral archiv metrik a méně než 1 % bylo využito pro konfiguraci, šablony a nastavení. V té době jsme již více než rok provozovali řešení Big data založené na Clickhouse. Směr pohybu nám byl jasný. Na našem jarním Hackathonu jsem napsal integraci Zabbixu s Clickhouse pro server a frontend. V té době už měl Zabbix podporu pro ElasticSearch a rozhodli jsme se je porovnat.
Srovnání Clickhouse a Elasticsearch
MM: – Pro srovnání jsme vygenerovali stejnou zátěž, jakou poskytuje server Zabbix, a podívali jsme se, jak by se systémy chovaly. Data jsme zapisovali v dávkách po 1000 řádcích pomocí CURL. Předem jsme předpokládali, že Clickhouse bude efektivnější pro profil zatížení, který dělá Zabbix. Výsledky dokonce předčily naše očekávání:
Za stejných testovacích podmínek zapsal Clickhouse třikrát více dat. Oba systémy přitom spotřebovávaly velmi efektivně (malé množství zdrojů) při čtení dat. Elastics však při nahrávání vyžadoval velké množství procesoru:
Celkově Clickhouse výrazně předčil Elastix ve spotřebě procesoru a rychlosti. Současně díky kompresi dat využívá Clickhouse 11krát méně pevného disku a provádí přibližně 30krát méně diskových operací:
MCH: – Ano, práce Clickhouse s diskovým subsystémem je implementována velmi efektivně. Můžete použít obrovské SATA disky pro databáze a dosáhnout rychlosti zápisu stovek tisíc řádků za sekundu. Předinstalovaný systém podporuje sharding, replikaci a je velmi snadno konfigurovatelný. S jeho celoročním používáním jsme více než spokojeni.
Chcete-li optimalizovat zdroje, můžete nainstalovat Clickhouse vedle vaší stávající hlavní databáze a ušetřit tak spoustu času CPU a diskových operací. Archiv metrik jsme přesunuli do stávajících clusterů Clickhouse:
Odlehčili jsme hlavní databázi MySQL natolik, že jsme ji mohli spojit na jednom počítači se serverem Zabbix a opustit dedikovaný server pro MySQL.
Jak funguje hlasování v Zabbix?
4 měsíci
MM: – Můžeme zapomenout na problémy se základnou?
MCH: - To je jisté! Dalším problémem, který musíme vyřešit, je pomalý sběr dat. Nyní je všech našich 15 proxy serverů přetíženo SNMP a procesy dotazování. A neexistuje žádný způsob, než instalovat nové a nové servery.
MM: - Skvělý. Ale nejprve nám řekněte, jak funguje hlasování v Zabbixu?
MCH: – Stručně řečeno, existuje 20 typů metrik a tucet způsobů, jak je získat. Zabbix může sbírat data buď v režimu „request-response“, nebo čekat na nová data přes „Trapper Interface“.
Za zmínku stojí, že v původním Zabbixu je tato metoda (Trapper) nejrychlejší.
Pro distribuci zátěže existují proxy servery:
Proxy mohou provádět stejné sběrné funkce jako server Zabbix, přijímat z něj úkoly a odesílat shromážděné metriky prostřednictvím rozhraní Trapper. Toto je oficiálně doporučený způsob rozložení zátěže. Proxy jsou také užitečné pro monitorování vzdálené infrastruktury provozované přes NAT nebo pomalý kanál:
MM: – S architekturou je vše jasné. Musíme se podívat na zdroje...
O pár dní později
Příběh o tom, jak vyhrál nmap fping
MM: "Myslím, že jsem něco vykopal."
MCH: - Řekni mi to!
MM: – Zjistil jsem, že při kontrole dostupnosti Zabbix kontroluje maximálně 128 hostitelů najednou. Zkusil jsem zvýšit toto číslo na 500 a odstranit interval mezi pakety v jejich pingu (ping) - to zdvojnásobilo výkon. Ale chtěl bych větší čísla.
MCH: – Ve své praxi musím někdy zkontrolovat dostupnost tisíců hostitelů a nikdy jsem neviděl nic rychlejšího než nmap. Jsem si jistý, že toto je nejrychlejší způsob. Pojďme to zkusit! Potřebujeme výrazně zvýšit počet hostitelů na iteraci.
MM: – Zkontrolujte více než pět set? 600?
MCH: - Alespoň pár tisíc.
MM: - OK. Nejdůležitější věc, kterou jsem chtěl říci, je, že jsem zjistil, že většina dotazování v Zabbixu probíhá synchronně. Rozhodně jej musíme změnit na asynchronní režim. Potom můžeme dramaticky zvýšit počet metrik shromážděných průzkumníky, zvláště pokud zvýšíme počet metrik na iteraci.
MCH: - Skvělý! A kdy?
MM: – Jako obvykle, včera.
MCH: – Porovnali jsme obě verze fping a nmap:
Na velkém počtu hostitelů se očekávalo, že nmap bude až pětkrát efektivnější. Protože nmap kontroluje pouze dostupnost a dobu odezvy, přesunuli jsme výpočet ztrát na triggery a výrazně zkrátili intervaly kontroly dostupnosti. Zjistili jsme, že optimální počet hostitelů pro nmap je kolem 4 tisíc na iteraci. Nmap nám umožnil třikrát snížit náklady na CPU na kontroly dostupnosti a zkrátit interval ze 120 sekund na 10.
Optimalizace hlasování
MM: „Pak jsme začali dělat průzkumy veřejného mínění. Zajímala nás především detekce SNMP a agenti. V Zabbix se dotazování provádí synchronně a byla přijata speciální opatření ke zvýšení účinnosti systému. V synchronním režimu způsobuje nedostupnost hostitele významné zhoršení dotazování. Existuje celý systém stavů, existují speciální procesy - takzvané nedostupné pollery, které pracují pouze s nedosažitelnými hostiteli:
Toto je komentář, který demonstruje stavovou matici, veškerou složitost systému přechodů, které jsou nutné k tomu, aby systém zůstal účinný. Samotné synchronní dotazování je navíc poměrně pomalé:
Proto pro nás tisíce poler streamů na desítkách proxy nemohly shromáždit potřebné množství dat. Asynchronní implementace vyřešila nejen problémy s počtem vláken, ale také výrazně zjednodušila stavový systém nedostupných hostitelů, protože pro jakýkoli počet kontrolovaný v jedné iteraci dotazování byla maximální doba čekání 1 timeout:
Kromě toho jsme upravili a vylepšili systém dotazování na požadavky SNMP. Faktem je, že většina lidí nemůže reagovat na více požadavků SNMP současně. Proto jsme vytvořili hybridní režim, kdy se dotazování SNMP stejného hostitele provádí asynchronně:
To se provádí pro celou smečku hostitelů. Tento režim nakonec není pomalejší než zcela asynchronní, protože dotazování na jeden a půl sta hodnot SNMP je stále mnohem rychlejší než 1 časový limit.
Naše experimenty ukázaly, že optimální počet požadavků v jedné iteraci je při SNMP dotazování přibližně 8 tisíc. Celkově nám přechod do asynchronního režimu umožnil zrychlit výkon dotazování 200krát, několik setkrát.
MCH: – Výsledné optimalizace dotazování ukázaly, že se můžeme nejen zbavit všech proxy, ale také zkrátit intervaly mnoha kontrol a proxy již nebudou potřeba jako způsob sdílení zátěže.
Asi před třemi měsíci
Změňte architekturu – zvyšte zátěž!
MM: - Maxi, je čas být produktivní? Potřebuji výkonný server a dobrého inženýra.
MCH: - Dobře, pojďme to naplánovat. Je nejvyšší čas přejít z mrtvého bodu 5 tisíc metrik za sekundu.
Ráno po upgradu
MCH: - Míšo, aktualizovali jsme se, ale ráno jsme se vrátili... Hádej, jaké rychlosti se nám podařilo dosáhnout?
MM: – maximálně 20 tisíc.
MCH: -Ano, 25! Bohužel jsme tam, kde jsme začali.
MM: - Proč? Dělal jsi nějakou diagnostiku?
MCH: - Ano jistě! Zde je například zajímavý top:
MM: - Pojďme se dívat. Vidím, že jsme vyzkoušeli velké množství dotazovacích vláken:
Ale zároveň nedokázali recyklovat systém ani z poloviny:
A celkový výkon je poměrně malý, asi 4 tisíce metrik za sekundu:
Je tu ještě něco dalšího?
MCH: – Ano, stopa jednoho z tazatelů:
MM: – Zde jasně vidíte, že proces dotazování čeká na „semafory“. Toto jsou zámky:
MCH: - Nejasné.
MM: – Podívejte, toto je podobné situaci, kdy se hromada vláken snaží pracovat se zdroji, se kterými může pracovat pouze jeden. Pak vše, co mohou udělat, je sdílet tento zdroj v průběhu času:
A celkový výkon práce s takovým zdrojem je omezen rychlostí jednoho jádra:
Tento problém lze vyřešit dvěma způsoby.
Upgradujte hardware stroje, přejděte na rychlejší jádra:
Nebo změnit architekturu a zároveň změnit zatížení:
MCH: – Mimochodem, na testovacím stroji použijeme méně jader než na bojovém, ale frekvence na jádro jsou 1,5krát rychlejší!
MM: - Průhledná? Musíte se podívat na kód serveru.
Cesta k datům na serveru Zabbix
MCH: – Abychom na to přišli, začali jsme analyzovat, jak jsou data přenášena uvnitř serveru Zabbix:
Skvělý obrázek, že? Pojďme si to projít krok za krokem, aby to bylo víceméně jasné. Za shromažďování dat jsou zodpovědná vlákna a služby:
Přenášejí shromážděné metriky přes soket do správce preprocesoru, kde jsou uloženy do fronty:
„Správce preprocesoru“ přenáší data svým pracovníkům, kteří provádějí pokyny pro předběžné zpracování a vracejí je zpět přes stejný soket:
Poté je správce preprocesoru uloží do mezipaměti historie:
Odtud je berou potápěči historie, kteří vykonávají poměrně hodně funkcí: například počítají triggery, naplňují mezipaměť hodnot a hlavně ukládají metriky do úložiště historie. Obecně je proces složitý a velmi matoucí.
MM: – První věc, kterou jsme viděli, bylo, že většina vláken soutěží o takzvanou „konfigurační mezipaměť“ (oblast paměti, kde jsou uloženy všechny konfigurace serveru). Vlákna zodpovědná za shromažďování dat provádějí zejména hodně blokování:
...protože konfigurace ukládá nejen metriky s jejich parametry, ale také fronty, ze kterých si dotazovači berou informace o dalším postupu. Když je mnoho polerů a jeden blokuje konfiguraci, ostatní čekají na požadavky:
Pollers by neměli být v konfliktu
První věc, kterou jsme udělali, bylo rozdělení fronty na 4 části a umožnit dotazovačům zablokovat tyto fronty, tyto části současně, za bezpečných podmínek:
Tím byla odstraněna konkurence pro konfigurační mezipaměť a výrazně se zvýšila rychlost pollerů. Pak jsme ale narazili na skutečnost, že správce preprocesoru začal hromadit frontu úloh:
Správce preprocesoru musí být schopen stanovit priority
Stalo se tak v případech, kdy mu chyběl výkon. Pak už mohl jen shromažďovat požadavky z procesů shromažďování dat a sčítat jejich vyrovnávací paměť, dokud nespotřeboval veškerou paměť a nespadl:
Abychom tento problém vyřešili, přidali jsme druhou zásuvku, která byla určena speciálně pro pracovníky:
Manažer preprocesoru tak měl možnost upřednostnit svou práci, a pokud se vyrovnávací paměť zvětší, úkolem je zpomalit odstraňování, což dává pracovníkům příležitost tuto vyrovnávací paměť využít:
Pak jsme zjistili, že jedním z důvodů zpomalení byli samotní pracovníci, protože soutěžili o zdroj, který byl pro jejich práci zcela nedůležitý. Tento problém jsme zdokumentovali jako opravu chyby a již byl vyřešen v nových verzích Zabbix:
Zvýšíme počet zásuvek - dostaneme výsledek
Dále se sám správce preprocesoru stal úzkým hrdlem, protože se jedná o jedno vlákno. Spočíval na rychlosti jádra a poskytoval maximální rychlost asi 70 tisíc metrik za sekundu:
Proto jsme vyrobili čtyři, se čtyřmi sadami zásuvek, dělníky:
A to nám umožnilo zvýšit rychlost na přibližně 130 tisíc metrik:
Nelinearita růstu je vysvětlena skutečností, že se objevila konkurence o mezipaměť historie. Soutěžili o něj 4 manažeři preprocesorů a potápěči historie. V tuto chvíli jsme na testovacím stroji přijímali přibližně 130 tisíc metrik za sekundu a využívali jej přibližně 95 % procesoru:
Asi před 2,5 měsíci
Odmítnutí ze strany snmp-community zvýšilo NVP jedenapůlkrát
MM: – Maxi, potřebuji nové testovací auto! Do toho současného se už nevejdeme.
MCH: - Co máš teď?
MM: – Nyní – 130 XNUMX NVP a procesor připravený na police.
MCH: - Páni! Chladný! Počkejte, mám dvě otázky. Podle mých výpočtů se naše potřeba pohybuje kolem 15-20 tisíc metrik za sekundu. Proč potřebujeme více?
MM: "Chci dokončit práci." Chtěl bych vidět, kolik toho z tohoto systému dokážeme vymáčknout.
MCH: - Ale…
MM: "Ale pro obchod je to k ničemu."
MCH: - To je jasné. A druhá otázka: dokážeme to, co nyní máme, podpořit sami, bez pomoci vývojáře?
MM: - Nemyslím. Změna způsobu fungování konfigurační mezipaměti je problém. Ovlivňuje změny ve většině vláken a je poměrně obtížné jej udržovat. S největší pravděpodobností bude velmi obtížné ji udržovat.
MCH: "Pak potřebujeme nějakou alternativu."
MM: - Existuje taková možnost. Můžeme přejít na rychlá jádra, přičemž opustíme nový systém zamykání. Stále se dostaneme na výkon 60-80 tisíc metrik. Zároveň můžeme ponechat veškerý zbytek kódu. Clickhouse a asynchronní dotazování bude fungovat. A bude snadné ho udržovat.
MCH: - Úžasný! Navrhuji, abychom se zastavili zde.
Po optimalizaci serverové strany jsme konečně mohli spustit nový kód do výroby. Některé změny jsme opustili ve prospěch přechodu na stroj s rychlými jádry a minimalizace počtu změn kódu. Také jsme zjednodušili konfiguraci a odstranili makra v datových položkách, kde to bylo možné, protože zavádějí další zamykání.
Například opuštění makra snmp-community, které se často vyskytuje v dokumentaci a příkladech, v našem případě umožnilo další zrychlení NVP asi 1,5krát.
Po dvou dnech ve výrobě
Odebírání vyskakovacích oken historie incidentů
MCH: – Míšo, používáme systém dva dny a všechno funguje. Ale jen když všechno funguje! Naplánovali jsme práci s převodem poměrně velkého segmentu sítě a znovu jsme rukama kontrolovali, co se zvedlo a co ne.
MM: - To nemůže být! Vše jsme zkontrolovali 10x. Server okamžitě řeší i úplnou nedostupnost sítě.
MCH: - Ano, rozumím všemu: server, databáze, top, austat, logy - všechno je rychlé... Ale podíváme se na webové rozhraní a na serveru je procesor „v polici“ a toto:
MM: - To je jasné. Podívejme se na web. Zjistili jsme, že v situaci, kdy došlo k velkému počtu aktivních incidentů, začala většina živých widgetů fungovat velmi pomalu:
Důvodem bylo generování vyskakovacích oken historie incidentů, která se generují pro každou položku v seznamu. Proto jsme upustili od generování těchto oken (okomentovali 5 řádků v kódu) a tím se naše problémy vyřešily.
Doba načítání widgetů, i když jsou zcela nedostupné, se zkrátila z několika minut na pro nás přijatelných 10-15 sekund a historii lze stále zobrazit kliknutím na čas:
Po práci. před 2 měsíci
MCH: - Míšo, odcházíš? Musíme si promluvit.
MM: - Neměl jsem v úmyslu. Zase něco se Zabbixem?
MCH: - Ne, klid! Chtěl jsem jen říct: všechno funguje, děkuji! Mám pivo.
Zabbix je efektivní
Zabbix je poměrně univerzální a bohatý systém a funkce. Může být použit pro malé instalace ihned po vybalení, ale jak rostou potřeby, musí být optimalizován. Chcete-li uložit velký archiv metrik, použijte vhodné úložiště:
- můžete využít vestavěné nástroje v podobě integrace s Elasticsearch nebo nahrávání historie do textových souborů (dostupné od verze 4);
- Můžete využít našich zkušeností a integrace s Clickhouse.
Chcete-li dramaticky zvýšit rychlost shromažďování metrik, shromažďujte je pomocí asynchronních metod a přenášejte je přes rozhraní trapperu na server Zabbix; nebo můžete použít patch, aby byly pollery Zabbix asynchronní.
Zabbix je napsán v C a je docela efektivní. Vyřešení několika architektonických úzkých míst umožňuje dále zvyšovat jeho výkon a podle našich zkušeností získat více než 100 tisíc metrik na jednoprocesorovém stroji.
Stejný patch Zabbix
MM: – Chci přidat několik bodů. Celá aktuální zpráva, všechny testy, čísla jsou uvedeny pro konfiguraci, kterou používáme. Nyní z něj odebíráme přibližně 20 tisíc metrik za sekundu. Pokud se snažíte pochopit, zda to pro vás bude fungovat, můžete porovnávat. To, o čem se dnes diskutovalo, je zveřejněno na GitHubu ve formě opravy:
Patch obsahuje:
- plná integrace s Clickhouse (zabbix server i frontend);
- řešení problémů se správcem preprocesoru;
- asynchronní dotazování.
Patch je kompatibilní se všemi verzemi 4, včetně lts. S největší pravděpodobností bude s minimálními změnami fungovat na verzi 3.4.
Děkuji vám za pozornost.
otázky
Otázka z publika (dále – A): – Dobré odpoledne! Prosím, řekněte mi, máte plány na intenzivní interakci s týmem Zabbix nebo s nimi s vámi, aby to nebyla záplata, ale normální chování Zabbix?
MM: – Ano, některé změny určitě provedeme. Něco se stane, něco v patchi zůstane.
A: – Velice vám děkuji za skvělou zprávu! Řekněte mi prosím, po aplikaci opravy zůstane podpora od Zabbixu a jak pokračovat v aktualizaci na vyšší verze? Bude možné aktualizovat Zabbix po vašem patchi na 4.2, 5.0?
MM: – Nemohu říci nic o podpoře. Kdybych byl technickou podporou Zabbix, pravděpodobně bych řekl ne, protože toto je kód někoho jiného. Pokud jde o kódovou základnu 4.2, naše pozice je: „Pohneme se časem a budeme se aktualizovat na další verzi.“ Proto budeme nějakou dobu zveřejňovat patch pro aktualizované verze. Již jsem řekl ve zprávě: počet změn s verzemi je stále poměrně malý. Myslím, že přechod z 3.4 na 4 nám trval asi 15 minut.Něco se tam změnilo, ale ne moc důležité.
A: – Plánujete tedy podporovat svůj patch a můžete jej bezpečně nainstalovat do výroby a v budoucnu nějakým způsobem přijímat aktualizace?
MM: – Důrazně to doporučujeme. To nám řeší spoustu problémů.
MCH: – Ještě jednou upozorňuji na to, že změny, které se netýkají architektury a netýkají se blokování či front, jsou modulární, jsou v samostatných modulech. I s drobnými změnami je můžete poměrně snadno udržovat.
MM: – Pokud vás zajímají podrobnosti, pak „Clickhouse“ využívá tzv. historickou knihovnu. Je rozvázaný - je to kopie podpěry Elastics, to znamená, že je konfigurovatelný. Volání mění pouze anketáře. Věříme, že to bude fungovat ještě dlouho.
A: - Díky moc. Řekněte mi, existuje nějaká dokumentace provedených změn?
MM: – Dokumentace je záplata. Je zřejmé, že se zavedením Clickhouse, se zavedením nových typů pollerů vznikají nové možnosti konfigurace. Odkaz z posledního snímku obsahuje krátký popis, jak jej používat.
O nahrazení fping nmapem
A: – Jak jste to nakonec provedli? Můžete uvést konkrétní příklady: máte strappery a externí skript? Co nakonec zkontroluje tak velké množství hostitelů tak rychle? Jak těžíte tyto hostitele? Potřebujeme je nějak nakrmit do nmapu, odněkud je získat, vložit, něco spustit?..
MM: - Chladný. Velmi správná otázka! Jde o to. Upravili jsme knihovnu (ICMP ping, součást Zabbixu) pro ICMP kontroly, které udávají počet paketů - jeden (1) a kód se snaží použít nmap. To znamená, že se jedná o vnitřní práci Zabbix, která se stala vnitřní prací pingla. V souladu s tím není vyžadována žádná synchronizace nebo použití lapače. Bylo to provedeno záměrně, abychom systém nechali nedotčený a nemuseli se zabývat synchronizací dvou databázových systémů: co zkontrolovat, nahrát přes poler a je náš upload nefunkční?.. To je mnohem jednodušší.
A: – Funguje to i pro proxy?
MM: – Ano, ale nekontrolovali jsme. Kód dotazování je stejný v Zabbixu i na serveru. Měl by pracovat. Dovolte mi ještě jednou zdůraznit: výkon systému je takový, že nepotřebujeme proxy.
MCH: - Správná odpověď na otázku je: "Proč potřebujete proxy s takovým systémem?" Jen kvůli NAT nebo monitorování přes nějaký pomalý kanál...
A: – A vy používáte Zabbix jako alertor, jestli tomu dobře rozumím. Nebo se vaše grafika (kde je archivní vrstva) přesunula do jiného systému, jako je Grafana? Nebo tuto funkci nevyužíváte?
MM: – Ještě jednou zdůrazním: dosáhli jsme úplné integrace. Naléváme do Clickhouse historii, ale zároveň jsme změnili php frontend. Php frontend jde do Clickhouse a dělá veškerou grafiku odtud. Zároveň, abych byl upřímný, máme část, která vytváří data v jiných grafických zobrazovacích systémech ze stejného Clickhouse, ze stejných dat Zabbix.
MCH: – Také v „Grafanu“.
Jak se rozhodovalo o alokaci zdrojů?
A: – Podělte se o trochu své vnitřní kuchyně. Jak došlo k rozhodnutí, že je nutné vyčlenit prostředky na seriózní zpracování produktu? To jsou obecně určitá rizika. A řekněte mi prosím v souvislosti s tím, že se chystáte podporovat nové verze: jak toto rozhodnutí ospravedlňuje z pohledu managementu?
MM: – Zřejmě jsme nevyprávěli drama dějin příliš dobře. Ocitli jsme se v situaci, kdy bylo potřeba něco udělat, a šli jsme v podstatě se dvěma paralelními týmy:
- Jedním z nich bylo spuštění monitorovacího systému využívajícího nové metody: monitoring jako službu, standardní sadu open source řešení, které kombinujeme a následně se snažíme změnit obchodní proces, abychom mohli pracovat s novým monitorovacím systémem.
- Zároveň jsme měli nadšeného programátora, který to dělal (o sobě). Tak se stalo, že vyhrál.
A: – A jaká je velikost týmu?
MCH: - Je před vámi.
A: – Takže jako vždy potřebujete vášnivého?
MM: – Nevím, co je to vášnivec.
A: - V tomto případě zřejmě vy. Děkuji moc, jste skvělí.
MM: - Dík.
O záplatách pro Zabbix
A: – Pro systém, který používá proxy (například v některých distribuovaných systémech), je možné adaptovat a patchovat, řekněme, pollery, proxy a částečně i samotný preprocesor Zabbixu; a jejich interakce? Je možné optimalizovat stávající vývoj pro systém s více proxy servery?
MM: – Vím, že server Zabbix je sestaven pomocí proxy (kód je zkompilován a získán). Ve výrobě jsme to nezkoušeli. Nejsem si tím jistý, ale myslím, že správce preprocesoru se v proxy nepoužívá. Úkolem proxy je převzít sadu metrik ze Zabbix, sloučit je (zaznamenává také konfiguraci, lokální databázi) a vrátit ji zpět serveru Zabbix. Server sám pak provede předběžné zpracování, když jej obdrží.
Zájem o proxy je pochopitelný. Prověříme to. To je zajímavé téma.
A: – Myšlenka byla tato: pokud můžete opravit pollery, můžete je opravit na proxy a opravit interakci se serverem a přizpůsobit preprocesor pro tyto účely pouze na serveru.
MM: – Myslím, že je to ještě jednodušší. Vezmete kód, použijete opravu a poté jej nakonfigurujete tak, jak potřebujete – shromáždíte proxy servery (například s ODBC) a distribuujete opravený kód mezi systémy. V případě potřeby - shromážděte proxy, v případě potřeby - server.
A: – S největší pravděpodobností nebudete muset dodatečně opravovat přenos proxy na server?
MCH: - Ne, je to standardní.
MM: – Ve skutečnosti jeden z nápadů nezazněl. Vždy jsme udržovali rovnováhu mezi explozí nápadů a množstvím změn a snadnou podporou.
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com