Bioyino — jaotatud, skaleeritav mõõdikute koondaja

Nii et, te kogute mõõdikute andmeid. Nagu ka meie. Me kogume samuti mõõdikute andmeid. Loomulikult on need äritegevuseks vajalikud. Täna räägime meie monitooringu süsteemi esimesest komponendist — statsd-ühilduvast agregatsiooniserverist. bioyino, miks me selle kirjutasime ja miks loobusime brubeckist.

Eelmistest artiklitest (1, 2) saate teada, et mõnda aega kogusime meie märgid kasutades brubeck. See on kirjutatud C-s. Koodi seisukohalt — lihtne nagu kork (mis on oluline, kui soovite sellele panustada) ja mis kõige tähtsam, suudab see ilma eriliste probleemideta hakkama saada meie 2 miljoni mõõdikuga sekundis (MPS) tipptasemel. Dokumentatsioon väidab, et see toetab 4 miljonit MPS, kuid ainult tingimusel. See tähendab, et selle arvu saate, kui seadistate võrgu õigesti Linuxis. (Kui palju MPS võime saada, kui võrku niisama jätta, seda me ei tea). Vaatamata nendele eelistustele oli meil brubecki suhtes mitmeid tõsiseid pretensioone.

Pretensioon 1. Github — projekti arendaja — on lõpetanud selle toetamise: ei avalda patše ega parandusi, ei võta vastu meie ja (mitte ainult meie) PR-e. Viimase paari kuu jooksul (umbes alates 2018. aasta veebruarist või märtsist) on aktiivsus taas alanud, kuid enne seda oli peaaegu 2 aastat täielikku vaikust. Lisaks on projekt arendatud Gihubi sisemiste vajaduste jaoks, mis võib osutuda tõsiseks takistuseks uute funktsioonide juurutamisel.

Pretensioon 2. Arvutuste täpsus. Brubeck kogub agregeerimiseks vaid 65536 väärtust. Meie juhtumil võib mõnede mõõdikute puhul aggregeerimise (30 sek) ajal tulla palju rohkem väärtusi (tipptasemel 1 527 392). Tulemuseks on, et maksimumide ja miinimumide väärtused tunduvad kasutud. Näiteks, nagu see:

Kuidas oli

Nii pidi olema

Sama põhjuse tõttu arvutatakse summad kokku üldse vale. Lisage siia 32-bitise float ülevoolu bug, mis saadab serveri segfault'i, kui see saab osaliselt süütu mõõdiku, ja kõik muutub suurepäraseks. See bug, muide, pole ikka veel parandatud.

Ja lõpuks, Pretensioon X. Artikli kirjutamise hetkeks oleme valmis esitama selle kõigile 14 enam-vähem töötavale statsd rakendusele, mille suutsime leida. Kujutame ette, et mingi eraldi infrastruktuur on kasvanud nii palju, et 4 miljoni MPS vastuvõtmine on juba ebapiisav. Või oletame, et see pole veel kasvanud, kuid mõõdikud on teie jaoks nii olulised, et isegi lühikesed, 2-3 minutilised katkestused graafikutel võivad muutuda kriitiliseks ja kutsub esile halbu meeleolusid juhtide seas. Kuna depressiooni ravimine on tänamatu asi, on vajalikud tehnilised lahendused.

Esiteks, talitluses ettenähtud usaldusväärsus, et äkiline probleem serveris ei tekitaks kontoris psühhiaatrilist zombi apokalüpsist. Teiseks, kaalutavus, et oleks võimalus vastu võtta rohkem kui 4 miljonit MPS, ilma et peaks sügavale Linuxi võrgu lahti kaevama ja rahulikult „laiendada“ vajalike mõõtmete saavutamiseks.

Kuna meil oli laienemise osas varu, otsustasime alustada usaldusväärsusest. "Oi! Usaldusväärsus! See on lihtne, me oskame seda," mõtlesime ja tõstsime üles 2 serverit, käivitades igas brubecki koopia. Selleks pidime kopeerima mõõdikute liiklus mõlemasse serverisse ja isegi kirjutama selle jaoks väikese utiliidi. Usaldusväärsuse probleem lahendati, kuid… mitte väga hästi. Alguses oli kõik nagu hästi: iga brubeck kogub oma aggregeerimise variandi, kirjutab andmed Graphite'i iga 30 sekundi järel, kirjutades üle vana intervalli (see toimub Graphite'i pool). Kui üks server siiski ebaõnnestub, on meil alati teine, millel on oma koopia aggregeeritud andmetest. Kuid probleem on see: kui server ebaõnnestub, ilmuvad graafikud "saagimise" märgid. See on seotud sellega, et brubecki 30-sekundi intervallid ei ole sünkroniseeritud ja ebaõnnestumise hetkest ei kirjutata ükski neist üle. Teise serveri käivitamise hetkel toimub sama. Täiesti talutav, kuid võiks parem olla! Kaaluõiguslikkuse probleem ei ole samuti kuhugi kadunud. Kõik mõõdikud lendavad endiselt ühele serverile, seetõttu oleme piiratud sama 2-4 miljoni MPS-ga sõltuvalt võrgu võimekusest.

