Նախկինում, երբ խոսում էինք backend-ի մասին, մենք սովորաբար դիմում էինք մեկ մեծ հավելվածի մեկ, մեծ տվյալների բազայով, և գրանցումը բավարար էր մոնիտորինգի համար: Այժմ, Kubernetes-ի նման տեխնոլոգիաների շնորհիվ, միկրոծառայությունները դարձել են ստանդարտ: Հավելվածներն ավելի շատ են և բաշխված, և ավանդական գրանցումն այլևս բավարար չէ մեր հավելվածներում առկա խնդիրները վրիպազերծելու և ախտորոշելու համար:
Մոնիտորինգի կազմակերպման հիանալի լուծում է OpenTelemetry-ն՝ ժամանակակից գործիքակազմ, որը կարող է օգտագործվել բաշխված համակարգերի վրիպազերծման և կատարողականի վերլուծության համար:
Այս հոդվածը նախատեսված է ՏՏ մասնագետների համար, ովքեր ձգտում են ընդլայնել իրենց գիտելիքները backend-ի օպտիմալացման ոլորտում: Ստորև մենք մանրամասն կներկայացնենք, թե ինչ է OpenTelemetry-ն, դրա հիմնական հասկացությունները և այն խնդիրները, որոնք այն օգնում է լուծել: Եթե ձեզ հետաքրքրում է, թե ինչպես OpenTelemetry-ն կարող է փոխել ձեր մոտեցումը հետևի համակարգերի մոնիտորինգի և վրիպազերծման նկատմամբ՝ բարձրացնելով դրանց հուսալիությունն ու արդյունավետությունը, կարդացեք շարունակությունը:
Խոշոր տեխնոլոգիական ընկերությունները առաջին անգամ բախվեցին բաշխված անտառահատումների և հետագծման մարտահրավերին 2000-ականների վերջին: 2010 թվականին Google-ը հրապարակեց մի փաստաթուղթ,
2014 թվականին ի հայտ եկավ Kubernetes-ը՝ զգալիորեն պարզեցնելով միկրոծառայությունների և այլ ամպային բաշխված համակարգերի զարգացումը։ Սա հանգեցրեց նրան, որ շատ ընկերություններ բախվեցին միկրոծառայությունների բաշխված անտառահատումների և հետագծման հետ կապված խնդիրների հետ: Բաշխված հետագծումը ստանդարտացնելու համար ստեղծվել է OpenTracing ստանդարտը, որն ընդունվել է CNCF-ի և Google-ի OpenCensus նախագծի կողմից:
2019 թվականին OpenTracing և OpenCensus նախագծերը հայտարարեցին միաձուլման մասին OpenTelemetry անունով: Այս հարթակը միավորում է երկար տարիների ընթացքում կուտակված լավագույն փորձը՝ թույլ տալով հետագծման, գրանցման և չափումների անխափան ինտեգրումը ցանկացած համակարգում՝ անկախ դրանց բարդությունից:
Այսօր OpenTelemetry-ն պարզապես նախագիծ չէ. դա արդյունաբերության ստանդարտ է հեռաչափության տվյալների հավաքագրման և փոխանցման համար: Այն մշակվել և աջակցվում է մասնագետների համայնքի և շուկայի առաջատար ընկերությունների կողմից, ինչպիսիք են Google-ը և Microsoft-ը: Նախագիծը շարունակում է զարգանալ՝ ձեռք բերելով նոր հնարավորություններ՝ ինտեգրման և օգտագործման գործընթացը պարզեցնելու համար:
OpenTelemetry-ն պրակտիկաների և գործիքների համապարփակ հավաքածու է, որը սահմանում է, թե ինչ ազդանշաններ կարող է ստեղծել հավելվածը՝ արտաքին աշխարհի հետ փոխազդելու համար, և ինչպես կարող են այդ ազդանշանները հավաքվել և պատկերացվել՝ վերահսկելու հավելվածների և համակարգի վիճակը որպես ամբողջություն: Ազդանշանների երեք հիմնական տեսակներն են՝ հետագծումը, գրանցումը և չափումների հավաքագրումը :
**Եկեք ավելի սերտ նայենք յուրաքանչյուր բաղադրիչին.
OpenTelemetry-ն ներկայացնում է շահագործման համատեքստերի հայեցակարգը: Համատեքստը հիմնականում ներառում է այնպիսի ատրիբուտներ, ինչպիսիք են՝ `trace_id`
(ընթացիկ գործողության նույնացուցիչը) և `span_id`
(ենթախնդրանքի նույնացուցիչը, ընդ որում ենթահարկի յուրաքանչյուր կրկնություն ունի յուրահատուկ `span_id`
):
Բացի այդ, համատեքստը կարող է պարունակել ստատիկ տեղեկատվություն, օրինակ՝ հանգույցի անունը, որտեղ տեղադրվում է հավելվածը կամ շրջակա միջավայրի անունը (prod/qa): Այս դաշտերը, որոնք հայտնի են որպես ռեսուրսներ OpenTelemetry տերմինաբանության մեջ, կցվում են յուրաքանչյուր մատյանին, չափագրությանը կամ հետքին՝ ավելի հեշտ որոնելու համար: Համատեքստերը կարող են ներառել նաև դինամիկ տվյալներ, օրինակ՝ ընթացիկ վերջնակետի նույնացուցիչը ( `http_path: "GET /user/:id/info"`
), որոնք կարող են ընտրովի կերպով կցվել տեղեկամատյանների, չափումների կամ հետքերի խմբերին:
OpenTelemetry համատեքստերը կարող են փոխանցվել տարբեր հավելվածների միջև՝ օգտագործելով համատեքստի տարածման արձանագրությունները: Այս արձանագրությունները բաղկացած են վերնագրերի հավաքածուներից, որոնք ավելացվում են HTTP կամ gRPC յուրաքանչյուր հարցումին կամ հերթերի հաղորդագրությունների վերնագրերին: Սա թույլ է տալիս ներքևի հավելվածներին այս վերնագրերից վերակառուցել գործողության համատեքստը:
Ահա համատեքստի տարածման մի քանի օրինակ.
B3-Տարածում Սա վերնագրերի մի շարք է ( x-b3-*
), որն ի սկզբանե մշակվել է Zipkin հետագծման համակարգի համար: Այն հարմարեցվել է OpenTracing-ին և օգտագործվել բազմաթիվ գործիքների և գրադարանների կողմից: B3-Propagation-ը կրում է trace_id
/ span_id
և դրոշակ, որը ցույց է տալիս, թե արդյոք անհրաժեշտ է նմուշառում:
W3C Trace Context Մշակված W3C աշխատանքային խմբի կողմից՝ այս ստանդարտը միավորում է համատեքստի տարածման տարբեր մոտեցումները մեկ ստանդարտի մեջ և հանդիսանում է կանխադրված OpenTelemetry-ում: Այս ստանդարտների կիրառման լավ օրինակն է տարբեր տեխնոլոգիաներով իրականացվող միկրոծառայությունների միջոցով անցնող հարցումների կատարմանը հետևելը՝ առանց մոնիտորինգի և վրիպազերծման ճշգրտության խախտման:
Հետագծումը մի քանի միկրոծառայությունների միջոցով հարցման ուղու ժամանակացույցի գրանցման և հետագայում վիզուալացման գործընթաց է:
Վիզուալիզացիայի մեջ յուրաքանչյուր տող կոչվում է «span» և ունի յուրահատուկ «span_id» : Արմատային տարածությունը կոչվում է «հետք» և ունի «trace_id» , որը ծառայում է որպես ամբողջ հարցման նույնացուցիչ:
Վիզուալիզացիայի այս տեսակը թույլ է տալիս.
trace_id
և span_id
՝ այլ ազդանշաններում օգտագործելու համար:
Չնայած իր ակնհայտ պարզությանը, անտառահատումները մնում են խնդիրների ախտորոշման ամենահզոր գործիքներից մեկը: OpenTelemetry-ն բարելավում է ավանդական անտառահատումները՝ ավելացնելով համատեքստային տեղեկատվություն: Մասնավորապես, եթե առկա է ակտիվ հետք, «trace_id» և «span_id» ատրիբուտներն ավտոմատ կերպով ավելացվում են տեղեկամատյաններում՝ դրանք կապելով հետագծման ժամանակացույցի հետ: Ավելին, մատյան ատրիբուտները կարող են ներառել ստատիկ տեղեկատվություն OpenTelemetry-ի համատեքստից, ինչպես, օրինակ, հանգույցի նույնացուցիչը, ինչպես նաև դինամիկ տեղեկատվություն, ինչպիսին է ներկայիս HTTP վերջնակետի նույնացուցիչը (`http_path: «GET /user/:id»`):
Օգտագործելով «trace_id»-ը, դուք կարող եք գտնել տեղեկամատյաններ բոլոր միկրոծառայություններից, որոնք կապված են ընթացիկ հարցման հետ, մինչդեռ «span_id»-ը թույլ է տալիս տարբերակել ենթահարկերը: Օրինակ, կրկնակի փորձերի դեպքում տարբեր փորձերից տեղեկամատյանները կունենան տարբեր «span_id»: Այս նույնացուցիչների օգտագործումը հնարավորություն է տալիս արագ վերլուծել ամբողջ համակարգի վարքագիծը իրական ժամանակում՝ արագացնելով խնդրի ախտորոշումը և բարձրացնելով կայունությունն ու հուսալիությունը:
Չափումների հավաքածուն տրամադրում է քանակական տվյալներ համակարգի կատարողականի վերաբերյալ, ինչպիսիք են ուշացումը, սխալի մակարդակը, ռեսուրսների օգտագործումը և այլն: Չափումների իրական ժամանակի մոնիտորինգը թույլ է տալիս արագ արձագանքել կատարողականի փոփոխություններին, կանխել ձախողումները և ռեսուրսների սպառումը և ապահովել օգտատերերի համար հավելվածի բարձր հասանելիությունն ու հուսալիությունը:
Ինտեգրումը մետրային պահպանման և վիզուալիզացիայի համակարգերի հետ, ինչպիսիք են Prometheus-ը և Grafana-ն, հեշտացնում է այս տվյալների պատկերացումը՝ զգալիորեն պարզեցնելով մոնիտորինգը:
OpenTelemetry մետրային կոլեկցիոներները համատեղելի են Prometheus և OpenMetrics ստանդարտների հետ՝ հնարավորություն տալով հեշտությամբ անցնել OpenTelemetry լուծումներին՝ առանց էական փոփոխությունների: OpenTelemetry SDK-ն թույլ է տալիս trace_id օրինակները արտահանել չափումների հետ մեկտեղ՝ հնարավորություն տալով համեմատել չափումները մատյանների օրինակների և հետքերի հետ:
Միասին տեղեկամատյանները, չափումները և հետագծումը ստեղծում են համակարգի վիճակի համապարփակ պատկերացում.
Բացի երեք հիմնական բաղադրիչներից, OpenTelemetry-ն ներառում է նմուշառման, ուղեբեռի և շահագործման համատեքստի կառավարում հասկացությունները:
Բարձր բեռնվածության համակարգերում տեղեկամատյանների և հետքերի ծավալը դառնում է հսկայական՝ պահանջելով զգալի ռեսուրսներ ենթակառուցվածքի և տվյալների պահպանման համար: Այս խնդիրը լուծելու համար OpenTelemetry-ի ստանդարտները ներառում են ազդանշանի նմուշառում՝ միայն հետքերի և տեղեկամատյանների մի մասը արտահանելու հնարավորություն: Օրինակ, դուք կարող եք մանրամասն ազդանշաններ արտահանել հարցումների տոկոսից, երկարաժամկետ հարցումներից կամ սխալի հարցումներից: Այս մոտեցումը թույլ է տալիս բավարար նմուշառում կատարել վիճակագրություն ստեղծելու համար՝ միաժամանակ խնայելով զգալի ռեսուրսներ:
Այնուամենայնիվ, եթե յուրաքանչյուր համակարգ ինքնուրույն որոշում է, թե որ հարցումները պետք է մանրամասնորեն մոնիտորինգի ենթարկվի, մենք ի վերջո ստանում ենք յուրաքանչյուր հարցումի մասնատված տեսակետ: Որոշ համակարգեր կարող են արտահանել մանրամասն տվյալներ, իսկ մյուսները կարող են միայն մասամբ արտահանել կամ ընդհանրապես չարտահանել:
Այս խնդիրը լուծելու համար OpenTelemetry-ի համատեքստի տարածման մեխանիզմները «trace_id»/`span_id»-ի հետ միասին փոխանցում են նմուշառման դրոշակ: Սա ապահովում է, որ եթե օգտագործողի հարցումը ստացող սկզբնական ծառայությունը որոշի, որ հարցումը պետք է մանրամասն վերահսկվի, մյուս բոլոր համակարգերը կհետևեն օրինակին: Հակառակ դեպքում, բոլոր համակարգերը պետք է մասամբ կամ չարտահանեն ազդանշաններ ռեսուրսները պահպանելու համար: Այս մոտեցումը կոչվում է «Գլխի նմուշառում»՝ որոշում, որն ընդունվում է հարցումների մշակման սկզբում, պատահականորեն կամ որոշ մուտքային հատկանիշների հիման վրա:
Բացի այդ, OpenTelemetry-ն աջակցում է «Tail Sampling», որտեղ բոլոր հավելվածները միշտ մանրամասն արտահանում են բոլոր ազդանշանները, բայց միջանկյալ բուֆեր գոյություն ունի: Բոլոր տվյալները հավաքելուց հետո այս բուֆերը որոշում է՝ պահպանել ամբողջական տվյալները, թե պահպանել միայն մասնակի նմուշ: Այս մեթոդը թույլ է տալիս յուրաքանչյուր հարցման կատեգորիայի ավելի ներկայացուցչական նմուշ (հաջող/երկար/սխալ), սակայն պահանջում է լրացուցիչ ենթակառուցվածքի կարգավորում:
Ուղեբեռի մեխանիզմը թույլ է տալիս կամայական բանալի-արժեք զույգեր փոխանցել trace_id
/ span_id
ի հետ միասին՝ ավտոմատ կերպով անցնելով բոլոր միկրոծառայությունների միջև հարցումների մշակման ընթացքում: Սա օգտակար է հարցման ուղու ողջ ընթացքում անհրաժեշտ լրացուցիչ տեղեկատվության փոխանցման համար, ինչպիսիք են օգտատիրոջ տեղեկատվությունը կամ գործարկման միջավայրի կարգավորումները:
Ուղեբեռի փոխանցման վերնագրի օրինակ՝ ըստ W3C ստանդարտի. tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5
Ահա ուղեբեռի օգտագործման որոշ օրինակներ.
Բիզնեսի համատեքստի փոխանցում Տեղեկություններ, ինչպիսիք են userId
, productId
կամ deviceId
կարող են փոխանցվել բոլոր միկրոծառայությունների միջոցով: Հավելվածները կարող են ավտոմատ կերպով մուտքագրել այս տեղեկատվությունը, թույլ տալով որոնումներ կատարել ըստ օգտագործողի համատեքստի՝ սկզբնական հարցման համար:
Հատուկ կազմաձևման պարամետրերի կարգավորումներ SDK-ների կամ ենթակառուցվածքների համար:
Routing Flags Դրոշներ, որոնք օգնում են բեռի հավասարակշռողներին երթուղային որոշումներ կայացնել: Փորձարկման ընթացքում որոշ հարցումներ կարող է անհրաժեշտ լինել ուղղորդել ծաղրական հետին պլանների համար: Քանի որ ուղեբեռը ավտոմատ կերպով փոխանցվում է բոլոր ծառայությունների միջոցով, կարիք չկա ստեղծել լրացուցիչ արձանագրություններ, պարզապես սահմանեք կանոն բեռնվածքի հավասարակշռության վրա:
Նկատի ունեցեք, որ չնայած ուղեբեռի արդյունավետության ազդեցությունը նվազագույն է, չափից ավելի օգտագործումը կարող է զգալիորեն մեծացնել ցանցի և ծառայությունների ծանրաբեռնվածությունը: Զգուշորեն ընտրեք, թե որ տվյալներն իսկապես պետք է փոխանցեք ուղեբեռի միջոցով՝ աշխատանքի հետ կապված խնդիրներից խուսափելու համար:
Ենթակառուցվածքի մակարդակում OpenTelemetry-ի ներդրումը ներառում է OpenTelemetry-ի հետին մասի ինտեգրումը հավելվածի ճարտարապետության մեջ և ենթակառուցվածքի կազմաձևումը տվյալների ագրեգացման համար:
Գործընթացը բաղկացած է չորս փուլից.
Հավելվածների ինտեգրում Առաջին փուլում OpenTelemetry SDK-ները ուղղակիորեն ինտեգրվում են հավելվածների մեջ՝ չափումներ, տեղեկամատյաններ և հետքեր հավաքելու համար՝ ապահովելով տվյալների շարունակական հոսք համակարգի յուրաքանչյուր բաղադրիչի աշխատանքի վերաբերյալ:
Արտահանողների կազմաձևում Հավաքված տվյալները հավելվածներից արտահանողների միջոցով փոխանցվում են արտաքին համակարգեր՝ հետագա մշակման համար, ինչպիսիք են գրանցումը, մոնիտորինգը, հետագծումը կամ վերլուծական համակարգերը՝ կախված ձեր կարիքներից:
Համախմբում և պահպանում Այս փուլը կարող է ներառել տվյալների նորմալացում, լրացուցիչ տեղեկություններով հարստացում և տարբեր աղբյուրներից ստացված տվյալների միաձուլում՝ համակարգի վիճակի միասնական պատկերացում ստեղծելու համար:
Տվյալների պատկերացում Վերջապես, մշակված տվյալները ներկայացվում են որպես վահանակներ այնպիսի համակարգերում, ինչպիսիք են Grafana-ն (չափումների և հետքերի համար) կամ Kibana-ն (տեղեկամատյանների համար): Սա թիմերին թույլ է տալիս արագորեն գնահատել համակարգի առողջությունը, բացահայտել խնդիրներն ու միտումները, ինչպես նաև ստեղծել ահազանգեր՝ հիմնված գեներացված ազդանշանների վրա:
Հավելվածի հետ ինտեգրվելու համար դուք պետք է միացնեք համապատասխան OpenTelemetry SDK-ն օգտագործվող ծրագրավորման լեզվի համար կամ օգտագործեք գրադարաններ և շրջանակներ, որոնք ուղղակիորեն աջակցում են OpenTelemetry-ին: OpenTelemetry-ն հաճախ կիրառում է լայնորեն օգտագործվող ինտերֆեյսներ հայտնի գրադարաններից՝ թույլ տալով բացվող փոխարինումներ: Օրինակ, Micrometer գրադարանը սովորաբար օգտագործվում է չափումների հավաքագրման համար Java էկոհամակարգում: OpenTelemetry SDK-ն ապահովում է Micrometer ինտերֆեյսների իր իրականացումները՝ հնարավորություն տալով մետրային արտահանում առանց հիմնական հավելվածի կոդը փոխելու: Ավելին, OpenTelemetry-ն առաջարկում է ավելի հին OpenTracing և OpenCensus ինտերֆեյսների իրականացում, ինչը հեշտացնում է սահուն միգրացիան դեպի OpenTelemetry:
ՏՏ համակարգերում OpenTelemetry-ն կարող է դառնալ հուսալի և արդյունավետ backend-ների ապագայի բանալին: Այս գործիքը հեշտացնում է վրիպազերծումը և մոնիտորինգը, ինչպես նաև հնարավորություններ է բացում նոր մակարդակում հավելվածի կատարողականի և օպտիմալացման խորը ընկալման համար: Միացե՛ք OpenTelemetry համայնքին՝ օգնելու ձևավորել ապագա, որտեղ backend-ի մշակումն ավելի պարզ և արդյունավետ է: