Svo þú safnar mælingum. Eins og við erum. Við söfnum líka mælingum. Auðvitað, nauðsynlegt fyrir fyrirtæki. Í dag munum við tala um fyrsta hlekkinn á vöktunarkerfi okkar - statsd-samhæfan söfnunarþjón , hvers vegna við skrifuðum það og hvers vegna við yfirgáfum Brubeck.
Frá fyrri greinum okkar (, ) þú getur komist að því að þar til nokkurn tíma söfnuðum við merkjum með því að nota . Það er skrifað í C. Frá sjónarhóli kóðans er það eins einfalt og tappi (þetta er mikilvægt þegar þú vilt leggja þitt af mörkum) og, síðast en ekki síst, það sér um rúmmál okkar upp á 2 milljónir mælikvarða á sekúndu (MPS) þegar mest er. án vandræða. Í skjölunum kemur fram stuðningur við 4 milljónir MPS með stjörnu. Þetta þýðir að þú færð uppgefna tölu ef þú stillir netið rétt á Linux. (Við vitum ekki hversu marga MPS þú getur fengið ef þú skilur netið eftir eins og það er). Þrátt fyrir þessa kosti höfðum við nokkrar alvarlegar kvartanir um brubeck.
Krafa 1. Github, verktaki verkefnisins, hætti að styðja það: birti plástra og lagfæringar, samþykkti okkar og (ekki aðeins okkar) PR. Undanfarna mánuði (einhvers staðar frá febrúar-mars 2018) hefur starfsemin hafist á ný en þar áður var næstum 2 ár af algjörri ró. Auk þess er verið að þróa verkefnið , sem getur orðið alvarleg hindrun fyrir innleiðingu nýrra eiginleika.
Krafa 2. Nákvæmni útreikninga. Brubeck safnar samtals 65536 gildum fyrir samansafn. Í okkar tilviki, fyrir suma mælikvarða, á söfnunartímabilinu (30 sekúndur), gætu miklu fleiri gildi borist (1 þegar mest var). Sem afleiðing af þessari sýnatöku virðast hámarks- og lágmarksgildin gagnslaus. Til dæmis, svona:
Eins og það var
Hvernig það hefði átt að vera
Af sömu ástæðu eru upphæðir almennt rangt reiknaðar. Bættu hér við villu með 32-bita flotflæði, sem venjulega sendir þjóninn í aðskilgreina þegar hann fær að því er virðist saklausa mælikvarða, og allt verður frábært. Villan, við the vegur, hefur ekki verið lagaður.
Og, að lokum, Krafa X. Þegar þetta er skrifað erum við tilbúin að kynna það fyrir öllum 14 meira eða minna starfandi tölfræðiútfærslum sem við gátum fundið. Við skulum ímynda okkur að einhver einstök innviði hafi stækkað svo mikið að það er ekki lengur nóg að samþykkja 4 milljónir MPS. Eða jafnvel þótt það hafi ekki stækkað enn, en mælikvarðar eru nú þegar svo mikilvægir fyrir þig að jafnvel stuttar, 2-3 mínútur í töflunum geta þegar orðið mikilvægar og valdið óyfirstíganlegu þunglyndi meðal stjórnenda. Þar sem að meðhöndla þunglyndi er vanþakklátt verkefni er þörf á tæknilegum lausnum.
Í fyrsta lagi, bilanaþol, svo að skyndilegt vandamál á þjóninum valdi ekki geðrænum uppvakningaheimild á skrifstofunni. Í öðru lagi, skala til að geta tekið við meira en 4 milljón MPS, án þess að grafa djúpt í Linux netstafla og stækka rólega „í breidd“ í nauðsynlega stærð.
Þar sem við höfðum pláss fyrir mælikvarða ákváðum við að byrja með bilanaþol. „UM! Bilanaþol! Það er einfalt, við getum gert það,“ hugsuðum við og settum af stað 2 netþjóna og bjuggum til eintak af brubeck á hverjum. Til að gera þetta þurftum við að afrita umferð með mæligildum á báða netþjóna og jafnvel skrifa fyrir þetta . Við leystum bilanaþolsvandann með þessu, en... ekki mjög vel. Í fyrstu virtist allt frábært: hver brubeck safnar sinni eigin útgáfu af samsöfnun, skrifar gögn í Graphite einu sinni á 30 sekúndna fresti og skrifar yfir gamla bilið (þetta er gert á grafíthliðinni). Ef einn netþjónn bilar skyndilega, höfum við alltaf annan með eigin afriti af uppsöfnuðum gögnum. En hér er vandamálið: ef þjónninn bilar birtist „sög“ á línuritunum. Þetta stafar af því að 30 sekúndna millibil brubeck eru ekki samstillt og við hrun er eitt þeirra ekki skrifað yfir. Þegar seinni þjónninn byrjar gerist það sama. Alveg þolanlegt, en ég vil betra! Vandamálið við sveigjanleika hefur heldur ekki horfið. Allar mælingar „fljúga“ enn á einn netþjón og þess vegna erum við takmörkuð við sömu 2-4 milljónir MPS, allt eftir netstigi.
Ef þú hugsar aðeins um vandamálið og á sama tíma grafir upp snjó með skóflu, þá gæti eftirfarandi augljós hugmynd komið upp í hugann: þú þarft statsd sem getur virkað í dreifðri stillingu. Það er, einn sem útfærir samstillingu milli hnúta í tíma og mæligildum. „Auðvitað er slík lausn líklega þegar til,“ sögðum við og fórum á Google…. Og þeir fundu ekkert. Eftir að hafa farið í gegnum skjölin fyrir mismunandi tölfræði ( frá og með 11.12.2017. desember XNUMX), fundum við nákvæmlega ekkert. Svo virðist sem hvorki verktaki né notendur þessara lausna hafa enn rekist á SVO margar mælikvarðar, annars myndu þeir örugglega finna eitthvað upp á.
Og svo minntumst við á „leikfang“ statsd - bioyino, sem var skrifað á Just for Fun hackaþoninu (nafn verkefnisins var búið til af handritinu áður en hackathonið hófst) og komumst að því að okkur vantaði okkar eigin tölfræði brýn. Til hvers?
- vegna þess að það eru of fáir statd klónar í heiminum,
- vegna þess að það er hægt að veita æskilegt eða nálægt æskilegu bilanaþoli og sveigjanleika (þar á meðal að samstilla samanlagðar mæligildi milli netþjóna og leysa vandamálið við að senda átök),
- vegna þess að það er hægt að reikna mælikvarða nákvæmari en Brubeck gerir,
- vegna þess að þú getur safnað ítarlegri tölfræði sjálfur, sem Brubeck gaf okkur nánast ekki,
- vegna þess að ég hafði tækifæri til að forrita mína eigin ofurframmistöðu dreifða mælikvarða, sem mun ekki alveg endurtaka arkitektúr annarrar svipaðrar hyperfor... jæja, það er það.
Hvað á að skrifa á? Auðvitað í Rust. Hvers vegna?
- vegna þess að það var þegar til frumgerð lausn,
- vegna þess að höfundur greinarinnar þekkti Rust þegar á þeim tíma og var fús til að skrifa eitthvað í hana til framleiðslu með tækifæri til að setja það í opinn uppspretta,
- vegna þess að tungumál með GC henta okkur ekki vegna eðlis móttekinnar umferðar (næstum rauntíma) og GC hlé eru nánast óviðunandi,
- vegna þess að þú þarft hámarksafköst sambærileg við C
- vegna þess að Rust veitir okkur óttalausa samveru, og ef við hefðum byrjað að skrifa það í C/C++, þá hefðum við rakað inn enn fleiri veikleika, buffer overflows, keppnisaðstæður og önnur skelfileg orð en brubeck.
Það voru líka rök gegn Rust. Fyrirtækið hafði enga reynslu af því að búa til verkefni í Rust og nú ætlum við heldur ekki að nota það í aðalverkefninu. Það var því alvarlegur ótti um að ekkert myndi ganga upp en við ákváðum að taka sénsinn og reyndum.
Tíminn leið...
Að lokum, eftir nokkrar misheppnaðar tilraunir, var fyrsta virka útgáfan tilbúin. Hvað gerðist? Þetta er það sem gerðist.
Hver hnút fær sitt eigið mælikvarða og safnar þeim saman, og safnar ekki saman mæligildum fyrir þær gerðir þar sem þarf fullt sett þeirra fyrir endanlega samansöfnun. Hnútarnir eru tengdir hver öðrum með einhvers konar dreifðri læsasamskiptareglu, sem gerir þér kleift að velja meðal þeirra þann eina (hér grétum við) sem er verðugt að senda mælikvarða til Stóra. Nú er verið að leysa þetta vandamál af , en í framtíðinni nær metnaður höfundar til Raft, þar sem sá verðugasti verður að sjálfsögðu samstöðuleiðtogahnúturinn. Til viðbótar við samstöðu, senda hnútar nokkuð oft (einu sinni á sekúndu sjálfgefið) til nágranna sinna þá hluta fyrirfram samantekinna mælikvarða sem þeim tókst að safna á þeirri sekúndu. Það kemur í ljós að mælikvarði og bilanaþol eru varðveitt - hver hnút hefur enn fullt sett af mæligildum, en mælikvarðar eru sendar þegar samanlagðar, í gegnum TCP og kóðaðar í tvöfalda samskiptareglu, þannig að tvíverkunarkostnaður minnkar verulega miðað við UDP. Þrátt fyrir tiltölulega mikinn fjölda komandi mæligilda krefst uppsöfnun mjög lítið minni og jafnvel minni CPU. Fyrir mjög samþjappanlega vöruverði okkar er þetta aðeins nokkra tugi megabæta af gögnum. Sem aukabónus fáum við engar óþarfa endurskrifanir á gögnum í Graphite, eins og raunin var með burbeck.
UDP pakkar með mæligildum eru í ójafnvægi á milli hnúta á netbúnaði í gegnum einfaldan Round Robin. Auðvitað greinir netvélbúnaðurinn ekki innihald pakka og getur því dregið miklu meira en 4M pakka á sekúndu, svo ekki sé minnst á mælikvarða sem hann veit ekkert um. Ef við tökum með í reikninginn að mæligildin koma ekki ein í einu í hverjum pakka, þá sjáum við ekki frammistöðuvandamál á þessum stað. Ef netþjónn hrynur skynjar nettækið fljótt (innan 1-2 sekúndna) þessa staðreynd og fjarlægir netþjóninn sem hrundi úr snúningi. Sem afleiðing af þessu er hægt að kveikja og slökkva á óvirkum hnútum (þ. Hámarkið sem við töpum er hluti af mælingunum sem komu inn á síðustu sekúndu. Skyndilegt tap/lokun/skipti á leiðara mun samt skapa minniháttar frávik (30 sekúndna bilið er enn ósamstillt), en ef samskipti eru á milli hnúta er hægt að lágmarka þessi vandamál, til dæmis með því að senda út samstillingarpakka .
Smá um innri uppbyggingu. Forritið er að sjálfsögðu fjölþráður en þráðararkitektúrinn er öðruvísi en notaður er í brubeck. Þræðirnir í brubeck eru þeir sömu - hver þeirra ber ábyrgð á bæði upplýsingasöfnun og samansöfnun. Í bioyino er starfsmönnum skipt í tvo hópa: þá sem bera ábyrgð á netinu og þá sem bera ábyrgð á samsöfnun. Þessi skipting gerir þér kleift að stjórna forritinu á sveigjanlegri hátt eftir tegund mæligilda: þar sem mikil samsöfnun er krafist geturðu bætt við söfnun, þar sem netumferð er mikil, geturðu bætt við fjölda netflæðis. Í augnablikinu, á netþjónum okkar, vinnum við í 8 net- og 4 söfnunarflæði.
Talningarhlutinn (ábyrgur fyrir söfnun) er frekar leiðinlegur. Stuðlarum sem fylltir eru af netflæði er dreift á talningarflæði, þar sem þeir eru síðan flokkaðir og teknir saman. Ef óskað er eftir, eru gefin mæligildi fyrir sendingu til annarra hnúta. Allt þetta, þar með talið að senda gögn á milli hnúta og vinna með Consul, er framkvæmt ósamstillt og keyrt á rammanum .
Miklu fleiri vandamál við þróun voru af völdum nethlutans sem ber ábyrgð á móttöku mæligilda. Meginmarkmið þess að aðgreina netflæði í aðskildar einingar var viljinn til að draga úr þeim tíma sem flæði eyðir ekki til að lesa gögn úr innstungunni. Valkostir sem nota ósamstillta UDP og venjulegt recvmsg hurfu fljótt: sá fyrsti eyðir of miklu notendarými CPU fyrir atburðavinnslu, sá seinni krefst of margra samhengisrofa. Þess vegna er það nú notað með stórum biðmunum (og bufferar, herrar yfirmenn, eru ekkert fyrir ykkur!). Stuðningur við venjulega UDP er frátekinn fyrir létt tilvik þar sem recvmmsg er ekki þörf. Í fjölskilaboðaham er hægt að ná aðalatriðinu: langflestum tíma hrífar netþráðurinn stýrikerfisröðina - les gögn úr falsinu og flytur þau yfir í notendarýmisbuffið, skiptir aðeins stundum yfir í að gefa fyllta biðminni til samanlagðar. Biðröðin í falsinu safnast nánast ekki upp, fjöldi pakka sem hefur sleppt vex nánast ekki.
Athugið
Í sjálfgefnum stillingum er biðminni stillt á að vera frekar stór. Ef þú ákveður skyndilega að prófa netþjóninn sjálfur gætirðu lent í þeirri staðreynd að eftir að hafa sent lítinn fjölda mælikvarða, munu þeir ekki berast í Graphite, sem eru eftir í netstraumsbuffi. Til að vinna með lítinn fjölda mæligilda þarftu að stilla bufsize og task-queue-stærð á minni gildi í stillingunni.
Að lokum, nokkur töflur fyrir kortaunnendur.
Tölfræði um fjölda komandi mæligilda fyrir hvern netþjón: meira en 2 milljónir MPS.
Slökkva á einum af hnútunum og endurdreifa mæligildum fyrir komandi.
Tölfræði um mælikvarða á útleið: aðeins einn hnútur sendir alltaf - árásarstjórinn.
Tölfræði um rekstur hvers hnúts, að teknu tilliti til villna í ýmsum kerfiseiningum.
Upplýsingar um mæligildi sem koma inn (mælingarheiti eru falin).
Hvað ætlum við að gera við þetta allt næst? Auðvitað, skrifaðu kóða, fjandinn...! Upphaflega var áætlað að verkefnið væri opið uppspretta og verður það áfram alla ævi. Strax áætlanir okkar fela í sér að skipta yfir í okkar eigin útgáfu af Raft, breyta jafningjasamskiptareglunum í færanlegri, kynna frekari innri tölfræði, nýjar gerðir mæligilda, villuleiðréttingar og aðrar endurbætur.
Að sjálfsögðu eru allir velkomnir að hjálpa til við þróun verkefnisins: búa til PR, málefni, ef mögulegt er munum við bregðast við, bæta o.s.frv.
Með því að segja, það er allt gott fólk, keyptu fílana okkar!
Heimild: www.habr.com