Sa sammelje jo metriken. As wy binne. Wy sammelje ek metriken. Fansels, nedich foar bedriuw. Hjoed sille wy prate oer de alderearste keppeling fan ús tafersjochsysteem - in statsd-kompatible aggregaasjetsjinner , Wêrom hawwe wy it skreaun en wêrom wy brubeck ferlitten hawwe.
Fan ús eardere artikels (, ) kinne jo fine út dat oant in skoft wy sammele marks mei help . It is skreaun yn C. Ut in koade eachpunt, it is sa ienfâldich as in stekker (dit is wichtich as jo wolle bydrage) en, it wichtichste, it behannelet ús folumes fan 2 miljoen metrics per sekonde (MPS) op peak sûnder problemen. De dokumintaasje stelt stipe foar 4 miljoen MPS mei in asterisk. Dit betsjut dat jo it opjûne figuer krije as jo it netwurk goed ynstelle op Linux. (Wy witte net hoefolle MPS jo kinne krije as jo it netwurk ferlitte lykas it is). Nettsjinsteande dizze foardielen hiene wy ferskate serieuze klachten oer brubeck.
Oanfraach 1. Github, de ûntwikkelder fan it projekt, stoppe it stypjen: publisearjen fan patches en reparaasjes, akseptearje ús en (net allinich ús) PR. De lêste moannen (earne fan febrewaris-maart 2018) is de aktiviteit wer opstarten, mar dêrfoar wie der hast 2 jier folsleine rêst. Dêrneist wurdt it projekt ûntwikkele , Dat kin in serieuze obstakel wurde foar de ynfiering fan nije funksjes.
Oanfraach 2. Krektens fan berekkeningen. Brubeck sammelet yn totaal 65536 wearden foar aggregaasje. Yn ús gefal kinne foar guon metriken yn 'e aggregaasjeperioade (30 sekonden) folle mear wearden komme (1 op it hichtepunt). As gefolch fan dizze sampling, de maksimum en minimale wearden lykje nutteloos. Bygelyks, lykas dit:
Sa't it wie
Hoe hie it wêze moatten
Om deselde reden wurde bedraggen oer it generaal ferkeard berekkene. Foegje hjir in brek ta mei in 32-bit floatoverflow, dy't de tsjinner oer it algemien stjoert nei segfault by it ûntfangen fan in skynber ûnskuldige metrik, en alles wurdt geweldich. De bug is trouwens net reparearre.
En, úteinlik, Oanfraach X. Op it stuit fan dit skriuwen binne wy ree om it te presintearjen oan alle 14 min of mear wurkjende statistyske ymplemintaasjes dy't wy koenen fine. Litte wy ús foarstelle dat guon inkele ynfrastruktuer sa groeid is dat it akseptearjen fan 4 miljoen MPS net mear genôch is. Of sels as it noch net groeid is, mar de metriken binne al sa wichtich foar jo dat sels koarte, 2-3 minuten dips yn 'e charts al kritysk wurde kinne en oanfallen fan ûnoerwinlike depresje ûnder managers feroarsaakje. Sûnt it behanneljen fan depresje in tankleaze taak is, binne technyske oplossingen nedich.
As earste, skuldtolerânsje, sadat in hommelse probleem op 'e tsjinner gjin psychiatryske zombie-apokalyps op it kantoar feroarsaket. Twads, skaalfergrutting om mear dan 4 miljoen MPS te kinne akseptearje, sûnder djip yn 'e Linux-netwurkstapel te graven en kalm "yn' e breedte" te groeien nei de fereaske grutte.
Sûnt wy hiene romte foar skaalfergrutting, wy besletten om te begjinnen mei skuld tolerânsje. "OER! Marzje foar flaters! It is ienfâldich, wy kinne it dwaan, "tochten wy en lansearren 2 servers, en brochten in kopy fan brubeck op elk. Om dit te dwaan, moasten wy ferkear kopiearje mei metriken nei beide servers en sels skriuwe foar dit . Wy hawwe oplost it probleem tolerânsje mei dizze, mar ... net hiel goed. Yn it earstoan like alles geweldich: elke brubeck sammelt syn eigen ferzje fan aggregaasje, skriuwt gegevens nei Graphite ien kear elke 30 sekonden, oerskriuwt it âlde ynterval (dit wurdt dien oan 'e Graphite-kant). As ien server ynienen mislearret, hawwe wy altyd in twadde mei in eigen kopy fan 'e aggregearre gegevens. Mar hjir is it probleem: as de tsjinner mislearret, ferskynt in "saw" op 'e grafiken. Dat komt troch it feit dat brubeck syn 30-sekonde yntervallen binne net syngronisearre, en op it momint fan in crash ien fan harren wurdt net oerskreaun. As de twadde tsjinner begjint, bart itselde ding. Hiel te fernearen, mar ik wol better! It probleem fan skaalberens is ek net fuortgien. Alle metriken noch "fleane" nei in inkele tsjinner, en dêrom binne wy beheind ta deselde 2-4 miljoen MPS, ôfhinklik fan it netwurk nivo.
As jo in bytsje tinke oer it probleem en tagelyk snie grave mei in shovel, kin it folgjende foar de hân lizzende idee yn 't sin komme: jo hawwe in statsd nedich dy't kin wurkje yn ferdielde modus. Dat is, ien dy't syngronisaasje ymplemintearret tusken knooppunten yn tiid en metriken. "Fansels, sa'n oplossing bestiet wierskynlik al," seine wy en gongen nei Google .... En se fûnen neat. Nei it trochgean fan de dokumintaasje foar ferskate statsd ( as fan 11.12.2017. Desimber XNUMX), wy fûnen hielendal neat. Blykber hawwe noch de ûntwikkelders noch de brûkers fan dizze oplossingen noch SO folle metriken tsjinkaam, oars soene se grif wat komme.
En doe herinnerden wy ús oer it "boartersguod" statsd - bioyino, dat waard skreaun op 'e Just for Fun hackathon (de namme fan it projekt waard generearre troch it skript foar it begjin fan' e hackathon) en realisearre dat wy ús eigen statsd driuwend nedich wiene. Foar wat?
- om't d'r te min statd-klonen yn 'e wrâld binne,
- om't it mooglik is om de winske of tichtby de winske fouttolerânsje en skalberens te leverjen (ynklusyf syngronisearjen fan aggregearre metriken tusken servers en it oplossen fan it probleem fan it ferstjoeren fan konflikten),
- om't it mooglik is om metriken krekter te berekkenjen dan Brubeck docht,
- om't jo sels mear detaillearre statistiken kinne sammelje, dy't brubeck ús praktysk net levere,
- om't ik hie in kâns om te programmearje myn eigen hyperperformance distributedscalelabplication, dat sil net hielendal werhelje de arsjitektuer fan in oare ferlykbere hyperfor ... goed, dat is it.
Wat te skriuwen op? Fansels, yn Rust. Wêrom?
- om't d'r al in prototype-oplossing wie,
- om't de skriuwer fan it artikel Rust op dat stuit al koe en begearich wie om der wat yn te skriuwen foar produksje mei de mooglikheid om it yn iepen boarne te setten,
- om't talen mei GC net geskikt binne foar ús fanwegen de aard fan it ûntfongen ferkear (hast realtime) en GC-pauzes praktysk net akseptabel binne,
- om't jo maksimale prestaasjes nedich binne fergelykber mei C
- om't Rust foarsjocht ús mei fearless concurrency, en as wy begûn te skriuwen it yn C / C ++, wy soenen hawwe raked yn noch mear kwetsberens, bufferoverlop, ras betingsten en oare enge wurden as brubeck.
Der wie ek in argumint tsjin Rust. It bedriuw hie gjin ûnderfining mei it meitsjen fan projekten yn Rust, en no binne wy ek net fan plan om it te brûken yn it haadprojekt. Dêrom wiene d'r serieuze eangsten dat neat soe wurkje, mar wy besletten om in kâns te nimmen en besochten.
De tiid gie foarby...
Uteinlik, nei ferskate mislearre besykjen, wie de earste wurkferzje klear. Wat is bard? Dit is wat der bard is.
Elk knooppunt ûntfangt syn eigen set metriken en sammelet se, en aggregearret gjin metriken foar dy typen wêr't har folsleine set fereaske is foar definitive aggregaasje. De knooppunten binne ferbûn mei elkoar troch in soarte fan ferspraat slot protokol, wêrmei jo te selektearjen ûnder harren de ienige (hjir we rôpen) dy't wurdich is te stjoeren metrics nei de Grutte. Dit probleem wurdt op it stuit oplost troch , mar yn 'e takomst de ambysjes fan' e skriuwer útwreidzje nei Raft, wêr't de meast wurdich sil, fansels, de konsensusliederknooppunt wêze. Neist konsensus stjoere knooppunten frij faak (ien kear per sekonde standert) nei har buorlju dy dielen fan pre-aggregearre metriken dy't se yn dy sekonde slaggen te sammeljen. It docht bliken dat skaalfergrutting en fouttolerânsje bewarre bleaun binne - elke knooppunt hâldt noch in folsleine set metriken, mar de metriken wurde al aggregearre stjoerd, fia TCP en kodearre yn in binêre protokol, sadat duplikaasjekosten signifikant wurde fermindere yn ferliking mei UDP. Nettsjinsteande it frij grutte oantal ynkommende metriken, fereasket accumulation heul lyts ûnthâld en noch minder CPU. Foar ús heul komprimerbere mertics is dit mar in pear tsientallen megabytes oan gegevens. As in ekstra bonus, wy krije gjin oerstallige gegevens rewrites yn Graphite, lykas it gefal wie mei burbeck.
UDP-pakketten mei metriken binne unbalansearre tusken knopen op netwurkapparatuer fia in ienfâldige Round Robin. Fansels parseart de netwurkhardware de ynhâld fan pakketten net en kin dêrom folle mear dan 4M pakketten per sekonde lûke, om net te sizzen fan metriken wêrfan it hielendal neat wit. As wy rekken hâlde mei dat de metriken net ien op ien yn elk pakket komme, dan foarsei wy gjin prestaasjesproblemen op dit plak. As in tsjinner crasht, detektearret it netwurkapparaat fluch (binnen 1-2 sekonden) dit feit en ferwideret de ferûngelokke tsjinner fan rotaasje. As gefolch hjirfan kinne passive (dus net-lieder) knopen praktysk oan- en útskeakele wurde sûnder tekeningen op 'e charts te merken. It maksimum dat wy ferlieze is diel fan 'e metriken dy't yn' e lêste sekonde kamen. In hommelse ferlies / ôfsluting / skeakel fan in lieder sil noch in lytse anomaly meitsje (it ynterval fan 30 sekonden is noch net syngronisearre), mar as d'r kommunikaasje is tusken knooppunten, kinne dizze problemen minimalisearre wurde, bygelyks troch syngronisaasjepakketten út te stjoeren .
In bytsje oer de ynterne struktuer. De applikaasje is fansels multithreaded, mar de threading-arsjitektuer is oars as dy brûkt yn brubeck. De triedden yn brubeck binne itselde - elk fan har is ferantwurdlik foar sawol ynformaasjesammeling as aggregaasje. Yn bioyino wurde arbeiders ferdield yn twa groepen: dyjingen dy't ferantwurdlik binne foar it netwurk en dyjingen dy't ferantwurdlik binne foar aggregaasje. Dizze divyzje lit jo de applikaasje fleksibeler beheare ôfhinklik fan it type metriken: wêr't yntinsive aggregaasje nedich is, kinne jo aggregators tafoegje, wêr't in protte netwurkferkear is, kinne jo it oantal netwurkstreamen tafoegje. Op it stuit wurkje wy op ús servers yn 8 netwurk en 4 aggregaasjestreamen.
It tellen (ferantwurdlik foar aggregaasje) diel is frij saai. Buffers fol mei netwurkstreamen wurde ferdield oer tellende streamen, wêr't se dêrnei wurde parseard en aggregearre. Op oanfraach wurde metriken jûn foar ferstjoeren nei oare knopen. Dit alles, ynklusyf it ferstjoeren fan gegevens tusken knooppunten en wurkjen mei Consul, wurdt asynchronysk útfierd, rint op it ramt .
Folle mear problemen tidens ûntwikkeling waarden feroarsake troch it netwurkdiel dat ferantwurdlik is foar it ûntfangen fan metriken. It haaddoel fan it skieden fan netwurkstreamen yn aparte entiteiten wie de winsk om de tiid te ferminderjen dy't in stream trochbringt net om gegevens út 'e socket te lêzen. Opsjes mei help fan asynchronous UDP en reguliere recvmsg ferdwûn fluch: de earste ferbrûkt tefolle brûkersromte CPU foar evenemint ferwurking, de twadde fereasket tefolle kontekst switches. Dêrom wurdt it no brûkt mei grutte buffers (en buffers, hearen offisieren, binne neat foar jo!). Stipe foar reguliere UDP is reservearre foar ljochte gefallen dêr't recvmmsg net nedich is. Yn multyberjochtmodus is it mooglik om it wichtichste ding te berikken: de grutte mearderheid fan 'e tiid raket de netwurkdraad de OS-wachtrige - lêst gegevens fan' e socket en draacht it oer nei de brûkersromte-buffer, mar soms oerskeakelje nei it jaan fan de folle buffer oan aggregators. De wachtrige yn 'e socket sammelet praktysk net, it oantal sakke pakketten groeit praktysk net.
remark
Yn 'e standertynstellingen is de buffergrutte ynsteld om frij grut te wêzen. As jo ynienen beslute om te besykjen de tsjinner sels, kinne jo tsjinkomme it feit dat nei it ferstjoeren fan in lyts oantal metrics, se sille net oankomme yn Graphite, oerbleaune yn it netwurk stream buffer. Om te wurkjen mei in lyts oantal metriken, moatte jo bufsize en taakwachtrige-grutte ynstelle op lytsere wearden yn 'e konfiguraasje.
Ta beslút, guon charts foar chart leafhawwers.
Statistiken oer it oantal ynkommende metriken foar elke tsjinner: mear as 2 miljoen MPS.
Ien fan 'e knopen útskeakelje en ynkommende metriken opnij fersprieden.
Statistiken oer útgeande metriken: mar ien knooppunt stjoert altyd - de oerfalbaas.
Statistiken fan de wurking fan elke knooppunt, rekken hâldend mei flaters yn ferskate systeem modules.
Detaillearjen fan ynkommende metriken (metryske nammen binne ferburgen).
Wat binne wy fan plan te dwaan mei dit alles folgjende? Fansels, skriuw koade, ferdomme...! It projekt wie oarspronklik pland om iepen-boarne te wêzen en sil sa syn hiele libben bliuwe. Us direkte plannen omfetsje it wikseljen nei ús eigen ferzje fan Raft, it feroarjen fan it peer-protokol nei in mear draachber, it yntrodusearjen fan ekstra ynterne statistiken, nije soarten metriken, bug fixes en oare ferbetteringen.
Fansels is elkenien wolkom om te helpen by de ûntwikkeling fan it projekt: meitsje PR, Kwestje, as it mooglik is sille wy reagearje, ferbetterje, ensfh.
Mei dat sein, dat binne allegear minsken, keapje ús oaljefanten!
Boarne: www.habr.com