De folgjende HighLoad++ konferinsje wurdt hâlden op 6 en 7 april 2020 yn Sint Petersburg Details en tickets . HighLoad++ Moskou 2018. Hall "Moskou". 9. novimber, 15:00. Theses en .
* Monitoring - online en analytyk.
* Basisbeheiningen fan it ZABBIX-platfoarm.
* Oplossing foar skaalfergrutting fan analytyske opslach.
* Optimalisaasje fan 'e ZABBIX-tsjinner.
* UI-optimalisaasje.
* Underfining it betsjinjen fan it systeem ûnder loads fan mear dan 40k NVPS.
* Koarte konklúzjes.
Mikhail Makurov (hjirnei - MM): - Hoi allegearre!
Maxim Chernetsov (hjirnei - MCH): - Goeiemiddei!
MM: – Lit my Maxim foarstelle. Max is in talintfolle yngenieur, de bêste netwurker dy't ik ken. Maxim is belutsen by netwurken en tsjinsten, harren ûntwikkeling en eksploitaasje.
MCH: - En ik soe graach fertelle oer Mikhail. Mikhail is in C-ûntwikkelder. Hy skreau ferskate oplossingen foar ferwurking mei hege lading foar ús bedriuw. Wy wenje en wurkje yn 'e Oeral, yn 'e stêd fan stoere manlju Chelyabinsk, yn it bedriuw Intersvyaz. Us bedriuw is in leveransier fan ynternet- en kabeltelevyzjetsjinsten foar ien miljoen minsken yn 16 stêden.
MM: - En it is it wurdich te sizzen dat Intersvyaz folle mear is as allinich in provider, it is in IT-bedriuw. De measte fan ús oplossingen wurde makke troch ús IT-ôfdieling.
A: fan servers dy't ferkear ferwurkje nei in opropsintrum en mobile applikaasje. De IT-ôfdieling hat no sa'n 80 minsken mei hiel, hiel ferskaat kompetinsjes.
Oer Zabbix en syn arsjitektuer
MCH: - En no sil ik besykje in persoanlik rekord te setten en yn ien minút te sizzen wat Zabbix is (hjirnei oantsjutten as "Zabbix").
Zabbix positionearret himsels as in out-of-the-box tafersjochsysteem op bedriuwsnivo. It hat in protte funksjes dy't it libben makliker meitsje: avansearre eskalaasjeregels, API foar yntegraasje, groepearring en auto-deteksje fan hosts en metriken. Zabbix hat saneamde skaalfergrutting ark - proxies. Zabbix is in iepen boarne systeem.
Koart oer arsjitektuer. Wy kinne sizze dat it bestiet út trije komponinten:
- Tsjinner. Skreaun yn C. Mei frij komplekse ferwurking en oerdracht fan ynformaasje tusken triedden. Alle ferwurking fynt dêryn plak: fan ûntfangen oant opslaan nei de databank.
- Alle gegevens wurde opslein yn 'e databank. Zabbix stipet MySQL, PostreSQL en Oracle.
- De webynterface is skreaun yn PHP. Op de measte systemen komt it mei in Apache-tsjinner, mar wurket effisjinter yn kombinaasje mei nginx + php.
Hjoed wolle wy ien ferhaal fertelle út it libben fan ús bedriuw relatearre oan Zabbix ...
In ferhaal út it libben fan it bedriuw Intersvyaz. Wat hawwe wy en wat hawwe wy nedich?
5 of 6 moannen lyn. Ien dei nei it wurk...
MCH: - Misha, hallo! Ik bin bliid dat ik dy slagge te fangen - der is in petear. Wy hiene wer problemen mei it tafersjoch. By in grut ûngelok gie alles stadich en wie der gjin ynformaasje oer de steat fan it netwurk. Spitigernôch is dit net de earste kear dat dit bard is. Ik ha dyn help nedich. Litte wy ús tafersjoch meitsje ûnder alle omstannichheden!
MM: - Mar lit ús earst syngronisearje. Ik haw dêr in pear jier net sjoen. Foar safier't ik my herinner, hawwe wy Nagios ferlitten en oer 8 jier lyn oergien nei Zabbix. En no lykje wy 6 krêftige servers te hawwen en sawat in tsiental proxy's. Bin ik wat betiizje?
MCH: - Hast. 15 servers, wêrfan guon firtuele masines binne. It wichtichste is dat it ús net rêdt op it momint dat wy it it meast nedich binne. As in ûngelok - de servers fertrage en jo kinne neat sjen. Wy hawwe besocht de konfiguraasje te optimalisearjen, mar dit levere net de optimale prestaasjesferheging.
MM: - It is dúdlik. Hawwe jo wat sjoen, hawwe jo al wat út de diagnoaze helle?
MCH: - It earste ding dat jo moatte dwaan is de databank. MySQL wurdt konstant laden, opslach fan nije metriken, en as Zabbix begjint mei it generearjen fan in boskje eveneminten, giet de databank letterlik in pear oeren yn overdrive. Ik haw jo al ferteld oer it optimalisearjen fan de konfiguraasje, mar letterlik dit jier hawwe se de hardware bywurke: de tsjinners hawwe mear as hûndert gigabyte oan ûnthâld en skiif-arrays op SSD RAID's - it hat gjin punt om it op 'e lange termyn lineêr te groeien. Wat dogge we?
MM: - It is dúdlik. Yn 't algemien is MySQL in LTP-database. Blykber is it net mear geskikt foar it opslaan fan in argyf fan metriken fan ús grutte. Litte wy it útfine.
MCH: - Litte wy!
Yntegraasje fan Zabbix en Clickhouse as gefolch fan 'e hackathon
Nei in skoft krigen wy nijsgjirrige gegevens:
It grutste part fan 'e romte yn ús databank waard beset troch it metrike argyf en minder dan 1% waard brûkt foar konfiguraasje, sjabloanen en ynstellings. Tsjin dy tiid hienen wy de Big data-oplossing opereare basearre op Clickhouse foar mear dan in jier. De bewegingsrjochting wie foar ús dúdlik. Op ús Spring Hackathon skreau ik de yntegraasje fan Zabbix mei Clickhouse foar de server en frontend. Op dat stuit hie Zabbix al stipe foar ElasticSearch, en wy besletten se te fergelykjen.
Fergeliking fan Clickhouse en Elasticsearch
MM: - Foar fergeliking hawwe wy deselde lading generearre as de Zabbix-tsjinner biedt en seagen hoe't de systemen har gedrage. Wy skreaunen gegevens yn batches fan 1000 rigels, mei CURL. Wy gongen fan tefoaren oan dat Clickhouse effisjinter soe wêze foar it loadprofyl dat Zabbix docht. De resultaten oertroffen sels ús ferwachtingen:
Under deselde testbetingsten skreau Clickhouse trije kear mear gegevens. Tagelyk konsumeare beide systemen tige effisjint (in lyts bedrach fan boarnen) by it lêzen fan gegevens. Mar Elastics hawwe in grutte hoemannichte prosessor nedich by it opnimmen:
Yn totaal wie Clickhouse signifikant superieur oan Elastix yn termen fan prosessorferbrûk en snelheid. Tagelyk brûkt Clickhouse, fanwegen gegevenskompresje, 11 kear minder op 'e hurde skiif en fiert sawat 30 kear minder skiifoperaasjes:
MCH: - Ja, it wurk fan Clickhouse mei it skiifsubsysteem wurdt heul effisjint ymplementearre. Jo kinne enoarme SATA-skiven brûke foar databases en skriuwsnelheden krije fan hûnderttûzenen rigels per sekonde. It out-of-the-box systeem stipet sharding, replikaasje, en is heul maklik te konfigurearjen. Wy binne mear dan tefreden mei it gebrûk it hiele jier troch.
Om boarnen te optimalisearjen, kinne jo Clickhouse ynstalleare neist jo besteande haaddatabank en dêrmei in protte CPU-tiid en skiifoperaasjes besparje. Wy hawwe it argyf fan metriken ferpleatst nei besteande Clickhouse-klusters:
Wy hawwe de haad MySQL-database safolle ûntlêste dat wy it op ien masine kinne kombinearje mei de Zabbix-tsjinner en de tawijde tsjinner foar MySQL ferlitte.
Hoe wurket polling yn Zabbix?
4 moannen lyn
MM: – No, kinne wy de problemen mei de basis ferjitte?
MCH: - Dat is wis! In oar probleem dat wy moatte oplosse is trage gegevenssammeling. No binne al ús 15 proxy-tsjinners oerladen mei SNMP- en pollingprosessen. En d'r is gjin manier útsein om nije en nije servers te ynstallearjen.
MM: - Grut. Mar earst, fertel ús hoe't polling wurket yn Zabbix?
MCH: - Koartsein, d'r binne 20 soarten metriken en in tsiental manieren om se te krijen. Zabbix kin gegevens sammelje yn 'e "fersyk-antwurd" modus, of wachtsje op nije gegevens fia de "Trapper Interface".
It is de muoite wurdich opskriuwen dat yn de oarspronklike Zabbix dizze metoade (Trapper) is de fluchste.
D'r binne proxy-tsjinners foar loaddistribúsje:
Proxies kinne deselde sammelfunksjes útfiere as de Zabbix-tsjinner, taken derfan ûntfange en de sammele metriken ferstjoere fia de Trapper-ynterface. Dit is de offisjeel oanrikkemandearre manier om de lading te fersprieden. Proxies binne ek nuttich foar it kontrolearjen fan ynfrastruktuer op ôfstân dy't wurket fia NAT as in traach kanaal:
MM: - Alles is dúdlik mei arsjitektuer. Wy moatte nei de boarnen sjen ...
In pear dagen letter
It ferhaal fan hoe't nmap fping wûn
MM: "Ik tink dat ik wat opgroeven haw."
MCH: - Fertel my!
MM: - Ik ûntduts dat by it kontrolearjen fan beskikberens, Zabbix maksimaal 128 hosts tagelyk kontrolearret. Ik besocht dit nûmer te ferheegjen nei 500 en it ynter-pakket ynterval te ferwiderjen yn har ping (ping) - dit ferdûbele de prestaasjes. Mar ik soe graach gruttere oantallen.
MCH: – Yn myn praktyk moat ik soms de beskikberens fan tûzenen hosts kontrolearje, en ik haw noait wat flugger sjoen as nmap foar dit. Ik bin der wis fan dat dit de rapste manier is. Litte wy it besykje! Wy moatte it oantal hosts per iteraasje signifikant ferheegje.
MM: - Kontrolearje mear as fiifhûndert? 600?
MCH: - Op syn minst in pear tûzen.
MM: - OK. It wichtichste wat ik sizze woe is dat ik fûn dat de measte polling yn Zabbix synchroon wurdt dien. Wy moatte it perfoarst feroarje nei asynchrone modus. Dan kinne wy it oantal metriken sammele troch pollers dramatysk ferheegje, foaral as wy it oantal metriken per iteraasje ferheegje.
MCH: - Grut! En wannear?
MM: - Lykas gewoanlik, juster.
MCH: - Wy fergelike beide ferzjes fan fping en nmap:
Op in grut oantal hosts waard ferwachte dat nmap oant fiif kear effektiver wie. Sûnt nmap kontrolearret allinich beskikberens en reaksjetiid, hawwe wy de berekkening fan ferliezen ferpleatst nei triggers en de yntervallen foar beskikberenskontrôle signifikant fermindere. Wy fûnen dat it optimale oantal hosts foar nmap sawat 4 tûzen per iteraasje wie. Nmap liet ús de CPU-kosten fan kontrôles foar beskikberens mei trije kear ferminderje en it ynterval ferminderje fan 120 sekonden nei 10.
Polling optimisaasje
MM: ,,Dan begûnen wy pollers te dwaan. Wy wiene benammen ynteressearre yn SNMP-deteksje en aginten. Yn Zabbix wurdt polling syngroan dien en binne spesjale maatregels nommen om de effisjinsje fan it systeem te fergrutsjen. Yn syngroane modus feroarsaket ûnbeskikberens fan host signifikante degradaasje fan polling. D'r is in hiele systeem fan steaten, d'r binne spesjale prosessen - de saneamde ûnberikbere pollers, dy't allinich wurkje mei net te berikken hosts:
Dit is in kommentaar dy't de steatsmatrix toant, alle kompleksiteit fan it systeem fan transysjes dy't nedich binne om it systeem effektyf te bliuwen. Derneist is syngroane polling sels frij stadich:
Dêrom koene tûzenen pollerstreamen op tsientallen proxy's net de fereaske hoemannichte gegevens foar ús sammelje. De asynchrone ymplemintaasje hat net allinich de problemen mei it oantal threaden oplost, mar hat ek it steatsysteem fan net-beskikbere hosts signifikant ferienfâldige, om't foar elk oantal kontrolearre yn ien polling-iteraasje, de maksimale wachttiid wie 1 time-out:
Derneist hawwe wy it pollingsysteem foar SNMP-oanfragen wizige en ferbettere. It feit is dat de measte minsken net tagelyk kinne reagearje op meardere SNMP-oanfragen. Dêrom hawwe wy in hybride modus makke, doe't SNMP-polling fan deselde host asynchronysk wurdt dien:
Dit wurdt dien foar it heule pakket fan hosts. Dizze modus is úteinlik net stadiger as in folslein asynchrone, om't it pollen fan ien en in healhûndert SNMP-wearden noch folle flugger is dan 1 time-out.
Us eksperiminten hawwe oantoand dat it optimale oantal oanfragen yn ien iteraasje sawat 8 tûzen is mei SNMP-polling. Yn totaal koe de oergong nei asynchrone modus ús de pollingprestaasjes mei 200 kear fersnelle, ferskate hûndert kear.
MCH: - De resultearjende optimisaasjes foar polling lieten sjen dat wy net allinich alle proxy's kinne kwytreitsje, mar ek de yntervallen foar in protte kontrôles ferminderje, en proxy's sille net mear nedich wêze as in manier om de lading te dielen.
Sa'n trije moanne lyn
Feroarje de arsjitektuer - fergrutsje de lading!
MM: - No, Max, is it tiid om produktyf te wurden? Ik haw in krêftige tsjinner en in goede yngenieur nedich.
MCH: - Okee, litte wy it planne. It is heech tiid om te bewegen fan it deade punt fan 5 tûzen metriken per sekonde.
Moarn nei de fernijing
MCH: - Misha, wy hawwe ússels bywurke, mar fan 'e moarn rôlen wy werom ... Rêd hokker snelheid wy slagge om te berikken?
MM: - 20 tûzen maksimaal.
MCH: -jo, 25! Spitigernôch binne wy krekt wêr't wy begon binne.
MM: - Wêrom? Hawwe jo in diagnostyk útfierd?
MCH: - Ja wis! Hjir is bygelyks in nijsgjirrige top:
MM: - Lit ús sjen. Ik sjoch dat wy in enoarm oantal fraachpetearen hawwe besocht:
Mar tagelyk koene se it systeem net sels mei de helte recycle:
En de totale prestaasje is frij lyts, sawat 4 tûzen metriken per sekonde:
Is der noch wat oars?
MCH: – Ja, slach fan ien fan de pollers:
MM: - Hjir kinne jo dúdlik sjen dat it peilingsproses wachtet op "semafoaren". Dit binne de slûzen:
MCH: - Undúdlik.
MM: - Sjoch, dit is te fergelykjen mei in situaasje dêr't in bosk triedden besykje te wurkjen mei boarnen wêrmei mar ien tagelyk kin wurkje. Dan alles wat se kinne dwaan is dizze boarne oer de tiid te dielen:
En de totale prestaasjes fan wurkjen mei sa'n boarne wurdt beheind troch de snelheid fan ien kearn:
D'r binne twa manieren om dit probleem op te lossen.
Upgrade de hardware fan 'e masine, wikselje nei rappere kearnen:
Of feroarje de arsjitektuer en feroarje tagelyk de lading:
MCH: - Trouwens, op 'e testmasine sille wy minder kearnen brûke dan op' e bestriding, mar se binne 1,5 kear rapper yn frekwinsje per kearn!
MM: - Opklearje? Jo moatte sjen nei de tsjinner koade.
Gegevenspaad yn Zabbix-tsjinner
MCH: - Om it út te finen, begon wy te analysearjen hoe't gegevens wurde oerdroegen binnen de Zabbix-tsjinner:
Coole foto, krekt? Litte wy it stap foar stap trochgean om it min of mear dúdlik te meitsjen. D'r binne diskusjes en tsjinsten ferantwurdlik foar it sammeljen fan gegevens:
Se stjoere de sammele metriken fia in socket oer nei de Preprocessor-manager, wêr't se wurde bewarre yn in wachtrige:
De "preprocessor manager" stjoert gegevens nei syn arbeiders, dy't foarferwurkingsynstruksjes útfiere en werombringe fia deselde socket:
Hjirnei bewarret de preprocessorbehearder se yn 'e skiedniscache:
Dêrwei wurde se nommen troch histoaryske sinkers, dy't in protte funksjes útfiere: bygelyks triggers berekkenje, de wearde-cache ynfolje en, wichtichste, metriken opslaan yn 'e skiednis opslach. Yn 't algemien is it proses kompleks en heul betiizjend.
MM: - It earste ding dat wy seagen wie dat de measte triedden konkurrearje foar de saneamde "konfiguraasjecache" (it ûnthâldgebiet dêr't alle serverkonfiguraasjes wurde opslein). Diskusjes ferantwurdlik foar it sammeljen fan gegevens dogge benammen in protte blokkearjen:
...sûnt de konfiguraasje net allinich metriken opslacht mei har parameters, mar ek wachtrijen wêrfan pollers ynformaasje nimme oer wat se folgjende dwaan moatte. As d'r in protte pollers binne en ien blokkeart de konfiguraasje, wachtsje de oaren op fersiken:
Pollers moatte net konflikt
Dêrom wie it earste wat wy diene de wachtrige te dielen yn 4 dielen en tastean pollers dizze wachtrigen, dizze dielen tagelyk, te blokkearjen, ûnder feilige omstannichheden:
Dit fuortsmiten konkurrinsje foar de konfiguraasje cache, en de snelheid fan pollers tanommen gâns. Mar doe kamen wy it feit tsjin dat de preprocessor-manager in wachtrige fan banen begon te sammeljen:
Preprocessor manager moat yn steat wêze om prioriteit te jaan
Dit barde yn gefallen dêr't hy miste prestaasjes. Dan alles wat hy koe dwaan wie oanfragen sammelje fan prosessen foar gegevenssammeling en har buffer optelle oant it al it ûnthâld konsumearre en ferûngelokke:
Om dit probleem op te lossen, hawwe wy in twadde socket tafoege dy't spesifyk wijd wie oan arbeiders:
Sa hie de preprocessor-manager de kâns om syn wurk te prioritearjen en, as de buffer groeit, is de taak om de ferwidering te fertragen, wêrtroch arbeiders de kâns jaan om dizze buffer te nimmen:
Doe ûntdutsen wy dat ien fan 'e redenen foar de fertraging de arbeiders sels wie, om't se konkurrearje foar in boarne dy't folslein ûnbelangryk wie foar har wurk. Wy hawwe dit probleem dokumintearre as in bug-fix, en it is al oplost yn nije ferzjes fan Zabbix:
Wy ferheegje it oantal sockets - wy krije it resultaat
Fierder waard de preprocessorbehearder sels in knelpunt, om't it ien tried is. It rêste op 'e kearnsnelheid, wêrtroch in maksimale snelheid fan sawat 70 tûzen metriken per sekonde joech:
Dêrom makken wy fjouwer, mei fjouwer sets sockets, arbeiders:
En dit liet ús de snelheid ferheegje nei sawat 130 tûzen metriken:
De net-lineariteit fan groei wurdt ferklearre troch it feit dat konkurrinsje foar de skiednis-cache ferskynde. 4 preprocessor managers en skiednis sinkers konkurrearren foar it. Op dit punt krigen wy sawat 130 tûzen metriken per sekonde op 'e testmasjine, en brûkten it troch sawat 95% fan' e prosessor:
Oer 2,5 moanne lyn
Wegering fan snmp-mienskip fergrutte NVP's mei oardel kear
MM: – Max, ik ha in nije testauto nedich! Wy passe net mear yn de hjoeddeiske.
MCH: - Wat hast no?
MM: - No - 130k NVP's en in shelf-klear prosessor.
MCH: - Wow! Koel! Wachtsje, ik haw twa fragen. Neffens myn berekkeningen is ús need sawat 15-20 tûzen metriken per sekonde. Wêrom hawwe wy mear nedich?
MM: "Ik wol it wurk ôfmeitsje." Ik soe graach sjen hoefolle wy kinne squeeze út dit systeem.
MCH: - Mar...
MM: "Mar it is nutteloos foar bedriuw."
MCH: - It is dúdlik. En de twadde fraach: kinne wy stypje wat wy no hawwe op ús eigen, sûnder de help fan in ûntwikkelder?
MM: - Ik tink net. It feroarjen fan hoe't de konfiguraasjecache wurket is in probleem. It beynfloedet feroaringen yn 'e measte triedden en is frij lestich te ûnderhâlden. Meast wierskynlik sil it heul lestich wêze om it te behâlden.
MCH: "Dan hawwe wy in soarte fan alternatyf nedich."
MM: - Der is sa'n opsje. Wy kinne oerstappe nei snelle kearnen, wylst wy it nije beskoattelsysteem ferlitte. Wy sille noch in prestaasje krije fan 60-80 tûzen metriken. Tagelyk kinne wy de rest fan 'e koade litte. Clickhouse en asynchrone polling sil wurkje. En it sil maklik te ûnderhâlden wêze.
MCH: - Ferbazend! Ik stel foar dat wy hjir stopje.
Nei it optimalisearjen fan de serverkant, koenen wy einlings de nije koade yn produksje lansearje. Wy ferlitte guon fan 'e feroarings yn it foardiel fan in oerstap nei in masine mei flugge kearnen en minimalisearje it oantal koade feroarings. Wy hawwe ek de konfiguraasje ferienfâldige en makro's elimineare yn gegevensitems wêr mooglik, om't se ekstra beskoattelje yntrodusearje.
Bygelyks, it ferlitten fan 'e snmp-mienskipsmakro, dy't faak te finen is yn dokumintaasje en foarbylden, makke it yn ús gefal mooglik om NVP's fierder te fersnellen mei sawat 1,5 kear.
Nei twa dagen yn produksje
It fuortsmiten fan ynsidint skiednis pop-ups
MCH: - Misha, wy hawwe it systeem twa dagen brûkt, en alles wurket. Mar allinich as alles wurket! Wy hiene pland wurk mei de oerdracht fan in frij grut segmint fan it netwurk, en wy wer kontrolearre mei ús hannen wat gie omheech en wat net.
MM: - Kin net! Wy hawwe alles 10 kear kontrolearre. De tsjinner behannelet sels folsleine netwurkbeskikberens direkt.
MCH: - Ja, ik begryp alles: server, database, top, austat, logs - alles is fluch ... Mar wy sjogge nei de webynterface, en d'r is in prosessor "yn 'e planke" op' e server en dit:
MM: - It is dúdlik. Litte wy it web besjen. Wy fûnen dat yn in situaasje wêr't d'r in grut oantal aktive ynsidinten wiene, de measte live widgets heul stadich begon te wurkjen:
De reden hjirfoar wie de generaasje fan pop-ups foar ynsidinthistoarje dy't wurde oanmakke foar elk item yn 'e list. Dêrom hawwe wy de generaasje fan dizze finsters ferlitten (kommentearre út 5 rigels yn 'e koade), en dit loste ús problemen op.
De laadtiid foar widgets, sels as folslein net beskikber, is fermindere fan ferskate minuten nei de akseptabele 10-15 sekonden foar ús, en de skiednis kin noch besjoen wurde troch te klikken op de tiid:
Nei it wurk. 2 moannen lyn
MCH: - Misha, geane jo fuort? Wy moatte prate.
MM: - Ik wie net fan doel. Wer wat mei Zabbix?
MCH: - Nee, rêstich! Ik woe gewoan sizze: alles wurket, tank! Ik ha in bierke.
Zabbix is effisjint
Zabbix is in frij universele en ryk systeem en funksje. It kin brûkt wurde foar lytse ynstallaasjes út 'e doaze, mar as behoeften groeie, moat it optimalisearre wurde. Om in grut argyf fan metriken op te slaan, brûk in geskikte opslach:
- jo kinne ynboude ark brûke yn 'e foarm fan yntegraasje mei Elasticsearch of histoarje uploaden nei tekstbestannen (beskikber fanôf ferzje 4);
- Jo kinne profitearje fan ús ûnderfining en yntegraasje mei Clickhouse.
Om de snelheid fan it sammeljen fan metriken dramatysk te ferheegjen, sammelje se mei asynchrone metoaden en stjoer se fia de trapper-ynterface nei de Zabbix-tsjinner; of jo kinne in patch brûke om Zabbix pollers asynchronous te meitsjen.
Zabbix is skreaun yn C en is frij effisjint. Troch ferskate arsjitektoanyske knyppunten op te lossen kinne jo de prestaasjes fierder ferheegje en, yn ús ûnderfining, mear dan 100 tûzen metriken krije op in ienprosessormasine.
Itselde Zabbix patch
MM: - Ik wol noch in pear punten bymeitsje. It heule hjoeddeistige rapport, alle tests, nûmers wurde jûn foar de konfiguraasje dy't wy brûke. Wy nimme der no sawat 20 tûzen metriken per sekonde fan. As jo besykje te begripen oft dit foar jo sil wurkje, kinne jo fergelykje. Wat hjoed waard besprutsen wurdt pleatst op GitHub yn 'e foarm fan in patch:
De patch omfettet:
- folsleine yntegraasje mei Clickhouse (sawol Zabbix-tsjinner as frontend);
- problemen oplosse mei de preprocessor manager;
- asynchrone polling.
De patch is kompatibel mei alle ferzje 4, ynklusyf lts. Meast wierskynlik, mei minimale feroarings sil it wurkje op ferzje 3.4.
Tige tank foar jo oandacht.
Jo fragen
Fraach út it publyk (hjirnei – A): – Goeiemiddei! Fertel my asjebleaft, hawwe jo plannen foar yntinsive ynteraksje mei it Zabbix-team of mei har mei jo, sadat dit gjin patch is, mar normaal gedrach fan Zabbix?
MM: - Ja, wy sille grif wat feroarings ynsette. Der sil wat barre, wat bliuwt yn 'e patch.
A: – Tige tank foar it treflike ferslach! Fertel my asjebleaft, nei it tapassen fan de patch sil stipe fan Zabbix bliuwe en hoe kinne jo trochgean mei bywurkjen nei hegere ferzjes? Sil it mooglik wêze om Zabbix nei jo patch te aktualisearjen nei 4.2, 5.0?
MM: - Ik kin neat sizze oer stipe. As ik Zabbix technyske stipe wie, soe ik wierskynlik nee sizze, om't dit de koade fan in oar is. Wat de 4.2-koadebase oanbelanget, is ús posysje: "Wy sille mei de tiid bewege, en wy sille ússels bywurkje oer de folgjende ferzje." Dêrom sille wy in skoft in patch pleatse foar bywurke ferzjes. Ik sei yn it rapport al: it tal feroarings mei ferzjes is noch frij lyts. Ik tink dat de oergong fan 3.4 nei 4 ús sa'n 15 minuten duorre.Dêr feroare wat, mar net hiel wichtich.
A: - Dat jo binne fan plan om jo patch te stypjen en jo kinne it feilich ynstallearje yn produksje en op ien of oare manier updates krije yn 'e takomst?
MM: - Wy riede it sterk oan. Dit lost in protte problemen foar ús op.
MCH: – Ik wol noch ien kear omtinken jaan oan it feit dat de feroarings dy’t de arsjitektuer net oangeane en gjin blokkearjen of wachtrijen oangeane, modulêr binne, se binne yn aparte modules. Sels mei lytse feroarings kinne jo se frij maklik ûnderhâlde.
MM: - As jo ynteressearre binne yn de details, dan brûkt "Clickhouse" de saneamde skiednis bibleteek. It is untied - it is in kopy fan 'e Elastics-stipe, dat is, it is konfigurearber. Polling feroaret allinnich pollers. Wy leauwe dat dit sil wurkje foar in lange tiid.
A: - Tige dank. Fertel my, is d'r dokumintaasje fan 'e makke wizigingen?
MM: - Dokumintaasje is in patch. Fansels, mei de ynfiering fan Clickhouse, mei de ynfiering fan nije soarten pollers, ûntsteane nije konfiguraasjeopsjes. De keppeling fan 'e lêste slide hat in koarte beskriuwing fan hoe't jo it brûke.
Oer it ferfangen fan fping mei nmap
A: - Hoe hawwe jo dit einlings útfierd? Kinne jo spesifike foarbylden jaan: hawwe jo strappers en in ekstern skript? Wat einiget mei it kontrolearjen fan sa'n grut oantal hosts sa fluch? Hoe mingje jo dizze hosts? Moatte wy se fiede om op ien of oare manier te nmap, se earne wei te heljen, se yn te setten, wat te rinnen?
MM: - Koel. In heul korrekte fraach! It punt is dit. Wy hawwe de bibleteek (ICMP-ping, diel fan Zabbix) wizige foar ICMP-kontrôles, dy't it oantal pakketten oanjaan - ien (1), en de koade besiket nmap te brûken. Dat is, dit is it ynterne wurk fan Zabbix, dat it ynterne wurk fan 'e pinger wurden is. Dêrtroch is gjin syngronisaasje of gebrûk fan in trapper nedich. Dit waard bewust dien om it systeem yntakt te litten en net te krijen mei de syngronisaasje fan twa databanksystemen: wat te kontrolearjen, upload fia de poller, en is ús upload brutsen?.. Dit is folle ienfâldiger.
A: – Docht it ek foar folmacht?
MM: - Ja, mar wy hawwe net kontrolearre. De polling koade is itselde yn sawol Zabbix as de tsjinner. Moat wurkje. Lit my nochris beklamje: de prestaasje fan it systeem is sa dat wy gjin proxy nedich hawwe.
MCH: - It goede antwurd op 'e fraach is: "Wêrom hawwe jo in proxy nedich mei sa'n systeem?" Allinich fanwege NAT of tafersjoch fia in soarte fan trage kanaal ...
A: - En jo brûke Zabbix as in allertor, as ik it goed begryp. Of hawwe jo grafiken (wêr't de argyflaach is) ferpleatst nei in oar systeem, lykas Grafana? Of brûke jo dizze funksjonaliteit net?
MM: – Ik sil nochris beklamje: wy hawwe folsleine yntegraasje berikt. Wy skine skiednis yn Clickhouse, mar tagelyk hawwe wy de php-frontend feroare. De Php-frontend giet nei Clickhouse en docht alle grafiken dêrwei. Tagelyk, om earlik te wêzen, hawwe wy in diel dat gegevens bouwt yn oare grafyske werjeftesystemen fan deselde Clickhouse, fan deselde Zabbix-gegevens.
MCH: - Yn "Grafan" ek.
Hoe binne besluten makke oer de allocaasje fan middels?
A: - Diel in bytsje fan jo binnenkeuken. Hoe waard it beslút makke dat it nedich wie om middels te allocearjen foar serieuze ferwurking fan it produkt? Dit binne yn 't algemien bepaalde risiko's. En fertel my asjebleaft, yn it ramt fan it feit dat jo nije ferzjes stypje: hoe rjochtfeardiget dit beslút út in behearspunt?
MM: - Blykber hawwe wy it drama fan 'e skiednis net sa goed ferteld. Wy fûnen ússels yn in situaasje wêr't wat dien wurde moast, en wy gongen yn essinsje mei twa parallelle teams:
- Ien wie it lansearjen fan in tafersjochsysteem mei nije metoaden: tafersjoch as in tsjinst, in standert set fan iepen boarne-oplossingen dy't wy kombinearje en dan besykje it bedriuwsproses te feroarjen om te wurkjen mei it nije tafersjochsysteem.
- Tagelyk hienen wy in entûsjaste programmeur dy't dit die (oer himsels). It barde sa dat er wûn.
A: - En wat is de grutte fan it team?
MCH: - Se is foar dy.
A: - Dus, lykas altyd, jo moatte in hertstochtlik?
MM: - Ik wit net wat in hertstochtlik is.
A: - Yn dit gefal, blykber, do. Tige tank, do bist geweldich.
MM: - Tank.
Oer patches foar Zabbix
A: - Foar in systeem dat brûkt proxy (bygelyks, yn guon ferspraat systemen), is it mooglik om te passen en patch, sizze, pollers, proxy en foar in part de preprocessor fan Zabbix sels; en harren ynteraksje? Is it mooglik om besteande ûntwikkelingen te optimalisearjen foar in systeem mei meardere proxy's?
MM: – Ik wit dat de Zabbix-tsjinner wurdt gearstald mei in proxy (de koade is kompilearre en krigen). Wy hawwe dit net testen yn produksje. Ik bin der net wis fan oer dit, mar ik tink dat de preprocessor manager wurdt net brûkt yn de proxy. De taak fan 'e proxy is om in set metriken fan Zabbix te nimmen, se te fusearjen (it registrearret ek de konfiguraasje, de lokale databank) en jou it werom nei de Zabbix-tsjinner. De tsjinner sels sil dan de foarferwurking dwaan as it it ûntfangt.
De belangstelling foar proxies is begryplik. Wy sille it kontrolearje. Dit is in nijsgjirrich ûnderwerp.
A: - It idee wie dit: as jo pollers kinne patchje, kinne jo se op 'e proxy patchje en de ynteraksje mei de server patchje, en de preprocessor oanpasse foar dizze doelen allinich op' e server.
MM: - Ik tink dat it noch ienfâldiger is. Jo nimme de koade, tapasse in patch, konfigurearje it dan sa't jo nedich binne - sammelje proxy-tsjinners (bygelyks mei ODBC) en fersprieden de patched koade oer systemen. Wêr nedich - sammelje in proxy, wêr nedich - in tsjinner.
A: - Wierskynlik hoege jo de proxy-oerdracht ek net nei de tsjinner te patchjen?
MCH: - Nee, it is standert.
MM: – Eins klonk ien fan de ideeën net. Wy hawwe altyd in lykwicht hâlden tusken de eksploazje fan ideeën en it bedrach fan feroaringen en it gemak fan stipe.
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com