Pra, ju mbledhni metrika. Dhe ne gjithashtu. Ne mbledhim edhe metrika. Sigurisht, ato që janë të rëndësishme për biznesin. Sot do t'ju tregojmë për lidhjen e parë në sistemin tonë të monitorimit - serverin e grumbullimit të pajtueshëm me statsd. , pse e shkruam dhe pse e braktisëm Brubeck-un.
Nga artikujt tanĂ« tĂ« mĂ«parshĂ«m (, ) mund tĂ« zbuloni se deri pak kohĂ« mĂ« parĂ« ne mblidhnim etiketa duke pĂ«rdorur ĂshtĂ« shkruar nĂ« C. ĂshtĂ« aq i thjeshtĂ« sa njĂ« maus (gjĂ« qĂ« Ă«shtĂ« e rĂ«ndĂ«sishme kur doni tĂ« kontribuoni) dhe, mĂ« e rĂ«ndĂ«sishmja, trajton vĂ«llimin tonĂ« maksimal prej 2 milionĂ« metrikash pĂ«r sekondĂ« (MPS) pa asnjĂ« problem. Dokumentacioni pretendon mbĂ«shtetje pĂ«r 4 milionĂ« MPS me njĂ« yll. Kjo do tĂ« thotĂ« qĂ« do tĂ« merrni shifrĂ«n e deklaruar nĂ«se e konfiguroni rrjetin saktĂ«. Linux(Nuk e dimĂ« se sa MPS mund tĂ« merrni nĂ«se e lini rrjetin siç Ă«shtĂ«.) PavarĂ«sisht kĂ«tyre avantazheve, patĂ«m disa ankesa serioze nĂ« lidhje me brubeck-un.
Kërkesa 1. Github, zhvilluesi i projektit, ndaloi së mbështeturi atë: duke publikuar patch-e dhe rregullime, duke pranuar kërkesat tona të klientit (dhe të të tjerëve). Aktiviteti ka rifilluar në muajt e fundit (diku rreth shkurtit-marsit 2018), por para kësaj pati pothuajse dy vjet heshtje të plotë. Për më tepër, projekti është në zhvillim e sipër. , gjë që mund të bëhet një pengesë serioze për zbatimin e veçorive të reja.
Kërkesa 2. Saktësia e llogaritjes. Brubeck mbledh vetëm 65536 vlera për agregim. Në rastin tonë, për disa metrika, periudha e agregimit (30 sekonda) mund të marrë vlera dukshëm më të larta (1,527,392 në kulmin). Si rezultat i kësaj mostrimi, vlerat maksimale dhe minimale duken të padobishme. Për shembull, si kjo:
Siç ishte
Si duhej të kishte qenë
Për të njëjtën arsye, shumat llogariten gabimisht. Shtojini kësaj një gabim me mbingarkesat e numrave të float-it 32-bit, i cili e dërgon serverin në një gabim segfault kur merr një metrikë në dukje të pafajshme, dhe gjithçka bëhet perfekte. Rastësisht, ky gabim nuk është rregulluar kurrë.
Dhe, së fundi, Kërkesa XNë kohën e shkrimit, jemi gati ta testojmë atë kundrejt të gjitha 14 implementimeve pak a shumë funksionale të statsd që kemi gjetur. Le të imagjinojmë se një infrastrukturë e caktuar është rritur aq shumë saqë gëlltitja e 4 milionë MPS nuk është më e mjaftueshme. Ose, edhe nëse nuk është rritur ende, metrikat janë aq të rëndësishme për ju saqë edhe uljet e shkurtra, 2-3-minutëshe në grafikë mund të bëhen kritike dhe të shkaktojnë periudha depresioni të pakapërcyeshëm tek menaxherët. Meqenëse trajtimi i depresionit është një detyrë e pafalshme, nevojiten zgjidhje teknike.
Së pari, toleranca ndaj defekteve, në mënyrë që një problem i papritur i serverit të mos shkaktojë një apokalips psikiatrik zombi në zyrë. Së dyti, shkallëzueshmëria, në mënyrë që të mund të përballojë mbi 4 milionë MPS pa pasur nevojë të gërmojë thellë në rrjet. Linux dhe rriten me qetësi "në gjerësi" në madhësinë e kërkuar.
MeqenĂ«se kishim pak hapĂ«sirĂ« ââpĂ«r shkallĂ«zueshmĂ«ri, vendosĂ«m tĂ« fillonim me tolerancĂ«n ndaj gabimeve. "Oh! TolerancĂ« ndaj gabimeve! ĂshtĂ« e thjeshtĂ«, mund ta bĂ«jmĂ«", menduam, dhe lançuam dy servera, duke ekzekutuar njĂ« kopje tĂ« brubeck nĂ« secilin. PĂ«r ta bĂ«rĂ« kĂ«tĂ«, na u desh tĂ« kopjonim trafikun me metrika nĂ« tĂ« dy serverat dhe madje tĂ« shkruanim njĂ« fragment kodi pĂ«r tĂ«. Ne e zgjidhĂ«m problemin e tolerancĂ«s sĂ« defekteve nĂ« kĂ«tĂ« mĂ«nyrĂ«, por... jo shumĂ« mirĂ«. NĂ« fillim, gjithçka dukej nĂ« rregull: çdo brubeck mbledh versionin e vet tĂ« agregimit, shkruan tĂ« dhĂ«na nĂ« Graphite çdo 30 sekonda, duke mbishkruar intervalin e vjetĂ«r (kjo bĂ«het nĂ« anĂ«n e Graphite). NĂ«se njĂ« server dĂ«shton, ne gjithmonĂ« kemi njĂ« tĂ« dytĂ« me kopjen e vet tĂ« tĂ« dhĂ«nave tĂ« agreguara. Por ja ku qĂ«ndron problemi: nĂ«se njĂ« server dĂ«shton, nĂ« grafikĂ« shfaqet njĂ« model "sharrim-me-sharrim". Kjo pĂ«r shkak tĂ« faktit se intervalet 30-sekondĂ«she tĂ« brubeck nuk janĂ« tĂ« sinkronizuara, dhe kur njĂ«ri prej tyre dĂ«shton, ai nuk mbishkruan. E njĂ«jta gjĂ« ndodh kur serveri i dytĂ« fillon. ĂshtĂ« e tolerueshme, por ne duam mĂ« mirĂ«! Problemi i shkallĂ«zueshmĂ«risĂ« gjithashtu mbetet. TĂ« gjitha metrikat ende shkojnĂ« nĂ« njĂ« server tĂ« vetĂ«m, dhe pĂ«r kĂ«tĂ« arsye ne jemi tĂ« kufizuar nĂ« tĂ« njĂ«jtat 2-4 milionĂ« MPS, varĂ«sisht nga performanca e rrjetit.
Nëse mendoni pak për problemin ndërsa pastroni borën, një ide e qartë mund t'ju lindë në mendje: ju nevojitet një statsd që mund të funksionojë në modalitetin e shpërndarë. Domethënë, një që zbaton sinkronizimin midis nyjeve sipas kohës dhe metrikave. "Me siguri një zgjidhje e tillë ndoshta ekziston tashmë," thamë ne, dhe shkuam të kërkonim në Google... Dhe nuk gjetëm asgjë. Pasi kërkuam në dokumentacion për statistika të ndryshme ( Që nga 11 dhjetori 2017, nuk gjetëm absolutisht asgjë. Me sa duket, as zhvilluesit dhe as përdoruesit e këtyre zgjidhjeve nuk kanë hasur ndonjëherë KAQ shumë metrika, përndryshe do të kishin gjetur diçka.
Dhe pastaj na u kujtua "lodra" statistikore, bioyino, të cilën e shkruam në hackathonin Just for Fun (emri i projektit u gjenerua nga një skript para hackathonit) dhe kuptuam se na duhej urgjentisht statistikat tona. Pse?
- sepse ka shumë pak klone të statsd në botë,
- sepse është e mundur të ofrohet toleranca e dëshiruar ose afër dëshiruar e gabimeve dhe shkallëzueshmëria (duke përfshirë sinkronizimin e metrikave të agreguara midis serverave dhe zgjidhjen e problemit të konflikteve gjatë dërgimit),
- sepse mund të llogaritni metrikat më saktë sesa Brubeck,
- sepse ne mund të mbledhim vetë statistika më të detajuara, të cilat Brubeck praktikisht nuk na i dha kurrë,
- sepse pata mundësinë të programoja aplikacionin tim në shkallë të shpërndarë me hiperperformancë, i cili nuk do ta përsëriste plotësisht arkitekturën e një tjetër hiperperformance të tillë... epo, e kuptoni.
Në çfarë të shkruaj? Në ndryshk, sigurisht. Pse?
- sepse tashmë ekzistonte një prototip i zgjidhjes,
- sepse autori i artikullit e njihte tashmë Rust-in në atë kohë dhe mezi priste të shkruante diçka në të për prodhim me mundësinë e publikimit të tij si burim të hapur,
- sepse gjuhët me GC nuk janë të përshtatshme për ne për shkak të natyrës së trafikut të marrë (pothuajse në kohë reale) dhe pauzat e GC janë praktikisht të papranueshme,
- sepse na duhet performancë maksimale e krahasueshme me C
- Sepse Rust na jep njëkohësi të patrembur, dhe nëse do të fillonim ta shkruanim në C/C++, do të merrnim edhe më shumë sesa brubeck, dobësi, tejmbushje të buffer-it, kushte race dhe fjalë të tjera të frikshme.
Pati edhe një argument kundër Rust. Kompania nuk kishte përvojë në krijimin e projekteve në Rust dhe ne nuk planifikonim ta përdornim atë në projektin tonë kryesor. Pra, kishte shqetësime serioze se nuk do të funksiononte, por vendosëm ta provonim.
Koha kaloiâŠ
MĂ« nĂ« fund, pas disa pĂ«rpjekjeve tĂ« dĂ«shtuara, versioni i parĂ« funksional ishte gati. ĂfarĂ« ndodhi? Ja si dukej.
Ădo nyje merr grupin e vet tĂ« metrikave dhe i grumbullon ato, por nuk i grumbullon metrikat pĂ«r ato lloje ku grupi i plotĂ« do tĂ« kĂ«rkohej pĂ«r grumbullimin pĂ«rfundimtar. Nyjet janĂ« tĂ« lidhura nĂ«pĂ«rmjet njĂ« protokolli tĂ« kyçjes sĂ« shpĂ«rndarĂ«, i cili u lejon atyre tĂ« zgjedhin atĂ« (e thirrĂ«m kĂ«tu) qĂ« ia vlen tĂ« dĂ«rgojĂ« metrika te i Madhi. Ky problem aktualisht po adresohet nga , por nĂ« tĂ« ardhmen ambiciet e autorit shtrihen deri nĂ« Raft, ku nyja udhĂ«heqĂ«se e konsensusit Ă«shtĂ«, sigurisht, mĂ« e denja. PĂ«rveç konsensusit, nyjet shpesh (si parazgjedhje, njĂ« herĂ« nĂ« sekondĂ«) u dĂ«rgojnĂ« fqinjĂ«ve tĂ« tyre ato pjesĂ« tĂ« metrikave tĂ« para-agreguara qĂ« kanĂ« arritur tĂ« mbledhin gjatĂ« asaj sekonde. Kjo ruan shkallĂ«zueshmĂ«rinĂ« dhe tolerancĂ«n ndaj gabimeve - çdo nyje ende mirĂ«mban njĂ« grup tĂ« plotĂ« metrikash, por metrikat dĂ«rgohen tĂ« agreguara, nĂ«pĂ«rmjet TCP dhe tĂ« koduara nĂ« njĂ« protokoll binar, duke ulur ndjeshĂ«m kostot e dublikimit krahasuar me UDP. PavarĂ«sisht numrit relativisht tĂ« madh tĂ« metrikave hyrĂ«se, akumulimi kĂ«rkon shumĂ« pak memorie dhe madje edhe mĂ« pak CPU. PĂ«r metrikat tona tĂ« kompresuara mirĂ«, kjo arrin vetĂ«m nĂ« disa dhjetĂ«ra megabajt tĂ« dhĂ«nash. NjĂ« bonus shtesĂ« Ă«shtĂ« shmangia e rishkrimeve tĂ« panevojshme tĂ« tĂ« dhĂ«nave nĂ« Graphite, siç ishte rasti me burbeck.
Paketat UDP me metrika janë të pabalancuara midis nyjeve në pajisjet e rrjetit duke përdorur një round robin të thjeshtë. Natyrisht, hardueri i rrjetit nuk e analizon përmbajtjen e paketës dhe për këtë arsye mund të trajtojë shumë më tepër se 4 milion paketa në sekondë, për të mos përmendur metrikat për të cilat nuk di asgjë. Duke pasur parasysh që metrikat nuk merren individualisht në secilën paketë, ne nuk parashikojmë ndonjë problem të performancës këtu. Nëse një server rrëzohet, pajisja e rrjetit shpejt (brenda 1-2 sekondave) e zbulon këtë dhe e heq serverin e rënë nga rrotullimi. Si rezultat, nyjet pasive (domethënë, jo-udhëheqëse) mund të ndizen dhe fiken praktikisht pa asnjë rënie të dukshme në grafikë. Më së shumti që humbasim janë disa nga metrikat që mbërritën në sekondën e fundit. Një humbje/ndërrim i papritur i udhëheqësit do të krijojë ende një anomali të vogël (intervali 30-sekondësh është ende jashtë sinkronizimit), por nëse ka komunikim midis nyjeve, këto probleme mund të minimizohen, për shembull, duke dërguar paketa sinkronizimi.
Pak rreth pjesëve të brendshme. Aplikacioni është, sigurisht, me shumë fije, por arkitektura e fijeve ndryshon nga ajo e përdorur në brubeck. Fijet në brubeck janë identike - secila është përgjegjëse si për mbledhjen e të dhënave ashtu edhe për agregimin. Në bioyino, fijet e punëtorëve ndahen në dy grupe: ato përgjegjëse për përpunimin e rrjetit dhe ato përgjegjëse për agregimin. Kjo ndarje lejon një menaxhim më fleksibël të aplikacionit në varësi të llojit të metrikave: aty ku kërkohet agregim intensiv, mund të shtohen agregues, ndërsa aty ku ka shumë trafik rrjeti, mund të shtohen më shumë fije rrjeti. Aktualisht, ne operojmë me tetë fije rrjeti dhe katër fije agregimi në serverat tanë.
Pjesa llogaritëse (e grumbullimit) është mjaft e lodhshme. Buferat e mbushura me rrjedha rrjeti shpërndahen midis fijeve llogaritëse, ku më pas analizohen dhe grumbullohen. Me kërkesë, metrikat dërgohen në nyje të tjera. E gjithë kjo, duke përfshirë transferimin e të dhënave midis nyjeve dhe ndërveprimin me Consul, kryhet në mënyrë asinkrone dhe funksionon në kornizë. .
Komponenti i rrjetit pĂ«rgjegjĂ«s pĂ«r marrjen e metrikave paraqiti shumĂ« mĂ« tepĂ«r sfida zhvillimi. QĂ«llimi kryesor i ndarjes sĂ« rrjedhave tĂ« rrjetit nĂ« entitete tĂ« ndara ishte zvogĂ«limi i kohĂ«s sĂ« shpenzuar pĂ«r secilĂ«n rrjedhĂ«. jo pĂ«r tĂ« lexuar tĂ« dhĂ«na nga njĂ« socket. Opsionet e pĂ«rdorimit tĂ« UDP asinkron dhe recvmsg tĂ« rregullt shpejt u lanĂ« jashtĂ« pĂ«rdorimit: e para konsumon shumĂ« hapĂ«sirĂ« ââCPU tĂ« pĂ«rdoruesit pĂ«r pĂ«rpunimin e ngjarjeve, ndĂ«rsa e dyta konsumon shumĂ« çelĂ«sa konteksti. Prandaj, qasja aktuale Ă«shtĂ« Me buffer-a tĂ« mĂ«dhenj (dhe buffer-at, zotĂ«rinj oficerĂ«, nuk janĂ« thjesht çdo gjĂ«!). MbĂ«shtetja pĂ«r UDP-nĂ« e rregullt Ă«shtĂ« e rezervuar pĂ«r rastet me ngarkesĂ« tĂ« ulĂ«t kur recvmmsg nuk Ă«shtĂ« i nevojshĂ«m. Modaliteti shumĂ«mesazhesh arrin qĂ«llimin kryesor: fija e rrjetit kalon pjesĂ«n mĂ« tĂ« madhe tĂ« kohĂ«s duke pastruar radhĂ«n e sistemit operativ - duke lexuar tĂ« dhĂ«na nga soketi dhe duke i transferuar ato nĂ« buffer-in e hapĂ«sirĂ«s sĂ« pĂ«rdoruesit, vetĂ«m herĂ« pas here duke kaluar pĂ«r t'ia dorĂ«zuar buffer-in e plotĂ« agreguesve. Radha e soketit praktikisht nuk grumbullohet kurrĂ« dhe numri i paketave tĂ« humbura mezi rritet.
Shënim
Si parazgjedhje, madhësia e memorjes së përkohshme është vendosur mjaft e madhe. Nëse vendosni ta testoni vetë serverin, mund të zbuloni se pas dërgimit të një numri të vogël metrikash, ato nuk mbërrijnë në Graphite, duke mbetur në memorjen e transmetimit të rrjetit. Për të trajtuar një numër të vogël metrikash, duhet të vendosni vlera më të vogla në skedarët e konfigurimit bufsize dhe task-queue-size.
Më në fund, disa grafikë për dashamirësit e grafikëve.
Statistikat mbi numrin e metrikave hyrëse për secilin server: më shumë se 2 milion MPS.
Ăaktivizimi i njĂ«rĂ«s prej nyjeve dhe rishpĂ«rndarja e metrikave hyrĂ«se.
Statistikat mbi metrikat dalëse: vetëm një nyje dërgon ndonjëherë - shefi i bastisjes.
Statistikat e funksionimit të secilës nyje, duke marrë parasysh gabimet në module të ndryshme të sistemit.
Detajet e metrikave hyrëse (emrat e metrikave janë të fshehura).
ĂfarĂ« planifikojmĂ« tĂ« bĂ«jmĂ« me tĂ« gjitha kĂ«to mĂ« pas? TĂ« shkruajmĂ« kod tĂ« mallkuar, sigurisht! Projekti fillimisht ishte planifikuar si me burim tĂ« hapur dhe do tĂ« mbetet i tillĂ« pĂ«r gjithĂ« jetĂ«n e tij. Planet tona tĂ« menjĂ«hershme pĂ«rfshijnĂ« kalimin nĂ« versionin tonĂ« tĂ« Raft, ndryshimin e protokollit tĂ« kolegĂ«ve nĂ« njĂ« mĂ« tĂ« lĂ«vizshĂ«m, shtimin e statistikave tĂ« brendshme shtesĂ«, llojeve tĂ« reja metrike, rregullimeve tĂ« gabimeve dhe pĂ«rmirĂ«simeve tĂ« tjera.
Sigurisht, kushdo që është i gatshëm të ndihmojë në zhvillimin e projektit është i mirëpritur: të krijojë PR, probleme dhe ne do t'u përgjigjemi atyre sa herë që të jetë e mundur, t'i përmirësojmë ato, etj.
Kaq është e gjitha, njerëz, siç thonë, blini elefantët tanë!
Burimi: www.habr.com
