Bioyino - բաշխված, մասշտաբային չափումների ագրեգատոր

Այսպիսով, դուք չափումներ եք հավաքում: Ինչպես մենք ենք: Մենք նաև հավաքում ենք չափումներ: Իհարկե, բիզնեսի համար անհրաժեշտ։ Այսօր մենք կխոսենք մեր մոնիտորինգի համակարգի առաջին կապի մասին՝ statsd-ի հետ համատեղելի ագրեգացիոն սերվերի մասին: բիոյինո, ինչու ենք մենք գրել այն և ինչու ենք լքել բրուբեկը:

Մեր նախորդ հոդվածներից (1, 2) կարող եք պարզել, որ մինչև որոշ ժամանակ մենք գնահատականներ ենք հավաքել՝ օգտագործելով Բրուբեկ. Այն գրված է C-ով: Կոդի տեսանկյունից այն նույնքան պարզ է, որքան վարդակից (սա կարևոր է, երբ ցանկանում եք նպաստել) և, ամենակարևորը, այն վերահսկում է մեր ծավալները՝ վայրկյանում 2 միլիոն չափումներ (MPS) առավելագույն պահին: առանց որևէ խնդիրների: Փաստաթղթում ասվում է աստղանիշով 4 միլիոն MPS-ի աջակցություն: Սա նշանակում է, որ դուք կստանաք նշված ցուցանիշը, եթե ցանցը ճիշտ կարգավորեք Linux-ում: (Մենք չգիտենք, թե քանի MPS կարող եք ստանալ, եթե դուրս գաք ցանցից այնպես, ինչպես կա): Չնայած այս առավելություններին, մենք մի քանի լուրջ բողոք ունեինք բրուբեկի հետ կապված։

Պահանջ 1. Ծրագրի մշակող Github-ը դադարեցրեց դրա աջակցությունը. կարկատաններ և ուղղումներ հրապարակելը, մերը և (ոչ միայն մեր) PR-ը ընդունելը: Վերջին մի քանի ամիսներին (2018 թվականի փետրվար-մարտ ինչ-որ տեղ) ակտիվությունը վերսկսվել է, սակայն մինչ այդ գրեթե 2 տարի լիակատար անդորր էր։ Բացի այդ, նախագիծը մշակման փուլում է ներքին Gihub կարիքների համար, ինչը կարող է լուրջ խոչընդոտ դառնալ նոր հնարավորությունների ներդրման համար։

Պահանջ 2. Հաշվարկների ճշգրտություն. Brubeck-ը հավաքում է ընդհանուր առմամբ 65536 արժեք ագրեգացիայի համար: Մեր դեպքում, որոշ չափումների համար, ագրեգացման ժամանակահատվածում (30 վայրկյան) կարող են շատ ավելի շատ արժեքներ հայտնվել (1 գագաթնակետին): Այս նմուշառման արդյունքում առավելագույն և նվազագույն արժեքներն անօգուտ են թվում: Օրինակ, այսպես.

Ինչպես եղավ

Ինչպես պետք է լիներ

Նույն պատճառով գումարները հիմնականում սխալ են հաշվարկվում։ Ավելացրե՛ք այստեղ 32-բիթանոց լողացող արտահոսքով սխալ, որը սովորաբար ուղարկում է սերվերին segfault-ի, երբ ստանում է անմեղ թվացող չափանիշ, և ամեն ինչ հիանալի է դառնում: Սխալը, ի դեպ, չի շտկվել։

Եվ, վերջապես, Պահանջ X. Գրելու պահին մենք պատրաստ ենք այն ներկայացնել բոլոր 14 քիչ թե շատ աշխատանքային statsd իրականացումներին, որոնք կարողացանք գտնել: Պատկերացնենք, որ առանձին ենթակառուցվածքներն այնքան են աճել, որ 4 միլիոն MPS ընդունելն այլևս բավարար չէ։ Կամ նույնիսկ եթե այն դեռ չի աճել, բայց չափիչները արդեն այնքան կարևոր են ձեզ համար, որ նույնիսկ կարճ 2-3 րոպեանոց անկումը գծապատկերներում արդեն կարող է դառնալ կրիտիկական և կառավարիչների շրջանում անհաղթահարելի դեպրեսիայի նոպաներ առաջացնել: Քանի որ դեպրեսիան բուժելը անշնորհակալ գործ է, անհրաժեշտ են տեխնիկական լուծումներ:

