Ďalšia konferencia HighLoad++ sa bude konať 6. a 7. apríla 2020 v Petrohrade Podrobnosti a vstupenky . HighLoad++ Moskva 2018. Hala “Moskva”. 9. novembra, 15:00. Tézy a .
* Monitorovanie – online a analytika.
* Základné obmedzenia platformy ZABBIX.
* Riešenie pre škálovanie analytického úložiska.
* Optimalizácia servera ZABBIX.
* Optimalizácia používateľského rozhrania.
* Skúsenosti s prevádzkou systému pri zaťažení viac ako 40 XNUMX NVPS.
* Stručné závery.
Michail Makurov (ďalej len MM): - Ahojte všetci!
Maxim Chernetsov (ďalej len MCH): - Dobrý deň!
MM: – Dovoľte mi predstaviť Maxima. Max je talentovaný inžinier, najlepší networker, akého poznám. Maxim sa zaoberá sieťami a službami, ich rozvojom a prevádzkou.
MCH: – A rád by som vám povedal o Michailovi. Michail je vývojár v jazyku C. Pre našu spoločnosť napísal niekoľko riešení na spracovanie vysoko zaťaženej dopravy. Žijeme a pracujeme na Urale, v meste tvrdých mužov Čeľabinsk, v spoločnosti Intersvyaz. Naša spoločnosť je poskytovateľom služieb internetu a káblovej televízie pre jeden milión ľudí v 16 mestách.
MM: – A stojí za to povedať, že Intersvyaz je oveľa viac ako len poskytovateľ, je to IT spoločnosť. Väčšinu našich riešení tvorí naše IT oddelenie.
a: od serverov spracovávajúcich prevádzku až po call centrum a mobilnú aplikáciu. IT oddelenie má teraz asi 80 ľudí s veľmi, veľmi rôznorodými kompetenciami.
O Zabbixe a jeho architektúre
MCH: – A teraz sa pokúsim vytvoriť osobný rekord a za minútu povedať, čo je Zabbix (ďalej len „Zabbix“).
Zabbix sa stavia ako hotový monitorovací systém na podnikovej úrovni. Má mnoho funkcií, ktoré uľahčujú život: pokročilé pravidlá eskalácie, API pre integráciu, zoskupovanie a automatickú detekciu hostiteľov a metrík. Zabbix má takzvané škálovacie nástroje – proxy. Zabbix je systém s otvoreným zdrojovým kódom.
Stručne o architektúre. Môžeme povedať, že pozostáva z troch komponentov:
- Server. Napísané v C. S pomerne zložitým spracovaním a prenosom informácií medzi vláknami. Prebieha v ňom všetko spracovanie: od prijatia až po uloženie do databázy.
- Všetky údaje sú uložené v databáze. Zabbix podporuje MySQL, PostreSQL a Oracle.
- Webové rozhranie je napísané v PHP. Na väčšine systémov sa dodáva so serverom Apache, ale efektívnejšie funguje v kombinácii s nginx + php.
Dnes by sme vám chceli porozprávať jeden príbeh zo života našej spoločnosti súvisiaci so Zabbixom...
Príbeh zo života spoločnosti Intersvyaz. Čo máme a čo potrebujeme?
pred 5 alebo 6 mesiacmi. Jeden deň po práci...
MCH: - Misha, ahoj! Som rád, že sa mi ťa podarilo chytiť - je tu rozhovor. Opäť sme mali problémy s monitorovaním. Počas veľkej havárie bolo všetko pomalé a chýbali informácie o stave siete. Žiaľ, nie je to prvýkrát, čo sa to stalo. Potrebujem tvoju pomoc. Zabezpečme, aby náš monitoring fungoval za každých okolností!
MM: - Ale najprv sa zosynchronizujme. Nepozrel som sa tam už pár rokov. Pokiaľ si pamätám, asi pred 8 rokmi sme opustili Nagios a prešli na Zabbix. A teraz sa zdá, že máme 6 výkonných serverov a asi tucet proxy. Mýlim si niečo?
MCH: - Skoro. 15 serverov, z ktorých niektoré sú virtuálne stroje. Najdôležitejšie je, že nás nezachráni vo chvíli, keď to najviac potrebujeme. Ako nehoda - servery sa spomaľujú a nič nevidíte. Snažili sme sa optimalizovať konfiguráciu, ale to neposkytlo optimálne zvýšenie výkonu.
MM: - To je jasné. Pozeral si niečo, už si niečo vyhrabal z diagnostiky?
MCH: – Prvá vec, s ktorou sa musíte vysporiadať, je databáza. MySQL sa neustále načítava, ukladá nové metriky a keď Zabbix začne generovať hromadu udalostí, databáza sa doslova na pár hodín prebije. Už som vám hovoril o optimalizácii konfigurácie, ale doslova tento rok aktualizovali hardvér: servery majú viac ako sto gigabajtov pamäte a diskových polí na SSD RAID – nemá zmysel to dlhodobo lineárne rozširovať. Čo urobíme?
MM: - To je jasné. Vo všeobecnosti je MySQL databáza LTP. Zjavne sa už nehodí na ukladanie archívu metrík našej veľkosti. Poďme na to.
MCH: - Poďme!
Integrácia Zabbix a Clickhouse ako výsledok hackathonu
Po nejakom čase sme dostali zaujímavé údaje:
Väčšinu miesta v našej databáze zaberal archív metrík a menej ako 1 % bolo použité na konfiguráciu, šablóny a nastavenia. V tom čase sme už viac ako rok prevádzkovali Big data riešenie založené na Clickhouse. Smer pohybu bol pre nás zrejmý. Na našom jarnom Hackathone som napísal integráciu Zabbixu s Clickhouse pre server a frontend. V tom čase už mal Zabbix podporu pre ElasticSearch a rozhodli sme sa ich porovnať.
Porovnanie Clickhouse a Elasticsearch
MM: – Pre porovnanie sme vygenerovali rovnakú záťaž, akú poskytuje server Zabbix, a pozreli sme sa, ako by sa systémy správali. Údaje sme zapisovali v dávkach po 1000 riadkov pomocou CURL. Vopred sme predpokladali, že Clickhouse bude efektívnejší pre profil zaťaženia, ktorý robí Zabbix. Výsledky dokonca prekonali naše očakávania:
Za rovnakých testovacích podmienok Clickhouse napísal trikrát viac údajov. Oba systémy zároveň veľmi efektívne spotrebovávali (malé množstvo zdrojov) pri čítaní dát. Elastics však pri nahrávaní vyžadoval veľké množstvo procesora:
Celkovo Clickhouse výrazne prevyšoval Elastix v spotrebe procesora a rýchlosti. Súčasne v dôsledku kompresie údajov Clickhouse používa 11-krát menej na pevnom disku a vykonáva približne 30-krát menej diskových operácií:
MCH: – Áno, práca Clickhouse s diskovým podsystémom je implementovaná veľmi efektívne. Môžete použiť obrovské SATA disky pre databázy a dosiahnuť rýchlosť zápisu stoviek tisíc riadkov za sekundu. Hotový systém podporuje sharding, replikáciu a je veľmi ľahko konfigurovateľný. S jeho používaním počas celého roka sme viac než spokojní.
Ak chcete optimalizovať zdroje, môžete nainštalovať Clickhouse vedľa vašej existujúcej hlavnej databázy a tým ušetriť veľa času CPU a diskových operácií. Archív metrík sme presunuli do existujúcich klastrov Clickhouse:
Hlavnú databázu MySQL sme odbremenili natoľko, že sme ju mohli skombinovať na jednom počítači so serverom Zabbix a opustiť dedikovaný server pre MySQL.
Ako funguje prieskum verejnej mienky v Zabbix?
4 mesiacmi
MM: – Môžeme zabudnúť na problémy so základňou?
MCH: - To je isté! Ďalším problémom, ktorý musíme vyriešiť, je pomalý zber dát. Teraz je všetkých našich 15 proxy serverov preťažených procesmi SNMP a dotazovania. A neexistuje spôsob, ako inštalovať nové a nové servery.
MM: - Skvelé. Najprv nám však povedzte, ako funguje prieskum v Zabbixe?
MCH: – Stručne povedané, existuje 20 typov metrík a tucet spôsobov, ako ich získať. Zabbix môže zbierať údaje buď v režime „request-response“, alebo čakať na nové údaje cez „Trapper Interface“.
Stojí za zmienku, že v pôvodnom Zabbixe je táto metóda (Trapper) najrýchlejšia.
Na distribúciu záťaže existujú proxy servery:
Proxy môžu vykonávať rovnaké zberné funkcie ako server Zabbix, prijímať z neho úlohy a odosielať zhromaždené metriky cez rozhranie Trapper. Toto je oficiálne odporúčaný spôsob rozloženia záťaže. Proxy sú tiež užitočné na monitorovanie vzdialenej infraštruktúry fungujúcej cez NAT alebo pomalý kanál:
MM: – S architektúrou je všetko jasné. Musíme sa pozrieť na zdroje...
O pár dní neskôr
Príbeh o tom, ako vyhral nmap fping
MM: "Myslím, že som niečo vykopal."
MCH: - Povedz mi!
MM: – Zistil som, že pri kontrole dostupnosti Zabbix kontroluje naraz maximálne 128 hostiteľov. Skúsil som zvýšiť toto číslo na 500 a odstrániť interval medzi paketmi v ich ping (ping) - to zdvojnásobilo výkon. Ale chcel by som väčšie čísla.
MCH: – Vo svojej praxi musím niekedy skontrolovať dostupnosť tisícok hostiteľov a nikdy som na to nevidel nič rýchlejšie ako nmap. Som si istý, že toto je najrýchlejší spôsob. Poďme to skúsiť! Musíme výrazne zvýšiť počet hostiteľov na jednu iteráciu.
MM: – Skontrolujte viac ako päťsto? 600?
MCH: - Aspoň pár tisíc.
MM: - Dobre. Najdôležitejšia vec, ktorú som chcel povedať, je, že som zistil, že väčšina prieskumov v Zabbixe prebieha synchrónne. Určite ho musíme zmeniť na asynchrónny režim. Potom môžeme dramaticky zvýšiť počet metrík zhromaždených prieskumníkmi, najmä ak zvýšime počet metrík na iteráciu.
MCH: - Skvelé! A kedy?
MM: – Ako obvykle, včera.
MCH: – Porovnali sme obe verzie fping a nmap:
Na veľkom počte hostiteľov sa očakávalo, že nmap bude až päťkrát efektívnejší. Keďže nmap kontroluje iba dostupnosť a čas odozvy, presunuli sme výpočet strát na spúšťače a výrazne skrátili intervaly kontroly dostupnosti. Zistili sme, že optimálny počet hostiteľov pre nmap je okolo 4 tisíc na iteráciu. Nmap nám umožnil trikrát znížiť náklady na kontrolu dostupnosti CPU a skrátiť interval zo 120 sekúnd na 10.
Optimalizácia hlasovania
MM: „Potom sme začali robiť prieskumy verejnej mienky. Nás zaujímala hlavne detekcia SNMP a agenti. V Zabbixe sa hlasovanie uskutočňuje synchrónne a boli prijaté špeciálne opatrenia na zvýšenie účinnosti systému. V synchrónnom režime spôsobuje nedostupnosť hostiteľa výrazné zhoršenie dopytu. Existuje celý systém štátov, existujú špeciálne procesy - takzvané nedostupné polery, ktoré pracujú iba s nedostupnými hostiteľmi:
Toto je komentár, ktorý demonštruje stavovú maticu, celú zložitosť systému prechodov, ktoré sú potrebné na to, aby systém zostal efektívny. Okrem toho je samotný synchrónny prieskum pomerne pomalý:
To je dôvod, prečo tisícky poler streamov na desiatkach proxy pre nás nedokázali nazbierať potrebné množstvo dát. Asynchrónna implementácia vyriešila nielen problémy s počtom vlákien, ale tiež výrazne zjednodušila stavový systém nedostupných hostiteľov, pretože pri akomkoľvek počte kontrolovanom v jednej iterácii dotazovania bola maximálna čakacia doba 1 timeout:
Okrem toho sme upravili a vylepšili systém hlasovania pre požiadavky SNMP. Faktom je, že väčšina ľudí nemôže odpovedať na viaceré požiadavky SNMP súčasne. Preto sme vytvorili hybridný režim, keď sa SNMP dotazovanie toho istého hostiteľa vykonáva asynchrónne:
Toto sa robí pre celý balík hostiteľov. Tento režim v konečnom dôsledku nie je pomalší ako úplne asynchrónny režim, pretože vyžiadanie jeden a pol stovky hodnôt SNMP je stále oveľa rýchlejšie ako 1 časový limit.
Naše experimenty ukázali, že optimálny počet požiadaviek v jednej iterácii je približne 8 tisíc s SNMP pollingom. Celkovo nám prechod do asynchrónneho režimu umožnil zrýchliť výkon hlasovania 200-krát, niekoľko stokrát.
MCH: – Výsledné optimalizácie prieskumov ukázali, že sa môžeme nielen zbaviť všetkých proxy, ale aj skrátiť intervaly mnohých kontrol a proxy už nebudú potrebné ako spôsob zdieľania záťaže.
Asi pred tromi mesiacmi
Zmeňte architektúru – zvýšte záťaž!
MM: - No, Max, je čas byť produktívny? Potrebujem výkonný server a dobrého inžiniera.
MCH: - Dobre, naplánujme si to. Je najvyšší čas prejsť z mŕtveho bodu 5 XNUMX metrík za sekundu.
Ráno po upgrade
MCH: - Misha, aktualizovali sme sa, ale do rána sme sa vrátili späť... Hádajte, akú rýchlosť sa nám podarilo dosiahnuť?
MM: - maximálne 20 tisíc.
MCH: - Áno, 25! Žiaľ, sme tam, kde sme začali.
MM: - Prečo? Spustil si nejakú diagnostiku?
MCH: - Áno samozrejme! Tu je napríklad zaujímavý top:
MM: - Sledujme. Vidím, že sme vyskúšali veľké množstvo vlákien prieskumu:
Zároveň však nedokázali recyklovať systém ani na polovicu:
A celkový výkon je pomerne malý, asi 4 XNUMX metrík za sekundu:
Existuje ešte niečo?
MCH: – Áno, stopa jedného z anketárov:
MM: – Tu jasne vidíte, že proces hlasovania čaká na „semafóry“. Toto sú zámky:
MCH: - Nejasné.
MM: – Pozrite, toto je podobné situácii, keď sa veľa vlákien snaží pracovať so zdrojmi, s ktorými môže naraz pracovať iba jeden. Potom všetko, čo môžu urobiť, je zdieľať tento zdroj v priebehu času:
A celkový výkon práce s takýmto zdrojom je obmedzený rýchlosťou jedného jadra:
Existujú dva spôsoby riešenia tohto problému.
Inovujte hardvér stroja, prejdite na rýchlejšie jadrá:
Alebo zmeňte architektúru a súčasne zmeňte zaťaženie:
MCH: – Mimochodom, na testovacom stroji použijeme menej jadier ako na bojovom, ale frekvenciou na jadro sú 1,5-krát rýchlejšie!
MM: - Jasný? Musíte sa pozrieť na kód servera.
Dátová cesta na serveri Zabbix
MCH: – Aby sme to zistili, začali sme analyzovať, ako sa údaje prenášajú na serveri Zabbix:
Skvelý obrázok, však? Poďme si to prejsť krok za krokom, aby to bolo viac-menej jasné. Za zhromažďovanie údajov sú zodpovedné vlákna a služby:
Zhromaždené metriky prenášajú cez soket do správcu preprocesora, kde sa ukladajú do frontu:
„Správca predprocesora“ prenáša údaje svojim pracovníkom, ktorí vykonávajú pokyny na predbežné spracovanie a vracajú ich späť cez rovnaký soket:
Potom ich správca preprocesora uloží do vyrovnávacej pamäte histórie:
Odtiaľ si ich berú potápači histórie, ktorí vykonávajú pomerne veľa funkcií: napríklad počítajú spúšťače, napĺňajú vyrovnávaciu pamäť hodnôt a hlavne ukladajú metriky do pamäte histórie. Vo všeobecnosti je tento proces zložitý a veľmi mätúci.
MM: – Prvá vec, ktorú sme videli, bolo, že väčšina vlákien súťaží o takzvanú „konfiguračnú vyrovnávaciu pamäť“ (oblasť pamäte, kde sú uložené všetky konfigurácie servera). Vlákna zodpovedné za zhromažďovanie údajov robia obzvlášť veľa blokovania:
...keďže konfigurácia ukladá nielen metriky s ich parametrami, ale aj fronty, z ktorých si anketári berú informácie o ďalšom postupe. Keď je veľa pollerov a jeden blokuje konfiguráciu, ostatní čakajú na požiadavky:
Anketári by nemali byť v konflikte
Preto prvá vec, ktorú sme urobili, bolo rozdeliť front na 4 časti a umožniť prieskumníkom zablokovať tieto fronty, tieto časti súčasne, za bezpečných podmienok:
Tým sa odstránila konkurencia pre vyrovnávaciu pamäť konfigurácie a výrazne sa zvýšila rýchlosť pollerov. Potom sme však narazili na skutočnosť, že správca preprocesora začal hromadiť rad úloh:
Správca preprocesora musí byť schopný určiť priority
Stalo sa tak v prípadoch, keď mu chýbal výkon. Potom všetko, čo mohol urobiť, bolo zhromaždiť požiadavky z procesov zberu údajov a sčítať ich vyrovnávaciu pamäť, kým nespotreboval všetku pamäť a nezrútil sa:
Na vyriešenie tohto problému sme pridali druhú zásuvku, ktorá bola určená špeciálne pre pracovníkov:
Manažér preprocesora mal teda možnosť uprednostniť svoju prácu a ak sa vyrovnávacia pamäť zväčšuje, úlohou je spomaliť odstraňovanie, čo dáva pracovníkom príležitosť túto vyrovnávaciu pamäť využiť:
Potom sme zistili, že jedným z dôvodov spomalenia boli samotní pracovníci, keďže súťažili o zdroj, ktorý bol pre ich prácu úplne nedôležitý. Tento problém sme zdokumentovali ako opravu chyby a už bol vyriešený v nových verziách Zabbix:
Zvyšujeme počet zásuviek - dostaneme výsledok
Ďalej sa samotný manažér preprocesora stal prekážkou, keďže ide o jedno vlákno. Spočíval na rýchlosti jadra, čo dáva maximálnu rýchlosť asi 70 XNUMX metrík za sekundu:
Preto sme vyrobili štyri, so štyrmi sadami zásuviek, pracovníkov:
A to nám umožnilo zvýšiť rýchlosť na približne 130 tisíc metrík:
Nelinearita rastu sa vysvetľuje skutočnosťou, že sa objavila súťaž o vyrovnávaciu pamäť histórie. Súťažili o ňu 4 manažéri preprocesorov a potápači histórie. V tomto bode sme na testovacom stroji prijímali približne 130 tisíc metrík za sekundu, pričom ho využívalo približne 95 % procesora:
Asi pred 2,5 mesiacmi
Odmietnutie zo strany snmp-community zvýšilo NVP jedenapolkrát
MM: – Max, potrebujem nové testovacie auto! Do súčasného sa už nezmestíme.
MCH: - Čo máš teraz?
MM: – Teraz – 130 XNUMX NVP a procesor pripravený na použitie.
MCH: - Wow! Super! Počkaj, mám dve otázky. Podľa mojich výpočtov sa naša potreba pohybuje okolo 15-20 tisíc metrík za sekundu. Prečo potrebujeme viac?
MM: "Chcem dokončiť prácu." Chcel by som vidieť, koľko dokážeme z tohto systému vyžmýkať.
MCH: - Ale…
MM: "Ale pre podnikanie je to zbytočné."
MCH: - To je jasné. A druhá otázka: dokážeme to, čo teraz máme, podporiť sami, bez pomoci vývojára?
MM: - Nemyslím si. Zmena fungovania konfiguračnej vyrovnávacej pamäte je problém. Ovplyvňuje zmeny vo väčšine vlákien a je dosť náročné na údržbu. S najväčšou pravdepodobnosťou bude veľmi ťažké ho udržiavať.
MCH: "Potom potrebujeme nejakú alternatívu."
MM: - Existuje taká možnosť. Môžeme prejsť na rýchle jadrá, pričom upustíme od nového uzamykacieho systému. Stále dostaneme výkon 60-80 tisíc metrík. Zároveň môžeme nechať celý zvyšok kódu. Clickhouse a asynchrónne polling budú fungovať. A bude sa ľahko udržiavať.
MCH: - Úžasný! Navrhujem, aby sme sa tu zastavili.
Po optimalizácii serverovej strany sme konečne mohli spustiť nový kód do produkcie. Upustili sme od niektorých zmien v prospech prechodu na stroj s rýchlymi jadrami a minimalizovaním počtu zmien kódu. Zjednodušili sme tiež konfiguráciu a odstránili makrá v dátových položkách tam, kde to bolo možné, pretože zavádzajú dodatočné uzamykanie.
Napríklad opustenie makra snmp-community, ktoré sa často nachádza v dokumentácii a príkladoch, v našom prípade umožnilo ďalšie zrýchlenie NVP približne 1,5-krát.
Po dvoch dňoch vo výrobe
Odstránenie kontextových okien histórie incidentov
MCH: – Misha, používame systém dva dni a všetko funguje. Ale len vtedy, keď všetko funguje! Plánovali sme prácu s presunom pomerne veľkého segmentu siete a opäť sme rukami kontrolovali, čo sa zvýšilo a čo nie.
MM: - Nemôže byť! Všetko sme skontrolovali 10 krát. Server okamžite zvládne aj úplnú nedostupnosť siete.
MCH: - Áno, rozumiem všetkému: server, databáza, top, austat, protokoly - všetko je rýchle... Ale pozrieme sa na webové rozhranie a na serveri je procesor „v poličke“ a toto:
MM: - To je jasné. Pozrime sa na web. Zistili sme, že v situácii, keď došlo k veľkému počtu aktívnych incidentov, väčšina živých miniaplikácií začala fungovať veľmi pomaly:
Dôvodom bolo generovanie kontextových okien histórie incidentov, ktoré sa generujú pre každú položku v zozname. Preto sme upustili od generovania týchto okien (odkomentovaných 5 riadkov v kóde), čím sa naše problémy vyriešili.
Čas načítania miniaplikácií, aj keď sú úplne nedostupné, sa skrátil z niekoľkých minút na pre nás prijateľných 10-15 sekúnd a históriu je možné stále zobraziť kliknutím na čas:
Po práci. Pred 2 mesiacmi
MCH: - Misha, odchádzaš? Musíme sa porozprávať.
MM: - Nemal som v úmysle. Zase niečo so Zabbixom?
MCH: - Nie, kľud! Chcel som len povedať: všetko funguje, ďakujem! Mám pivo.
Zabbix je efektívny
Zabbix je pomerne univerzálny a bohatý systém a funkcie. Dá sa použiť na malé inštalácie hneď po vybalení, ale s rastúcimi potrebami je potrebné ho optimalizovať. Ak chcete uložiť veľký archív metrík, použite vhodné úložisko:
- môžete využiť vstavané nástroje v podobe integrácie s Elasticsearch alebo nahrávania histórie do textových súborov (dostupné od verzie XNUMX);
- Môžete využiť naše skúsenosti a integráciu s Clickhouse.
Ak chcete výrazne zvýšiť rýchlosť zhromažďovania metrík, zbierajte ich pomocou asynchrónnych metód a preneste ich cez rozhranie zachytávača na server Zabbix; alebo môžete použiť opravu, aby boli pollery Zabbix asynchrónne.
Zabbix je napísaný v C a je celkom efektívny. Vyriešenie niekoľkých architektonických úzkych miest umožňuje ďalej zvyšovať jeho výkon a podľa našich skúseností získať viac ako 100 tisíc metrík na jednoprocesorovom stroji.
Rovnaká náplasť Zabbix
MM: – Chcem dodať pár bodov. Celá aktuálna správa, všetky testy, čísla sú uvedené pre konfiguráciu, ktorú používame. Teraz z toho berieme približne 20 XNUMX metrík za sekundu. Ak sa snažíte pochopiť, či to bude pre vás fungovať, môžete porovnávať. To, o čom sa dnes diskutovalo, je zverejnené na GitHub vo forme opravy:
Náplasť obsahuje:
- plná integrácia s Clickhouse (server aj frontend Zabbix);
- riešenie problémov so správcom preprocesora;
- asynchrónne hlasovanie.
Oprava je kompatibilná so všetkými verziami 4 vrátane lts. S najväčšou pravdepodobnosťou bude s minimálnymi zmenami fungovať na verzii 3.4.
Ďakujem vám za pozornosť.
otázky
Otázka z publika (ďalej – A): – Dobrý deň! Prosím, povedzte mi, máte plány na intenzívnu interakciu s tímom Zabbix alebo s nimi s vami, aby to nebola záplata, ale normálne správanie Zabbixu?
MM: – Áno, určite urobíme nejaké zmeny. Niečo sa stane, niečo zostane v záplate.
a: – Veľmi pekne vám ďakujem za skvelú správu! Povedzte mi, prosím, po aplikácii opravy zostane podpora od Zabbixu a ako pokračovať v aktualizácii na vyššie verzie? Bude možné aktualizovať Zabbix po vašej oprave na 4.2, 5.0?
MM: – Nemôžem povedať nič o podpore. Keby som bol technickou podporou Zabbix, pravdepodobne by som povedal nie, pretože toto je kód niekoho iného. Pokiaľ ide o kódovú základňu 4.2, naša pozícia je: „Pohneme sa časom a budeme sa aktualizovať na ďalšiu verziu.“ Preto nejaký čas budeme zverejňovať opravu pre aktualizované verzie. Už som povedal v správe: počet zmien s verziami je stále dosť malý. Myslím, že prechod z 3.4 na 4 nám trval asi 15 minút.. Niečo sa tam zmenilo, ale nie veľmi podstatné.
a: – Takže plánujete podporovať váš patch a môžete ho bezpečne nainštalovať do produkcie a v budúcnosti nejakým spôsobom dostávať aktualizácie?
MM: – Dôrazne odporúčame. To nám rieši veľa problémov.
MCH: – Ešte raz by som chcel upozorniť na to, že zmeny, ktoré sa netýkajú architektúry a netýkajú sa blokovania či radov sú modulárne, sú v samostatných moduloch. Dokonca aj s malými zmenami ich môžete udržiavať pomerne ľahko.
MM: – Ak vás zaujímajú podrobnosti, potom „Clickhouse“ používa takzvanú historickú knižnicu. Je rozviazaná - je kópiou podpery Elastics, čiže je konfigurovateľná. Hlasovanie mení iba anketárov. Veríme, že to bude fungovať ešte dlho.
a: - Mnohokrat dakujem. Povedzte mi, existuje nejaká dokumentácia o vykonaných zmenách?
MM: – Dokumentácia je záplata. Je zrejmé, že so zavedením Clickhouse, so zavedením nových typov pollerov vznikajú nové možnosti konfigurácie. Odkaz z poslednej snímky obsahuje krátky popis, ako ho použiť.
O nahradení fping za nmap
a: – Ako ste to nakoniec zrealizovali? Môžete uviesť konkrétne príklady: máte strapperov a externý scenár? Čo skončí tak rýchlou kontrolou takého veľkého počtu hostiteľov? Ako ťažíte týchto hostiteľov? Potrebujeme ich nejako nakŕmiť do nmapu, odniekiaľ ich získať, vložiť, niečo spustiť?...
MM: - V pohode. Veľmi správna otázka! Ide o to. Upravili sme knižnicu (ICMP ping, súčasť Zabbixu) pre ICMP kontroly, ktoré udávajú počet paketov - jeden (1) a kód sa snaží použiť nmap. To znamená, že toto je interná práca Zabbixu, ktorá sa stala internou prácou pingla. V súlade s tým nie je potrebná žiadna synchronizácia alebo použitie zachytávača. Bolo to urobené zámerne, aby systém zostal nedotknutý a nemuseli sme riešiť synchronizáciu dvoch databázových systémov: čo skontrolovať, nahrať cez poler a je náš upload nefunkčný?.. Je to oveľa jednoduchšie.
a: - Funguje to aj pre proxy?
MM: – Áno, ale neoverili sme to. Volebný kód je rovnaký v Zabbixe aj na serveri. Malo by fungovať. Dovoľte mi ešte raz zdôrazniť: výkon systému je taký, že nepotrebujeme proxy.
MCH: - Správna odpoveď na otázku je: "Prečo potrebujete proxy s takýmto systémom?" Len kvôli NAT alebo monitorovaniu cez nejaký pomalý kanál...
a: – A vy používate Zabbix ako alertor, ak tomu dobre rozumiem. Alebo sa vaša grafika (kde je archívna vrstva) presunula do iného systému, ako je Grafana? Alebo túto funkciu nevyužívate?
MM: – Ešte raz zdôrazním: dosiahli sme úplnú integráciu. Do Clickhouse nalievame históriu, no zároveň sme zmenili php frontend. Php frontend ide do Clickhouse a robí všetku grafiku odtiaľ. Zároveň, aby som bol úprimný, máme časť, ktorá vytvára údaje v iných grafických zobrazovacích systémoch z rovnakého Clickhouse, z rovnakých údajov Zabbix.
MCH: – Aj v „Grafane“.
Ako sa rozhodovalo o prideľovaní zdrojov?
a: – Zdieľajte trochu svojej vnútornej kuchyne. Ako došlo k rozhodnutiu, že je potrebné vyčleniť zdroje na seriózne spracovanie produktu? Vo všeobecnosti ide o určité riziká. A povedzte mi, prosím, v súvislosti s tým, že sa chystáte podporovať nové verzie: ako je toto rozhodnutie opodstatnené z hľadiska manažmentu?
MM: – Očividne sme drámu dejín neporozprávali veľmi dobre. Ocitli sme sa v situácii, keď bolo potrebné niečo urobiť, a išli sme v podstate s dvoma paralelnými tímami:
- Jedným z nich bolo spustenie monitorovacieho systému pomocou nových metód: monitoring ako služba, štandardná sada open source riešení, ktoré kombinujeme a následne sa snažíme zmeniť biznis proces, aby sme mohli pracovať s novým monitorovacím systémom.
- Zároveň sme mali nadšeného programátora, ktorý to robil (o sebe). Stalo sa, že vyhral.
a: – A aká je veľkosť tímu?
MCH: - Je pred vami.
a: – Takže ako vždy potrebujete vášnivého?
MM: – Neviem, čo je to vášnivec.
a: - V tomto prípade zrejme vy. Ďakujem veľmi pekne, ste super.
MM: - Vďaka.
O záplatách pre Zabbix
a: – Pre systém, ktorý používa proxy (napríklad v niektorých distribuovaných systémoch), je možné prispôsobiť a opraviť napríklad pollery, proxy a čiastočne aj samotný preprocesor Zabbixu; a ich interakcia? Je možné optimalizovať existujúci vývoj pre systém s viacerými proxy?
MM: – Viem, že server Zabbix je zostavený pomocou proxy (kód je zostavený a získaný). Vo výrobe sme to netestovali. Nie som si tým istý, ale myslím si, že manažér preprocesora sa v proxy nepoužíva. Úlohou proxy je prevziať sadu metrík zo Zabbixu, zlúčiť ich (zaznamenáva aj konfiguráciu, lokálnu databázu) a vrátiť ju späť serveru Zabbix. Samotný server potom vykoná predbežné spracovanie, keď ho prijme.
Záujem o proxy je pochopiteľný. Skontrolujeme to. Toto je zaujímavá téma.
a: – Myšlienka bola takáto: ak môžete opraviť pollery, môžete ich opraviť na proxy a opraviť interakciu so serverom a prispôsobiť preprocesor na tieto účely iba na serveri.
MM: – Myslím, že je to ešte jednoduchšie. Zoberiete kód, použijete opravu a potom ho nakonfigurujete tak, ako potrebujete – zhromaždíte proxy servery (napríklad s ODBC) a distribuujete opravený kód medzi systémy. Ak je to potrebné - zhromaždite proxy, ak je to potrebné - server.
a: – S najväčšou pravdepodobnosťou nebudete musieť dodatočne opravovať prenos proxy na server?
MCH: – Nie, je to štandardné.
MM: – V skutočnosti jeden z nápadov nezaznel. Vždy sme udržiavali rovnováhu medzi explóziou nápadov a množstvom zmien a jednoduchosťou podpory.
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com