Beraz, neurriak biltzen dituzu. Garen bezala. Neurriak ere biltzen ditugu. Jakina, negozioetarako beharrezkoa. Gaur gure monitorizazio sistemaren lehen estekari buruz hitz egingo dugu: statsd-ekin bateragarria den agregazio zerbitzaria , zergatik idatzi genuen eta zergatik abandonatu genuen brubeck.
Gure aurreko artikuluetatik (, ) jakin dezakezu noizbait arte markak biltzen genituen erabiliz . C-n idatzita dago. Kodearen ikuspuntutik, entxufe bat bezain erraza da (hau garrantzitsua da ekarpena egin nahi duzunean) eta, batez ere, 2 milioi metriko segundoko (MPS) gure bolumenak kudeatzen ditu gailurrean. arazorik gabe. Dokumentazioan 4 milioi MPS onartzen da izartxo batekin. Horrek esan nahi du adierazitako zifra lortuko duzula sarea Linux-en behar bezala konfiguratzen baduzu. (Ez dakigu zenbat MPS lor ditzakezun sarea bere horretan uzten baduzu). Abantaila hauek izan arren, hainbat kexa larri izan genituen brubeckaren inguruan.
Erreklamazioa 1. Github-ek, proiektuaren garatzaileak, laguntza emateari utzi zion: adabakiak eta konponketak argitaratzeari, gurea eta (ez bakarrik gurea) PR onartuz. Azken hilabeteotan (2018ko otsailetik martxotik nonbait), jarduera berriro ekin da, baina aurretik ia 2 urteko lasaitasun osoa egon zen. Horrez gain, proiektua garatzen ari da , funtzio berriak sartzeko oztopo larria bihur daitekeena.
Erreklamazioa 2. Kalkuluen zehaztasuna. Brubeck-ek guztira 65536 balio biltzen ditu agregaziorako. Gure kasuan, metrika batzuentzat, agregazio-aldian (30 segundo), askoz balio gehiago iritsi daitezke (gailurrean 1). Laginketa honen ondorioz, balio maximoak eta minimoak alferrikakoak dirudite. Adibidez, honela:
zen bezala
Nola izan behar zuen
Arrazoi beragatik, oro har, oker kalkulatzen dira zenbatekoak. Gehitu hemen 32 biteko flotatzaile gainezka duen akats bat, eta horrek orokorrean zerbitzaria segfault-era bidaltzen du itxuraz errugabea den metrika jasotzean, eta dena bikain bihurtzen da. Akatsa, bide batez, ez da konpondu.
Eta, azkenik, X erreklamazioa. Idazteko unean, prest gaude aurkitu ahal izan ditugun 14 estatistika-inplementazio gutxi-asko funtzionatzen dutenei aurkezteko. Imajina dezagun azpiegitura bakar batzuk hainbeste hazi direla non 4 milioi MPS onartzea nahikoa ez dela. Edo oraindik hazi ez bada ere, baina neurketak dagoeneko oso garrantzitsuak dira zuretzat, zerrendetan 2-3 minutuko jaitsiera laburrak ere kritiko bihur daitezkeela eta kudeatzaileen artean depresio gaindiezinak eragin ditzakete. Depresioa tratatzea esker oneko zeregina denez, irtenbide teknikoak behar dira.
Lehenik eta behin, akatsen tolerantzia, zerbitzarian bat-bateko arazo batek ez dezan bulegoan zonbi apokalipsi psikiatrikorik eragin. Bigarrenik, 4 milioi MPS baino gehiago onartu ahal izateko eskalatzea, Linux sareko pilan sakondu gabe eta behar den tamainara "zabalean" lasai hazten.
Eskalatzeko tokia geneukanez, akatsen tolerantziatik hastea erabaki genuen. " BURUZ! Akatsen tolerantzia! Erraza da, egin dezakeguΒ», pentsatu genuen eta 2 zerbitzari abiarazi genituen, bakoitzari brubeck kopia bat altxatuz. Horretarako, bi zerbitzarietan metrikekin trafikoa kopiatu behar izan dugu eta baita horretarako idatzi ere . Honekin akatsen tolerantziaren arazoa konpondu genuen, baina... ez oso ondo. Hasieran dena bikaina zirudien: brubeck bakoitzak bere agregazioaren bertsioa biltzen du, 30 segundoan behin idazten ditu datuak Graphite-n, tarte zaharra gainidatziz (Graphite aldean egiten da). Zerbitzari batek bat-batean huts egiten badu, beti dugu bigarren bat datu agregatuen kopia propioa duena. Baina hona hemen arazoa: zerbitzariak huts egiten badu, "zerra" bat agertzen da grafikoetan. Hau da, Brubeck-en 30 segundoko tarteak ez daudelako sinkronizatuta, eta istripu bat gertatzen den unean horietako bat ez da gainidazten. Bigarren zerbitzaria hasten denean, gauza bera gertatzen da. Nahiko jasangarria, baina hobe nahi dut! Eskalagarritasunaren arazoa ere ez da desagertu. Neurri guztiek zerbitzari bakar batera "hegan egiten dute" oraindik, eta, beraz, 2-4 milioi MPS berdinetara mugatzen gara, sare mailaren arabera.
Arazoari buruz pixka bat pentsatzen baduzu eta, aldi berean, pala batekin elurra ateratzen baduzu, ondoko ideia argia etor daiteke burura: modu banatuan funtziona dezakeen statsd bat behar duzu. Hau da, nodoen arteko sinkronizazioa denboran eta metriketan ezartzen duena. "Noski, ziurrenik dagoeneko existitzen da horrelako irtenbide bat", esan genuen eta Google-ra joan ginen... Eta ez zuten ezer aurkitu. Estatistika desberdinetarako dokumentazioa aztertu ondoren ( 11.12.2017ko abenduaren XNUMXtik aurrera), ez genuen ezer aurkitu. Antza denez, ez garatzaileek ez erabiltzaileek ez dute oraindik HAINBAT neurketa topatu, bestela, zalantzarik gabe, zerbait asmatuko lukete.
Eta gero, Just for Fun hackathon-en idatzitako "jostailu" estatistikaz - bioyinoz gogoratu ginen (proiektuaren izena hackatona hasi baino lehen sortu zuen gidoiak) eta gure estatistikak premiazkoan behar genituela konturatu ginen. Zertarako?
- munduan statsd klon gutxiegi daudelako,
- nahi den akatsen tolerantzia eta eskalagarritasuna eskaintzea posible baita (zerbitzarien arteko metrika agregatuak sinkronizatzea eta gatazkak bidaltzeko arazoa konpontzea barne),
- Brubeck-ek baino zehatzago kalkulatzea posible baita neurriak,
- izan ere, zuk zeuk bildu ditzakezu estatistika zehatzagoak, Brubeck-ek ia eman ez dizkigunak,
- izan ere, nire hiperperformance banatutako eskala laborategiko aplikazioa programatzeko aukera izan nuen, antzeko beste hipererredikzio baten arkitektura guztiz errepikatuko ez duena... tira, hori da.
Zertan idatzi? Noski, Rust-en. Zergatik?
- jada bazegoen irtenbide prototipo bat,
- artikuluaren egileak garai hartan jada ezagutzen zuen Rust eta irrikitan zegoelako zerbait idazteko ekoizpenerako, kode irekian jartzeko aukerarekin,
- izan ere, GC duten hizkuntzak ez zaizkigu egokiak jasotako trafikoaren izaeragatik (ia denbora errealean) eta GC etenaldiak ia onartezinak dira,
- C-ren pareko errendimendu maximoa behar duzulako
- izan ere, Rustek beldurrik gabeko konkurrentzia eskaintzen digu, eta C/C++-n idazten hasi bagina, are ahultasun gehiago, buffer gainezka, lasterketa-baldintzak eta brubeck baino beste hitz beldurgarri batzuk bilduko genituzke.
Herdoilaren aurkako eztabaida ere egon zen. Enpresak ez zuen Rust-en proiektuak sortzen esperientziarik, eta orain ere ez dugu proiektu nagusian erabiltzeko asmorik. Hori dela eta, ezerk aterako ez ote zen beldur handia zegoen, baina arriskua hartzea erabaki genuen eta saiatu ginen.
Denbora pasa zen...
Azkenik, huts egindako hainbat saiakeraren ondoren, lehen lan-bertsioa prest zegoen. Zer gertatu da? Hau da gertatu dena.
Nodo bakoitzak bere metrika-multzoa jasotzen du eta metatzen ditu, eta ez ditu metrikarik agregatzen beren multzo osoa azken agregaziorako beharrezkoa den mota horietarako. Nodoak elkarren artean konektatzen dira banatutako blokeo-protokolo baten bidez, hautatzeko aukera ematen duena Handiari metrikak bidaltzea merezi duen bakarra (hemen negar egin genuen). Arazo hau konpontzen ari da , baina etorkizunean egilearen asmoak zabaltzen dira Raft, non duinena, noski, adostasun lider nodoa izango da. Adostasunaz gain, nodoek sarritan (segundo behin lehenespenez) auzokideei bidaltzen dizkiete segundo horretan biltzea lortu duten aurre-agregatutako metrika zati horiek. Ematen du eskalatzea eta akatsen tolerantzia mantentzen direla - nodo bakoitzak neurketa multzo osoa dauka oraindik, baina neurketak dagoeneko batuta bidaltzen dira, TCP bidez eta protokolo bitar batean kodetuta, beraz, bikoizketa kostuak nabarmen murrizten dira UDPrekin alderatuta. Sarrerako metrika kopuru nahiko handia izan arren, metaketak oso memoria gutxi behar du eta are CPU gutxiago. Gure mertiko oso konprimigarrientzat, hamarnaka megabyte gutxiko datu baino ez dira. Hobari gehigarri gisa, ez dugu alferrikako datu berridazketarik lortzen Grafitoan, burbeck-en kasuan bezala.
Neurridun UDP paketeak sareko ekipoetako nodoen artean desorekatuta daude Round Robin sinple baten bidez. Jakina, sareko hardwareak ez du paketeen edukia analizatzen eta, beraz, segundoko 4M pakete baino askoz gehiago atera ditzake, ezer ez dakien metrikak aipatu gabe. Kontuan hartzen badugu neurriak ez direla pakete bakoitzean banan-banan etortzen, orduan ez dugu errendimendu-arazorik aurreikusten leku honetan. Zerbitzari bat huts egiten bada, sareko gailuak azkar (1-2 segundoko epean) detektatzen du gertakari hori eta huts egin duen zerbitzaria biratzetik kentzen du. Horren ondorioz, nodo pasiboak (hau da, liderrak ez direnak) ia aktibatu eta desaktibatu daitezke diagrametan beherapenak nabaritu gabe. Galtzen dugun maximoa azken segundoan sartutako neurketen zati bat da. Lider baten bat-bateko galerak/itzaliak/aldatzeak anomalia txiki bat sortuko du oraindik (30 segundoko tartea sinkronizatu gabe dago oraindik), baina nodoen arteko komunikazioa badago, arazo hauek gutxitu daitezke, adibidez, sinkronizazio paketeak bidaliz. .
Barne egiturari buruz pixka bat. Aplikazioa, noski, hari anitzekoa da, baina hari-arkitektura Brubeck-en erabiltzen denaren desberdina da. Brubeck-en hariak berdinak dira: horietako bakoitza informazioa biltzeaz eta gehitzeaz arduratzen da. Bioyinoan, langileak bi taldetan banatzen dira: sarearen arduradunak eta agregazio arduradunak. Zatiketa honek aplikazioa malgutasun handiagoz kudeatzeko aukera ematen du metrika motaren arabera: agregazio intentsiboa behar den lekuetan, agregatzaileak gehi ditzakezu, sareko trafiko handia dagoen tokietan, sare-fluxu kopurua gehi dezakezu. Momentu honetan, gure zerbitzarietan 8 sare eta 4 agregazio fluxutan lan egiten dugu.
Zenbaketa (agregazioaren arduraduna) zatia nahiko aspergarria da. Sare-fluxuek betetako bufferak zenbaketa-fluxuen artean banatzen dira, non gero analizatu eta agregatu egiten diren. Eskatuz gero, beste nodo batzuetara bidaltzeko metrikak ematen dira. Hori guztia, nodoen artean datuak bidaltzea eta Consul-ekin lan egitea barne, modu asinkronoan egiten da, esparruan exekutatzen. .
Garapenean zehar askoz arazo gehiago sortu ziren metrikak jasotzeaz arduratzen den sareko zatiak. Sare-fluxuak entitate bereizietan banatzearen helburu nagusia fluxu batek igarotzen duen denbora murrizteko nahia zen ez socketeko datuak irakurtzeko. UDP asinkronoa eta recvmsg erregularra erabiltzen dituzten aukerak azkar desagertu dira: lehenengoak erabiltzaile-espazio gehiegi kontsumitzen du gertaerak prozesatzeko, bigarrenak testuinguru-aldaketa gehiegi behar ditu. Horregatik, gaur egun erabiltzen da buffer handiekin (eta buffer, jaun ofizialak, ez dira ezer zuretzat!). UDP arruntaren euskarria recvmmsg behar ez den kasu arinetarako gordeta dago. Mezu anitzeko moduan, gauza nagusia lor daiteke: gehienetan, sareko hariak sistema eragilearen ilara arrastiatzen du - socketeko datuak irakurtzen ditu eta erabiltzaile-espazioko bufferera transferitzen ditu, noizean behin bakarrik betetako buffer-a ematera aldatzen da. agregatzaileak. Socketeko ilara ia ez da pilatzen, eroritako pakete kopurua ia ez da hazten.
Kontuan izan
Ezarpen lehenetsietan, buffer-aren tamaina nahiko handia izango da. Bat-batean zerbitzaria zuk zeuk probatzea erabakitzen baduzu, baliteke metrika kopuru txiki bat bidali ondoren ez direla Graphite-ra iritsiko, sareko korronteen bufferean geratuko direla. Neurri kopuru txiki batekin lan egiteko, busize eta zeregin-ilararen tamaina balio txikiagoak ezarri behar dituzu konfigurazioan.
Azkenik, taula zaleentzat zerrenda batzuk.
Zerbitzari bakoitzeko sarrerako metrika kopuruari buruzko estatistikak: 2 milioi MPS baino gehiago.
Nodoetako bat desgaitu eta sarrerako neurketak birbanatzea.
Irteerako neurketei buruzko estatistikak: nodo bakarrak bidaltzen ditu beti: raid-burua.
Nodo bakoitzaren funtzionamenduaren estatistikak, sistemaren hainbat modulutako akatsak kontuan hartuta.
Sarrerako neurketen xehetasunak (metrikoen izenak ezkutatuta daude).
Zer egiteko asmoa dugu hurrengo honekin guztiarekin? Noski, idatzi kodea, alajaina...! Proiektua hasiera batean kode irekia izateko pentsatuta zegoen eta horrela jarraituko du bere bizitzan zehar. Gure berehalako planak Raft-en gure bertsiora aldatzea, pareko protokoloa eramangarriagoa den batera aldatzea, barne-estatistika osagarriak, neurketa mota berriak, akatsen konponketak eta beste hobekuntza batzuk sartzea dira.
Noski, denek ongietorria dute proiektuaren garapenean laguntzera: PR sortu, Arazoak, ahal bada erantzungo dugu, hobetu, etab.
Hori esanda, hori guztia lagunok, erosi gure elefanteak!
Iturria: www.habr.com