Նախ, սխալների հանդուրժողականություն, որպեսզի սերվերի վրա հանկարծակի խնդիրը չառաջացնի հոգեբուժական զոմբի ապոկալիպսիս գրասենյակում: Երկրորդ, մասշտաբը, որպեսզի կարողանանք ընդունել ավելի քան 4 միլիոն MPS, առանց խորանալու Linux ցանցի կույտում և հանգիստ «լայնությամբ» հասնելու պահանջվող չափին:

Քանի որ մենք չափելու տեղ ունեինք, որոշեցինք սկսել սխալների հանդուրժողականությունից: "ՄԱՍԻՆ! Սխալների հանդուրժողականություն: Դա պարզ է, մենք կարող ենք դա անել», - մտածեցինք մենք և գործարկեցինք 2 սերվեր, յուրաքանչյուրի վրա բարձրացնելով բրուբեքի պատճենը: Դա անելու համար մենք պետք է կրկնօրինակեինք տրաֆիկը չափորոշիչներով երկու սերվերների վրա և նույնիսկ գրել դրա համար փոքր օգտակարություն. Սրանով լուծեցինք սխալների հանդուրժողականության խնդիրը, բայց... ոչ այնքան լավ։ Սկզբում ամեն ինչ հիանալի էր թվում. յուրաքանչյուր բրուբեկ հավաքում է ագրեգացիայի իր տարբերակը, 30 վայրկյանը մեկ անգամ գրում է տվյալները Graphite-ին՝ վերագրելով հին ինտերվալը (սա արվում է Graphite-ի կողմից): Եթե ​​հանկարծ մի սերվեր խափանվի, մենք միշտ ունենում ենք երկրորդը, որն ունի համախմբված տվյալների իր պատճենը: Բայց ահա խնդիրը. եթե սերվերը ձախողվի, գրաֆիկների վրա հայտնվում է «սղոց»: Դա պայմանավորված է նրանով, որ բրուբեքի 30 վայրկյան ինտերվալները համաժամանակացված չեն, և վթարի պահին դրանցից մեկը չի վերագրվում: Երբ երկրորդ սերվերը սկսվում է, նույն բանը տեղի է ունենում: Բավական տանելի է, բայց ես ավելի լավ եմ ուզում: Չի վերացել նաև մասշտաբայնության խնդիրը։ Բոլոր չափիչները դեռ «թռչում» են մեկ սերվերի վրա, և, հետևաբար, մենք սահմանափակվում ենք նույն 2-4 միլիոն MPS-ով՝ կախված ցանցի մակարդակից:

Եթե ​​մի փոքր մտածեք խնդրի մասին և միևնույն ժամանակ բահով ձյուն փորեք, ձեր գլխում կարող է գալ հետևյալ ակնհայտ միտքը՝ ձեզ պետք է վիճակագրություն, որը կարող է աշխատել բաշխված ռեժիմով։ Այսինքն, մեկը, որն իրականացնում է ժամանակի և չափման հանգույցների միջև համաժամացում: «Իհարկե, նման լուծում երևի արդեն կա»,- ասացինք մենք և գնացինք Google… Եվ նրանք ոչինչ չգտան։ Տարբեր վիճակագրության փաստաթղթերն անցնելուց հետո (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 թվականի դեկտեմբերի XNUMX-ի դրությամբ), մենք բացարձակապես ոչինչ չենք գտել: Ըստ երևույթին, ոչ մշակողները, ոչ էլ այս լուծումների օգտատերերը դեռ չեն հանդիպել ԱՅՍՔԱՆ չափումների, այլապես նրանք հաստատ ինչ-որ բան կմտածեին:

Եվ հետո մենք հիշեցինք «խաղալիքի» վիճակագրությունը՝ bioyino-ն, որը գրվել էր Just for Fun հաքաթոնում (նախագծի անվանումը ստեղծվել էր սցենարով նախքան հաքաթոնի մեկնարկը) և հասկացանք, որ մեզ շտապ անհրաժեշտ է մեր սեփական վիճակագրությունը: Ինչի համար?

