Kas yra „OpenTelemetry“ ir kaip ji gali pagerinti jūsų fono kokybę?

Anksčiau, kai kalbėdavome apie užpakalinę programą, dažniausiai kalbėdavome apie vieną didelę programą su viena didele duomenų baze, o registravimo pakakdavo stebėjimui. Dabar dėl tokių technologijų kaip „Kubernetes“ mikropaslaugos tapo standartu. Programų yra daugiau ir jų yra daugiau, o tradicinio registravimo nebepakanka derinant ir diagnozuojant mūsų programų problemas.

Puikus sprendimas organizuojant stebėjimą yra OpenTelemetry – modernus įrankių rinkinys, kuris gali būti naudojamas paskirstytų sistemų derinimui ir našumo analizei.

Šis straipsnis skirtas IT specialistams, norintiems praplėsti savo žinias apie endokrininį optimizavimą. Toliau išsamiai apžvelgsime, kas yra „OpenTelemetry“, pagrindines jos sąvokas ir problemas, kurias ji padeda išspręsti. Jei jus domina, kaip „OpenTelemetry“ gali pakeisti jūsų požiūrį į foninių sistemų stebėjimą ir derinimą, padidindama jų patikimumą ir efektyvumą – skaitykite toliau.

Trumpa „OpenTelemetry“ istorija

Didžiosios technologijų įmonės pirmą kartą susidūrė su paskirstyto medienos ruošos ir sekimo iššūkiu 2000-ųjų pabaigoje. 2010 m. „Google“ paskelbė dokumentą, Dapper, didelio masto paskirstytų sistemų sekimo infrastruktūra , kuris padėjo pagrindus „Twitter“ sekimo įrankiui „Zipkin“, išleistam 2012 m.

2014 metais atsirado Kubernetes, gerokai supaprastinęs mikropaslaugų ir kitų debesyse paskirstytų sistemų kūrimą. Dėl to daugelis įmonių susidūrė su paskirstyto registravimo ir sekimo mikroservisuose problemomis. Siekiant standartizuoti paskirstytą sekimą, buvo sukurtas OpenTracing standartas, priimtas CNCF ir Google OpenCensus projekto.

2019 m. „OpenTracing“ ir „OpenCensus“ projektai paskelbė apie susijungimą pavadinimu „OpenTelemetry“. Ši platforma sujungia per daugelį metų sukauptą geriausią praktiką, leidžiančią sklandžiai integruoti sekimą, registravimą ir metrikas į bet kurią sistemą, nepaisant jų sudėtingumo.

Šiandien „OpenTelemetry“ nėra tik projektas; tai pramonės standartas telemetrijos duomenims rinkti ir perduoti. Jį kuria ir palaiko specialistų ir rinkoje pirmaujančių įmonių, tokių kaip „Google“ ir „Microsoft“, bendruomenė. Projektas toliau tobulinamas, įgydamas naujų galimybių supaprastinti integravimo ir naudojimo procesą.

Kas yra viduje?

„OpenTelemetry“ yra išsamus praktikos ir įrankių rinkinys, apibrėžiantis, kokius signalus programa gali generuoti, kad sąveikautų su išoriniu pasauliu, ir kaip šiuos signalus galima rinkti ir vizualizuoti, kad būtų galima stebėti programų ir visos sistemos būseną. Trys pagrindiniai signalų tipai yra sekimas, registravimas ir metrikos rinkimas .

** Pažvelkime į kiekvieną komponentą atidžiau: \

Kontekstai

OpenTelemetry pristato operacijų kontekstų sąvoką. Kontekstas visų pirma apima atributus, tokius kaip `trace_id` (dabartinės operacijos identifikatorius) ir `span_id` (antrinės užklausos identifikatorius, kai kiekvienas pakartotinis antrinės užklausos bandymas turi unikalų `span_id` ).

Be to, kontekste gali būti statinės informacijos, pvz., mazgo, kuriame įdiegta programa, pavadinimas arba aplinkos pavadinimas (prod/qa). Šie laukai, OpenTelemetry terminologijoje vadinami ištekliais, pridedami prie kiekvieno žurnalo, metrikos ar pėdsako, kad būtų lengviau ieškoti. Kontekstas taip pat gali apimti dinaminius duomenis, pvz., dabartinio galutinio taško identifikatorių ( `http_path: "GET /user/:id/info"` ), kuriuos galima pasirinktinai prijungti prie žurnalų, metrikų ar pėdsakų grupių.

„OpenTelemetry“ kontekstai gali būti perduodami tarp skirtingų programų naudojant konteksto platinimo protokolus. Šiuos protokolus sudaro antraščių rinkiniai, kurie pridedami prie kiekvienos HTTP arba gRPC užklausos arba eilių pranešimų antraštės. Tai leidžia paskesnėms programoms atkurti operacijos kontekstą iš šių antraščių.

Štai keletas konteksto sklaidos pavyzdžių:

1. B3-Propagation Tai antraščių rinkinys ( x-b3-* ), iš pradžių sukurtas Zipkin sekimo sistemai. Jis buvo pritaikytas „OpenTracing“ ir naudojamas daugelyje įrankių bei bibliotekų. B3-Propagation yra trace_id / span_id ir vėliavėlė, nurodanti, ar atranka yra būtina.

   
   

2. W3C sekimo kontekstas Sukurtas W3C darbo grupės, šis standartas sujungia įvairius konteksto skleidimo metodus į vieną standartą ir yra numatytasis OpenTelemetry. Geras šių standartų taikymo pavyzdys yra užklausos vykdymo stebėjimas per mikropaslaugas, įdiegtas naudojant skirtingas technologijas, nepažeidžiant stebėjimo ir derinimo tikslumo.

Atsekimas

Sekimas – tai užklausos kelio laiko juostos per kelias mikropaslaugas įrašymo ir vėliau vizualizavimo procesas.

Vizualizacijoje kiekviena juosta vadinama „span“ ir turi unikalų „span_id“ . Šakninė sritis vadinama „trace“ ir turi „trace_id“ , kuri naudojama kaip visos užklausos identifikatorius.

Šio tipo vizualizacija leidžia:

• Išanalizuokite užklausų vykdymo laiką įvairiose sistemose ir duomenų bazėse, kad nustatytumėte kliūtis, kurias reikia optimizuoti.
• Aptikti ciklines priklausomybes tarp paslaugų.
• Raskite pasikartojančias užklausas. Naudodami sekimo duomenis taip pat galite kurti papildomą analizę, pvz., sukurti mikropaslaugų žemėlapį arba paskirstyti laiką skirtingose sistemose operacijos apdorojimo metu. Net jei nenaudojate sekimo duomenų laiko juostoms vizualizuoti, „OpenTelemetry“ vis tiek generuoja trace_id ir span_id kad būtų galima naudoti kituose signaluose.

Rąstai

Nepaisant akivaizdaus paprastumo, registravimas išlieka viena iš galingiausių problemų diagnozavimo priemonių. „OpenTelemetry“ pagerina tradicinį registravimą, pridėdama kontekstinės informacijos. Tiksliau, jei yra aktyvus sekimas, atributai „trace_id“ ir „span_id“ automatiškai pridedami prie žurnalų, susiejant juos su sekimo laiko juosta. Be to, žurnalo atributai gali apimti statinę informaciją iš „OpenTelemetry“ konteksto, pvz., mazgo identifikatorių, taip pat dinaminę informaciją, pvz., dabartinį HTTP galutinio taško identifikatorių („http_path: GET /user/:id“).

Naudodami „trace_id“, galite rasti žurnalus iš visų mikropaslaugų, susietų su dabartine užklausa, o „span_id“ leidžia atskirti papildomas užklausas. Pavyzdžiui, bandant pakartotinai, skirtingų bandymų žurnalai turės skirtingus „span_id“. Naudojant šiuos identifikatorius, galima greitai analizuoti visos sistemos elgseną realiuoju laiku, pagreitinant problemų diagnostiką ir padidinant stabilumą bei patikimumą.

Metrika

Metrikos rinkimas pateikia kiekybinius sistemos našumo duomenis, pvz., delsą, klaidų dažnį, išteklių naudojimą ir kt. Metrikų stebėjimas realiuoju laiku leidžia operatyviai reaguoti į našumo pokyčius, užkirsti kelią gedimams ir išteklių išeikvojimui bei užtikrinti aukštą programos prieinamumą ir patikimumą vartotojams.