Kui veidi probleemi üle mõelda ja samal ajal lund labidaga kaevata, võib pähe tulla selline ilmne idee: on vajalik statsd, mis suudab töötada jaotatud režiimis. See tähendab, et sellise, kus on rakendatud sünkroniseerimine sõlmede vahel aja ja mõõdikute osas. "Loomulikult on selline lahendus kindlasti olemas," ütlesime ja hakkasime guugeldama… ja ei leidnud midagi. Uurides erinevate statsd dokumentatsiooni (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 seisuga, me ei leidnud sisuliselt midagi. Tundub, et ei arendajad ega kasutajad nendel lahendustel KOHUTAVALT suure hulga mõõdikute osas sellist asja kokku puutunud ei ole, muidu oleks nad kindlasti midagi välja mõelnud.

Ja siis meenutasime „mänguasi” statsd - bioyino, mille kirjutasime hackathonil lihtsalt lõbu pärast (projekti nimi genereeriti enne hackathonit skripti abil) ning mõistsime, et me vajame kiiresti omaenda statsd-d. Miks?

• sest maailmas on liiga vähe statsd kloone,
• kuna on võimalik tagada soovitud või soovitavale lähedane talitlushäired ja skaleeritavus (sealhulgas sünkroniseerida kokku kogutud mõõdikud serverite vahel ja lahendada konfliktid saatmise ajal),
• sest on võimalik mõõdikud täpsemalt lugeda kui seda teeb brubeck,
• sest on võimalik koguda ise rohkem üksikasjalikku statistikat, mida brubeck meile praktiliselt ei pakkunud,
• sest tuli võimalus programmeerida omaenda hüperperformantne ja jaotatud rakendus, mis ei kopeeri täielikult teise sarnase hüperperformantsi arhitektuuri.

Millest kirjutada? Loomulikult Rustis. Miks?

• sest prototüüp lahendus oli juba olemas,
• sest artikli autor teadis siis juba Rusti ja tahtis midagi sellel kirjutada tootmisvalmis variandina, mille ta saaks avalikuks teha,
• sest jäätmed juhtimisprotsessidele ei sobi, arvestades saadud liiklust (peaaegu reaalajas) ja jäätmete pausid on praktiliselt vastuvõetamatud,
• sest on vajalik maksimaalne jõudlus, mis on võrdne C-ga
• sest Rust pakub meile kartmatut ühekordset töötlemist, ja kui me oleksime hakanud seda kirjutama C/C++, oleksime saanud rohkem haavatavusi, puhverdusülevalt ja võidulepestust kui brubeckis.

Oli ka argument Rusti vastu. Firmal polnud Rusti projektide loomise kogemust ja praegu ei plaanita seda ka põhiprojektis kasutada. Seega olid tõsised mured, et miski ei toimi, kuid otsustasime riskida ja proovisime.

Aeg kulges…

Lõpuks, pärast mitmeid ebaõnnestunud katseid, oli esimene töötav versioon valmis. Mida saime? Saime sellise.

Iga nod saab oma mõõdikute kogumi ja kogub neid enda juurde, kuid ei kogune mõõdikuid neid tüüpe, kus lõpliku kogumise jaoks on vaja nende täis kogumi. Nod on omavahel ühendatud mõne jaotatud lukustamise protokolliga, mis võimaldab valida neist selle ainulaadse (siin me nutame), kes on vääriline saatma mõõdikud Suurele. Praegu lahendatakse see küsimus vahendite kaudu, Consul, kuid tulevikus autori ambitsioonid ulatuvad tohutusse oma rakenduste Rafti, kus see vääriline on kindlasti konsensuse liider node. Lisaks konsensusele saadavad nod sageli (vaikimisi üks kord sekundis) oma naabritele neid eelnevalt kogutud mõõdikute osi, mis õnnestus selle sekundi jooksul koguda. See tähendab, et skaleeritavus ja talitlushäired säilivad - iga nod hoiab siiski täieliku kogumi mõõdikute, kuid mõõdikud saadetakse juba kogutud, TCP ja binaarprotokolli kodeerimise kaudu, mistõttu kulud dubleerimise suunas võrreldes UDP-d vähenevad. Hoolimata üsna suurest sisenevate mõõdikute hulgast, nõuab kogumine väga vähe mälu ja veel vähem CPU-d. Meie hästi kokkusurutud mõõdikute puhul on see vaid paar kümmend megabaiti andmeid. Täiendavaks kasuks on tõhusate andmete üle kirjutamise puudumine Graphites, nagu see oli burbecki puhul.

UDP paketid koos mõõdikutega jaotatakse nodesse võrguvarustuse kaudu lihtsa Round Robini teel. Loomulikult ei saa võrgu riistvara pakettide sisu, seega võib see leida palju rohkem kui 4M paketti sekundis, rääkimata mõõdikutest, millest ta midagi ei tea. Kui arvestada, et mõõdikud ei tule mitte üheski pakendis, siis ei prognoosime tõhususe probleeme sel hetkel. Serveri kokkuvarisemise korral tuvastab võrgu seade tõhusalt (1-2 sekundi jooksul) selle fakti ja eemaldab kukkunud serveri rotatsioonist. Selle tulemuseks on, et passiivseid (st mitte liidri) nodi saab sisse ja välja lülitada praktiliselt märkamatult. Maksimaalne, mida kaotame, on osa mõõdikuid, mis on saabunud viimase sekundi jooksul. Üksik kadumine/ väljalülitamine/ liidri vahetamine joonistab siiski väikese anomaalia (30-sekundiline intervall jääb endiselt sünkroniseerimata), kuid nodide vahelise side olemasolul võime need probleemid minimeerida, näiteks sünkroniseerivate pakettide saatmise teel.

Veidi sisemistest struktuuridest. Rakendus on loomulikult mitmeotstarbeline, kuid voogude arhitektuur erineb brubeckist. Brubecki vood on ühesugused — igaühe ülesanne on samaaegselt nii teabe kogumine kui ka aggregeerimine. Bioyino töövood (workers) on jagatud kaheks rühmaks: võrgu- ja aggregeerimisvood. Selline jaotamine võimaldab rakendust paindlikumalt hallata sõltuvalt mõõdikute tüübist: seal, kus on nõutav intensiivne aggregeerimine, saab lisada aggregeerijaid, seal, kus on palju võrgu liiklust — suurendada võrguvoogude arvu. Praegu töötame meie serverites 8 võrku ja 4 aggregeerimisvoo.

Aggregeerimise eest vastutav osa on piisavalt igav. Võrguvoogudest täidetud puhvrid jaotatakse aggregeerimise töötlemise voogude vahel, kus need hiljem analüüsitakse ja kogutakse. Nõutud mõõdikud saadetakse edastamiseks teistele nodidele. Kõik see, sealhulgas andmete edastamine nodide vahel ja töö Consuliga, toimub asünkroonselt, tuginedes raamistikele tokio.

Arendamise ajal tekitas rohkem probleeme võrguosa, mis vastutab mõõdikute vastuvõtmise eest. Peamine eesmärk võrguvoogude eraldamisel eraldi üksusteks oli aja vähendamine, mida voog kulutab ei andmete lugemiseks soketist. Variandid asünkroonse UDP ja tavalise recvmsg kasutamiseks langesid kiiresti välja: esimene kulutab liiga palju user-space CPU-d sündmuste töötlemiseks, teine — liiga palju konteksti vahetusi. Seetõttu kasutatakse praegu recvmmsg suuremate puhvritega (ja see, daamid ja härrad, ei ole sugugi tühine asi!). Tavalise UDP toimetamine on säilinud mittekoormatud olukordade jaoks, kus recvmmsg-i pole vaja. Multimessage režiimis saavutatakse peamine eesmärk: enamik võrgu voost kulutab aega OS-i järjekorra puhastamisel — loetakse andmeid soketist ja liigitatakse need userspace-puhvrisse, vaid harva vahetatakse aggregeerijatele edastatud täidetud puhvrit. Soketi järjekord ei kogune praktiliselt, ära visatud pakettide arv ei suurene.

Märkus

Vaikesätetes on puhver seatud piisavalt suureks. Kui otsustate serverit iseseisvalt proovida, võite sattuda olukorda, kus pärast väikese arvu mõõdikute saatmist ei jõua need Graphite'i, jäädes võrgu voolu puhvris. Väikese arvu mõõdikute jaoks tuleb seadistustes määrata bufsize ja task-queue-size väärtused väiksemaks.

Lõpuks — mõned grafikud graafikuhuvilistele.

Statistika saabuvate mõõdikute arvu kohta iga serveri kohta: üle 2 miljoni MPS.

Ühe nodi väljalülitamine ja saabuvate mõõdikute ümberjaotamine.

Statistika väljuvate mõõdikute kohta: ainult üks nodule saadab — raidend boss.

Statistika iga nodi töö kohta arvestades vigu erinevates süsteemi moodulites.

Sissetulevate mõõdikute detailimine (mõõdikute nimed on varjatud).

Mida plaanime selle kõigega edasi teha? Loomulikult kirjutame koodi, bl...! Projekt oli algselt planeeritud open-source'ina ja jääb selliseks kogu oma elu. Lähitulevikus plaanime üleminekut enda versioonile Raft, peer-protokolli vahetamist üha ülekantavamaks, täiendava sisemise statistika lisamist, uute mõõdikute liikide loomist, vigade parandamist ja muid täiustusi.

Loomulikult oodatakse kõiki, kes soovivad projekti arendamisel aidata: looge PR, Issues, ja vastuste võimalusel teeme koostööd jne.

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

Allikas: habr.com