• քանի որ աշխարհում շատ քիչ են վիճակագրական կլոնները,
• քանի որ հնարավոր է ապահովել խափանման ցանկալի հանդուրժողականություն և մասշտաբայնություն (ներառյալ սերվերների միջև ագրեգացված չափումների համաժամացումը և կոնֆլիկտների ուղարկման խնդիրը լուծելը),
• քանի որ հնարավոր է ավելի ճշգրիտ հաշվարկել չափումները, քան դա անում է Բրուբեկը,
• քանի որ դուք ինքներդ կարող եք ավելի մանրամասն վիճակագրություն հավաքել, որը մեզ գործնականում չի տրամադրել բրուբեկը,
• որովհետև ես հնարավորություն ունեի ծրագրավորելու իմ սեփական հիպերպերֆորմանսը, որը բաշխված սանդղակի վրա է, որն ամբողջությամբ չի կրկնի մեկ այլ նմանատիպ հիպերֆորմի ճարտարապետությունը… լավ, վերջ:

ինչի՞ վրա գրել. Իհարկե, Ռուստում: Ինչո՞ւ։

• քանի որ արդեն կար նախատիպ լուծում,
• քանի որ հոդվածի հեղինակն այն ժամանակ արդեն ճանաչում էր Ռաստին և ցանկանում էր դրա մեջ ինչ-որ բան գրել արտադրության համար՝ այն բաց կոդով տեղադրելու հնարավորությամբ,
• քանի որ GC-ով լեզուները մեզ համար հարմար չեն ստացված տրաֆիկի բնույթի պատճառով (գրեթե իրական ժամանակում) և GC-ի դադարները գործնականում անընդունելի են,
• քանի որ ձեզ անհրաժեշտ է առավելագույն կատարողականություն, որը համեմատելի է C-ի հետ
• քանի որ Rust-ը մեզ տալիս է անվախ միաժամանակություն, և եթե մենք սկսեինք գրել այն C/C++-ով, մենք կնկատեինք ավելի շատ խոցելիություններ, բուֆերային հեղեղումներ, մրցավազքի պայմաններ և այլ սարսափելի բառեր, քան brubeck-ը:

Վեճ կար նաև Ռուստի դեմ։ Ընկերությունը Rust-ում նախագծեր ստեղծելու փորձ չուներ, և այժմ մենք նույնպես չենք նախատեսում այն ​​օգտագործել հիմնական նախագծում։ Ուստի լուրջ մտավախություններ կային, որ ոչինչ չի ստացվի, բայց մենք որոշեցինք օգտվել հնարավորությունից և փորձեցինք:

Ժամանակն անցավ...

Ի վերջո, մի քանի անհաջող փորձերից հետո առաջին աշխատանքային տարբերակը պատրաստ էր։ Ինչ է պատահել? Ահա թե ինչ եղավ.

Յուրաքանչյուր հանգույց ստանում է չափումների իր հավաքածուն և կուտակում է դրանք, և չի համախմբում չափումները այն տեսակների համար, որտեղ դրանց ամբողջական հավաքածուն պահանջվում է վերջնական ագրեգացիայի համար: Հանգույցները միմյանց հետ կապված են ինչ-որ բաշխված կողպեքի արձանագրությամբ, որը թույլ է տալիս նրանցից ընտրել միակը (այստեղ մենք լաց եղանք), որն արժանի է չափումներ ուղարկելու Մեծին: Այս խնդիրը ներկայումս լուծվում է Հյուպատոս, բայց ապագայում հեղինակի հավակնությունները տարածվում են սեփական իրականացումը Լաստանավ, որտեղ ամենաարժանավորը, անշուշտ, կլինի կոնսենսուսի առաջնորդի հանգույցը։ Ի հավելումն կոնսենսուսի, հանգույցները բավականին հաճախ (վայրկյանում մեկ անգամ լռելյայն) ուղարկում են իրենց հարևաններին նախապես ագրեգացված չափումների այն մասերը, որոնք նրանք կարողացել են հավաքել այդ վայրկյանում: Պարզվում է, որ մասշտաբը և սխալների հանդուրժողականությունը պահպանված են. յուրաքանչյուր հանգույց դեռևս պարունակում է չափումների ամբողջական փաթեթ, բայց չափումները ուղարկվում են արդեն ագրեգացված, TCP-ի միջոցով և կոդավորված են երկուական արձանագրության մեջ, ուստի կրկնօրինակման ծախսերը զգալիորեն կրճատվում են UDP-ի համեմատ: Չնայած մուտքային ցուցանիշների բավականին մեծ թվին, կուտակումը պահանջում է շատ քիչ հիշողություն և նույնիսկ ավելի քիչ CPU: Մեր բարձր սեղմելի չափանիշների համար սա ընդամենը մի քանի տասնյակ մեգաբայթ տվյալ է: Որպես լրացուցիչ բոնուս՝ մենք չենք ստանում տվյալների ավելորդ վերագրանցումներ Graphite-ում, ինչպես եղավ Burbeck-ի դեպքում:

