Taigi jūs renkate metrikas. Kokie mes esame. Taip pat renkame rodiklius. Žinoma, reikalingos verslui. Šiandien kalbėsime apie pačią pirmąją mūsų stebėjimo sistemos nuorodą – su statsd suderinamą agregavimo serverį , kodėl tai parašėme ir kodėl atsisakėme brubecko.
Iš mūsų ankstesnių straipsnių (, ) galite sužinoti, kad iki kurio laiko rinkome ženklus naudodami . Jis parašytas C kalba. Kodo požiūriu jis paprastas kaip kištukas (tai svarbu, kai norite prisidėti) ir, svarbiausia, jis apdoroja mūsų 2 milijonų metrikų per sekundę (MPS) apimtis. be jokių problemų. Dokumentuose teigiama, kad parama 4 mln. MPS su žvaigždute. Tai reiškia, kad gausite nurodytą skaičių, jei teisingai sukonfigūravote tinklą „Linux“. (Nežinome, kiek MPS galite gauti, jei paliksite tinklą tokį, koks yra). Nepaisant šių pranašumų, turėjome keletą rimtų nusiskundimų dėl brubeko.
1 pretenzija. Projekto kūrėjas Github nustojo jį palaikyti: skelbti pataisas ir pataisymus, priimti mūsų ir (ne tik mūsų) PR. Pastaruosius kelis mėnesius (kažkur nuo 2018 m. vasario-kovo mėn.) veikla atsinaujino, bet prieš tai buvo beveik 2 metai visiškos ramybės. Be to, projektas vystomas , kuris gali tapti rimta kliūtimi diegti naujas funkcijas.
2 pretenzija. Skaičiavimų tikslumas. Iš viso Brubeck surenka 65536 vertes. Mūsų atveju, kai kurioms metrikoms agregavimo laikotarpiu (30 sekundžių) gali būti gauta daug daugiau verčių (1 527 392 piko metu). Dėl šio atrankos didžiausios ir mažiausios vertės atrodo nenaudingos. Pavyzdžiui, taip:
Kaip tai buvo
Kaip turėjo būti
Dėl tos pačios priežasties sumos paprastai apskaičiuojamos neteisingai. Pridėkite čia klaidą su 32 bitų plūduriuojančiu perpildymu, kuris paprastai siunčia serverį į segfault, kai gauna iš pažiūros nekaltą metriką, ir viskas tampa puiku. Beje, klaida nebuvo ištaisyta.
Ir, pagaliau, Reikalauti X. Rašymo metu esame pasirengę jį pristatyti visoms 14 daugiau ar mažiau veikiančių statsd diegimų, kuriuos mums pavyko rasti. Įsivaizduokime, kad kažkokia viena infrastruktūra taip išaugo, kad priimti 4 mln. MPS nebeužtenka. Arba net jei jis dar neišaugo, bet metrikos jums jau tokios svarbios, kad net trumpi, 2-3 minučių kritimai diagramose jau gali tapti kritiniais ir sukelti neįveikiamos depresijos priepuolius tarp vadovų. Kadangi depresijos gydymas yra nedėkingas darbas, reikalingi techniniai sprendimai.
Pirma, tolerancija gedimams, kad staigi problema serveryje nesukeltų psichiatrinės zombių apokalipsės biure. Antra, mastelio keitimas, kad būtų galima priimti daugiau nei 4 milijonus MPS, nesigilinant į Linux tinklo krūvą ir ramiai augant „į plotį“ iki reikiamo dydžio.
Kadangi turėjome vietos mastelio keitimui, nusprendėme pradėti nuo tolerancijos gedimams. "Apie! Gedimų tolerancija! Tai paprasta, mes galime tai padaryti“, – pagalvojome ir paleidome 2 serverius, kiekviename iškeldami brubeck kopiją. Norėdami tai padaryti, turėjome nukopijuoti srautą su metrika į abu serverius ir net parašyti . Su tuo išsprendėme atsparumo gedimams problemą, bet... nelabai. Iš pradžių viskas atrodė puiku: kiekvienas brubekas renka savo agregavimo versiją, kas 30 sekundžių įrašo duomenis į Graphite, perrašydamas seną intervalą (tai daroma grafito pusėje). Jei vienas serveris staiga sugenda, visada turime antrą su savo suvestinių duomenų kopija. Tačiau čia yra problema: jei serveris sugenda, diagramose pasirodo „pjūklas“. Taip yra dėl to, kad brubecko 30 sekundžių intervalai nėra sinchronizuojami, o avarijos metu vienas iš jų neperrašomas. Kai paleidžiamas antrasis serveris, atsitinka tas pats. Gana pakenčiama, bet noriu geriau! Mastelio keitimo problema taip pat neišnyko. Visos metrikos vis tiek „skraido“ į vieną serverį, todėl, priklausomai nuo tinklo lygio, apsiribojame iki 2–4 milijonų MPS.
Jei šiek tiek pagalvosite apie problemą ir tuo pačiu metu kasate sniegą kastuvu, tada gali kilti tokia akivaizdi mintis: jums reikia statsd, kuris gali veikti paskirstytu režimu. Tai yra toks, kuris įgyvendina laiko ir metrikos mazgų sinchronizavimą. „Žinoma, toks sprendimas tikriausiai jau yra“, – pasakėme ir nuėjome į „Google“. Ir jie nieko nerado. Peržiūrėję įvairių statistinių duomenų ( 11.12.2017 m. gruodžio XNUMX d.), visiškai nieko neradome. Matyt, nei šių sprendimų kūrėjai, nei vartotojai dar nesusidūrė su TIEK metrikų, kitaip tikrai ką nors sugalvotų.
Ir tada prisiminėme apie „žaislą“ statsd - bioyino, kuris buvo parašytas „Just for Fun“ hakatone (projekto pavadinimą sukūrė scenarijus prieš hakatono pradžią) ir supratome, kad mums skubiai reikia savo statsd. Kam?
- nes pasaulyje yra per mažai statsd klonų,
- nes galima užtikrinti norimą arba artimą norimam gedimų tolerancijai ir mastelio keitimui (įskaitant suvestinės metrikos sinchronizavimą tarp serverių ir siuntimo konfliktų sprendimą),
- nes metriką galima apskaičiuoti tiksliau nei tai daro Brubeck,
- nes galite patys rinkti detalesnę statistiką, kurios brubekas mums praktiškai nepateikė,
- nes turėjau progą suprogramuoti savo hyperperformance distributed scale lab aplikaciją, kuri visiškai nepakartos kito panašaus hyperfor architektūros... na ir viskas.
Ant ka rasyti? Žinoma, Rūdyje. Kodėl?
- nes jau buvo sprendimo prototipas,
- nes straipsnio autorius tuo metu jau pažinojo Rustą ir norėjo ką nors jame parašyti gamybai su galimybe įdėti jį į atvirąjį kodą,
- nes kalbos su GC mums netinka dėl gaunamo srauto pobūdžio (beveik realiu laiku), o GC pauzės yra praktiškai nepriimtinos,
- nes jums reikia maksimalaus našumo, palyginamo su C
- nes Rust suteikia mums bebaimį lygiagretumą, ir jei būtume pradėję tai rašyti C/C++, būtume atradę dar daugiau pažeidžiamumų, buferių perpildymo, lenktynių sąlygų ir kitų baisių žodžių nei brubeck.
Taip pat buvo argumentų prieš Rustą. Įmonė neturėjo patirties kuriant projektus Ruste, o dabar taip pat neplanuojame jos panaudoti pagrindiniame projekte. Todėl buvo rimtų nuogąstavimų, kad nieko neišeis, bet nusprendėme surizikuoti ir pabandėme.
Praėjęs laikas...
Galiausiai, po kelių nesėkmingų bandymų, pirmoji darbinė versija buvo paruošta. Kas nutiko? Taip atsitiko.
Kiekvienas mazgas gauna savo metrikų rinkinį ir jas kaupia, o metrikos nekaupia tiems tipams, kai galutiniam agregavimui reikalingas visas jų rinkinys. Mazgai yra sujungti vienas su kitu kažkokiu paskirstytu užrakto protokolu, kuris leidžia iš jų pasirinkti vienintelį (čia mes verkėme), kuris vertas siųsti metrikas Didžiajam. Šią problemą šiuo metu sprendžia , tačiau ateityje autoriaus ambicijos tęsiasi iki Plaustas, kur pats vertas, žinoma, bus sutarimo lyderio mazgas. Be sutarimo, mazgai gana dažnai (pagal numatytuosius nustatymus kartą per sekundę) siunčia savo kaimynams tas iš anksto sukauptos metrikos dalis, kurias jiems pavyko surinkti per tą sekundę. Pasirodo, mastelio keitimas ir gedimų tolerancija išsaugoma – kiekviename mazge vis dar yra visas metrikų rinkinys, tačiau metrika siunčiama jau apibendrinta, per TCP ir užkoduota į dvejetainį protokolą, todėl dubliavimo kaštai gerokai sumažėja, lyginant su UDP. Nepaisant gana didelio gaunamų metrikų skaičiaus, kaupimui reikia labai mažai atminties ir dar mažiau procesoriaus. Mūsų labai suspaudžiamiems mertikai tai yra tik kelios dešimtys megabaitų duomenų. Kaip papildoma premija, mes negauname nereikalingų duomenų perrašymų naudojant „Graphite“, kaip buvo Burbeck atveju.
UDP paketai su metrika yra nesubalansuoti tarp tinklo įrangos mazgų per paprastą Round Robin. Žinoma, tinklo aparatinė įranga neanalizuoja paketų turinio ir todėl gali ištraukti daug daugiau nei 4M paketų per sekundę, jau nekalbant apie metrikas, apie kurias ji visiškai nieko nežino. Jei atsižvelgsime į tai, kad kiekviename pakete metrikos neatsiranda po vieną, tai šioje vietoje nenumatome našumo problemų. Jei serveris sugenda, tinklo įrenginys greitai (per 1-2 sekundes) nustato šį faktą ir pašalina sudužusį serverį iš sukimosi. Dėl to pasyvūs (t. y. ne pirmaujantys) mazgai gali būti įjungti ir išjungti praktiškai nepastebėjus diagramų nuosmukių. Daugiausia, ką prarandame, yra dalis paskutinę sekundę gautų metrikų. Staigus lyderio praradimas / išjungimas / perjungimas vis tiek sukurs nedidelę anomaliją (30 sekundžių intervalas vis dar nesinchronizuojamas), tačiau jei tarp mazgų yra ryšys, šias problemas galima sumažinti, pavyzdžiui, siunčiant sinchronizavimo paketus. .
Šiek tiek apie vidinę struktūrą. Taikymas, žinoma, yra daugiasriegis, tačiau sriegimo architektūra skiriasi nuo naudojamos brubeck. Gijos brubeke yra vienodos – kiekviena iš jų atsakinga ir už informacijos rinkimą, ir už kaupimą. Bioyino darbuotojai skirstomi į dvi grupes: atsakingus už tinklą ir atsakingus už agregavimą. Šis skirstymas leidžia lanksčiau valdyti aplikaciją priklausomai nuo metrikų tipo: kur reikalingas intensyvus agregavimas, galima pridėti agregatorius, kur didelis tinklo srautas, galima pridėti tinklo srautų skaičių. Šiuo metu savo serveriuose dirbame 8 tinklo ir 4 agregavimo srautuose.
Skaičiavimo (atsakingo už sumavimą) dalis gana nuobodi. Tinklo srautų užpildyti buferiai paskirstomi tarp skaičiuojančių srautų, kur jie vėliau analizuojami ir sujungiami. Pagal pageidavimą pateikiami metrikai siuntimui į kitus mazgus. Visa tai, įskaitant duomenų siuntimą tarp mazgų ir darbą su Consul, atliekama asinchroniškai, veikiant sistemoje .
Daug daugiau problemų kūrimo metu sukėlė tinklo dalis, atsakinga už metrikų priėmimą. Pagrindinis tinklo srautų atskyrimo į atskirus objektus tikslas buvo siekis sumažinti srauto praleidžiamą laiką ne nuskaityti duomenis iš lizdo. Greitai išnyko parinktys, naudojant asinchroninį UDP ir įprastą recvmsg: pirmasis sunaudoja per daug vartotojo vietos procesoriaus įvykiams apdoroti, antrasis reikalauja per daug konteksto jungiklių. Todėl dabar jis naudojamas su dideliais buferiais (o buferiai, ponai pareigūnai, jums nieko!). Įprasto UDP palaikymas yra skirtas lengviems atvejams, kai recvmmsg nereikia. Daugiapranešimų režimu galima pasiekti pagrindinį dalyką: didžiąją laiko dalį tinklo gija iškrauna OS eilę – nuskaito duomenis iš lizdo ir perkelia juos į vartotojo erdvės buferį, tik retkarčiais persijungia į užpildyto buferio suteikimą agregatoriai. Eilė lizde praktiškai nesikaupia, išmestų paketų skaičius praktiškai neauga.
Atkreipti dėmesį
Pagal numatytuosius nustatymus buferio dydis nustatytas gana didelis. Jei staiga nuspręsite išbandyti serverį patys, galite susidurti su tuo, kad išsiuntus nedidelį skaičių metrikų, jie nepateks į Graphite, likdami tinklo srauto buferyje. Norėdami dirbti su nedideliu skaičiumi metrikų, konfigūracijose turite nustatyti bufsize ir užduočių eilės dydį į mažesnes reikšmes.
Galiausiai keletas diagramų, skirtų diagramų mėgėjams.
Statistika apie kiekvieno serverio gaunamų metrikų skaičių: daugiau nei 2 milijonai MPS.
Vieno iš mazgų išjungimas ir gaunamos metrikos perskirstymas.
Išeinančių metrikų statistika: visada siunčia tik vienas mazgas – reido bosas.
Kiekvieno mazgo veikimo statistika, atsižvelgiant į įvairių sistemos modulių klaidas.
Gaunamų metrikų detalizavimas (metrikos pavadinimai paslėpti).
Ką su visu tuo planuojame daryti toliau? Žinoma, parašyk kodą, po velnių...! Iš pradžių buvo planuota, kad projektas bus atvirojo kodo ir toks išliks visą savo gyvavimo laiką. Artimiausiuose mūsų planuose yra perėjimas prie savo „Raft“ versijos, tarpusavio protokolo keitimas į nešiojamesnį, papildomos vidinės statistikos įvedimas, naujų tipų metrikos, klaidų pataisymai ir kiti patobulinimai.
Žinoma, visi laukiami padėti kuriant projektą: kurkite PR, Issues, esant galimybei atsakysime, tobulinsime ir pan.
Tai pasakius, žmonės, pirkite mūsų dramblius!
Šaltinis: www.habr.com