Integracija su metrinių duomenų saugojimo ir vizualizavimo sistemomis, tokiomis kaip „Prometheus“ ir „Grafana“, leidžia lengviau vizualizuoti šiuos duomenis ir žymiai supaprastina stebėjimą.

Metriniai kolektoriai

„OpenTelemetry“ metrikos rinkėjai yra suderinami su „Prometheus“ ir „OpenMetrics“ standartais, todėl be didelių pakeitimų galima lengvai pereiti prie „OpenTelemetry“ sprendimų. OpenTelemetry SDK leidžia eksportuoti trace_id pavyzdžius kartu su metrika, todėl galima susieti metriką su žurnalo pavyzdžiais ir pėdsakais.

Signalo koreliacija

Žurnalai, metrika ir sekimas kartu sukuria išsamų sistemos būsenos vaizdą:

• Žurnaluose pateikiama informacija apie sistemos įvykius, leidžianti greitai nustatyti ir išspręsti klaidas.
• Metrika atspindi kokybinius ir kiekybinius sistemos veikimo rodiklius, tokius kaip atsako laikas arba klaidų dažnis.
• Sekimas papildo šį vaizdą, parodydamas užklausos vykdymo kelią per įvairius sistemos komponentus, padėdamas suprasti jų tarpusavio ryšius. Aiški žurnalų, pėdsakų ir metrikų koreliacija yra išskirtinis „OpenTelemetry“ bruožas. Pavyzdžiui, „Grafana“ leidžia vartotojams peržiūrėti atitinkamą sekimo ir užklausų metriką peržiūrint žurnalą, o tai labai padidina platformos patogumą ir efektyvumą.

Be trijų pagrindinių komponentų, „OpenTelemetry“ apima atrankos, bagažo ir operacijų konteksto valdymo sąvokas.

Mėginių ėmimas

Didelės apkrovos sistemose žurnalų ir pėdsakų kiekis tampa milžiniškas, todėl infrastruktūrai ir duomenų saugojimui reikia didelių išteklių. Siekiant išspręsti šią problemą, OpenTelemetry standartai apima signalų atranką – galimybę eksportuoti tik dalį pėdsakų ir žurnalų. Pavyzdžiui, galite eksportuoti išsamius signalus iš procentų užklausų, ilgalaikių užklausų arba klaidų užklausų. Šis metodas leidžia pakankamai atrinkti statistiką, kartu sutaupant daug išteklių.

Tačiau, jei kiekviena sistema savarankiškai nusprendžia, kurias užklausas išsamiai stebėti, kiekvienos užklausos vaizdas yra fragmentiškas. Kai kurios sistemos gali eksportuoti išsamius duomenis, o kitos gali eksportuoti tik iš dalies arba neeksportuoti iš viso.

Norėdami išspręsti šią problemą, „OpenTelemetry“ konteksto sklaidos mechanizmai kartu su „trace_id“/„span_id“ perduoda atrankos vėliavėlę. Tai užtikrina, kad jei pradinė paslauga, gavusi vartotojo užklausą, nusprendžia, kad užklausą reikia atidžiai stebėti, visos kitos sistemos paseks. Priešingu atveju visos sistemos turėtų iš dalies arba neeksportuoti signalų, kad būtų taupomi ištekliai. Šis metodas vadinamas „Head Sampling“ – sprendimas, priimtas užklausos apdorojimo pradžioje, atsitiktinai arba remiantis kai kuriais įvesties atributais.

Be to, „OpenTelemetry“ palaiko „Uodegos mėginių ėmimą“, kai visos programos visada išsamiai eksportuoja visus signalus, tačiau yra tarpinis buferis. Surinkus visus duomenis, šis buferis nusprendžia, ar išsaugoti visus duomenis, ar palikti tik dalinį mėginį. Šis metodas leidžia gauti reprezentatyvesnį kiekvienos užklausos kategorijos pavyzdį (sėkmingas / ilgas / klaida), tačiau reikia papildomos infrastruktūros sąrankos.

Bagažas