Չափանիշներով UDP փաթեթները անհավասարակշռված են ցանցային սարքավորումների հանգույցների միջև պարզ Round Robin-ի միջոցով: Իհարկե, ցանցային սարքավորումը չի վերլուծում փաթեթների բովանդակությունը և, հետևաբար, կարող է վայրկյանում քաշել 4M փաթեթից շատ ավելին, էլ չասած չափումների մասին, որոնց մասին ընդհանրապես ոչինչ չգիտի: Եթե ​​հաշվի առնենք, որ չափորոշիչները չեն գալիս յուրաքանչյուր փաթեթում մեկ առ մեկ, ապա այս վայրում մենք չենք կանխատեսում կատարողականի որևէ խնդիր: Եթե ​​սերվերը խափանում է, ցանցային սարքը արագ (1-2 վայրկյանի ընթացքում) հայտնաբերում է այս փաստը և հեռացնում է վթարի ենթարկված սերվերը ռոտացիայից: Սրա արդյունքում պասիվ (այսինքն՝ ոչ առաջատար) հանգույցները կարող են միացնել և անջատվել գործնականում առանց գծապատկերների վրա անկումներ նկատելու։ Առավելագույնը, որը մենք կորցնում ենք, այն չափումների մի մասն է, որը հայտնվեց վերջին վայրկյանին: Առաջնորդի հանկարծակի կորուստը/անջատումը/անջատումը դեռևս կստեղծի աննշան անոմալիա (30 վայրկյան ինտերվալը դեռ համաժամանակացված չէ), բայց եթե հանգույցների միջև հաղորդակցություն կա, այդ խնդիրները կարող են նվազագույնի հասցնել, օրինակ՝ ուղարկելով համաժամացման փաթեթներ: .

Մի փոքր ներքին կառուցվածքի մասին. Հավելվածը, իհարկե, բազմաթելային է, բայց թելերի ճարտարապետությունը տարբերվում է բրուբեքում օգտագործվողից: Բրուբեկի թելերը նույնն են. նրանցից յուրաքանչյուրը պատասխանատու է ինչպես տեղեկատվության հավաքման, այնպես էլ համախմբման համար: Bioyino-ում աշխատողները բաժանվում են երկու խմբի՝ ցանցի համար պատասխանատուներ և ագրեգացիայի համար պատասխանատուներ: Այս բաժանումը թույլ է տալիս ավելի ճկուն կառավարել հավելվածը՝ կախված չափանիշների տեսակից. որտեղ ինտենսիվ ագրեգացիա է պահանջվում, կարող եք ավելացնել ագրեգատորներ, որտեղ շատ ցանցային տրաֆիկ կա, կարող եք ավելացնել ցանցի հոսքերի քանակը: Այս պահին մեր սերվերների վրա մենք աշխատում ենք 8 ցանցային և 4 ագրեգացիոն հոսքերով։

Հաշվիչ (համախմբման համար պատասխանատու) մասը բավականին ձանձրալի է։ Ցանցային հոսքերով լցված բուֆերները բաշխվում են հաշվվող հոսքերի միջև, որտեղ դրանք հետագայում վերլուծվում և ագրեգացվում են: Հարցման դեպքում տրված են չափումներ՝ այլ հանգույցներ ուղարկելու համար։ Այս ամենը, ներառյալ հանգույցների միջև տվյալներ ուղարկելը և հյուպատոսի հետ աշխատելը, կատարվում է ասինխրոն՝ գործարկելով շրջանակի վրա։ Tokio.

