Pra, po mbledhni metrika. Ashtu si ne. Ne gjithashtu mbledhim metrika. Sigurisht, ato tĂ« nevojshme pĂ«r biznesin. Sot do tĂ« flasim pĂ«r lidhjen e parĂ« tĂ« sistemit tonĂ« tĂ« monitorimit â serverin e agregatĂ«s qĂ« Ă«shtĂ« nĂ« pĂ«rputhje me statsd , pĂ«rse e shkruam atĂ« dhe pse hoqĂ«m dorĂ« nga brubeck.
Nga artikujt tanĂ« tĂ« mĂ«parshĂ«m (, ) mund tĂ« mĂ«soni se deri nĂ« njĂ« moment tĂ« caktuar ne mbledhim etiketat duke pĂ«rdorur . Ai Ă«shtĂ« shkruar nĂ« C. Nga pikĂ«pamja e kodit â i thjeshtĂ« si njĂ« kork (kjo Ă«shtĂ« e rĂ«ndĂ«sishme, kur dĂ«shironi tĂ« kontribuoni) dhe, mĂ« e rĂ«ndĂ«sishmja, pĂ«rballon pa ndonjĂ« problem volume tona prej 2 milion metrike nĂ« sekondĂ« (MPS) nĂ« kulm. Dokumentacioni deklaron mbĂ«shtetje pĂ«r 4 milion MPS me njĂ« yll. Kjo do tĂ« thotĂ« se numri i deklaruar do tĂ« merrni, nĂ«se e konfiguroni drejt rrjetin nĂ« Linux. (Sa MPS mund tĂ« merrni, nĂ«se e lini rrjetin siç Ă«shtĂ«, nuk e dimĂ«). PavarĂ«sisht kĂ«tyre avantazheve, ne kishim disa ankesat serioze lidhur me brubeck.
Ankesa 1. Github â zhvilluesi i projektit â e ndali mbĂ«shtetje atĂ«: tĂ« publikojmĂ« patch-e dhe rregullime, tĂ« pranojmĂ« PR-tĂ« tona dhe (jo vetĂ«m tonat). NĂ« muajt e fundit (diku qĂ« nga shkurt-marsi 2018) aktiviteti rinisi, por para kĂ«saj kishte pothuajse 2 vjet qetĂ«si tĂ« plotĂ«. PĂ«r mĂ« tepĂ«r, projekti po zhvillohet , qĂ« mund tĂ« bĂ«het njĂ« pengesĂ« e madhe pĂ«r implementimin e mundĂ«sive tĂ« reja.
Ankesa 2. Saktësia e llogaritjeve. Brubeck mbledh vetëm 65536 vlera për agregim. Në rastin tonë, për disa metrika gjatë periudhës së agregimit (30 sekonda) mund të vijnë shumë më shumë vlera (1 527 392 në kulm). Si rezultat i këtij kampioni, vlerat e maksimumeve dhe minimaleve duken të padobishme. Për shembull, ja kështu:
Si ishte
Si duhej të ishte
Për të njëjtën arsye, shumat llogariten krejtësisht të papërshtatshme. Shtoni këtu një bug me mbushjen e float-it 32-bit, i cili dërgon serverin në segfault kur merr një metrikë që duket e pafajshme, dhe bëhet krejtësisht e shkëlqyer. Ky bug, për më tepër, nuk është rregulluar ende.
Dhe, në fund, Ankesa X. Në momentin e shkruarjes së këtij artikulli, jemi të gatshëm të paraqesim të gjitha 14 implementimet më shumë ose më pak funksionale të statsd që arritëm të gjejmë. Le të imagjinojmë se ndonjë infrastrukturë e veçantë është rritur aq shumë sa që pranimet prej 4 milion MPS nuk janë më të mjaftueshme. Ose ndoshta nuk është rritur ende, por metrikat për ju janë aq të rëndësishme sa që edhe ndërprerje të shkurtra, 2-3 minuta në grafikë, mund të bëhen kritike dhe të shkaktojnë episode të pashmangshme depresioni te menaxherët. Duke qenë se trajtimi i depresionit është një punë e falenderueshme, janë të nevojshme zgjidhje teknike.
Së pari, qëndrueshmëria për të shmangur një problem të papritur në server që të mos shkaktojë një apokalips zombi në zyrë. Së dyti, shkallëzimi për të marrë mundësinë të pranojmë më shumë se 4 milion MPS, pa nxjerrë me thellësi në stakun e rrjetit Linux dhe duke u zgjeruar qetësisht deri në përmasat e nevojshme.
Duke qenë se kishte hapësirë për shkallëzim, vendosëm të fillonim me qëndrueshmërinë. "Oh! Qëndrueshmëria! Kjo është e thjeshtë, ne e dimë të bëjmë", menduam dhe aktivizuam 2 servera, duke ngritur në çdo server një kopje të brubeck. Për këtë na duhej të kopjonim trafikun me metrikat në të dy serverat dhe madje të shkruanim për këtë . Problemin e qëndrueshmërisë e zgjidhëm kështu, por... jo shumë mirë. Në fillim, gjithçka dukej mjaft në rregull: çdo brubeck mbledh versionin e tij të agregimit, shkruan të dhënat në Graphite çdo 30 sekonda, duke riparuar intervalin e vjetër (kjo bëhet në anën e Graphite). Nëse ndonjëherë një server dështon, ne gjithmonë kemi një të dytë me një kopje të vetë të dhënave të agreguara. Por ja problemi: nëse serveri dështon, në grafikë shfaqet "shkalla serratuar". Kjo ndodh sepse intervalet 30 sekondëshe të brubeck nuk janë të sinkronizuara, dhe në momentin e rënies një nga ato nuk riparon. Në momentin e aktivizimit të serverit të dytë ndodh e njëjta gjë. Mjaft e përballueshme, por dëshirojmë më mirë! Problemi i shkallëzueshmërisë gjithashtu nuk është zhdukur. Të gjitha metrikat vazhdojnë të "fluturojnë" në një server të vetëm, dhe prandaj jemi të kufizuar në të njëjtat 2-4 milion MPS varësisht nga përmirësimi i rrjetit.
Nëse mendojmë pak për problemin dhe njëkohësisht gërmojmë në borë me një bajonete, na vjen në mendje një ide kaq e qartë: na nevojitet një statsd që punon në një mod të shpërndarë. Kështu, një që implementon sinkronizimin midis nyjeve sipas kohës dhe metrikeve. "Sigurisht, një zgjidhje e tillë padyshim që ekziston", thamë ne dhe shkuam të kërkojmë në Google... dhe nuk gjetëm asgjë. Pas një shqyrtimi të dokumentacionit për statsd të ndryshme ( në datën 11.12.2017), nuk gjetëm asgjë. Duket se as zhvilluesit as përdoruesit e këtyre zgjidhjeve deri tani nuk janë përballur me një KAQ shumë metrikash, ndryshe ata do të kishin përcaktuar diçka.
Dhe këtu na erdhën në mendje statsd 'loja' - bioyino, që e kishim shkruar në hackathon thjesht për argëtim (emri i projektit ishte gjeneruar nga një skript para se të fillonte hackathon) dhe kuptuam se na nevojitet urgjentisht një statsd i vet. Pse?
- sepse në botë ka shumë pak klone statsd,
- sepse mund të sigurojmë qëndrueshmëri dhe shkallëzim të dëshirueshëm ose të afërt me të dëshiruarin (përfshirë sinkronizimin e metrikave të agreguara midis serverëve dhe zgjidhjen e problemeve të konflikteve gjatë dërgimit),
- sepse mund të llogarisim metrikat më saktë se çfarë bën brubeck,
- sepse mund të mbledhim vetë statistika më të detajuara, të cilat brubeck nuk na i ofronte pothuajse fare,
- sepse na u dha mundësia të programojmë aplikacionin tonë të shpërndarë me performancë të lartë, i cili nuk do të ishte një kopje e plotë e arkitekturës së një aplikacioni tjetër të tillë hyperfor... nuviponeli.
Në çfarë të shkruajmë? Sigurisht, në Rust. Pse?
- sepse tashmë kishte një prototip zgjidhjeje,
- sepse autori i këtij artikulli atëherë e dinte Rust dhe donte të shkruante diçka për prodhim me mundësinë e publikimit në open-source,
- sepse gjuhët me GC nuk na përshtaten për shkak të natyrës së trafikut që merrnim (praktikisht realtime) dhe pauzat e GC janë pothuajse të papranueshme,
- sepse na nevojitet performancë maksimale, krahasueshme me C
- sepse Rust na ofron një konkurencë pa frikë, dhe nëse do të fillonim ta shkruanim këtë në C/C++, do të kishim më shumë, shumë më tepër, siç ishim me brubeck, dobësi, mbushje të bufferëve, race conditions dhe fjalë të tjera të frikshme.
I had an argument against Rust. The company lacked experience in creating projects with Rust, and we currently do not plan to use it in our main project. Therefore, there were serious concerns that it might not work out, but we decided to take the risk and give it a try.
Time went onâŠ
Finally, after several unsuccessful attempts, the first working version was ready. What did we get? We got something like this.
Each node receives its own set of metrics and accumulates them without aggregating metrics for those types where their complete set is required for final aggregation. The nodes are interconnected by a distributed lock protocol, which allows selecting among them the one and only (here we cried) that is worthy of sending metrics to The Great. Currently, this issue is being addressed using , but in the future, the author's ambitions extend to Raft, where that very worthy one will undoubtedly be the consensus leader node. Besides consensus, nodes very often (by default once a second) send their neighbors the parts of the pre-aggregated metrics that managed to be gathered during that second. Thus, scalability and fault tolerance are maintained â each of the nodes still holds the complete set of metrics, but the metrics are now sent aggregated, over TCP and encoded in a binary protocol, significantly reducing the duplication costs compared to UDP. Despite a fairly large number of incoming metrics, accumulation requires very little memory and even less CPU. For our well-compressible metrics, this amounts to just a few tens of megabytes of data. An additional bonus is the absence of unnecessary data rewrites in Graphite, unlike what occurred with burbeck.
UDP paketet me metrike janĂ« disbalancuar midis nyjeve nĂ« pajisjet rrjetit pĂ«rmes njĂ« Round Robin tĂ« thjeshtĂ«. Natyrisht, aparatet rrjetore nuk analizojnĂ« pĂ«rmbajtjen e paketave dhe prandaj mund tĂ« pĂ«rballojnĂ« shumĂ« mĂ« tepĂ«r se 4M paketa nĂ« sekondĂ«, pĂ«r tĂ« mos pĂ«rmendur metrikat, pĂ«r tĂ« cilat ato nuk dinĂ« asgjĂ«. Duke marrĂ« parasysh se metrikat vijnĂ« jo vetĂ«m njĂ« nĂ« çdo paketĂ«, nuk parashikojmĂ« probleme me performancĂ«n kĂ«tu. NĂ« rast tĂ« rĂ«nies sĂ« serverit, pajisja rrjetore e zbulon atĂ« shpejt (brenda 1-2 sekondash) dhe e heq serverin qĂ« ka rĂ«nĂ« nga rotacioni. Si rezultat, nyjet pasive (t.e. ato qĂ« nuk janĂ« lider) mund tĂ« aktivizohen dhe deaktivizohen pothuajse pa vĂ«nĂ« re rĂ«niet nĂ« grafikĂ«. Maksimumi qĂ« humbasim â Ă«shtĂ« njĂ« pjesĂ« e metrikave qĂ« kanĂ« ardhur pĂ«r sekondĂ«n e fundit. Humbja e papritur / çaktivizimi / kalimi i liderit do tĂ« tĂ«rheqĂ« gjithnjĂ« njĂ« anomalie tĂ« vogĂ«l (intervali 30-sekondĂ«sh Ă«shtĂ« ende i asinkronizuar), por nĂ«se ka lidhje mes nyjeve, kĂ«to probleme mund tĂ« minimizohen, pĂ«r shembull, duke dĂ«rguar paketat e sinkronizimit.
Pak rreth strukturĂ«s sĂ« brendshme. Aplikacioni, natyrisht, Ă«shtĂ« me shumĂ«çșżçš, por arkitektura e threadave ndryshon nga ajo qĂ« pĂ«rdoret nĂ« brubeck. Threadat nĂ« brubeck janĂ« tĂ« njĂ«jtĂ« â çdo njĂ« prej tyre pĂ«rgjigjet njĂ«kohĂ«sisht pĂ«r mbledhjen e informacionit dhe pĂ«r agregimin. NĂ« bioyino, threadat e punĂ«s (workers) janĂ« tĂ« ndarĂ« nĂ« dy grupe: pĂ«rgjegjĂ«s pĂ«r rrjetin dhe pĂ«rgjegjĂ«s pĂ«r agregimin. Kjo ndarje e lejon menaxhimin mĂ« fleksibĂ«l tĂ« aplikacionit nĂ« varĂ«si tĂ« llojit tĂ« metrikave: aty ku kĂ«rkohet njĂ« agregim intensiv, mund tĂ« shtojmĂ« agregatorĂ«, aty ku ka shumĂ« trafik rrjeti â mund tĂ« rrisim numrin e threadave rrjetorĂ«. Momentalisht, nĂ« serverĂ«t tanĂ« po punojmĂ« me 8 threadat rrjetorĂ« dhe 4 threadat agregues.
Pjesa llogaritëse (përgjegjëse për agregimin) është mjaft e mërzitshme. Bufrat e mbushur me threadat rrjetorë shpërndahen ndërmjet threadave llogaritës, ku më pas përpunohen dhe agregohen. Në kërkesë, metrikat dërgohen për t'u dërguar në nyje të tjera. E gjithë kjo, duke përfshirë dërgimin e të dhënave midis nyjeve dhe punën me Consul, kryhet asinkronisht, duke punuar mbi frameworkun .
Ădo problem mĂ« tĂ« madh gjatĂ« zhvillimit e shkaktoi pjesa rrjetore, e cila ishte pĂ«rgjegjĂ«se pĂ«r pranimin e metrikave. QĂ«llimi kryesor i ndarjes sĂ« rrjedhave rrjetore nĂ« entitete tĂ« veçanta ishte tĂ« zvogĂ«lohej koha qĂ« rrjedha shpenzon jo nĂ« leximin e tĂ« dhĂ«nave nga socket. Opsionet qĂ« pĂ«rdorin UDP asinkron dhe recvmsg tĂ« zakonshĂ«m u hodhĂ«n shpejt: e para konsumon shumĂ« CPU nĂ« hapĂ«sirĂ«n e pĂ«rdoruesit pĂ«r pĂ«rpunimin e ngjarjeve, e dyta â shumĂ« ndĂ«rrime konteksti. Prandaj tani pĂ«rdoret me bufe tĂ« mĂ«dha (dhe buferat, zotĂ«rinj oficerĂ«, nuk janĂ« çështje e zakontĂ«!). MbĂ«shtetje pĂ«r UDP tĂ« zakonshĂ«m Ă«shtĂ« lĂ«nĂ« pĂ«r raste tĂ« papĂ«rgjegjshme, kur nuk ka nevojĂ« pĂ«r recvmmsg. NĂ« modin multimessage arrijmĂ« tĂ« arrihet e madhja: shumica dĂ«rrmuese e kohĂ«s rrjedha rrjetore pastron radhĂ«n e OS â lexon tĂ« dhĂ«nat nga socket dhe i zhvendos ato nĂ« buferin e hapĂ«sirĂ«s sĂ« pĂ«rdoruesit, vetĂ«m ndonjĂ«herĂ« duke kaluar pĂ«r tĂ« dhĂ«nĂ« buferin e mbushur agregatorĂ«ve. RadhĂ«t nĂ« socket praktikisht nuk grumbullohen, numri i paketimeve tĂ« hedhura praktikisht nuk rritet.
Shënim
Në cilësimet e paracaktuara, madhësia e buferit është caktuar mjaft e madhe. Nëse papritur vendosni të provoni serverin vetë, ndoshta do të përballeni me faktin që pas dërgimit të një sasie të vogël metrike, ato nuk do të arrijnë në Graphite, duke mbetur në buferin e rrjedhës rrjetore. Për të punuar me një numër të vogël metrike, duhet të caktohet në konfigurim vlera më të vogla për bufsize dhe task-queue-size.
NĂ« fund â disa grafika pĂ«r ata qĂ« i pĂ«lqejnĂ« grafikat.
Statistika e numrit të metrikave në hyrje për secilin server: më shumë se 2 milion MPS.
Ăaktivizimi i njĂ«rit nga nodet dhe riparimi i metrikave nĂ« hyrje.
Statistika pĂ«r metrikat nĂ« dalje: gjithmonĂ« dĂ«rgohet vetĂ«m njĂ« nod â raidboss.
Statistika e punës së secilit nod duke marrë parasysh gabimet në modulet e ndryshme të sistemit.
Detajet e metrikave në hyrje (emrat e metrikave janë të fshehur).
ĂfarĂ« planifikojmĂ« tĂ« bĂ«jmĂ« mĂ« tej me tĂ« gjitha kĂ«to? Sigurisht qĂ« do tĂ« shkruajmĂ« kod, blâŠ! Projekti fillimisht ishte planifikuar si open-source dhe do tĂ« mbetet i tillĂ« gjatĂ« gjithĂ« jetĂ«s sĂ« tij. NĂ« planet e afĂ«rta â kalimi nĂ« versionin tonĂ« tĂ« Raft, ndĂ«rrimi i protokollit peer nĂ« njĂ« mĂ« tĂ« portueshĂ«m, futja e statistikave tĂ« brendshme tĂ« mĂ«tejshme, tipe tĂ« reja metrikash, rregullimi i gabimeve dhe pĂ«rmirĂ«sime tĂ« tjera.
Sigurisht, të gjithë ata që duan të ndihmojnë në zhvillimin e projektit janë të mirëpritur: krijoni PR, Issues, dhe ne do të mundohemi të përgjigjemi dhe të punojmë më shumë kur të jetë e mundur.
Me këtë, siç thonë, kjo është gjithçka, blini elefantët tanë!
Burimi: habr.com
