Konferenca tjetër e HighLoad++ do të mbahet më 6 dhe 7 prill 2020 në Shën Petersburg Detajet dhe biletat . HighLoad++ Moskë 2018. Salla “Moska”. 9 Nëntor, ora 15:00. Tezat dhe .
* Monitorimi - online dhe analitika.
* Kufizimet themelore të platformës ZABBIX.
* Zgjidhje për shkallëzimin e ruajtjes së analitikës.
* Optimizimi i serverit ZABBIX.
* Optimizimi i UI.
* Përvoja e funksionimit të sistemit nën ngarkesa prej më shumë se 40 mijë NVPS.
* Përfundime të shkurtra.
Mikhail Makurov (në tekstin e mëtejmë - MM): - Pershendetje te gjitheve!
Maxim Chernetsov (në tekstin e mëtejmë - MCH): - Mirembrema!
MM: – Më lejoni të prezantoj Maksimin. Max është një inxhinier i talentuar, rrjeti më i mirë që njoh. Maxim është i përfshirë në rrjete dhe shërbime, zhvillimin dhe funksionimin e tyre.
MCH: - Dhe unë do të doja t'ju tregoja për Mikhail. Mikhail është një zhvillues i C. Ai shkroi disa zgjidhje të përpunimit të trafikut me ngarkesë të lartë për kompaninë tonë. Ne jetojmë dhe punojmë në Urale, në qytetin e burrave të ashpër Chelyabinsk, në kompaninë Intersvyaz. Kompania jonë është një ofrues i shërbimeve të internetit dhe televizionit kabllor për një milion njerëz në 16 qytete.
MM: – Dhe ia vlen të thuhet se Intersvyaz është shumë më tepër sesa thjesht një ofrues, është një kompani IT. Shumica e zgjidhjeve tona janë bërë nga departamenti ynë i IT.
dhe: nga serverët që përpunojnë trafikun në qendrën e thirrjeve dhe aplikacionin celular. Departamenti i IT-së tani ka rreth 80 persona me kompetenca shumë, shumë të ndryshme.
Rreth Zabbix dhe arkitekturës së tij
MCH: - Dhe tani do të përpiqem të vendos një rekord personal dhe të them në një minutë se çfarë është Zabbix (në tekstin e mëtejmë "Zabbix").
Zabbix pozicionohet si një sistem monitorimi i jashtëm i nivelit të ndërmarrjes. Ka shumë veçori që e bëjnë jetën më të lehtë: rregulla të avancuara përshkallëzimi, API për integrimin, grupimin dhe zbulimin automatik të hosteve dhe metrikës. Zabbix ka të ashtuquajturat mjete shkallëzuese - proxies. Zabbix është një sistem me burim të hapur.
Shkurtimisht për arkitekturën. Mund të themi se përbëhet nga tre komponentë:
- Serveri. Shkruar në C. Me përpunim dhe transferim mjaft kompleks të informacionit ndërmjet temave. I gjithë përpunimi zhvillohet në të: nga marrja në ruajtjen në bazën e të dhënave.
- Të gjitha të dhënat ruhen në bazën e të dhënave. Zabbix mbështet MySQL, PostreSQL dhe Oracle.
- Ndërfaqja e internetit është e shkruar në PHP. Në shumicën e sistemeve vjen me një server Apache, por funksionon në mënyrë më efikase në kombinim me nginx + php.
Sot do të donim të tregonim një histori nga jeta e kompanisë sonë në lidhje me Zabbix...
Një histori nga jeta e kompanisë Intersvyaz. Çfarë kemi dhe çfarë kemi nevojë?
5 ose 6 muaj më parë. Një ditë pas punës...
MCH: - Misha, përshëndetje! Më vjen mirë që arrita t'ju kap - ka një bisedë. Ne përsëri patëm probleme me monitorimin. Gjatë një aksidenti të madh, gjithçka ishte e ngadaltë dhe nuk kishte asnjë informacion për gjendjen e rrjetit. Fatkeqësisht, kjo nuk është hera e parë që ndodh. Me duhet ndihma jote. Le ta bëjmë monitorimin tonë të funksionojë në çdo rrethanë!
MM: - Por le të sinkronizojmë së pari. Unë nuk kam shikuar atje për disa vjet. Me sa mbaj mend, ne e braktisëm Nagios-in dhe kaluam në Zabbix rreth 8 vjet më parë. Dhe tani duket se kemi 6 serverë të fuqishëm dhe rreth një duzinë proxies. A po ngatërroj ndonjë gjë?
MCH: - Pothuajse. 15 serverë, disa prej të cilëve janë makina virtuale. Gjëja më e rëndësishme është që nuk na shpëton në momentin kur kemi më shumë nevojë. Si një aksident - serverët ngadalësohen dhe nuk mund të shihni asgjë. Ne u përpoqëm të optimizonim konfigurimin, por kjo nuk siguroi rritjen optimale të performancës.
MM: - Është e qartë. A keni parë diçka, a keni nxjerrë tashmë diçka nga diagnostikimi?
MCH: – Gjëja e parë me të cilën duhet të merreni është baza e të dhënave. MySQL ngarkohet vazhdimisht, duke ruajtur metrika të reja dhe kur Zabbix fillon të gjenerojë një sërë ngjarjesh, baza e të dhënave shkon në mbingarkesë për fjalë për fjalë disa orë. Unë tashmë ju thashë për optimizimin e konfigurimit, por fjalë për fjalë këtë vit ata azhurnuan harduerin: serverët kanë më shumë se njëqind gigabajt memorie dhe grupe disku në SSD RAID - nuk ka kuptim ta rritni atë në mënyrë lineare në afat të gjatë. Çfarë bëjmë ne?
MM: - Është e qartë. Në përgjithësi, MySQL është një bazë të dhënash LTP. Me sa duket, nuk është më i përshtatshëm për të ruajtur një arkivë metrike të përmasave tona. Le ta kuptojmë.
MCH: - Le të!
Integrimi i Zabbix dhe Clickhouse si rezultat i hackathon
Pas ca kohësh morëm të dhëna interesante:
Pjesa më e madhe e hapësirës në bazën tonë të të dhënave ishte e zënë nga arkivi i metrikës dhe më pak se 1% u përdor për konfigurimin, shabllonet dhe cilësimet. Në atë kohë, ne kishim funksionuar zgjidhjen e të dhënave të mëdha bazuar në Clickhouse për më shumë se një vit. Drejtimi i lëvizjes ishte i qartë për ne. Në Hackathon tonë pranveror, unë shkrova integrimin e Zabbix me Clickhouse për serverin dhe frontendin. Në atë kohë, Zabbix tashmë kishte mbështetje për ElasticSearch, dhe ne vendosëm t'i krahasojmë ato.
Krahasimi i Clickhouse dhe Elasticsearch
MM: – Për krahasim, ne krijuam të njëjtën ngarkesë siç ofron serveri Zabbix dhe shikuam se si do të silleshin sistemet. Ne shkruam të dhëna në grupe prej 1000 rreshtash, duke përdorur CURL. Ne supozuam paraprakisht se Clickhouse do të ishte më efikas për profilin e ngarkesës që bën Zabbix. Rezultatet madje tejkaluan pritjet tona:
Në të njëjtat kushte testimi, Clickhouse shkroi tre herë më shumë të dhëna. Në të njëjtën kohë, të dy sistemet konsumuan në mënyrë shumë efikase (një sasi e vogël burimesh) gjatë leximit të të dhënave. Por Elastics kërkonte një sasi të madhe procesori gjatë regjistrimit:
Në total, Clickhouse ishte dukshëm superior ndaj Elastix për sa i përket konsumit dhe shpejtësisë së procesorit. Në të njëjtën kohë, për shkak të kompresimit të të dhënave, Clickhouse përdor 11 herë më pak në hard disk dhe kryen afërsisht 30 herë më pak operacione të diskut:
MCH: – Po, puna e Clickhouse me nënsistemin e diskut zbatohet me shumë efikasitet. Ju mund të përdorni disqe të mëdha SATA për bazat e të dhënave dhe të merrni shpejtësi shkrimi prej qindra mijëra rreshtash në sekondë. Sistemi i jashtëm mbështet ndarjen, riprodhimin dhe është shumë i lehtë për t'u konfiguruar. Ne jemi më se të kënaqur me përdorimin e tij gjatë gjithë vitit.
Për të optimizuar burimet, mund të instaloni Clickhouse pranë bazës së të dhënave kryesore ekzistuese dhe në këtë mënyrë të kurseni shumë kohë të CPU-së dhe operacioneve të diskut. Ne kemi zhvendosur arkivin e metrikës në grupimet ekzistuese të Clickhouse:
Ne e lehtësuam aq shumë bazën kryesore të të dhënave MySQL saqë mund ta kombinonim atë në një makinë me serverin Zabbix dhe të braktisnim serverin e dedikuar për MySQL.
Si funksionon votimi në Zabbix?
Muaj më parë 4
MM: – Epo, a mund të harrojmë problemet me bazën?
MCH: - Kjo është e sigurt! Një problem tjetër që duhet të zgjidhim është mbledhja e ngadaltë e të dhënave. Tani të gjithë 15 serverët tanë proxy janë të mbingarkuar me SNMP dhe procese votimi. Dhe nuk ka asnjë mënyrë tjetër përveç instalimit të serverëve të rinj dhe të rinj.
MM: - E shkëlqyeshme. Por së pari, na tregoni se si funksionon sondazhi në Zabbix?
MCH: – Me pak fjalë, ekzistojnë 20 lloje metrikash dhe një duzinë mënyrash për t'i marrë ato. Zabbix mund të mbledhë të dhëna ose në modalitetin "kërkesë-përgjigje", ose të presë për të dhëna të reja përmes "Trapper Interface".
Vlen të përmendet se në Zabbix origjinal kjo metodë (Trapper) është më e shpejta.
Ekzistojnë serverë proxy për shpërndarjen e ngarkesës:
Proxies mund të kryejnë të njëjtat funksione grumbullimi si serveri Zabbix, duke marrë detyra prej tij dhe duke dërguar metrikat e mbledhura përmes ndërfaqes Trapper. Kjo është mënyra e rekomanduar zyrtarisht për të shpërndarë ngarkesën. Proxies janë gjithashtu të dobishëm për monitorimin e infrastrukturës së largët që funksionon përmes NAT ose një kanali të ngadaltë:
MM: – Gjithçka është e qartë me arkitekturën. Duhet të shikojmë burimet...
Nja dy ditë më vonë
Historia se si fitoi nmap fping
MM: "Mendoj se kam nxjerrë diçka."
MCH: - Me trego!
MM: – Zbulova se kur kontrollon disponueshmërinë, Zabbix kontrollon maksimumi 128 hoste në të njëjtën kohë. Unë u përpoqa ta rris këtë numër në 500 dhe të heq intervalin ndërmjet paketave në ping (ping) e tyre - kjo dyfishoi performancën. Por unë do të doja numra më të mëdhenj.
MCH: – Në praktikën time, ndonjëherë më duhet të kontrolloj disponueshmërinë e mijëra hosteve dhe nuk kam parë kurrë diçka më të shpejtë se nmap për këtë. Jam i sigurt se kjo është mënyra më e shpejtë. Le ta provojmë! Ne duhet të rrisim ndjeshëm numrin e hosteve për përsëritje.
MM: – Kontrollo më shumë se pesëqind? 600?
MCH: - Të paktën nja dy mijë.
MM: - NE RREGULL. Gjëja më e rëndësishme që doja të them është se zbulova se shumica e sondazheve në Zabbix bëhen në mënyrë sinkrone. Ne patjetër duhet ta ndryshojmë atë në modalitetin asinkron. Atëherë ne mund të rrisim në mënyrë dramatike numrin e metrikave të mbledhura nga anketuesit, veçanërisht nëse rrisim numrin e metrikave për përsëritje.
MCH: - E shkëlqyeshme! Dhe kur?
MM: – Si zakonisht dje.
MCH: – Ne krahasuam të dy versionet e fping dhe nmap:
Në një numër të madh hostesh, nmap pritej të ishte deri në pesë herë më efektiv. Meqenëse nmap kontrollon vetëm disponueshmërinë dhe kohën e përgjigjes, ne e zhvendosëm llogaritjen e humbjeve në aktivizues dhe reduktuam ndjeshëm intervalet e kontrollit të disponueshmërisë. Ne gjetëm se numri optimal i hosteve për nmap është rreth 4 mijë për përsëritje. Nmap na lejoi të reduktojmë koston e CPU-së për kontrollet e disponueshmërisë me tre herë dhe të zvogëlojmë intervalin nga 120 sekonda në 10.
Optimizimi i sondazheve
MM: “Pastaj filluam të bëjmë sondazhe. Ne ishim të interesuar kryesisht për zbulimin dhe agjentët e SNMP. Në Zabbix, sondazhi bëhet në mënyrë sinkrone dhe janë marrë masa të veçanta për rritjen e efikasitetit të sistemit. Në modalitetin sinkron, mosdisponueshmëria e hostit shkakton degradim të konsiderueshëm në sondazh. Ekziston një sistem i tërë shtetesh, ka procese të veçanta - të ashtuquajturat votues të paarritshëm, të cilët punojnë vetëm me hostë të paarritshëm:
Ky është një koment që demonstron matricën e gjendjes, gjithë kompleksitetin e sistemit të tranzicioneve që kërkohen në mënyrë që sistemi të mbetet efektiv. Për më tepër, sondazhi sinkron në vetvete është mjaft i ngadaltë:
Kjo është arsyeja pse mijëra flukse sondazhesh në dhjetëra përfaqësues nuk mund të mbledhin sasinë e kërkuar të të dhënave për ne. Zbatimi asinkron zgjidhi jo vetëm problemet me numrin e temave, por gjithashtu thjeshtoi ndjeshëm sistemin shtetëror të hosteve të padisponueshëm, sepse për çdo numër të kontrolluar në një përsëritje votimi, koha maksimale e pritjes ishte 1 skadim:
Për më tepër, ne modifikuam dhe përmirësonim sistemin e votimit për kërkesat SNMP. Fakti është se shumica e njerëzve nuk mund t'u përgjigjen kërkesave të shumta SNMP në të njëjtën kohë. Prandaj, ne krijuam një modalitet hibrid, kur sondazhi SNMP i të njëjtit host kryhet në mënyrë asinkrone:
Kjo është bërë për të gjithë paketën e hosteve. Ky modalitet në fund të fundit nuk është më i ngadalshëm se ai plotësisht asinkron, pasi sondazhi i njëqind e gjysmë vlerave SNMP është ende shumë më i shpejtë se 1 kohë.
Eksperimentet tona kanë treguar se numri optimal i kërkesave në një përsëritje është afërsisht 8 mijë me sondazhin SNMP. Në total, kalimi në modalitetin asinkron na lejoi të përshpejtonim performancën e sondazheve me 200 herë, disa qindra herë.
MCH: – Optimizimet e sondazheve që rezultuan treguan se ne jo vetëm që mund të heqim qafe të gjitha proxy-et, por gjithashtu të zvogëlojmë intervalet për shumë kontrolle dhe proxies nuk do të nevojiten më si një mënyrë për të ndarë ngarkesën.
Rreth tre muaj më parë
Ndryshoni arkitekturën - rritni ngarkesën!
MM: - Epo, Maks, a është koha për t'u bërë produktiv? Më duhet një server i fuqishëm dhe një inxhinier i mirë.
MCH: - Mirë, le ta planifikojmë. Është koha për të lëvizur nga pika e vdekur e 5 mijë metrikave në sekondë.
Mëngjes pas përmirësimit
MCH: - Misha, ne u përditësuam, por deri në mëngjes u rikthyem... Merreni me mend se çfarë shpejtësie arritëm të arrinim?
MM: – Maksimumi 20 mijë.
MCH: - Po, 25! Fatkeqësisht, jemi aty ku e nisëm.
MM: - Pse? A keni kryer ndonjë diagnostifikim?
MCH: - Po sigurisht! Këtu, për shembull, është një top interesant:
MM: - Le të shikojmë. Unë shoh që ne kemi provuar një numër të madh të temave të votimit:
Por në të njëjtën kohë ata nuk mund ta riciklonin sistemin as përgjysmë:
Dhe performanca e përgjithshme është mjaft e vogël, rreth 4 mijë metrikë në sekondë:
A ka ndonjë gjë tjetër?
MCH: – Po, gjurma e njërit prej anketuesve:
MM: – Këtu shihet qartë se procesi i votimit është në pritje të “semaforëve”. Këto janë flokët:
MCH: - E paqartë.
MM: – Shikoni, kjo është e ngjashme me një situatë ku një grup fijesh po përpiqen të punojnë me burime me të cilat vetëm njëri mund të punojë në të njëjtën kohë. Atëherë gjithçka që ata mund të bëjnë është të ndajnë këtë burim me kalimin e kohës:
Dhe performanca totale e punës me një burim të tillë është i kufizuar nga shpejtësia e një bërthame:
Ka dy mënyra për të zgjidhur këtë problem.
Përmirësoni harduerin e makinës, kaloni në bërthama më të shpejta:
Ose ndryshoni arkitekturën dhe në të njëjtën kohë ndryshoni ngarkesën:
MCH: – Nga rruga, në makinën e provës do të përdorim më pak bërthama sesa në atë luftarake, por ato janë 1,5 herë më të shpejta në frekuencë për bërthamë!
MM: - Qartë? Duhet të shikoni kodin e serverit.
Rruga e të dhënave në serverin Zabbix
MCH: – Për ta kuptuar, filluam të analizojmë se si transferohen të dhënat brenda serverit Zabbix:
Fotografi e bukur, apo jo? Le ta kalojmë hap pas hapi për ta bërë pak a shumë të qartë. Ekzistojnë lidhje dhe shërbime përgjegjëse për mbledhjen e të dhënave:
Ata transmetojnë matjet e mbledhura përmes një prize te menaxheri i paraprocesorit, ku ruhen në një radhë:
"Menaxheri i paraprocesorit" transmeton të dhëna te punonjësit e tij, të cilët ekzekutojnë instruksionet e parapërpunimit dhe i kthejnë ato përsëri përmes të njëjtit fole:
Pas kësaj, menaxheri i paraprocesorit i ruan ato në cache të historisë:
Prej andej ato merren nga sinkerët e historisë, të cilët kryejnë mjaft funksione: për shembull, llogaritjen e nxitësve, mbushjen e cache-it të vlerave dhe, më e rëndësishmja, ruajtjen e metrikës në ruajtjen e historisë. Në përgjithësi, procesi është kompleks dhe shumë konfuz.
MM: – Gjëja e parë që pamë ishte se shumica e temave konkurrojnë për të ashtuquajturën “cache e konfigurimit” (zona e kujtesës ku ruhen të gjitha konfigurimet e serverit). Temat përgjegjëse për mbledhjen e të dhënave bllokojnë veçanërisht shumë:
...meqenëse konfigurimi ruan jo vetëm metrikat me parametrat e tyre, por edhe radhët nga të cilat anketuesit marrin informacione se çfarë të bëjnë më pas. Kur ka shumë anketues dhe njëri bllokon konfigurimin, të tjerët presin kërkesa:
Anketuesit nuk duhet të konfliktohen
Prandaj, gjëja e parë që bëmë ishte ndarja e radhës në 4 pjesë dhe lejimi i anketuesve të bllokojnë këto radhë, këto pjesë në të njëjtën kohë, në kushte të sigurta:
Kjo hoqi konkurrencën për cache-in e konfigurimit dhe shpejtësia e anketuesve u rrit ndjeshëm. Por më pas hasëm në faktin që menaxheri i paraprocesorit filloi të grumbullonte një radhë pune:
Menaxheri i paraprocesorit duhet të jetë në gjendje të japë përparësi
Kjo ndodhte në rastet kur i mungonte performanca. Më pas, gjithçka që mundi të bënte ishte të grumbullonte kërkesa nga proceset e mbledhjes së të dhënave dhe të shtonte buferin e tyre derisa të konsumonte të gjithë kujtesën dhe të rrëzohej:
Për të zgjidhur këtë problem, ne shtuam një prizë të dytë që iu dedikua posaçërisht punëtorëve:
Kështu, menaxheri i paraprocesorit pati mundësinë të prioritizojë punën e tij dhe, nëse buferi rritet, detyra është të ngadalësojë heqjen, duke u dhënë punëtorëve mundësinë për të marrë këtë bufer:
Më pas zbuluam se një nga arsyet e ngadalësimit ishin vetë punëtorët, pasi ata po konkurronin për një burim që ishte krejtësisht i parëndësishëm për punën e tyre. Ne e dokumentuam këtë problem si një rregullim të gabimeve dhe ai tashmë është zgjidhur në versionet e reja të Zabbix:
Ne rrisim numrin e prizave - marrim rezultatin
Më tej, vetë menaxheri i paraprocesorit u bë një pengesë, pasi është një fije. Ai mbështetej në shpejtësinë bazë, duke dhënë një shpejtësi maksimale prej rreth 70 mijë metrikë në sekondë:
Prandaj, ne bëmë katër, me katër grupe prizash, punëtorë:
Dhe kjo na lejoi të rrisim shpejtësinë në afërsisht 130 mijë metrikë:
Jo-lineariteti i rritjes shpjegohet me faktin se është shfaqur konkurrenca për cache-in e historisë. Për të konkurruan 4 menaxherë të parapërpunuesve dhe zhytës të historisë. Në këtë pikë, ne po merrnim afërsisht 130 mijë metrikë në sekondë në makinën e testimit, duke e shfrytëzuar atë nga afërsisht 95% e procesorit:
Rreth 2,5 muaj më parë
Refuzimi nga komuniteti snmp rriti NVP-të me një herë e gjysmë
MM: – Maks, më duhet një makinë e re testuese! Ne nuk përshtatemi më me atë aktual.
MCH: - Çfarë ke tani?
MM: – Tani – 130 mijë NVP dhe një procesor i gatshëm për raft.
MCH: - Uau! E bukur! Prit, kam dy pyetje. Sipas llogaritjeve të mia, nevoja jonë është rreth 15-20 mijë metrikë në sekondë. Pse na duhen më shumë?
MM: "Unë dua të përfundoj punën." Do të doja të shihja se sa mund të shtrydhim nga ky sistem.
MCH: - Por…
MM: "Por është e padobishme për biznes."
MCH: - Është e qartë. Dhe pyetja e dytë: a mund ta mbështesim atë që kemi tani vetë, pa ndihmën e një zhvilluesi?
MM: - Nuk mendoj. Ndryshimi i mënyrës se si funksionon cache-i i konfigurimit është një problem. Ndikon në ndryshimet në shumicën e fijeve dhe është mjaft i vështirë për t'u ruajtur. Me shumë mundësi, do të jetë shumë e vështirë për ta mbajtur atë.
MCH: "Atëherë ne kemi nevojë për një lloj alternativë."
MM: - Ekziston një opsion i tillë. Mund të kalojmë në bërthama të shpejta, duke braktisur sistemin e ri të kyçjes. Ne ende do të marrim një performancë prej 60-80 mijë metrikë. Në të njëjtën kohë, ne mund të lëmë të gjithë pjesën tjetër të kodit. Clickhouse dhe sondazhi asinkron do të funksionojnë. Dhe do të jetë e lehtë për tu mirëmbajtur.
MCH: - E mahnitshme! Unë sugjeroj të ndalemi këtu.
Pas optimizimit të anës së serverit, më në fund ishim në gjendje të nisnim kodin e ri në prodhim. Ne braktisëm disa nga ndryshimet në favor të kalimit në një makinë me bërthama të shpejta dhe minimizimin e numrit të ndryshimeve të kodit. Ne kemi thjeshtuar gjithashtu konfigurimin dhe kemi eliminuar makrot në artikujt e të dhënave aty ku është e mundur, pasi ato paraqesin mbyllje shtesë.
Për shembull, braktisja e makros së komunitetit snmp, i cili shpesh gjendet në dokumentacion dhe shembuj, në rastin tonë bëri të mundur përshpejtimin e mëtejshëm të NVP-ve me rreth 1,5 herë.
Pas dy ditësh në prodhim
Heqja e dritareve kërcyese të historikut të incidenteve
MCH: – Misha, ne kemi dy ditë që përdorim sistemin dhe gjithçka funksionon. Por vetëm kur gjithçka funksionon! Ne kishim planifikuar punë me transferimin e një segmenti mjaft të madh të rrjetit dhe kontrolluam përsëri me duart tona se çfarë u ngjit dhe çfarë jo.
MM: - Nuk mund të jetë! Ne kontrolluam gjithçka 10 herë. Serveri trajton edhe padisponueshmërinë e plotë të rrjetit në çast.
MCH: - Po, unë kuptoj gjithçka: server, bazë të dhënash, krye, austat, regjistra - gjithçka është e shpejtë... Por ne shikojmë ndërfaqen e uebit dhe ka një procesor "në raft" në server dhe kjo:
MM: - Është e qartë. Le të shikojmë ueb-in. Ne zbuluam se në një situatë ku kishte një numër të madh incidentesh aktive, shumica e miniaplikacioneve të drejtpërdrejta filluan të funksionojnë shumë ngadalë:
Arsyeja për këtë ishte gjenerimi i dritareve kërcyese të historisë së incidenteve që krijohen për secilin artikull në listë. Prandaj, ne braktisëm gjenerimin e këtyre dritareve (komentuam 5 rreshta në kod) dhe kjo zgjidhi problemet tona.
Koha e ngarkimit për miniaplikacionet, edhe kur nuk janë plotësisht të disponueshme, është reduktuar nga disa minuta në 10-15 sekondat e pranueshme për ne, dhe historia mund të shihet ende duke klikuar në kohën:
Pas pune. 2 muaj me pare
MCH: - Misha, po largohesh? Duhet të flasim.
MM: - Nuk e kisha ndërmend. Diçka me Zabbix përsëri?
MCH: - Jo, pusho! Unë thjesht doja të them: gjithçka funksionon, faleminderit! Unë kam një birrë.
Zabbix është efikas
Zabbix është një sistem dhe funksion mjaft universal dhe i pasur. Mund të përdoret për instalime të vogla jashtë kutisë, por me rritjen e nevojave, ai duhet të optimizohet. Për të ruajtur një arkiv të madh metrikash, përdorni një ruajtje të përshtatshme:
- mund të përdorni mjete të integruara në formën e integrimit me Elasticsearch ose ngarkimit të historisë në skedarë teksti (të disponueshëm nga versioni 4);
- Ju mund të përfitoni nga përvoja dhe integrimi ynë me Clickhouse.
Për të rritur në mënyrë dramatike shpejtësinë e mbledhjes së metrikave, mblidhni ato duke përdorur metoda asinkrone dhe transmetojini ato përmes ndërfaqes trapper në serverin Zabbix; ose mund të përdorni një patch për t'i bërë anketuesit Zabbix asinkron.
Zabbix është i shkruar në C dhe është mjaft efikas. Zgjidhja e disa pengesave arkitekturore ju lejon të rrisni më tej performancën e tij dhe, në përvojën tonë, të merrni më shumë se 100 mijë metrikë në një makinë me një procesor.
E njëjta patch Zabbix
MM: – Dua të shtoj disa pika. I gjithë raporti aktual, të gjitha testet, numrat janë dhënë për konfigurimin që ne përdorim. Tani po marrim afërsisht 20 mijë metrikë në sekondë prej saj. Nëse po përpiqeni të kuptoni nëse kjo do të funksionojë për ju, mund të krahasoni. Ajo që u diskutua sot është postuar në GitHub në formën e një patch:
Patch përfshin:
- integrim i plotë me Clickhouse (si server Zabbix ashtu edhe frontend);
- zgjidhja e problemeve me menaxherin e paraprocesorit;
- votimi asinkron.
Patch-i është i pajtueshëm me të gjithë versionin 4, duke përfshirë lts. Me shumë mundësi, me ndryshime minimale do të funksionojë në versionin 3.4.
Faleminderit për vëmendjen tuaj.
Pyetjet tuaja
Pyetje nga auditori (në tekstin e mëtejmë – A): – Mirëdita! Ju lutem më tregoni, a keni plane për ndërveprim intensiv me ekipin e Zabbix apo me ata me ju, në mënyrë që kjo të mos jetë një patch, por sjellje normale e Zabbix?
MM: – Po, do të bëjmë patjetër disa nga ndryshimet. Diçka do të ndodhë, diçka do të mbetet në arnim.
dhe: – Faleminderit shumë për raportin e shkëlqyer! Ju lutem më tregoni, pas aplikimit të patch-it, mbështetja nga Zabbix do të mbetet dhe si të vazhdohet përditësimi në versionet më të larta? A do të jetë e mundur të përditësoni Zabbix pas patch-it tuaj në 4.2, 5.0?
MM: – Nuk mund të them asgjë për mbështetjen. Nëse do të isha mbështetja teknike e Zabbix, ndoshta do të thosha jo, sepse ky është kodi i dikujt tjetër. Sa i përket bazës së kodeve 4.2, pozicioni ynë është: "Ne do të lëvizim me kalimin e kohës dhe do të përditësojmë veten në versionin tjetër." Prandaj, për disa kohë ne do të postojmë një patch për versionet e përditësuara. Unë tashmë thashë në raport: numri i ndryshimeve me versionet është ende mjaft i vogël. Unë mendoj se kalimi nga 3.4 në 4 na mori rreth 15 minuta. Diçka ndryshoi atje, por jo shumë e rëndësishme.
dhe: – Pra, planifikoni të mbështesni patch-in tuaj dhe mund ta instaloni me siguri në prodhim dhe të merrni përditësime në një farë mënyre në të ardhmen?
MM: – Ne e rekomandojmë fuqimisht. Kjo na zgjidh shumë probleme.
MCH: – Edhe një herë, dëshiroj të tërheq vëmendjen se ndryshimet që nuk kanë të bëjnë me arkitekturën dhe nuk kanë të bëjnë me bllokimin apo radhët janë modulare, janë në module të veçanta. Edhe me ndryshime të vogla ju mund t'i mbani ato mjaft lehtë.
MM: – Nëse jeni të interesuar për detajet, atëherë “Clickhouse” përdor të ashtuquajturën bibliotekë të historisë. Është e zgjidhur - është një kopje e mbështetjes Elastics, domethënë është e konfigurueshme. Sondazhi ndryshon vetëm anketuesit. Ne besojmë se kjo do të funksionojë për një kohë të gjatë.
dhe: - Faleminderit shume. Më thuaj, a ka ndonjë dokumentacion të ndryshimeve të bëra?
MM: – Dokumentacioni është një arnim. Natyrisht, me prezantimin e Clickhouse, me futjen e llojeve të reja të votuesve, lindin opsione të reja konfigurimi. Lidhja nga rrëshqitja e fundit ka një përshkrim të shkurtër se si ta përdorni.
Rreth zëvendësimit të fping me nmap
dhe: – Si e realizuat përfundimisht këtë? A mund të jepni shembuj konkretë: a keni strippers dhe një skenar të jashtëm? Çfarë përfundon duke kontrolluar kaq shpejt një numër kaq të madh hostesh? Si i shfrytëzoni këto hoste? A duhet t'i ushqejmë për nmap disi, t'i marrim nga diku, t'i vendosim, të ekzekutojmë diçka?..
MM: - E ftohtë. Nje pyetje shume korrekte! Çështja është kjo. Ne modifikuam bibliotekën (ping ICMP, pjesë e Zabbix) për kontrollet ICMP, të cilat tregojnë numrin e paketave - një (1), dhe kodi përpiqet të përdorë nmap. Kjo është, kjo është puna e brendshme e Zabbix, e cila është bërë puna e brendshme e pinger. Rrjedhimisht, nuk kërkohet asnjë sinkronizim ose përdorimi i një trapper. Kjo është bërë qëllimisht në mënyrë që të lihet sistemi i paprekur dhe të mos kemi të bëjmë me sinkronizimin e dy sistemeve të bazës së të dhënave: çfarë të kontrollojmë, të ngarkojmë përmes polerit dhe a është prishur ngarkimi ynë?.. Kjo është shumë më e thjeshtë.
dhe: – A funksionon edhe për proxy?
MM: – Po, por nuk e kontrolluam. Kodi i votimit është i njëjtë si në Zabbix ashtu edhe në server. Duhet të funksionojë. Më lejoni të theksoj edhe një herë: performanca e sistemit është e tillë që nuk kemi nevojë për një përfaqësues.
MCH: - Përgjigja e saktë në pyetjen është: "Pse ju duhet një përfaqësues me një sistem të tillë?" Vetëm për shkak të NAT ose monitorimit përmes një lloj kanali të ngadaltë...
dhe: – Dhe ju përdorni Zabbix-in si alertor, nëse e kuptoj mirë. Apo grafikat tuaja (ku është shtresa e arkivit) janë zhvendosur në një sistem tjetër, siç është Grafana? Apo nuk po e përdorni këtë funksionalitet?
MM: – Do të theksoj edhe një herë: ne kemi arritur integrimin e plotë. Ne po derdhim historinë në Clickhouse, por në të njëjtën kohë kemi ndryshuar frontin e php. Pjesa e përparme e Php shkon në Clickhouse dhe bën të gjitha grafikat nga atje. Në të njëjtën kohë, për të qenë i sinqertë, ne kemi një pjesë që ndërton të dhëna në sisteme të tjera të ekranit grafik nga i njëjti Clickhouse, nga të njëjtat të dhëna Zabbix.
MCH: – Edhe në “Grafan”.
Si u morën vendimet për shpërndarjen e burimeve?
dhe: – Ndani pak nga kuzhina juaj e brendshme. Si u mor vendimi që ishte e nevojshme të ndaheshin burime për përpunim serioz të produktit? Këto janë, në përgjithësi, rreziqe të caktuara. Dhe ju lutem më thoni, në kuadër të faktit që do të mbështesni versione të reja: si justifikon ky vendim nga pikëpamja menaxheriale?
MM: – Me sa duket, dramën e historisë nuk e kemi treguar shumë mirë. Ne u gjendëm në një situatë ku duhej bërë diçka dhe në thelb shkuam me dy ekipe paralele:
- Njëri ishte lansimi i një sistemi monitorimi duke përdorur metoda të reja: monitorimi si shërbim, një grup standard i zgjidhjeve me burim të hapur që ne i kombinojmë dhe më pas përpiqemi të ndryshojmë procesin e biznesit në mënyrë që të punojmë me sistemin e ri të monitorimit.
- Në të njëjtën kohë, ne kishim një programues entuziast që e bënte këtë (për veten e tij). Kështu ndodhi që ai fitoi.
dhe: – Dhe sa është madhësia e ekipit?
MCH: - Ajo është para jush.
dhe: – Pra, si gjithmonë, keni nevojë për një pasionant?
MM: – Nuk e di se çfarë është një pasionant.
dhe: - Në këtë rast, me sa duket, ju. Faleminderit shumë, jeni të mrekullueshëm.
MM: - Faleminderit.
Rreth arna për Zabbix
dhe: – Për një sistem që përdor proxies (për shembull, në disa sisteme të shpërndara), a është e mundur të përshtaten dhe të rregullohen, të themi, pollers, proxies dhe pjesërisht paraprocesori i vetë Zabbix; dhe ndërveprimin e tyre? A është e mundur të optimizohen zhvillimet ekzistuese për një sistem me shumë përfaqësues?
MM: – E di që serveri Zabbix është montuar duke përdorur një përfaqësues (kodi përpilohet dhe merret). Ne nuk e kemi testuar këtë në prodhim. Nuk jam i sigurt për këtë, por mendoj se menaxheri i paraprocesorit nuk përdoret në proxy. Detyra e përfaqësuesit është të marrë një grup metrikash nga Zabbix, t'i bashkojë ato (ai gjithashtu regjistron konfigurimin, bazën e të dhënave lokale) dhe t'ia kthejë atë serverit Zabbix. Vetë serveri më pas do të bëjë parapërpunimin kur ta marrë atë.
Interesi për proxy është i kuptueshëm. Do ta kontrollojmë. Kjo është një temë interesante.
dhe: – Ideja ishte kjo: nëse mund t'i patchoni polluesit, mund t'i rregulloni ato në proxy dhe të rregulloni ndërveprimin me serverin, dhe të përshtatni paraprocesorin për këto qëllime vetëm në server.
MM: – Mendoj se është edhe më e thjeshtë. Ju merrni kodin, aplikoni një patch, më pas e konfiguroni ashtu siç ju nevojitet - mblidhni serverë proxy (për shembull, me ODBC) dhe shpërndani kodin e korrigjuar nëpër sisteme. Kur është e nevojshme - mblidhni një përfaqësues, kur është e nevojshme - një server.
dhe: - Me shumë mundësi, nuk do t'ju duhet të rregulloni më tej transmetimin e përfaqësuesit në server?
MCH: - Jo, është standard.
MM: – Në fakt, një nga idetë nuk tingëllonte. Ne kemi mbajtur gjithmonë një ekuilibër midis shpërthimit të ideve dhe sasisë së ndryshimeve dhe lehtësisë së mbështetjes.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com