Զարգացման ընթացքում շատ ավելի շատ խնդիրներ առաջացան չափումների ստացման համար պատասխանատու ցանցային մասի պատճառով: Ցանցային հոսքերը առանձին սուբյեկտների բաժանելու հիմնական նպատակը հոսքի ծախսած ժամանակը կրճատելու ցանկությունն էր: ոչ վարդակից տվյալները կարդալու համար: Ասինխրոն UDP-ի և սովորական recvmsg-ի օգտագործող ընտրանքները արագ անհետացան. առաջինը սպառում է չափազանց շատ օգտագործողի տարածք՝ իրադարձությունների մշակման համար, երկրորդը պահանջում է չափազանց շատ համատեքստային անջատիչներ: Հետևաբար այն այժմ օգտագործվում է recvmmsg մեծ բուֆերներով (և բուֆերները, պարոնայք սպաներ, ձեզ համար ոչինչ են): Սովորական UDP-ի աջակցությունը վերապահված է թեթև դեպքերի համար, որտեղ recvmmsg կարիք չկա: Բազմահաղորդագրությունների ռեժիմում հնարավոր է հասնել հիմնական բանին. ժամանակի ճնշող մեծամասնությունը ցանցային շարանը հավաքում է ՕՀ-ի հերթը. կարդում է տվյալները վարդակից և փոխանցում այն ​​օգտվողների տարածքի բուֆերին, միայն երբեմն անցնում է լցված բուֆերը տալուն: ագրեգատորներ. Վարդակում հերթը գործնականում չի կուտակվում, ընկած փաթեթների թիվը գործնականում չի աճում։

Նշում

Լռելյայն կարգավորումներում բուֆերի չափը սահմանված է բավականին մեծ: Եթե ​​հանկարծ որոշեք ինքներդ փորձել սերվերը, կարող եք բախվել այն փաստի հետ, որ փոքր թվով չափումներ ուղարկելուց հետո դրանք չեն գա Գրաֆիտ՝ մնալով ցանցի հոսքի բուֆերում։ Փոքր թվով չափումների հետ աշխատելու համար դուք պետք է կազմաձևում սահմանեք bufsize և task-queue-size ավելի փոքր արժեքներ:

Վերջապես, մի ​​քանի գծապատկերներ աղյուսակների սիրահարների համար:

Յուրաքանչյուր սերվերի համար մուտքային չափումների քանակի վիճակագրություն՝ ավելի քան 2 միլիոն MPS:

Հանգույցներից մեկի անջատում և մուտքային չափումների վերաբաշխում:

Վիճակագրություն ելքային չափումների վերաբերյալ. միշտ ուղարկում է միայն մեկ հանգույց՝ ռեյդ բոսը:

Յուրաքանչյուր հանգույցի աշխատանքի վիճակագրություն՝ հաշվի առնելով համակարգի տարբեր մոդուլների սխալները:

Մուտքային չափումների մանրամասնում (մետրային անունները թաքցված են):

Ի՞նչ ենք նախատեսում անել այս ամենի հետ հաջորդիվ: Իհարկե, գրեք կոդ, անիծյալ... Նախագիծն ի սկզբանե նախատեսված էր լինել բաց կոդով և այդպես կմնա իր ողջ կյանքի ընթացքում: Մեր անմիջական ծրագրերը ներառում են Raft-ի մեր սեփական տարբերակին անցնելը, գործընկերային արձանագրությունը ավելի շարժականի փոխելը, լրացուցիչ ներքին վիճակագրության, նոր տեսակի չափումների, վրիպակների շտկում և այլ բարելավումներ:

Իհարկե, բոլորը կարող են օգնել նախագծի զարգացմանը՝ ստեղծել PR, Հարցեր, հնարավորության դեպքում կարձագանքենք, կբարելավենք և այլն։

Այս ասելով, այսքանն է, ժողովուրդ, գնե՛ք մեր փղերին:

Source: www.habr.com