Bagažo mechanizmas leidžia perduoti savavališkas rakto-reikšmių poras kartu su trace_id / span_id , automatiškai perduodamas tarp visų mikro paslaugų apdorojant užklausą. Tai naudinga perduodant papildomą informaciją, reikalingą užklausos kelyje, pvz., vartotojo informaciją arba vykdymo aplinkos nustatymus.

Bagažo perdavimo pagal W3C standartą antraštės pavyzdys: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Štai keli bagažo naudojimo pavyzdžiai:

• Verslo konteksto informacijos, pvz., userId , productId arba deviceId perdavimas gali būti perduodamas per visas mikropaslaugas. Programos gali automatiškai užregistruoti šią informaciją, leidžiančios atlikti žurnalo paieškas pagal vartotojo kontekstą pagal pradinę užklausą.

• Specifiniai konfigūracijos parametrai SDK arba infrastruktūros nustatymai.

• Maršruto nustatymo vėliavėlės Žymės, kurios padeda apkrovos balansuotojams priimti sprendimus dėl maršruto. Atliekant bandymą, kai kurias užklausas gali reikėti nukreipti, kad būtų galima apsimesti užpakalinėmis programomis. Kadangi bagažas automatiškai perduodamas per visas paslaugas, nereikia kurti papildomų protokolų – tiesiog nustatykite taisyklę apkrovos balansavimo priemonėje.

  
  

Infrastruktūros įgyvendinimas

„OpenTelemetry“ diegimas infrastruktūros lygiu apima „OpenTelemetry“ užpakalinių programų integravimą į programos architektūrą ir duomenų kaupimo infrastruktūros konfigūravimą.

Procesas susideda iš keturių etapų:

1. Programų integravimas Pirmajame etape OpenTelemetry SDK yra tiesiogiai integruojami į programas, kad būtų galima rinkti metriką, žurnalus ir pėdsakus, užtikrinant nuolatinį duomenų apie kiekvieno sistemos komponento veikimą srautą.

   
   

2. Eksportuotojų konfigūravimas Surinkti duomenys nukreipiami iš programų per eksportuotojus į išorines sistemas, kad būtų galima toliau apdoroti, pvz., registravimo, stebėjimo, sekimo ar analizės sistemas, atsižvelgiant į jūsų poreikius.

   
   

3. Apibendrinimas ir saugojimas Šiame etape galima normalizuoti duomenis, praturtinti juos papildoma informacija ir sujungti duomenis iš skirtingų šaltinių, kad būtų sukurtas vieningas sistemos būsenos vaizdas.

   
   

4. Duomenų vizualizavimas Galiausiai apdoroti duomenys pateikiami kaip prietaisų skydeliai tokiose sistemose kaip Grafana (metrikai ir pėdsakai) arba Kibana (žurnalams). Tai leidžia komandoms greitai įvertinti sistemos būklę, nustatyti problemas ir tendencijas bei nustatyti įspėjimus pagal generuojamus signalus.

Programos įgyvendinimas

Norėdami integruoti su programa, turite prijungti atitinkamą OpenTelemetry SDK naudojamai programavimo kalbai arba naudoti bibliotekas ir sistemas, kurios tiesiogiai palaiko OpenTelemetry. „OpenTelemetry“ dažnai diegia plačiai naudojamas sąsajas iš žinomų bibliotekų, leidžiančias pakeisti įprastus pakeitimus. Pavyzdžiui, mikrometro biblioteka dažniausiai naudojama metrikai rinkti Java ekosistemoje. „OpenTelemetry SDK“ pateikia mikrometro sąsajų diegimus, leidžiančius eksportuoti metriką nekeičiant pagrindinio programos kodo. Be to, „OpenTelemetry“ siūlo senesnių „OpenTracing“ ir „OpenCensus“ sąsajų diegimus, palengvinančius sklandų perėjimą prie „OpenTelemetry“.

Išvada

IT sistemose OpenTelemetry gali tapti raktu į patikimų ir efektyvių užpakalinių sistemų ateitį. Šis įrankis supaprastina derinimą ir stebėjimą, taip pat atveria galimybes giliai suprasti programos našumą ir optimizuoti nauju lygiu. Prisijunkite prie „OpenTelemetry“ bendruomenės, kad padėtumėte formuoti ateitį, kurioje užpakalinės programos kūrimas yra paprastesnis ir efektyvesnis!