Bioyino — jaotatud, skaleeritav mõõdikute koondaja

Nii et, teie kogute mõõdikuid. Nagu meie. Meie kogume samuti mõõdikuid. Loomulikult selliseid, mis on äri jaoks vajalikud. Täna räägime meie jälgimissüsteemi esimesest elemendist — statsd-ühilduvast aggregeerimiserverist. bioyino, miks me selle kirjutasime ja miks loobusime brubeckist.

Meie varasematest artiklitest (1, 2) saab teada, et kuni teatud ajani kogusime märke brubecki abil. brubeck. See on kirjutatud C-s. Koodivaates — lihtne nagu kork (see on oluline, kui soovite panustada) ja, mis kõige tähtsam, suudab see meie mahtudega 2 miljonit mõõdikut sekundis (MPS) tipptasemel probleemideta hakkama saada. Dokumentatsioon lubab 4 miljonit MPS tähega. See tähendab, et nimetatud number saavutatakse, kui seadistate võrgu Linuxis õigesti. (Kui palju MPS on võimalik saada, kui võrku jätta selliseks nagu on, ei ole meile teada). Hoolimata neist eeliseid oli brubecki suhtes mitmeid tõsiseid pretensioone.

Pretensioon 1. Github — projekti arendaja — lõpetas selle toetamise: plaastrite ja paranduste avaldamise, meie ja (mitte ainult meie) PR-de vastuvõtmise. Viimastel kuudel (umbes alates veebruari-märtsi 2018) on aktiivsus taaselustatud, kuid enne seda oli peaaegu 2 aastat täielikku vaikust. Lisaks on projekt arendatud Gihubi sisemiste vajaduste jaoks, mis võib saada tõsiseks takistuseks uute võimaluste rakendamisel.

Pretensioon 2. Arvutuste täpsus. Brubeck kogub aggregeerimiseks vaid 65536 väärtust. Meie puhul võib mõnede mõõdikute puhul aggregeerimise perioodi (30 sek) jooksul tulla palju rohkem väärtusi (tipptasemel 1 527 392). Sellise proovivõtmise tulemusena näevad maksimumide ja miinimumide väärtused täiesti kasutud. Näiteks, nii:

Kuidas oli

Nii nagu oleks pidanud olema

Sama põhjusel arvestatakse summasid üldiselt valesti. Lisage siia 32-bitisest floatist tulenev ülevoolu viga, mis saadab serveri segfault'i, kui see saab näiliselt süütuid mõõdikuid, ja asi muutub veelgi paremaks. Viga, muide, pole siiani parandatud.

Ja lõpuks, Pretensioon X. Artikli kirjutamise hetkeks oleme valmis esitama selle kõigile 14 enam-vähem töötavale statsd rakendusele, mida oleme suutnud leida. Kujutame ette, et mõni infrastruktuur on kasvanud piisavalt suureks, et 4 miljoni MPS vastuvõtmine ei ole enam piisav. Või olgu see veel kasvanud, kuid mõõdikud on teie jaoks juba nii olulised, et isegi lühikesed, 2-3 minuti pikkused katkestused graafikutes võivad olla kriitilised ja tekitada halbu tujusi juhtide seas. Kuna depressiooni ravimine on tänamatu töö, vajame tehnilisi lahendusi.

