Konferenca e ardhshme HighLoad++ do të zhvillohet më 6 dhe 7 prill 2020 në Shën Petersburg. Detajet dhe biletat. . HighLoad++ Moskë 2018. Salla «Moska». 9 nëntor, 15:00. Abstraktet dhe .
* Monitorimi â online dhe analiza.
* Kufizimet kryesore të platformës ZABBIX.
* Zgjidhje për zgjerimin e magazinës së analizës.
* Optimizimi i serverit ZABBIX.
* Optimizimi i UI.
* Eksperienca në përdorimin e sistemit në ngarkesa mbi 40k NVPS.
* Përmbledhje të shkurtra.
Mikhail Makurov (mĂ« tej â MM): â PĂ«rshĂ«ndetje tĂ« gjithĂ«ve!
Maxim Chernetsov (mĂ« tej â MĂ): â MirĂ«dita!
MM: â MĂ« lejoni tĂ« prezantoj Maxim. Max Ă«shtĂ« njĂ« inxhinier i talentuar, miku mĂ« i mirĂ« i rrjeteve qĂ« njoh. Maxim merret me rrjetet dhe shĂ«rbimet, zhvillimin dhe mirĂ«mbajtjen e tyre.
MĂ: â Dhe do tĂ« doja tĂ« flisja pĂ«r Mikhailin. Mikhail Ă«shtĂ« programues nĂ« C. Ai ka shkruar disa zgjidhje me ngarkesĂ« tĂ« lartĂ« pĂ«r pĂ«rpunimin e trafik, pĂ«r kompaninĂ« tonĂ«. Ne jetojmĂ« dhe punojmĂ« nĂ« Ural, nĂ« qytetin e burra tĂ« fortĂ« Chelyabinsk, nĂ« kompaninĂ« «Intersvyaz». Kompania ynĂ« Ă«shtĂ« njĂ« ofrues shĂ«rbimesh interneti dhe televizionit kabllor pĂ«r njĂ« milion njerĂ«z nĂ« 16 qytete.
MM: â Dhe duhet tĂ« them se «Intersvyaz» Ă«shtĂ« shumĂ« mĂ« tepĂ«r se thjesht njĂ« ofrues shĂ«rbimesh, Ă«shtĂ« njĂ« kompani IT. Shumica e zgjidhjeve tona janĂ« bĂ«rĂ« nga departamenti ynĂ« IT.
P: nga serverët që përpunojnë trafik, deri te qendra e thirrjeve dhe aplikacioni mobil. Në departamentin IT tani janë rreth 80 persona me kompetenca shumë të ndryshme.
Për Zabbix dhe arkitekturën e tij
MĂ: â Tani do tĂ« pĂ«rpiqem tĂ« vendos njĂ« rekord personal dhe nĂ« njĂ« minutĂ« tĂ« them se çfarĂ« Ă«shtĂ« Zabbix (mĂ« tej â «Zabbix«).
«Zabbix» pozicionohet si njĂ« sistem monitorimi «nga kutia» pĂ«r nivelin e ndĂ«rmarrjeve. Ai ka shumĂ« funksione tĂ« thjeshta pĂ«r jetĂ«n: rregulla tĂ« avancuara pĂ«r eskalimin, API pĂ«r integrim, grupimin dhe zbulimin automatik tĂ« hosteve dhe metrikave. NĂ« «Zabbix» ka ato qĂ« quhen mjete pĂ«r zgjerim â proxy. «Zabbix» Ă«shtĂ« njĂ« sistem me kod tĂ« hapur.
Përmbledhje mbi arkitekturën. Mund të themi se ajo përbëhet nga tre komponente:
- Serveri. Shkruar në C. Me përpunimin dhe transferimin e informacionit midis proceseve të ndërlikuar. Të gjitha përpunimet ndodhin aty: nga marrja deri te ruajtja në bazë.
- Të dhënat e gjitha ruhen në bazë. «Zabbix» mbështet MySQL, PostgreSQL dhe Oracle.
- Ndërfaqja e uebit është shkruar në PHP. Në shumicën e sistemeve vjen me serverin Apache, por funksionon më efektivisht me nginx + php.
Sot do të dëshirojmë të ndajmë një histori nga jeta e kompanisë sonë, lidhur me "Zabbix"...
Historia nga jeta e kompanisĂ« "Intersvyaz". ĂfarĂ« kemi dhe çfarĂ« na nevojitet?
5 ose 6 muaj më parë. Një ditë pas punës...
MĂ: â Misha, pĂ«rshĂ«ndetje! Jam i lumtur qĂ« tĂ« kapa â kam njĂ« bisedĂ«. PĂ«rsĂ«ri kemi pasur probleme me monitorimin. GjatĂ« njĂ« avarie tĂ« madhe, gjithçka ishte ngadalĂ«suar, dhe nuk kishim asnjĂ« informacion pĂ«r gjendjen e rrjetit. FatkeqĂ«sisht, kjo po ndodh pĂ«rsĂ«ri. Kam nevojĂ« pĂ«r ndihmĂ«n tĂ«nde. Le tĂ« bĂ«jmĂ« qĂ« monitorimi ynĂ« tĂ« funksionojĂ« nĂ« çdo rast!
MM: â Por le tĂ« fillojmĂ« sĂ« pari me sinkronizimin. Nuk kam parĂ« atje pĂ«r disa vite. Sa mĂ« kujtohet, ne hodhĂ«m poshtĂ« Nagios dhe kaluam nĂ« "Zabbix" rreth 8 vjet mĂ« parĂ«. Dhe tani duket se kemi 6 serverĂ« tĂ« fuqishĂ«m dhe rreth njĂ« duzinĂ« proxy. A po e ngatĂ«rron ndonjĂ« gjĂ«?
MĂ: â Pothuajse. 15 serverĂ«, disa prej tĂ« cilĂ«ve janĂ« makina virtuale. E rĂ«ndĂ«sishmja Ă«shtĂ« se kjo nuk na shpĂ«ton nĂ« momentin mĂ« tĂ« nevojshĂ«m. Kur ndodh njĂ« avari â serverĂ«t ngadalĂ«sohen dhe nuk shikohet asgjĂ«. Kemi provuar tĂ« optimizojmĂ« konfigurimin, por optimizimi nuk sjell njĂ« rritje optimale tĂ« performancĂ«s.
MM: â E kuptoj. Keni parĂ« diçka, a keni nxjerrĂ« ndonjĂ« informacion nga diagnostika?
MĂ: â E para qĂ« duhet tĂ« merremi me tĂ« Ă«shtĂ« bazat e tĂ« dhĂ«nave. MySQL Ă«shtĂ« gjithashtu vazhdimisht nĂ«n ngarkesĂ«, duke ruajtur metrikat e reja, ndĂ«rsa kur "Zabbix" fillon tĂ« gjenerojĂ« njĂ« mori ngjarjesh â baza shpĂ«rngulet brenda pĂ«r disa orĂ«. TĂ« optimizoja konfigurimin tĂ«ndĂ« tĂ« kam thĂ«nĂ« tashmĂ«, ndĂ«rsa kĂ«tĂ« vit kemi pĂ«rmirĂ«suar harduerin: nĂ« serverĂ« kemi mĂ« shumĂ« se njĂ«qind GB memoria dhe grumbuj tĂ« diskĂ«ve nĂ« RAID SSD â nuk ka kuptim ta rritim atĂ« mĂ« tej. ĂfarĂ« do tĂ« bĂ«jmĂ«?
MM: â E kuptoj. NĂ« tĂ« vĂ«rtetĂ«, MySQL Ă«shtĂ« njĂ« bazĂ« tĂ« dhĂ«nash LTP. Duket se nuk Ă«shtĂ« mĂ« e pĂ«rshtatshme pĂ«r ruajtjen e arkivave tĂ« metrikeve tĂ« kĂ«tij madhĂ«sie. Le tĂ« merremi me tĂ«.
MĂ: â Le tĂ« bĂ«jmĂ«!
Integrimi i Zabbix dhe Clickhouse si rezultat i hackathon-it
Pas një kohe, morëm të dhëna interesante:
Shumica e hapësirës në bazën tonë u zëvendësua nga arkiva e metrikave dhe më pak se 1% u përdor për konfigurim, shabllone dhe cilësime. Në atë kohë, ne kishim operuar një zgjidhje Big Data bazuar në Clickhouse për më shumë se një vit. Drejtimi i veprimit ishte i qartë për ne. Në «Hackathon»-in tonë të pranverës, shkrova integrimin e «Zabbix»-it me «Clickhouse» për serverin dhe frontend-in. Në atë kohë, «Zabbix» tashmë kishte mbështetje për ElasticSearch, dhe ne vendosëm të bëjmë një krahasim mes tyre.
Krahasimi Clickhouse dhe Elasticsearch
MM: â PĂ«r krahasim, ne gjeneronim ngarkesĂ« tĂ« njĂ«jtĂ«n si ajo qĂ« ofron «serveri Zabbix» dhe shikonim se si do tĂ« funksionojnĂ« sistemet. Ne shkruam tĂ« dhĂ«na nĂ« grupe nga 1000 rreshta, pĂ«rdorĂ«m CURL. Ne parashikuam se «Clickhouse» do tĂ« ishte mĂ« efektiv pĂ«r profilin e ngarkesĂ«s qĂ« bĂ«n «Zabbix». Rezultatet madje e tejkaluan pritshmĂ«ritĂ« tona:
Në kushte të njëjta në testet, «Clickhouse» shkruante tri herë më shumë të dhëna. Megjithatë, të dy sistemet konsumonin shumë efikasitet (një sasi të vogël burimesh) kur lexonin të dhënat. Por «Elasticsearch» kërkonte një sasi të madhe procesori gjatë shkruajtes:
Përmbledhtas, «Clickhouse» e tejkaloi dukshëm «Elasticsearch» në konsumimin e procesorit dhe shpejtësinë. Duke marrë parasysh kompresimin e të dhënave, «Clickhouse» përdor 11 herë më pak hapësirë në disk dhe bën rreth 30 herë më pak operacione në disk:
MĂ: â Po, puna me sistemin diskor nĂ« «Clickhouse» Ă«shtĂ« realizuar shumĂ« efektivisht. PĂ«r bazat mund tĂ« pĂ«rdoren disqe tĂ« mĂ«dha SATA dhe tĂ« arrihet njĂ« shpejtĂ«si shkruese nĂ« qindra mijĂ«ra rreshta nĂ« sekondĂ«. Sistemi mbĂ«shtet natyrshĂ«m sharding, replikimin dhe Ă«shtĂ« shumĂ« e lehtĂ« pĂ«r t'u konfiguruar. Ne jemi mĂ« shumĂ« se tĂ« kĂ«naqur me pĂ«rdorimin e saj pĂ«r njĂ« vit.
Për optimizimin e burimeve, mund të instaloni «Clickhouse» afër bazës ekzistuese kryesore dhe kështu të ruani shumë kohë procesori dhe operacione diskore. Ne e transferuam arkivën e metrikave në klasteret ekzistuese të «Clickhouse»:
Ne e ngarkuam kaq shumë bazën kryesore MySQL, saqë mundëm ta bashkojmë atë në një makinë me «serverin Zabbix» dhe të heqim dorë nga një server i dedikuar për MySQL.
Si funksionon polling në Zabbix?
4 muaj më parë
MM: â Tani mund t'i harrojmĂ« problemet me bazĂ«n?
MĂ: â Kjo Ă«shtĂ« e vĂ«rtetĂ«! NjĂ« tjetĂ«r detyrĂ« qĂ« na duhet tĂ« zgjidhim Ă«shtĂ« mbledhja e ngadalshme e tĂ« dhĂ«nave. Tani tĂ« gjithĂ« 15 serverĂ«t tanĂ« tĂ« proxy janĂ« tĂ« ngarkuar me procese SNMP dhe polling. Dhe nuk ka asgjĂ« tjetĂ«r pĂ«rveçse tĂ« vendosim serverĂ« tĂ« rinj e tĂ« rinj.
MM: â ShumĂ« mirĂ«. Por mĂ« thuaj sĂ« pari, si funksionon polling nĂ« 'Zabbix'?
MĂ: â NĂ«se bĂ«jmĂ« tĂ« shkurtĂ«r, ekzistojnĂ« 20 lloje metrikash dhe dhjetĂ« mĂ«nyra pĂ«r t'i marrĂ« ato. 'Zabbix' mund tĂ« mbledhĂ« tĂ« dhĂ«na ose nĂ« modalitetin 'kĂ«rkesĂ« â pĂ«rgjigje', ose tĂ« presĂ« tĂ« dhĂ«na tĂ« reja pĂ«rmes 'Trap Interface'.
Duhet të përmendim se në 'Zabbix' origjinal, kjo mënyrë (Trapper) është më e shpejtë.
Ekzistojnë proxy për shpërndarjen e ngarkesës:
Proxy mund të kryejnë të njëjtat funksione mbledhjeje si serveri 'Zabbix', duke marrë detyra prej tij dhe duke dërguar metrikat e mbledhura pikërisht përmes interfesës Trapper. Kjo është mënyra e rekomanduar zyrtarisht për shpërndarjen e ngarkesës. Gjithashtu, proxy janë të dobishme për monitorimin e infrastrukturës së largët që punon përmes NAT ose një kanali të ngadalshëm:
MM: â Arkitektura Ă«shtĂ« e qartĂ«. Duhet tĂ« shohim burimet...
Disa ditë më vonë
Një tregim për atë se si nmap fping fitoi
MM: â Duket se kam gjetur diçka.
MĂ: â Trego!
MM: â Kam zbuluar se gjatĂ« kontrollimeve tĂ« disponueshmĂ«risĂ«, 'Zabbix' bĂ«n verifikimin maksimal deri nĂ« 128 hoste njĂ«herĂ«sh. Kam provuar ta rris kĂ«tĂ« numĂ«r deri nĂ« 500 dhe kam hequr intervalin mes paketave nĂ« ping-un e tyre â kjo rriti performancĂ«n dyfish. Por do tĂ« doja numra mĂ« tĂ« mĂ«dha.
MĂ: â NĂ« praktikĂ«n time, ndonjĂ«herĂ« mĂ« duhet tĂ« kontrolloj disponueshmĂ«rinĂ« e mijĂ«ra hosteve, dhe asgjĂ« mĂ« shpjet se nmap nuk e kam hasur pĂ«r kĂ«tĂ«. Jam i sigurt se kjo Ă«shtĂ« mĂ«nyra mĂ« e shpejtĂ«. Le ta provojmĂ«! Duhet tĂ« rrisim ndjeshĂ«m numrin e hosteve pĂ«r njĂ« iteracion.
MM: â TĂ« kontrollojmĂ« mĂ« shumĂ« se pesĂ«qind? 600?
MĂ: â TĂ« paktĂ«n disa mijĂ«ra.
MM: â Ok. E rĂ«ndĂ«sishmja, qĂ« doja tĂ« thosha: zbulova se shumica e pollingut nĂ« 'Zabbix' bĂ«het nĂ« mĂ«nyrĂ« sinkrone. Ne patjetĂ«r duhet ta rikonfigurojmĂ« nĂ« mĂ«nyrĂ«n asinkrone. Pastaj do tĂ« jemi nĂ« gjendje tĂ« rrisim ndjeshĂ«m numrin e metrikave tĂ« mbledhura nga pollerĂ«t, sidomos nĂ«se rrisim numrin e metrikave pĂ«r njĂ« iteracion.
MĂ: â ShkĂ«lqyer! Dhe kur?
MM: â Si zakonisht, dje.
MĂ: â Ne krahasuam tĂ« dy versionet e fping dhe nmap:
Në një numër të madh hostesh, nmap ishte për të pritur deri në pesë herë më efikas. Duke qenë se nmap verifikon vetëm faktin e disponueshmërisë dhe kohën e përgjigjes, ne e kemi zhvendosur numërimin e humbjeve në triggera dhe kemi reduktuar ndjeshëm intervalet e verifikimit të disponueshmërisë. Numri optimal i hosteve për nmap e gjetëm rreth 4 mijë për një iteracion. Nmap na lejoi të ulni tri herë shpenzimet e CPU-së për verifikimet e disponueshmërisë dhe të shkurtosh intervalin nga 120 sekonda në 10.
Optimizimi i pollingut
MM: â MĂ« pas u merremi me pollerĂ«t. Kryesisht, na interesonte marrja e SNMP dhe agjentĂ«t. NĂ« 'Zabbix', polling-u Ă«shtĂ« bĂ«rĂ« nĂ« mĂ«nyrĂ« sinkrone dhe janĂ« marrĂ« masa tĂ« veçanta pĂ«r tĂ« rritur efikasitetin e sistemit. NĂ« modin sinkron, mosdisponueshmĂ«ria e hosteve shkakton njĂ« degradim tĂ« konsiderueshĂ«m tĂ« pollingut. Ekziston njĂ« sistem i tĂ«rĂ« gjendjesh, janĂ« procese speciale â tĂ« ashtuquajturit unreachable-pollers, qĂ« punojnĂ« vetĂ«m me hostet e papranueshĂ«m:
Kjo është një komment që tregon matricën e gjendjeve, gjithë kompleksitetin e sistemeve të kalimeve, të cilat janë të nevojshme për të mbajtur sistemin efikas. Për më tepër, vetë polling-u sinkron është mjaft i ngadalshëm:
Pikërisht për këtë arsye, mijëra rrjedha pollerësh në dhjetë proxy nuk mundën të mbledhin për ne numrin e duhur të të dhënave. Zbatimi asinkron zgjidhi jo vetëm problemet me numrin e rrjedhave, por gjithashtu e thjeshtoi ndjeshëm sistemin e gjendjeve të hosteve të papranueshëm, sepse për çdo numër që kontrollohet në një iteracion polling-u, koha maksimale e pritjes ishte 1 timeout:
Përveç kësaj, ne modifikuam dhe përmirësuam sistemin e pollingut për kërkesat SNMP. Problemi është se shumica e tyre nuk mund të përgjigjen në disa kërkesa SNMP në të njëjtën kohë. Prandaj, ne krijuam një mod të hibridizuar, kur polling-u SNMP për të njëjtin host bëhet asinkron:
Kjo bëhet për një grup të tërë hostesh. Ky mod, në përfundim, nuk është më i ngadalshëm se i plotë asinkroni, pasi pyetja e njëqind e pesëdhjetë vlerave SNMP është ende shumë më e shpejtë se një timeout.
Eksperimentet tona treguan se numri optimal i kërkesave në një iteracion është rreth 8 mijë gjatë polling-ut SNMP. Në total, kalimi në modin asinkron lehtësoi performancën e polling-ut 200 herë, disa qindra herë.
MĂ: Optimizimet e marra nga polling-u treguan se jo vetĂ«m qĂ« mund tĂ« heqim tĂ« gjitha proxy-t, por gjithashtu tĂ« zvogĂ«lojmĂ« intervalet pĂ«r shumĂ« verifikime, dhe proxy-t nuk do tĂ« nevojiten si njĂ« mĂ«nyrĂ« pĂ«r tĂ« ndarĂ« ngarkesĂ«n.
Rreth tre muaj më parë
Ndrysho arkitekturĂ«n â rrit ngarkesĂ«n!
MM: â ĂfarĂ«, Max, Ă«shtĂ« koha pĂ«r prodhim? MĂ« nevojitet njĂ« server i fuqishĂ«m dhe njĂ« inxhinier i mirĂ«.
MĂ: â MirĂ«, do ta planifikojmĂ«. Ka kohĂ« qĂ« Ă«shtĂ« koha tĂ« lĂ«vizim nga pika e vdekur tĂ« 5 mijĂ« metrikave nĂ« sekondĂ«.
Mengjesi pas përmirësimit
MĂ: â Misha, ne u pĂ«rmirĂ«suam, por deri nĂ« mengjes u rikthyem mbrapa⊠Gjeje se cila shpejtĂ«si arritĂ«m?
MM: â Maksimumi katĂ«r mijĂ«.
MĂ: â Po, 25! FatkeqĂ«sisht, jemi aty ku filluam.
MM: â Pse ndodhi kjo? NdĂ«rruam ndonjĂ« diagnostikĂ«?
MĂ: â Po, sigurisht! Ja, pĂ«r shembull, njĂ« top interesant:
MM: â Le tĂ« shohim. Po shoh se kemi provuar njĂ« numĂ«r tĂ« madh rrjedhash tĂ« polling-ut:
Por, në këtë rast, nuk arritëm të utilizojmë sistemin as gjysmë:
Dhe produktiviteti total është mjaft i vogël, rreth 4 mijë metrika në sekondë:
A ka diçka tjetër?
MĂ: â Po, strace njĂ« nga pollerĂ«t:
MM: â KĂ«tu Ă«shtĂ« qartĂ« se procesi i polling-ut pret 'semaforĂ«'. KĂ«to janĂ« bllokime:
MĂ: â Nuk Ă«shtĂ« e qartĂ«.
MM: â Shiko, duket si situata kur njĂ« numĂ«r i madh rrjedhash pĂ«rpiqen tĂ« punojnĂ« me njĂ« burim, me tĂ« cilin mund tĂ« punohet vetĂ«m nga njĂ«ri nĂ« tĂ« njĂ«jtĂ«n kohĂ«. AtĂ«herĂ«, gjithçka qĂ« mund tĂ« bĂ«jnĂ« â Ă«shtĂ« tĂ« ndajnĂ« atĂ« burim sipas kohĂ«s:
Dhe produktiviteti total i punës me një burim të tillë kufizohet nga shpejtësia e një bërthamë:
Këtë problem mund ta zgjidhim në dy mënyra.
Përmirëso harduerin e makinerisë, kaloni në bërthama më të shpejta:
Ose ndryshoni arkitekturën dhe ngarkesën në të njëjtën kohë:
MĂ: â PĂ«r mĂ« tepĂ«r, nĂ« makinerinĂ« testuese do tĂ« pĂ«rdorim mĂ« pak bĂ«rthama sesa nĂ« makinerinĂ« prodhuese, por ato janĂ« rreth 1.5 herĂ« mĂ« tĂ« shpejta nĂ« frekuencĂ« pĂ«r bĂ«rthamĂ«!
MM: â E qartĂ«? Duhet tĂ« shohim kodin e serverit.
Rruga e të dhënave në serverin Zabbix
MĂ: â PĂ«r tĂ« kuptuar, filluam tĂ« analizojmĂ« se si kalojnĂ« tĂ« dhĂ«nat brenda serverit 'Zabbix':
Kjo është një pamje interesante, apo jo? Le të kalojmë nëpër të hapa pas hapi për të sqaruar diçka. Ka rrjedha dhe shërbime, të cilat janë përgjegjëse për mbledhjen e të dhënave:
Metrikat e mbledhura i dërgojnë nëpër socket në menaxherin e përpunuesit, ku ruhen në radhë:
Menaxheri i përpunuesit i kalon të dhënat punëtorëve të tij, të cilët ekzekutojnë udhëzimet e përpunimit dhe i kthejnë ata prapë përmes të njëjtit socket:
Pas kësaj, menaxheri i preproçesorit i ruan ato në memorie historike:
Prej aty, i marrin sinkronizuesit e historisë që kryejnë shumë funksione: për shembull, llogaritjen e triggerëve, mbushjen e caches e vlerave dhe, më e rëndësishmja, ruajtjen e metricave në depo historike. Në përgjithësi, procesi është kompleks dhe mjaft i ngatërruar.
MM: â E para qĂ« pamĂ« â ishte se shumica e rrjedhave konkurrojnĂ« pĂ«r njĂ« "cache konfigurimi" (njĂ« zonĂ« memorie ku ruhen tĂ« gjitha konfigurimet e serverit). Sidomos shumĂ« bllokime shkaktojnĂ« rrjedhat qĂ« janĂ« pĂ«rgjegjĂ«se pĂ«r marrjen e tĂ« dhĂ«nave:
...sidomos sepse në konfigurim ruhen jo vetëm metricat me parametrat e tyre, por edhe radhët nga të cilat pollet marrin informacion për atë që duhet të bëjnë më pas. Kur ka shumë pole, dhe një bllokon konfigurimin, të tjerët presin kërkesat:
Pollet nuk duhet të konkurrojnë
Prandaj, e para qĂ« bĂ«mĂ« â e ndamĂ« radhĂ«n nĂ« 4 pjesĂ« dhe lejuam pollet nĂ« kushte tĂ« sigurta tĂ« bllokojnĂ« kĂ«to radhĂ«, kĂ«to pjesĂ« njĂ«kohĂ«sisht:
Kjo e hoqi konkurrencën për cache-in e konfigurimeve, dhe shpejtësia e punës së poleve u rrit ndjeshëm. Por më pas u përballëm me faktin se menaxheri i preproçesorit filloi të mbledhë radhën e detyrave:
Menaxheri i preproçesorit duhet të dijë të vendosë prioritete
Kjo ndodhte nĂ« raste kur i mungonte performanca. AtĂ«herĂ«, gjithçka qĂ« mund tĂ« bĂ«nte â tĂ« mbante kĂ«rkesat nga proceset e mbledhjes sĂ« tĂ« dhĂ«nave dhe t'i grumbullonte ato nĂ« njĂ« bufer deri sa tĂ« merrte tĂ« gjithĂ« memorien dhe tĂ« dĂ«shtonte:
Për të zgjidhur këtë problem, ne shtuam një socket të dytë, i cili ishte rezervuar veçanërisht për punëtorët:
Në këtë mënyrë, menaxheri i preproçesorit mori mundësinë të prioritizojë punën e tij dhe në rast të zgjerimit të buferit, detyra për të ngadalësuar marrjen, duke i dhënë mundësinë punëtorëve të marrin atë bufer:
Pastaj zbulomĂ« qĂ« njĂ« nga arsyet e ngadalĂ«simit ishin vetĂ« punĂ«torĂ«t, pasi ata konkuronin pĂ«r njĂ« burim qĂ« sâkishte rĂ«ndĂ«si pĂ«r punĂ«n e tyre. Ky problem ne e zgjidhĂ«m me njĂ« bug-fix, dhe nĂ« versionet e reja tĂ« "Zabbix-it" ai tashmĂ« Ă«shtĂ« zgjidhur:
ShtojmĂ« numrin e soketĂ«ve â marrim rezultat
Më pas, vetë menaxheri i preproçesorit u bë pika e ngadalësimit, për shkak se ky është një rrjedhë. Ai kishte probleme me shpejtësinë e bërthamës, duke dhënë një shpejtësi maksimale prej rreth 70,000 metricave në sekondë:
Prandaj, ne e zhvilluam katër me katër grupe socket-esh dhe punëtorësh:
Dhe kjo na lehtësoi rritjen e shpejtësisë rreth 130 mijë metrikave:
Nelinjeariteti i rritjes shpjegohet me faktin se ndodhi konkurrenca për cache-in e historisë. Për të konkuronin 4 menaxherë të parapërpunimit dhe sinkronizuesit e historisë. Deri në këtë moment, ne po marrim rreth 130 mijë metrika në sekundë në makinën testuese, duke e shfrytëzuar atë rreth 95% në CPU:
Rreth 2.5 muaj më parë
Braktisja e snmp-community e rriti NVP-të një herë e gjysmë
MM: â Max, mĂ« nevojitet njĂ« makinĂ« testuese e re! Nuk po i pĂ«rshtatemi mĂ« nĂ« kĂ«tĂ« tĂ« tanishme.
MĂ: â ĂfarĂ« kemi tani?
MM: â Tani ka 130 mijĂ« NVP dhe CPU "nĂ« raft".
MĂ: â Wow! Super! Po prisni, kam dy pyetje. Nga llogaritjet e mia, ne kemi nevojĂ« pĂ«r rreth 15-20 mijĂ« metrika nĂ« sekundĂ«. Pse na duhen mĂ« shumĂ«?
MM: â Dua ta pĂ«rfundoj kĂ«tĂ« punĂ«. Dua tĂ« shohim sa mund tĂ« nxjerrim nga ky sistem.
MĂ: â PorâŠ
MM: â Por pĂ«r biznesin Ă«shtĂ« e padobishme.
MĂ: â E kuptoj. Dhe pyetja e dytĂ«: a mund ta mbĂ«shtesim atĂ« qĂ« kemi tani vetĂ«, pa ndihmĂ«n e zhvilluesit?
MM: â Nuk e mendoj. Ndryshimi i funksionimit me cache-in e konfiguracionit Ă«shtĂ« njĂ« problem. Ka tĂ« bĂ«jĂ« me ndryshimet nĂ« shumicĂ«n e rrjedhave dhe Ă«shtĂ« mjaft komplekse pĂ«r mbĂ«shtetje. MĂ« mirĂ« s'do tĂ« jetĂ« e lehtĂ« pĂ«r ta mbajtur.
MĂ: â AtĂ«herĂ« na duhet njĂ« alternativĂ«.
MM: â Ka njĂ« opsion tĂ« tillĂ«. Ne mund tĂ« kalojmĂ« nĂ« bĂ«rthamĂ« tĂ« shpejtĂ«, duke braktisur sistemin e ri tĂ« bllokimit. Ne ende do tĂ« arrijmĂ« njĂ« performancĂ« prej 60-80 mijĂ« metrikash. NĂ« kĂ«tĂ« rast, ne do tĂ« mund tĂ« mbajmĂ« tĂ« gjithĂ« kodin tjetĂ«r. "Clickhouse", polling-asinkron do tĂ« funksionojnĂ«. Dhe kjo do tĂ« jetĂ« e lehtĂ« pĂ«r t'u mbajtur.
MĂ: â ShkĂ«lqyeshĂ«m! Propozoj tĂ« ndalojmĂ« kĂ«tu.
Pas optimizimit të pjesës serverike, ne përfundimisht arritëm të lançojmë kodin e ri në prodhim. Ne braktisëm disa ndryshime në favor të kalimit në një makinë me bërthama të shpejta dhe minimizimit të ndryshimeve në kod. Ne gjithashtu e thjeshtuam konfigurimin dhe, sa më shumë të ishte e mundur, heqëm dorë nga makros në elementet e të dhënave, pasi ato janë burim i bllokimeve shtesë.
Për shembull, braktisja e makros snmp-community, e cila është e zakonshme në dokumentacion dhe shembuj, në rastin tonë lejoj që të përshpejtojmë NVP-të rreth 1.5 herë më shumë.
Pas dy ditësh në prodhim
Heqim dritaret e historeve të incidenteve
MĂ: â Misha, ne po dy dy pĂ«rdorim sistemin, dhe gjithçka funksionon. Por vetĂ«m kur gjithçka funksionon! Kishim punĂ« tĂ« planifikuara me transferimin e njĂ« segmenti tĂ« madh tĂ« rrjetit, dhe sĂ«rish kontrolluam me duar se çfarĂ« u ngrit, çfarĂ« â jo.
MM: â Nuk mund tĂ« jetĂ«! Ne e kontrolluam gjithçka 10 herĂ«. Serveri pĂ«rpunon madje edhe papĂ«rgjegjshmĂ«rinĂ« e plotĂ« tĂ« rrjetit menjĂ«herĂ«.
MĂ: â E kuptoj gjithçka: server, baza, top, austat, logjet â gjithçka shpejt⊠Por ne po shohim ndĂ«rfaqen e uebit, dhe atje â procesori "nĂ« raft" nĂ« server dhe kjo:
MM: â E kuptoj. Le tĂ« shohim nĂ« web. Ne zbulonim se nĂ« situatĂ«n kur kishte njĂ« numĂ«r tĂ« madh tĂ« incidenteve aktive, shumica e widgeteve operuese filluan tĂ« funksiononin shumĂ« ngadalĂ«:
Arsyeja për këtë ishte gjenerimi i dritareve të hapura me historikun e incidenteve, të cilat gjenerohen për çdo element në listë. Prandaj ne u larguam nga gjenerimi i këtyre dritareve (komentuar 5 rreshta në kod), dhe kjo e zgjidhi problemin tonë.
Koha e ngarkesës së widgeteve, madje edhe në mungesë të plotë, u shkurtua nga disa minuta në 10-15 sekonda që janë të pranueshme për ne, dhe historia për më tepër mund të shikohet me një klikim në kohë:
Pas punës. 2 muaj më parë.
MĂ: â Misha, po ik? Kam njĂ« bisedĂ«.
MM: â Nuk isha duke planifikuar. PĂ«rsĂ«ri diçka me "Zabbix"?
MĂ: â Jo, qetĂ«sohu! Thjesht doja tĂ« thoja: gjithçka funksionon, faleminderit! UnĂ« do tĂ« paguaj birrĂ«.
Zabbix është efikas
«Zabbix» është një sistem dhe funksion mjaft universale dhe e pasur. Ai mund të përdoret lehtësisht për instalime të vogla "nga kutia", por me rritjen e nevojave, duhet optimizuar. Për ruajtjen e një arkivi të madh të metrikave, përdorni një depo të përshtatshme:
- mund të përdorni mjete të integruara në formën e integrimit me "Elastikserç" ose eksportimin e historisë në skedarë tekstualë (i disponueshëm që nga versioni i katërt);
- mund të shfrytëzoni përvojën tonë dhe integrimin me "ClickHouse".
Për të rritur ndjeshëm shpejtësinë e mbledhjes së metrikave, mbledhni ato me metoda asinkrone dhe transferoni nëpërmjet ndërfaqes të trukkër-interfaces në serverin "Zabbix"; ose mund të përdorni një patch për asinkroninë e pollevëve të vetë "Zabbix".
«Zabbix» është shkruar në C dhe është mjaft efikase. Disa vendosje të ngushta arkitekturore lejojnë që ta rrisim performancën e tij dhe, nga përvoja jonë, të marrim më shumë se 100 mijë metrika në një makinë me një procesor.
Atë patch Zabbix
MM: â Dua tĂ« shtoj disa pika. TĂ« gjitha tĂ« dhĂ«nat e tanishme, tĂ« gjitha testet, shifrat janĂ« dhĂ«nĂ« pĂ«r konfigurimin qĂ« po pĂ«rdorim. Nga ajo, aktualisht po marrim rreth 20 mijĂ« metrika nĂ« sekondĂ«. NĂ«se pĂ«rpiqeni tĂ« kuptoni nĂ«se kjo do tĂ« funksionojĂ« pĂ«r ju â mund tĂ« bĂ«ni njĂ« krahasim. Ajo qĂ« u tha sot Ă«shtĂ« e publikuar nĂ« GitHub nĂ« formĂ«n e njĂ« patch:
Patchi përfshin:
- integrim të plotë me «ClickHouse» (si për serverin «Zabbix» ashtu edhe për frontendin);
- zgjidhjen e problemeve me menaxherin e përpunuesve;
- polling asinkron.
Patchi është në përputhje me të gjitha versionet 4, përfshirë lts. Me shumë mundësi, me disa ndryshime minimale do të funksionojë në versionin 3.4.
Faleminderit për vëmendjen.
Pyetje
Pyetje nga audienca (nĂ« vijim â A): â MirĂ«dita! Ju lutem, a keni plane pĂ«r njĂ« bashkĂ«punim intensiv me ekipin Zabbix apo ata me ju, qĂ« tĂ« mos jetĂ« vetĂ«m njĂ« patch, por njĂ« sjellje normale e «Zabbix»?
MM: â Po, disa nga ndryshimet ne do t'i angazhojmĂ« nĂ« sistemin. Disa do tĂ« mbeten nĂ« patch.
P: â Faleminderit shumĂ« pĂ«r raportin e shkĂ«lqyer! Ju lutem, a do tĂ« ketĂ« mbĂ«shtetje nga «Zabbix» pas aplikimit tĂ« patch-it dhe si mund tĂ« pĂ«rditĂ«sohemi nĂ« versione mĂ« tĂ« larta? A do tĂ« jetĂ« e mundur tĂ« pĂ«rditĂ«sojmĂ« «Zabbix» pas patch-it tuaj nĂ« 4.2, 5.0?
MM: â PĂ«r mbĂ«shtetjen nuk mund tĂ« them. Sikur tĂ« isha mbĂ«shtetje teknike pĂ«r «Zabbix», ndoshta do tĂ« thosha jo, sepse Ă«shtĂ« kod i huaj. Sa i pĂ«rket bazĂ«s kode 4.2, pozita jonĂ« Ă«shtĂ« kjo: «Ne do tĂ« ecim me kohĂ«n dhe vetĂ« do tĂ« pĂ«rditĂ«sohemi nĂ« versionin tjetĂ«r». Prandaj pĂ«r njĂ« kohĂ« do tĂ« publikojmĂ« patchin pĂ«r versionet e pĂ«rditĂ«suara. Kam thĂ«nĂ« tashmĂ« nĂ« raport: numri i ndryshimeve mes versioneve Ă«shtĂ« ende mjaft i vogĂ«l. Mendoj se kalimi nga 3.4 nĂ« 4 na mori, duket, rreth 15 minuta. Disa gjĂ«ra u ndĂ«rruan, por jo shumĂ« tĂ« rĂ«ndĂ«sishme.
P: â Pra, ju planifikoni tĂ« mbani patch-in tuaj dhe mund ta vendosni atĂ« nĂ« prodhim, duke marrĂ« mĂ« vonĂ« pĂ«rditĂ«sime nĂ« njĂ« formĂ« tĂ« caktuar?
MM: â Ne e rekomandojmĂ« kategorikisht. Kjo zgjidh shumĂ« probleme pĂ«r ne.
MĂ: â Desejoi tĂ« theksoj se ndryshimet qĂ« nuk prekin arkitekturĂ«n dhe qĂ« nuk lidhen me bllokimet, radhĂ«t â ato janĂ« modulare, ndodhin nĂ« module tĂ« veçanta. Edhe nĂ« mĂ«nyrĂ« tĂ« pavarur, pĂ«r ndryshime tĂ« vogla, ato mund tĂ« mbahen mjaft lehtĂ«.
MM: â NĂ«se jeni tĂ« interesuar pĂ«r detaje, "Clickhouse" pĂ«rdor njĂ« bibliotekĂ« tĂ« njohur si historia. Ajo Ă«shtĂ« e shkĂ«putur â Ă«shtĂ« njĂ« kopje qĂ« mbĂ«shtet "Elastic" dhe Ă«shtĂ« e ndryshueshme konfiguruese. Polling ndryshon vetĂ«m pollerĂ«t. Ne mendojmĂ« se kjo do tĂ« funksionojĂ« pĂ«r njĂ« kohĂ« tĂ« gjatĂ«.
P: â Faleminderit shumĂ«. MĂ« tregoni, a ka ndonjĂ« dokumentacion pĂ«r ndryshimet e bĂ«ra?
MM: â Dokumentacioni Ă«shtĂ« patch. ĂshtĂ« e qartĂ« se me introduktimin e "Clickhouse", me introduktimin e llojeve tĂ« reja tĂ« pollerĂ«ve, lindin opsione tĂ« reja konfiguruese. NĂ« lidhjen e diapozitivit tĂ« fundit ka njĂ« pĂ«rshkrim tĂ« shkurtĂ«r se si ta pĂ«rdorni kĂ«tĂ«.
Për zëvendësimin e fping me nmap
P: â Si e realizuat kĂ«tĂ« nĂ« fund? Mund tĂ« ndani shembuj konkretĂ«: a pĂ«rdorni strapper dhe skenarin e jashtĂ«m? ĂfarĂ« kontrollon aq shpejt njĂ« numĂ«r kaq tĂ« madh hostesh? Si i nxirrni kĂ«ta hoste? Duhet t'i futni ndonjĂ«herĂ« nmap-it, ta merrni nga diku, ta vendosni, ta aktivizoni?
MM: â ShumĂ« mirĂ«. NjĂ« pyetje shumĂ« e drejtĂ«! Kjo Ă«shtĂ« çështja. Ne modifikuam bibliotekĂ«n (ICMP ping, komponent i "Zabbix") pĂ«r kontrolle ICMP, ku Ă«shtĂ« e caktuar numri i pakove â njĂ« (1), dhe kodi pĂ«rpiqet tĂ« pĂ«rdorĂ« nmap. Pra, kjo Ă«shtĂ« puna e brendshme e "Zabbix", qĂ« Ă«shtĂ« bĂ«rĂ« pjesĂ« e punĂ«s sĂ« pingers. NĂ« pĂ«rputhje me kĂ«tĂ«, nuk ka nevojĂ« pĂ«r asnjĂ« sinkronizim ose pĂ«rdorim tĂ« trapper-it. Kjo u bĂ« me qĂ«llim pĂ«r tĂ« ruajtur sistemin tĂ« pandarĂ« dhe pĂ«r tĂ« mos u angazhuar me sinkronizimin e dy sistemeve tĂ« bazĂ«s: çfarĂ« duhet tĂ« kontrollohet, tĂ« ngarkohet pĂ«rmes poller-it, a nuk Ă«shtĂ« prishur ngarkesa jonĂ«?... Kjo Ă«shtĂ« shumĂ« mĂ« e lehtĂ«.
P: â A funksionon edhe pĂ«r proxy?
MM: â Po, por ne nuk e kemi testuar. Kodi i polling-ut Ă«shtĂ« i njĂ«jtĂ« nĂ« "Zabbix" dhe nĂ« server. Duhet tĂ« funksionojĂ«. Edhe njĂ« herĂ« po e theksoj: performanca e sistemit Ă«shtĂ« e tillĂ« sa qĂ« nuk na duhen proxy.
MĂ: â Pergjigja e saktĂ« pĂ«r pyetjen Ă«shtĂ«: "PĂ«rse ju nevojitet proxy me njĂ« sistem tĂ« tillĂ«?" VetĂ«m pĂ«r shkak tĂ« NAT-it ose pĂ«r tĂ« monitoruar pĂ«rmes ndonjĂ« kanali tĂ« ngadalshĂ«m...
P: â A e pĂ«rdorni "Zabbix" si alarmin, nĂ«se e kuptova saktĂ«. Ose tĂ« dhĂ«nat pĂ«rshtatĂ«se (ku ka njĂ« shtresĂ« arkivimi) tani janĂ« nĂ« njĂ« sistem tjetĂ«r, si Grafana? Ose nuk e pĂ«rdorni kĂ«tĂ« funksionalitet?
MM: â The integration has been fully completed. We are dumping history into 'ClickHouse', but we have also modified the php frontend. The php frontend communicates with 'ClickHouse' to generate all the graphs from there. Honestly, we have a part that builds data from the same 'ClickHouse' and the same data from 'Zabbix' for graphical representation in other systems.
MĂ: â Including in 'Grafana'.
How was the decision made regarding resource allocation?
P: â Share a bit of the internal process. How was the decision made to allocate resources for a serious product overhaul? This involves certain risks. And please tell us, in the context of your plans to support new versions: how is this decision justified from a management perspective?
MM: â Apparently, we did not tell the history dramatically enough. We found ourselves in a situation where something had to be done, and we essentially moved forward with two parallel teams:
- One focused on launching a monitoring system using new methods: monitoring as a service, a standard set of open-source solutions that we combine and then try to modify our business process to work with the new monitoring system.
- At the same time, we had an enthusiastic programmer who was working on this (about himself). It just happened that he prevailed.
P: â And what is the size of the team?
MĂ: â It stands before you.
P: â So, as always, a passionate person is needed?
MM: â I donât know what a passionate person is.
P: â In this case, apparently, you are. Thank you very much, you are amazing.
MM: â Thank you.
About patches for Zabbix
P: â For a system that uses proxies (for instance, in some distributed systems), is it possible to adapt and patch your solution for, say, pollers, proxies, and partially for the preprocessor of 'Zabbix'; and their interaction? Is it possible to optimize the existing developments for a system with multiple proxies?
MM: â I know that the 'Zabbix' server is built using proxies (it is compiled and generates code). We have not tested this in production. I am not sure about it, but it seems to me that the preprocessor manager is not used in the proxies. The task of the proxy is to collect a set of metrics from 'Zabbix', fetch them (it also records the configuration, local database) and return them back to the 'Zabbix' server. The server will then perform the preprocessing when it receives them.
Interesi për proxy është i kuptueshëm. Ne do ta verifikojmë këtë. Kjo është një temë interesante.
P: â Ideja ishte kjo: nĂ«se mund tĂ« patch-ojmĂ« pollerĂ«t, mund t'i patch-ojmĂ« ata pĂ«r proxy dhe tĂ« adaptojmĂ« para-procesorin pĂ«r kĂ«to qĂ«llime vetĂ«m nĂ« server.
MM: â Mendoj se gjithçka Ă«shtĂ« akoma mĂ« e thjeshtĂ«. Merrni kodin, aplikoni patch-in, pastaj konfigurojeni siç dĂ«shironi â krijoni servere proxy (p.sh., me ODBC) dhe shpĂ«rndani kodin e patch-uar nĂ« sisteme. Atje ku Ă«shtĂ« e nevojshme â krijoni proxy, atje ku Ă«shtĂ« e nevojshme â server.
P: â ShtesĂ« pĂ«r tĂ« patch-uar dĂ«rgimin e proxy nĂ« server, do tĂ« jetĂ« e nevojshme, apo jo?
MĂ: â Jo, ajo Ă«shtĂ« standarde.
MM: â NĂ« tĂ« vĂ«rtetĂ« nuk u pĂ«rmend njĂ«ra nga idetĂ«. Ne gjithmonĂ« kemi mbajtur njĂ« balancĂ« midis shpĂ«rthimit tĂ« ideve dhe numrit tĂ« ndryshimeve, lehtĂ«sisĂ« sĂ« mbĂ«shtetjes.
Pak reklamĂ« đ
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendĂ«r tĂ« tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m te ne nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
