Kwa hivyo unakusanya vipimo. Kama tulivyo. Pia tunakusanya vipimo. Bila shaka, ni muhimu kwa biashara. Leo tutazungumza juu ya kiunga cha kwanza kabisa cha mfumo wetu wa ufuatiliaji - seva ya mkusanyiko inayoendana na takwimu. , kwa nini tuliandika na kwa nini tuliachana na brubeck.
Kutoka kwa nakala zetu zilizopita (, ) unaweza kujua kuwa hadi wakati fulani tulikusanya vitambulisho kwa kutumia . Imeandikwa katika C. Kwa mtazamo wa msimbo, ni rahisi kama plagi (hii ni muhimu unapotaka kuchangia) na, muhimu zaidi, inashughulikia ujazo wetu wa vipimo milioni 2 kwa sekunde (MPS) kwa kilele. bila matatizo yoyote. Nyaraka zinaonyesha msaada kwa Wabunge milioni 4 wenye nyota. Hii ina maana kwamba utapata takwimu iliyoelezwa ikiwa utasanidi mtandao kwa usahihi kwenye Linux. (Hatujui ni Wabunge wangapi unaweza kupata ukiacha mtandao ulivyo). Licha ya faida hizi, tulikuwa na malalamiko kadhaa mazito kuhusu brubeck.
Dai 1. Github, msanidi wa mradi, aliacha kuunga mkono: kuchapisha viraka na marekebisho, kukubali yetu na (sio yetu tu) PR. Katika miezi michache iliyopita (mahali fulani kutoka Februari-Machi 2018), shughuli imeanza tena, lakini kabla ya hapo kulikuwa na karibu miaka 2 ya utulivu kamili. Aidha, mradi unaendelezwa , ambayo inaweza kuwa kikwazo kikubwa kwa kuanzishwa kwa vipengele vipya.
Dai 2. Usahihi wa mahesabu. Brubeck hukusanya jumla ya maadili 65536 kwa kujumlisha. Kwa upande wetu, kwa vipimo vingine, wakati wa kujumlisha (sekunde 30), maadili mengi zaidi yanaweza kufika (1 katika kilele). Kama matokeo ya sampuli hii, maadili ya juu na ya chini yanaonekana kuwa hayana maana. Kwa mfano, kama hii:
Kama ilivyokuwa
Jinsi ilivyopaswa kuwa
Kwa sababu hiyo hiyo, kiasi kwa ujumla huhesabiwa vibaya. Ongeza hapa hitilafu iliyo na kufurika kwa kuelea kwa biti 32, ambayo kwa ujumla hutuma seva kwenye makosa wakati inapokea kipimo kinachoonekana kuwa kisicho na hatia, na kila kitu huwa kizuri. Mdudu, kwa njia, haijasasishwa.
Na, hatimaye, Dai X. Wakati wa kuandika, tuko tayari kuiwasilisha kwa utekelezaji wote 14 zaidi au chini wa kufanya kazi wa takwimu ambao tuliweza kupata. Hebu fikiria kwamba baadhi ya miundombinu imeongezeka sana hivi kwamba kukubali Wabunge milioni 4 haitoshi tena. Au hata ikiwa haijakua bado, lakini vipimo tayari ni muhimu sana kwako hivi kwamba hata muda mfupi, wa dakika 2-3 kwenye chati unaweza tayari kuwa mbaya na kusababisha mapigo ya unyogovu usioweza kushindwa kati ya wasimamizi. Kwa kuwa kutibu unyogovu ni kazi isiyo na shukrani, ufumbuzi wa kiufundi unahitajika.
Kwanza, uvumilivu wa makosa, ili shida ya ghafla kwenye seva isisababishe apocalypse ya zombie ya akili katika ofisi. Pili, kuongeza uwezo wa kukubali Wabunge zaidi ya milioni 4, bila kuchimba ndani ya safu ya mtandao ya Linux na kukua kwa utulivu "kwa upana" kwa saizi inayohitajika.
Kwa kuwa tulikuwa na nafasi ya kuongeza, tuliamua kuanza na uvumilivu wa makosa. "KUHUSU! Uvumilivu wa makosa! Ni rahisi, tunaweza kuifanya, "tulifikiria na kuzindua seva 2, tukiinua nakala ya brubeck kwa kila moja. Ili kufanya hivyo, tulilazimika kunakili trafiki na vipimo kwa seva zote mbili na hata kuandika kwa hili . Tulitatua tatizo la uvumilivu wa makosa na hili, lakini ... sio vizuri sana. Mara ya kwanza kila kitu kilionekana kuwa kizuri: kila brubeck hukusanya toleo lake la mkusanyiko, huandika data kwa Graphite mara moja kila sekunde 30, na kufuta muda wa zamani (hii inafanywa kwa upande wa Graphite). Seva moja ikishindwa ghafla, huwa tuna ya pili na nakala yake ya data iliyojumlishwa. Lakini hapa kuna tatizo: ikiwa seva inashindwa, "saw" inaonekana kwenye grafu. Hii ni kutokana na ukweli kwamba vipindi vya brubeck vya sekunde 30 havijasawazishwa, na wakati wa ajali moja yao haijaandikwa. Wakati seva ya pili inapoanza, jambo lile lile hufanyika. Inavumiliwa kabisa, lakini nataka bora! Tatizo la scalability pia halijaisha. Vipimo vyote bado "kuruka" kwa seva moja, na kwa hivyo tunawekewa Wabunge milioni 2-4 sawa, kulingana na kiwango cha mtandao.
Ikiwa unafikiri kidogo juu ya tatizo na wakati huo huo kuchimba theluji na koleo, basi wazo la wazi lifuatalo linaweza kukumbuka: unahitaji statsd ambayo inaweza kufanya kazi katika hali ya kusambazwa. Hiyo ni, ile inayotumia usawazishaji kati ya nodi kwa wakati na vipimo. "Bila shaka, suluhu kama hilo labda tayari lipo," tulisema na kwenda kwa Googleβ¦. Na hawakupata chochote. Baada ya kupitia nyaraka za takwimu tofauti ( hadi tarehe 11.12.2017 Desemba XNUMX), hatukupata chochote. Inavyoonekana, si watengenezaji au watumiaji wa suluhu hizi bado hawajakumbana na vipimo vingi, vinginevyo bila shaka wangekuja na kitu.
Na kisha tukakumbuka kuhusu "toy" statsd - bioyino, ambayo iliandikwa kwenye Just for Fun hackathon (jina la mradi lilitolewa na hati kabla ya kuanza kwa hackathon) na tukagundua kuwa tulihitaji takwimu zetu wenyewe. Kwa ajili ya nini?
- kwa sababu kuna nakala chache sana za takwimu ulimwenguni,
- kwa sababu inawezekana kutoa taka au karibu na ustahimilivu wa hitilafu unaohitajika (ikiwa ni pamoja na kusawazisha vipimo vilivyojumlishwa kati ya seva na kutatua tatizo la kutuma mizozo),
- kwa sababu inawezekana kukokotoa vipimo kwa usahihi zaidi kuliko brubeck,
- kwa sababu unaweza kukusanya takwimu za kina zaidi mwenyewe, ambazo brubeck hakutupa,
- kwa sababu nilikuwa na nafasi ya kupanga maombi yangu ya maabara ya kiwango cha usambazaji wa hyperperformance, ambayo haitarudia kabisa usanifu wa hyperperformance nyingine sawa ... vizuri, ndivyo hivyo.
Nini cha kuandika? Bila shaka, katika Rust. Kwa nini?
- kwa sababu tayari kulikuwa na suluhisho la mfano,
- kwa sababu mwandishi wa makala hiyo tayari alijua Rust wakati huo na alikuwa na hamu ya kuandika kitu ndani yake kwa ajili ya uzalishaji na fursa ya kuiweka katika chanzo wazi,
- kwa sababu lugha zilizo na GC hazitufai kwa sababu ya hali ya trafiki inayopokelewa (karibu wakati halisi) na kusitisha kwa GC haikubaliki,
- kwa sababu unahitaji utendaji wa juu zaidi kulinganishwa na C
- kwa sababu Rust hutupatia upatanishi usio na woga, na ikiwa tungeanza kuiandika katika C/C++, tungekuwa tumejiwekea udhaifu zaidi, kufurika kwa bafa, hali ya mbio na maneno mengine ya kutisha kuliko brubeck.
Kulikuwa pia na mabishano dhidi ya Kutu. Kampuni haikuwa na uzoefu wa kuunda miradi katika Rust, na sasa hatuna mpango wa kuitumia katika mradi mkuu. Kwa hivyo, kulikuwa na hofu kubwa kwamba hakuna kitu kitafanya kazi, lakini tuliamua kuchukua nafasi na kujaribu.
Muda ulipita...
Hatimaye, baada ya majaribio kadhaa yaliyoshindwa, toleo la kwanza la kazi lilikuwa tayari. Nini kimetokea? Hiki ndicho kilichotokea.
Kila nodi hupokea seti yake ya vipimo na kuvikusanya, na haijumuishi vipimo vya aina hizo ambapo seti yao kamili inahitajika kwa ujumlisho wa mwisho. Nodes zimeunganishwa kwa kila mmoja kwa aina fulani ya itifaki ya lock iliyosambazwa, ambayo inakuwezesha kuchagua kati yao pekee (hapa tulilia) ambayo inastahili kutuma metrics kwa Mkuu. Tatizo hili kwa sasa linatatuliwa na , lakini katika siku zijazo matarajio ya mwandishi yanaenea hadi Raft, ambapo anayestahili zaidi, bila shaka, atakuwa nodi ya kiongozi wa makubaliano. Mbali na makubaliano, nodi mara nyingi (mara moja kwa sekunde kwa chaguo-msingi) hutuma kwa majirani zao sehemu hizo za vipimo vilivyojumlishwa awali ambazo walifanikiwa kukusanya katika sekunde hiyo. Inabadilika kuwa kuongeza na uvumilivu wa makosa huhifadhiwa - kila nodi bado ina seti kamili ya vipimo, lakini metriki hutumwa tayari kuunganishwa, kupitia TCP na kusimba katika itifaki ya binary, hivyo gharama za kurudia zimepunguzwa kwa kiasi kikubwa ikilinganishwa na UDP. Licha ya idadi kubwa ya vipimo vinavyoingia, mkusanyiko unahitaji kumbukumbu ndogo sana na hata CPU kidogo. Kwa metiki zetu zinazoweza kubanwa sana, hii ni makumi machache tu ya megabaiti za data. Kama bonasi ya ziada, hatupati data iliyoandikwa upya isiyo ya lazima katika Graphite, kama ilivyokuwa kwa burbeck.
Pakiti za UDP zilizo na vipimo hazina usawa kati ya nodi kwenye vifaa vya mtandao kupitia Round Robin rahisi. Kwa kweli, vifaa vya mtandao havichanganui yaliyomo kwenye pakiti na kwa hivyo vinaweza kuvuta pakiti zaidi ya 4M kwa sekunde, bila kutaja metriki ambazo hazijui chochote. Ikiwa tutazingatia kwamba vipimo haviji moja kwa moja katika kila pakiti, basi hatuoni matatizo yoyote ya utendaji mahali hapa. Ikiwa seva itaacha kufanya kazi, kifaa cha mtandao haraka (ndani ya sekunde 1-2) hutambua ukweli huu na huondoa seva iliyoanguka kutoka kwa mzunguko. Kama matokeo ya hii, nodi za passiv (yaani, zisizo za kiongozi) zinaweza kuwashwa na kuzimwa kivitendo bila kugundua michoro kwenye chati. Kiwango cha juu tunachopoteza ni sehemu ya vipimo vilivyokuja sekunde ya mwisho. Kupoteza / kuzimwa kwa ghafla / kubadili kwa kiongozi bado kutasababisha shida ndogo (muda wa sekunde 30 bado haujasawazishwa), lakini ikiwa kuna mawasiliano kati ya nodi, shida hizi zinaweza kupunguzwa, kwa mfano, kwa kutuma pakiti za maingiliano. .
Kidogo kuhusu muundo wa ndani. maombi ni, bila shaka, multithreaded, lakini usanifu threading ni tofauti na kutumika katika brubeck. Nyuzi katika brubeck ni sawa - kila mmoja wao anajibika kwa ukusanyaji wa habari na mkusanyiko. Katika bioyino, wafanyakazi wamegawanywa katika makundi mawili: wale wanaohusika na mtandao na wale wanaohusika na kujumlisha. Mgawanyiko huu hukuruhusu kudhibiti programu kwa urahisi zaidi kulingana na aina ya vipimo: ambapo mkusanyiko wa kina unahitajika, unaweza kuongeza viunganishi, ambapo kuna trafiki nyingi za mtandao, unaweza kuongeza idadi ya mtiririko wa mtandao. Kwa sasa, kwenye seva zetu tunafanya kazi katika mtandao 8 na mtiririko wa mkusanyiko 4.
Sehemu ya kuhesabu (inayohusika na mkusanyiko) ni ya kuchosha sana. Vihifadhi vilivyojazwa na mtiririko wa mtandao husambazwa kati ya mitiririko ya kuhesabu, ambapo huchanganuliwa na kujumlishwa. Kwa ombi, vipimo hutolewa kwa kutuma kwa nodi zingine. Haya yote, ikiwa ni pamoja na kutuma data kati ya nodi na kufanya kazi na Balozi, hufanywa kwa njia ya asynchronously, inayoendesha kwenye mfumo. .
Matatizo mengi zaidi wakati wa utayarishaji yalisababishwa na sehemu ya mtandao inayowajibika kupokea vipimo. Lengo kuu la kutenganisha mtiririko wa mtandao katika vyombo tofauti lilikuwa hamu ya kupunguza muda ambao mtiririko hutumia hakuna kusoma data kutoka kwa soketi. Chaguo zinazotumia UDP isiyosawazisha na recvmsg za kawaida zilitoweka haraka: ya kwanza hutumia CPU ya nafasi ya mtumiaji nyingi sana kwa usindikaji wa tukio, ya pili inahitaji swichi nyingi za muktadha. Kwa hivyo sasa inatumika na buffers kubwa (na buffers, maafisa waungwana, si kitu kwako!). Usaidizi wa UDP ya kawaida umehifadhiwa kwa kesi nyepesi ambapo recvmmsg haihitajiki. Katika hali ya multimessage, inawezekana kufikia jambo kuu: idadi kubwa ya wakati, thread ya mtandao inatafuta foleni ya OS - inasoma data kutoka kwa tundu na kuihamisha kwenye buffer ya nafasi ya mtumiaji, mara kwa mara tu kubadilisha hadi kutoa buffer iliyojaa. wakusanyaji. Foleni katika tundu kivitendo haina kujilimbikiza, idadi ya pakiti imeshuka kivitendo haina kukua.
Kumbuka
Katika mipangilio chaguo-msingi, saizi ya bafa imewekwa kuwa kubwa kabisa. Ikiwa unaamua ghafla kujaribu seva mwenyewe, unaweza kukutana na ukweli kwamba baada ya kutuma idadi ndogo ya metrics, hawatafika kwenye Graphite, iliyobaki kwenye buffer ya mkondo wa mtandao. Ili kufanya kazi na idadi ndogo ya vipimo, unahitaji kuweka ukubwa wa bufsize na foleni ya kazi kuwa thamani ndogo katika usanidi.
Hatimaye, baadhi ya chati kwa wapenzi chati.
Takwimu za idadi ya vipimo vinavyoingia kwa kila seva: zaidi ya MPS milioni 2.
Inazima moja ya nodi na kusambaza tena vipimo vinavyoingia.
Takwimu za vipimo vinavyotoka: nodi moja pekee hutuma kila mara - bosi wa uvamizi.
Takwimu za uendeshaji wa kila nodi, kwa kuzingatia makosa katika moduli mbalimbali za mfumo.
Maelezo ya vipimo vinavyoingia (majina ya kipimo yamefichwa).
Je, tunapanga kufanya nini na haya yote ijayo? Bila shaka, andika kanuni, jamani...! Mradi ulipangwa awali kuwa wazi na utaendelea kuwa hivyo katika maisha yake yote. Mipango yetu ya haraka ni pamoja na kubadili toleo letu la Raft, kubadilisha itifaki ya programu zingine hadi inayoweza kubebeka zaidi, kuanzisha takwimu za ziada za ndani, aina mpya za vipimo, kurekebishwa kwa hitilafu na maboresho mengine.
Bila shaka, kila mtu anakaribishwa kusaidia katika maendeleo ya mradi: kuunda PR, Masuala, ikiwa inawezekana tutajibu, kuboresha, nk.
Kwa kusema hivyo tu jamani, nunua tembo wetu!
Chanzo: mapenzi.com