Esiteks, talitlushäirete vastupidavus, et ootamatud serveriprobleemid ei cause`iks kontoris psühhiaatrilist zombiapokalypsi. Teiseks, skaleeritavus, et saaksime vastu võtta rohkem kui 4 miljonit MPS, ilma et peaksime sügavale Linuxi võrgu kihti kaevama ja rahulikult laienema „laiusesse“ soovitud suuruseni.

Kuna meil oli skaleeritavuse osas varu, otsustasime alustada talitlushäirete vastupidavusest. "O! Talitlushäirete vastupidavus! See on lihtne, me oskame seda!" — mõtlesime ja käivitasime 2 serverit, tõstes igaühele üles brubeck koopia. Selleks pidime kopeerima liikluse mõõdikutega mõlemasse serverisse ja isegi kirjutama selle jaoks väikese utiliidi. Me lahendasime talitlushäirete vastupidavuse probleemi, kuid... mitte eriti hästi. Algul tundus kõik olevat suurepärane: iga brubeck kogub oma aggregeerimise versiooni, kirjutab andmed Graphite'i iga 30 sekundi tagant, ülekirjutades vana intervalli (see toimub Graphite'i pool). Kui üks server peaks riknema, on meil alati olemas teine server koos oma aggregeeritud andmete koopia. Kuid probleem on selles, et kui server rikneb, tekib graafikutesse "saag". See on tingitud sellest, et brubeck'i 30-sekundi intervallid ei ole sünkroonitud ja katkestuse hetkel ei ülekirjutata ühte neist. Kui teine server käivitatakse, toimub sama asi. Täiesti talutav, kuid tahaks parem! Skaleeritavuse probleem pole samuti kuhugi kadunud. Kõik mõõdikud jooksevad endiselt ühele serverile, seega oleme piiratud samade 2-4 miljoni MPS-ga, sõltuvalt võrgu jõudlusest.

Kui mõelda probleemile ja samal ajal lühikese labidaga lund kaevata, võib pähe tulla üks ilmne mõte: meil on vaja statsd, mis suudab töötada jaotatud režiimis. See tähendab, et see võimaldab sünkroniseerida nodede vahel aega ja mõõdikuid. "Loomulikult on selline lahendus juba olemas," ütlesime ja läksime guugeldama... Ja ei leidnud midagi. Uurides erinevate statsd dokumentatsiooni (https://github.com/etsy/statsd/wiki#server-implementations 31.12.2017), ei leidnud me tegelikult mitte midagi. Tundub, et ei arendajad ega kasutajad ei ole sellise KOGUSE mõõdikutega seni kokku puutunud, muidu oleks nad kindlasti midagi välja mõelnud.

Ja siis meenutasime me "mänguasja" statsd - bioyino, mille olime kirjutatud hackathonil lihtsalt lõbu pärast (projekti nimi genereeris skript enne hackathoni algust) ja mõistsime, et meil on hädasti vaja oma statsd. Miks?

• sest maailmas on liiga vähe statsd kloone,
• sest on võimalik tagada soovitud või soovitavale lähedane vigade taluvus ja skalaarne kasv (sealhulgas sünkroniseerida agreetitud mõõdikud serverite vahel ja lahendada konfliktid edastamise ajal),
• sest mõõdikuid on võimalik arvestada täpsemalt kui brubeck,
• sest saame ise koguda detailsemat statistikat, mida brubeck meile praktiliselt ei pakkunud,
• sest tekkis võimalus programmeerida oma hüperperformantne jaotatud skaleeritav rakendus, mis ei jälgi täielikult teise sarnase hüperperform... nuviponeli arhitektuuri.

Millega me kirjutame? Loomulikult Rustiga. Miks?

• sest prototüüp lahendus oli juba olemas,
• sest artikli autor teadis tol ajal juba Rusti ja tahtis sellel kirjutada midagi tootmises koos võimalusega avaldada see open-source,
• sest GC-ga keelad ei sobi meile saadud liikluse loomuse tõttu (peaaegu reaalajas) ja GC-pausid on peaaegu vastuvõetamatud,
• sest maksimaalne jõudlus on vajalik, võrreldav C-ga
• sest Rust pakub meile fearless concurrency, ja kui me oleksime hakanud seda kirjutama C/C++-ga, oleksime saanud veel rohkem haavatavusi, puhkerikkumisi, race conditions ja muid hirmutavaid sõnu kui brubeck.

Oli ka argumente ka Rusti vastu. Ettevõttel ei olnud kogemusi projektide loomisel Rustis ning praegu me ka ei plaani seda oma peamises projektis kasutada. Seetõttu oli tõsiseid muresid, et midagi ei õnnestu, kuid otsustasime riskida ja proovida.

Aeg möödus...

Lõpuks, pärast mitmeid ebaõnnestunud katseid, oli esimene töötav versioon valmis. Mis välja tuli? Tuli just selline.

Iga sõlm saab oma mõõdikute komplekti ja kogub need enda juurde, kuid ei agrega mõõdikuid nende tüüpide jaoks, kus lõppagregatsiooni jaoks on vajalik nende täiskomplekt. Sõlmed on ühendatud mingi jaotatud lukustuse protokolliga, mis võimaldab valida nende seast selle ainsa (siin me nutame), mis on teeninud õiguse edastada mõõdikud Suurele. Praegu lahendab seda probleemi Consul, kuid tulevikus ulatuvad autori ambitsioonid oma tehnoloogia Rafti, kus see ainuõigust saanud on loomulikult konsensuse juht. Lisaks konsensusele saadavad sõlmed üsna sageli (vaikimisi üks kord sekundis) oma naabritele need eel-agreggeeritud mõõdikute osad, mida õnnestus selle sekundi jooksul koguda. Selgub, et skaleeritavus ja tõrketaluvus säilivad - iga sõlm hoiab endas endiselt täiskiht mõõdikuid, kuid mõõdikud saadetakse nüüd juba agreggeeritult, TCP kaudu ja binaarprotokolli kodeerimisega, seega kulud dubleerimisele on võrreldes UDP-ga märkimisväärselt vähenenud. Hoolimata üsna suurest sisenevate mõõdikute arvust, vajab kogumine väga vähe mälu ja veel vähem CPU-d. Meie hästi tihendatud mõõdikute jaoks on see vaid paar kümmet megabaiti andmeid. Täiendava boonuseks saame andmete liigsete üle kirjutamiste puudumise Graphites, nagu see oli burbeckiga.

UDP-paketid koos mõõdikute väärtustega jagunevad võrguseadmestikuna lihtsalt Round Robin'i meetodil. Loomulikult ei analüüsi võrgu riistvara pakettide sisu ning seega suudab see käsitleda palju rohkem kui 4M paketti sekundis, rääkimata mõõdikutest, millest see üldse midagi ei tea. Arvestades, et mõõdikud saabuvad mitte ükshaaval igas pakendis, ei prognoosi me siin jõudluse probleeme. Kui server peaks alla minema, tuvastab võrgu seade kiiresti (1-2 sekundi jooksul) selle olukorra ning eemaldab langemisega serveri rotatsioonist. Tulemuseks on see, et passiivseid (st mitte liidri) node saab sisse ja välja lülitada peaaegu märkamatult graafikute langemisi. Maksimum, mida me kaotame, on osa mõõdikuid, mis saabusid viimase sekundi jooksul. Äkiline kadumine/lülitamine/liidri vahetus joonistab endiselt väikese anomaalia (30-sekundiline intervall jääb endiselt desünkroniseerituks), kuid node'ide vaheline side aitab minimeerida ka need probleemid, näiteks saatmisega sünkroonimis paketid.

Natuke meie sisemisest seadistusest. Rakendus on muidugi mitme lõimega, kuid lõimed arhitektuur erineb sellest, mida on kasutatud brubeck'is. Lõimed brubeck'is on ühesugused — igaühe ülesanne on samaaegselt koguda teavet ja teha selle agregatsiooni. bioyino's on töö lõimed (workers) jagatud kaheks grupiks: ühed vastutavad võrgu eest ja teised vastutavad agregatsiooni eest. Selline jaotus võimaldab rakendust paindlikumalt juhtida sõltuvalt mõõdikute tüübist: seal, kus vajatakse intensiivset agregatsiooni, saab suurendada agregaatoreid, seal, kus on palju võrgu liiklust — suurendada võrgulõimede arvu. Hetkel töötame meie serverites 8 võrglõime ja 4 agregatsioonilõimega.

Agregeerimise (arvestava) osa töö on piisavalt igav. Võrgulõimede poolt täidetud puhvri jaotamine toimub arvestavatel lõimedel, kus andmed parseli ja agrigeeritakse. Kui palutakse mõõdikud, antakse need edasi teistele node'idele. Kõik see, sealhulgas andmete edastamine node'ide vahel ja töö Consul'iga, toimub asünkroonselt, töötab raamistiku peal. tokio.

Arendusplatside arendamise käigus esines palju probleeme võrguosas, mis oli vastutav mõõtmiste vastuvõtu eest. Peamine eesmärk võrguvoogude eraldamiseks eraldi üksusteks oli püüd vähendada aega, mida voog kulutab ei andmete lugemiseks soketist. Asünkroonseid UDP ja tavapärase recvmsg'i variandid langesid kiiresti välja: esimene kasutab liiga palju user-space CPU-d sündmuste töötlemiseks, teine — liiga palju konteksti vahetusi. Seetõttu kasutatakse praegu recvmmsg suurte puhverdate (ja puhvärd, härra ohvitserid, see pole mingisugune nalja asi!). Tavalise UDP toe säilitamine on jäänud koormamata juhtumitele, kus recvmmsg'i ei ole tingimata vaja. Multimeetserežiimis suudetakse saavutada põhiline eesmärk: enamik aega veedab võrguvoog OS-i järjekorra sorteerimisel — loeb andmeid soketist ja paneb need userspace'i puhvri, vaid harva vahetades, et anda täidetud puhver edasi agregaatoritele. Soketi järjekord praktiliselt ei kogune, visatud pakettide arv praktiliselt ei kasva.

Märkus

Vaikimisi sätetega on puhvri suurus seadistatud piisavalt suureks. Kui otsustate serverit ise proovida, võite kokku puutuda olukorraga, kus pärast väikese hulga mõõtmiste saatmist need ei jõua Graphite'i, jäädes võrguvoo puhvri. Väikese hulga mõõtmiste töötlemiseks tuleb seadistuses määrata bufsize ja task-queue-size väiksemate väärtustega.

Lõpetuseks — veidi graafikuid graafikute armastajatele.

Sisse tulevate mõõtmiste statistika igas serveris: üle 2 miljoni MPS.

Ühe node väljalülitamine ja sisse tulevate mõõtmiste ümberjaotamine.

Väljuvate mõõtmiste statistika: saadab alati ainult üks node — raidboss.

Iga node'i töö statistika, arvesse võttes süsteemi erinevate moodulite vigu.

Sisse tulevate mõõtmiste detailiseerimine (mõõtmiste nimed on varjatud).

Mida me plaanime kõigega edasi teha? Muidugi, kodeerida, bl…! Projekt oli algselt plaanitud avatud allikana ja jääb selliseks kogu oma elu jooksul. Lähitulevikus plaanime üleminekut oma versioonile Raft, peer-protokolli vahetamist ülekantavamaks, lisama sisemist statistikat, uusi mõõtmisetüüpe, parandama vigu ja teisi parandusi.

Loomulikult on kõik, kes soovivad projekti arendamisele kaasa aidata, teretulnud: looge PR-e, Issues, vastame ja täiustame võimaluste piires jne.

Nii nagu öeldakse, that’s all folks, ostke meie elevante!

Allikas: habr.com