Felly rydych chi'n casglu metrigau. Fel yr ydym ni. Rydym hefyd yn casglu metrigau. Wrth gwrs, yn angenrheidiol ar gyfer busnes. Heddiw, byddwn yn siarad am ddolen gyntaf ein system fonitro - gweinydd agregu sy'n gydnaws â statsd , pam wnaethon ni ei ysgrifennu a pham rydyn ni wedi rhoi'r gorau i brubeck.
O'n herthyglau blaenorol (, ) gallwch ddarganfod bod hyd at beth amser rydym yn casglu marciau gan ddefnyddio . Fe'i hysgrifennir yn C. O safbwynt cod, mae mor syml â phlwg (mae hyn yn bwysig pan fyddwch am gyfrannu) ac, yn bwysicaf oll, mae'n trin ein cyfeintiau o 2 filiwn metrig yr eiliad (MPS) yn ystod oriau brig heb unrhyw broblemau. Mae'r ddogfennaeth yn nodi cefnogaeth i 4 miliwn o MPS gyda seren. Mae hyn yn golygu y byddwch yn cael y ffigur a nodir os ydych chi'n ffurfweddu'r rhwydwaith yn gywir ar Linux. (Nid ydym yn gwybod faint o MPS y gallwch ei gael os byddwch yn gadael y rhwydwaith fel y mae). Er gwaethaf y manteision hyn, cawsom nifer o gwynion difrifol am brubeck.
Cais 1 . Rhoddodd Github, datblygwr y prosiect, y gorau i'w gefnogi: cyhoeddi clytiau ac atebion, derbyn ein rhai ni ac (nid ein rhai ni yn unig) Cysylltiadau Cyhoeddus. Yn ystod yr ychydig fisoedd diwethaf (yn rhywle rhwng Chwefror a Mawrth 2018), mae gweithgaredd wedi ailddechrau, ond cyn hynny bu bron i 2 flynedd o dawelwch llwyr. Yn ogystal, mae'r prosiect yn cael ei ddatblygu , a all ddod yn rhwystr difrifol i gyflwyno nodweddion newydd.
Cais 2 . Cywirdeb y cyfrifiadau. Mae Brubeck yn casglu cyfanswm o 65536 o werthoedd ar gyfer agregu. Yn ein hachos ni, ar gyfer rhai metrigau, yn ystod y cyfnod agregu (30 eiliad), efallai y bydd llawer mwy o werthoedd yn cyrraedd (1 ar yr uchafbwynt). O ganlyniad i'r samplu hwn, mae'r gwerthoedd uchaf ac isaf yn ymddangos yn ddiwerth. Er enghraifft, fel hyn:
Fel yr oedd
Sut y dylai fod wedi bod
Am yr un rheswm, mae symiau'n cael eu cyfrifo'n anghywir yn gyffredinol. Ychwanegwch yma byg gyda gorlif arnofio 32-bit, sydd yn gyffredinol yn anfon y gweinydd i segfault wrth dderbyn metrig sy'n ymddangos yn ddiniwed, ac mae popeth yn dod yn wych. Nid yw'r byg, gyda llaw, wedi'i drwsio.
Ac yn olaf Hawl X. Ar adeg ysgrifennu hwn, rydym yn barod i'w gyflwyno i bob un o'r 14 o weithrediadau statsd gweithio mwy neu lai yr oeddem yn gallu dod o hyd iddynt. Gadewch i ni ddychmygu bod rhywfaint o seilwaith unigol wedi tyfu cymaint fel nad yw derbyn 4 miliwn o MPS yn ddigon bellach. Neu hyd yn oed os nad yw wedi tyfu eto, ond mae'r metrigau eisoes mor bwysig i chi fel y gall hyd yn oed gostyngiadau byr, 2-3 munud yn y siartiau ddod yn dyngedfennol ac achosi pyliau o iselder anorchfygol ymhlith rheolwyr. Gan fod trin iselder yn dasg ddiddiolch, mae angen atebion technegol.
Yn gyntaf, goddefgarwch bai, fel nad yw problem sydyn ar y gweinydd yn achosi apocalypse zombie seiciatrig yn y swyddfa. Yn ail, graddio i allu derbyn mwy na 4 miliwn o MPS, heb gloddio'n ddwfn i bentwr rhwydwaith Linux a thyfu'n dawel “o led” i'r maint gofynnol.
Gan fod gennym le i raddio, fe benderfynon ni ddechrau gyda goddef diffygion. "AMOD! Goddef bai! Mae'n syml, gallwn ei wneud, ”fe wnaethon ni feddwl a lansio 2 weinydd, gan godi copi o brubeck ar bob un. I wneud hyn, roedd yn rhaid i ni gopïo traffig gyda metrigau i'r ddau weinydd a hyd yn oed ysgrifennu ar gyfer hyn . Fe wnaethon ni ddatrys y broblem goddefgarwch bai gyda hyn, ond ... ddim yn dda iawn. Ar y dechrau roedd popeth yn ymddangos yn wych: mae pob brubeck yn casglu ei fersiwn ei hun o agregu, yn ysgrifennu data i Graffit unwaith bob 30 eiliad, gan drosysgrifo'r hen gyfwng (gwneir hyn ar yr ochr Graffit). Os bydd un gweinydd yn methu'n sydyn, mae gennym bob amser ail un gyda'i gopi ei hun o'r data cyfanredol. Ond dyma’r broblem: os bydd y gweinydd yn methu, mae “gwel” yn ymddangos ar y graffiau. Mae hyn oherwydd y ffaith nad yw cyfnodau 30 eiliad brubeck yn cael eu cysoni, ac ar adeg damwain nid yw un ohonynt wedi'i drosysgrifo. Pan fydd yr ail weinydd yn cychwyn, mae'r un peth yn digwydd. Eithaf goddefgar, ond dwi eisiau gwell! Nid yw problem scalability wedi diflannu ychwaith. Mae pob metrig yn dal i “hedfan” i un gweinydd, ac felly rydym wedi'n cyfyngu i'r un 2-4 miliwn o MPS, yn dibynnu ar lefel y rhwydwaith.
Os ydych chi'n meddwl ychydig am y broblem ac ar yr un pryd yn cloddio eira gyda rhaw, yna efallai y bydd y syniad amlwg canlynol yn dod i'r meddwl: mae angen statsd arnoch a all weithio yn y modd gwasgaredig. Hynny yw, un sy'n gweithredu cydamseriad rhwng nodau mewn amser a metrigau. “Wrth gwrs, mae’n debyg bod datrysiad o’r fath eisoes yn bodoli,” dywedasom ac aethom at Google…. A chawsant ddim. Ar ôl mynd trwy'r ddogfennaeth ar gyfer gwahanol statsd ( o Ragfyr 11.12.2017, XNUMX), ni welsom ddim byd o gwbl. Yn ôl pob tebyg, nid yw datblygwyr na defnyddwyr yr atebion hyn wedi dod ar draws SO lawer o fetrigau eto, fel arall byddent yn bendant yn meddwl am rywbeth.
Ac wedyn fe wnaethom gofio am y “tegan” statsd - bioyino, a ysgrifennwyd yn yr hackathon Just for Fun (cynhyrchwyd enw'r prosiect gan y sgript cyn dechrau'r hacathon) a sylweddoli bod angen ein statsd ein hunain ar frys. Am beth?
- oherwydd bod rhy ychydig o glonau statsd yn y byd,
- oherwydd ei bod yn bosibl darparu'r goddefgarwch nam a'r graddadwyedd dymunol neu'n agos ato (gan gynnwys cydamseru metrigau cyfanredol rhwng gweinyddwyr a datrys y broblem o anfon gwrthdaro),
- oherwydd ei bod yn bosibl cyfrifo metrigau yn fwy cywir nag y mae brubeck yn ei wneud,
- oherwydd gallwch chi gasglu ystadegau manylach eich hun, na roddodd brubeck i ni yn ymarferol,
- oherwydd cefais gyfle i raglennu fy nghais labordy graddfa ddosbarthedig gorberfformiad fy hun, na fydd yn ailadrodd pensaernïaeth hyperfor tebyg arall yn llwyr ... wel, dyna ni.
Beth i ysgrifennu arno? Wrth gwrs, yn Rust. Pam?
- oherwydd bod datrysiad prototeip eisoes,
- oherwydd bod awdur yr erthygl eisoes yn adnabod Rust bryd hynny ac yn awyddus i ysgrifennu rhywbeth ynddo i'w gynhyrchu gyda'r cyfle i'w roi mewn ffynhonnell agored,
- oherwydd nad yw ieithoedd gyda GC yn addas i ni oherwydd natur y traffig a dderbynnir (bron amser real) ac mae seibiau GC bron yn annerbyniol,
- oherwydd mae angen perfformiad uchaf tebyg i C
- oherwydd mae Rust yn rhoi arian cyfred di-ofn i ni, a phe baem yn dechrau ei ysgrifennu yn C / C ++, byddem wedi cribinio mewn hyd yn oed mwy o wendidau, gorlifiadau byffer, amodau hil a geiriau brawychus eraill na brubeck.
Bu dadl hefyd yn erbyn Rust. Nid oedd gan y cwmni unrhyw brofiad o greu prosiectau yn Rust, ac erbyn hyn nid ydym hefyd yn bwriadu ei ddefnyddio yn y prif brosiect. Felly, roedd ofnau difrifol na fyddai dim yn gweithio allan, ond fe benderfynon ni gymryd siawns a cheisio.
Aeth amser heibio...
Yn olaf, ar ôl sawl ymgais aflwyddiannus, roedd y fersiwn weithredol gyntaf yn barod. Beth ddigwyddodd? Dyma beth ddigwyddodd.
Mae pob nod yn derbyn ei set ei hun o fetrigau ac yn eu cronni, ac nid yw'n agregu metrigau ar gyfer y mathau hynny lle mae angen eu set lawn ar gyfer agregu terfynol. Mae'r nodau wedi'u cysylltu â'i gilydd gan ryw fath o brotocol clo dosbarthedig, sy'n eich galluogi i ddewis yn eu plith yr unig un (yma buom yn crio) sy'n deilwng o anfon metrigau i'r Un Mawr. Mae'r broblem hon yn cael ei datrys ar hyn o bryd gan , ond yn y dyfodol mae uchelgeisiau’r awdur yn ymestyn i Raft, lle bydd yr un mwyaf teilwng, wrth gwrs, yn nod arweinydd consensws. Yn ogystal â chonsensws, mae nodau yn eithaf aml (unwaith yr eiliad yn ddiofyn) yn anfon at eu cymdogion y rhannau hynny o fetrigau agregedig ymlaen llaw y maent wedi llwyddo i'w casglu yn yr eiliad honno. Mae'n ymddangos bod goddefgarwch graddio a diffygion yn cael eu cadw - mae pob nod yn dal i ddal set lawn o fetrigau, ond mae'r metrigau'n cael eu hanfon eisoes wedi'u hagregu, trwy TCP a'u hamgodio i mewn i brotocol deuaidd, felly mae costau dyblygu yn cael eu lleihau'n sylweddol o'u cymharu â CDU. Er gwaethaf y nifer eithaf mawr o fetrigau sy'n dod i mewn, ychydig iawn o gof sydd ei angen ar gyfer cronni a hyd yn oed llai o CPU. Ar gyfer ein rhinweddau cywasgadwy iawn, dim ond ychydig ddegau o megabeit o ddata yw hyn. Fel bonws ychwanegol, ni chawn unrhyw ailysgrifennu data diangen yn Graphite, fel yn achos burbeck.
Mae pecynnau CDU gyda metrigau yn anghytbwys rhwng nodau ar offer rhwydwaith trwy Robin Rownd syml. Wrth gwrs, nid yw caledwedd y rhwydwaith yn dosrannu cynnwys pecynnau ac felly gall dynnu llawer mwy na phecynnau 4M yr eiliad, heb sôn am fetrigau nad yw'n gwybod dim byd amdanynt. Os byddwn yn cymryd i ystyriaeth nad yw'r metrigau yn dod un ar y tro ym mhob pecyn, yna nid ydym yn rhagweld unrhyw broblemau perfformiad yn y lle hwn. Os bydd gweinydd yn damwain, mae dyfais y rhwydwaith yn canfod y ffaith hon yn gyflym (o fewn 1-2 eiliad) ac yn tynnu'r gweinydd sydd wedi chwalu o gylchdroi. O ganlyniad i hyn, gellir troi nodau goddefol (h.y., nad ydynt yn arweinydd) ymlaen ac i ffwrdd yn ymarferol heb sylwi ar ostyngiadau ar y siartiau. Mae'r uchafswm rydyn ni'n ei golli yn rhan o'r metrigau a ddaeth i mewn ar yr eiliad olaf. Bydd colli/cau/newid arweinydd yn sydyn yn dal i greu mân anghysondeb (mae'r cyfwng o 30 eiliad yn dal heb ei gysoni), ond os oes cyfathrebu rhwng nodau, gellir lleihau'r problemau hyn, er enghraifft, drwy anfon pecynnau cydamseru. .
Ychydig am y strwythur mewnol. Mae'r cais, wrth gwrs, yn aml-edau, ond mae'r bensaernïaeth edafu yn wahanol i'r un a ddefnyddir mewn brubeck. Mae'r edafedd mewn brubeck yr un peth - mae pob un ohonynt yn gyfrifol am gasglu a chydgrynhoi gwybodaeth. Yn bioyino, rhennir gweithwyr yn ddau grŵp: y rhai sy'n gyfrifol am y rhwydwaith a'r rhai sy'n gyfrifol am agregu. Mae'r rhaniad hwn yn caniatáu ichi reoli'r cais yn fwy hyblyg yn dibynnu ar y math o fetrigau: lle mae angen agregu dwys, gallwch ychwanegu cydgrynwyr, lle mae llawer o draffig rhwydwaith, gallwch ychwanegu nifer y llif rhwydwaith. Ar hyn o bryd, ar ein gweinyddion rydym yn gweithio mewn 8 llif rhwydwaith a 4 llif agregu.
Mae'r rhan gyfrif (sy'n gyfrifol am agregu) yn eithaf diflas. Mae clustogau sy'n cael eu llenwi gan lifau rhwydwaith yn cael eu dosbarthu ymhlith llifoedd cyfrif, lle cânt eu dosrannu a'u hagregu wedyn. Ar gais, rhoddir metrigau i'w hanfon i nodau eraill. Mae hyn i gyd, gan gynnwys anfon data rhwng nodau a gweithio gyda Conswl, yn cael ei berfformio'n anghydamserol, gan redeg ar y fframwaith .
Achoswyd llawer mwy o broblemau yn ystod datblygiad gan y rhan rhwydwaith sy'n gyfrifol am dderbyn metrigau. Y prif nod o wahanu llifoedd rhwydwaith yn endidau ar wahân oedd yr awydd i leihau'r amser y mae llif yn ei dreulio dim i ddarllen data o'r soced. Diflannodd opsiynau sy'n defnyddio CDU asyncronig a recvmsg rheolaidd yn gyflym: mae'r cyntaf yn defnyddio gormod o CPU gofod defnyddiwr ar gyfer prosesu digwyddiadau, mae angen gormod o switshis cyd-destun ar yr ail. Felly mae'n cael ei ddefnyddio nawr gyda byfferau mawr (a byfferau, swyddogion bonheddig, yn ddim i chi!). Cedwir cefnogaeth ar gyfer CDU rheolaidd ar gyfer achosion ysgafn lle nad oes angen recvmmsg. Yn y modd aml-neges, mae'n bosibl cyflawni'r prif beth: y mwyafrif helaeth o'r amser, mae'r edau rhwydwaith yn cribo'r ciw OS - yn darllen data o'r soced ac yn ei drosglwyddo i'r byffer gofod defnyddiwr, dim ond yn achlysurol yn newid i roi'r byffer wedi'i lenwi i cydgrynwyr. Yn ymarferol nid yw'r ciw yn y soced yn cronni, yn ymarferol nid yw nifer y pecynnau wedi'u gollwng yn tyfu.
Nodyn
Yn y gosodiadau diofyn, mae maint y byffer wedi'i osod i fod yn eithaf mawr. Os byddwch chi'n penderfynu'n sydyn i roi cynnig ar y gweinydd eich hun, efallai y byddwch chi'n dod ar draws y ffaith, ar ôl anfon nifer fach o fetrigau, na fyddant yn cyrraedd Graffit, gan aros yn y byffer ffrwd rhwydwaith. I weithio gyda nifer fach o fetrigau, mae angen i chi osod maint bufsize a task-queue-size i werthoedd llai yn y ffurfwedd.
Yn olaf, rhai siartiau ar gyfer y rhai sy'n hoff o siartiau.
Ystadegau ar nifer y metrigau sy'n dod i mewn ar gyfer pob gweinydd: mwy na 2 filiwn o MPS.
Analluogi un o'r nodau ac ailddosbarthu metrigau sy'n dod i mewn.
Ystadegau ar fetrigau sy'n mynd allan: dim ond un nod sy'n anfon bob amser - y bos cyrch.
Ystadegau gweithrediad pob nod, gan ystyried gwallau mewn gwahanol fodiwlau system.
Manylion y metrigau sy'n dod i mewn (mae enwau metrig wedi'u cuddio).
Beth ydyn ni'n bwriadu ei wneud gyda hyn i gyd nesaf? Wrth gwrs, ysgrifennwch god, damn...! Cynlluniwyd y prosiect yn wreiddiol i fod yn ffynhonnell agored a bydd yn parhau felly drwy gydol ei oes. Mae ein cynlluniau uniongyrchol yn cynnwys newid i'n fersiwn ein hunain o Raft, newid y protocol cymheiriaid i un mwy cludadwy, cyflwyno ystadegau mewnol ychwanegol, mathau newydd o fetrigau, atgyweiriadau i fygiau a gwelliannau eraill.
Wrth gwrs, mae croeso i bawb helpu yn natblygiad y prosiect: creu Cysylltiadau Cyhoeddus, Materion, os yn bosibl byddwn yn ymateb, yn gwella, ac ati.
Gyda dweud hynny, dyna i gyd Folks, prynwch ein eliffantod!
Ffynhonnell: hab.com