Agrāk, kad runājām par aizmugursistēmu, mēs parasti atsaucāmies uz vienu lielu lietojumprogrammu ar vienu lielu datu bāzi, un uzraudzībai pietika ar reģistrēšanu. Tagad, pateicoties tādām tehnoloģijām kā Kubernetes , mikropakalpojumi ir kļuvuši par standartu. Lietojumprogrammu ir daudz un izplatītākas, un ar tradicionālo reģistrēšanu vairs nepietiek, lai atkļūdotu un diagnosticētu problēmas mūsu lietojumprogrammās.
Lielisks risinājums uzraudzības organizēšanai ir OpenTelemetry — moderns rīku komplekts, ko var izmantot sadalīto sistēmu atkļūdošanai un veiktspējas analīzei.
Šis raksts ir paredzēts IT profesionāļiem, kuri vēlas paplašināt savas zināšanas aizmugursistēmas optimizācijā. Tālāk mēs detalizēti aprakstīsim, kas ir OpenTelemetry, tās galvenie jēdzieni un problēmas, ko tā palīdz atrisināt. Ja jūs interesē, kā OpenTelemetry var mainīt jūsu pieeju aizmugursistēmas uzraudzībai un atkļūdošanai, uzlabojot to uzticamību un efektivitāti, lasiet tālāk.
Lielie tehnoloģiju uzņēmumi pirmo reizi saskārās ar izplatītas mežizstrādes un izsekošanas izaicinājumu 2000. gadu beigās. 2010. gadā Google publicēja rakstu,
2014. gadā parādījās Kubernetes, būtiski vienkāršojot mikropakalpojumu un citu mākoņdatošanas sistēmu izstrādi. Tas noveda pie tā, ka daudzi uzņēmumi saskārās ar problēmām ar izplatītu reģistrēšanu un izsekošanu mikropakalpojumos. Lai standartizētu izplatīto izsekošanu, tika izveidots OpenTracing standarts, ko pieņēma CNCF un Google OpenCensus projekts.
2019. gadā projekti OpenTracing un OpenCensus paziņoja par apvienošanos ar nosaukumu OpenTelemetry. Šī platforma apvieno daudzu gadu laikā uzkrāto labāko praksi, ļaujot netraucēti integrēt izsekošanu, reģistrēšanu un metriku jebkurā sistēmā neatkarīgi no to sarežģītības.
Mūsdienās OpenTelemetry nav tikai projekts; tas ir nozares standarts telemetrijas datu vākšanai un pārsūtīšanai. To izstrādā un atbalsta speciālistu kopiena un tirgū vadošie uzņēmumi, piemēram, Google un Microsoft. Projekts turpina attīstīties, iegūstot jaunas iespējas, lai vienkāršotu integrācijas un lietošanas procesu.
OpenTelemetry ir visaptverošs prakšu un rīku kopums, kas nosaka, kādus signālus lietojumprogramma var ģenerēt, lai mijiedarbotos ar ārpasauli, un kā šos signālus var savākt un vizualizēt, lai uzraudzītu lietojumprogrammu un visas sistēmas stāvokli. Trīs galvenie signālu veidi ir izsekošana, reģistrēšana un metrikas apkopošana .
**Apskatīsim katru komponentu tuvāk: \
OpenTelemetry ievieš operāciju kontekstu jēdzienu. Kontekstā galvenokārt ir ietverti tādi atribūti kā `trace_id`
(pašreizējās darbības identifikators) un `span_id`
(apakšpieprasījuma identifikators, katram apakšpieprasījuma atkārtotajam mēģinājumam ir unikāls `span_id`
).
Turklāt kontekstā var būt ietverta statiska informācija, piemēram, mezgla nosaukums, kurā lietojumprogramma ir izvietota, vai vides nosaukums (prod/qa). Šie lauki, kas OpenTelemetry terminoloģijā tiek dēvēti par resursiem, ir pievienoti katram žurnālam, metrikai vai pēdai, lai atvieglotu meklēšanu. Konteksti var ietvert arī dinamiskus datus, piemēram, pašreizējā galapunkta identifikatoru ( `http_path: "GET /user/:id/info"`
), ko var selektīvi pievienot žurnālu, metrikas vai izsekošanas grupām.
OpenTelemetry kontekstus var nodot starp dažādām lietojumprogrammām, izmantojot konteksta izplatīšanas protokolus. Šie protokoli sastāv no galveņu kopām, kas tiek pievienotas katram HTTP vai gRPC pieprasījumam vai rindu ziņojumu galvenēm. Tas ļauj pakārtotajām lietojumprogrammām rekonstruēt darbības kontekstu no šīm galvenēm.
Šeit ir daži konteksta izplatīšanas piemēri:
B3-Propagation Šī ir galveņu kopa ( x-b3-*
), kas sākotnēji tika izstrādāta Zipkin izsekošanas sistēmai. Tas tika pielāgots programmai OpenTracing, un to izmantoja daudzi rīki un bibliotēkas. B3 — izplatīšanās satur trace_id
/ span_id
un karodziņu, kas norāda, vai ir nepieciešama izlase.
W3C izsekošanas konteksts Šis standarts, ko izstrādājusi W3C darba grupa, apvieno dažādas konteksta izplatīšanas pieejas vienā standartā un ir OpenTelemetry noklusējuma iestatījums. Labs šo standartu piemērošanas piemērs ir pieprasījuma izpildes izsekošana caur mikropakalpojumiem, kas ieviesti ar dažādām tehnoloģijām, neapdraudot uzraudzības un atkļūdošanas precizitāti.
Izsekošana ir process, kurā tiek reģistrēts un pēc tam vizualizēts pieprasījuma ceļa laika skala, izmantojot vairākus mikropakalpojumus.
Vizualizācijā katra josla tiek saukta par "span" un tai ir unikāls "span_id" . Saknes diapazons tiek saukts par "trace" , un tam ir "trace_id" , kas kalpo kā visa pieprasījuma identifikators.
Šis vizualizācijas veids ļauj:
trace_id
un span_id
izmantošanai citos signālos.
Neskatoties uz šķietamo vienkāršību, reģistrēšana joprojām ir viens no jaudīgākajiem rīkiem problēmu diagnosticēšanai. OpenTelemetry uzlabo tradicionālo reģistrēšanu, pievienojot kontekstuālo informāciju. Konkrēti, ja ir aktīva izsekošana, atribūti trace_id un span_id tiek automātiski pievienoti žurnāliem, saistot tos ar izsekošanas laika skalu. Turklāt žurnāla atribūti var ietvert statisku informāciju no OpenTelemetry konteksta, piemēram, mezgla identifikatoru, kā arī dinamisku informāciju, piemēram, pašreizējo HTTP galapunkta identifikatoru (`http_path: "GET /user/:id"`).
Izmantojot “trace_id”, varat atrast žurnālus no visiem mikropakalpojumiem, kas saistīti ar pašreizējo pieprasījumu, savukārt “span_id” ļauj atšķirt apakšpieprasījumus. Piemēram, atkārtotu mēģinājumu gadījumā dažādu mēģinājumu žurnāliem būs atšķirīgs span_id. Šo identifikatoru izmantošana ļauj ātri analizēt visas sistēmas darbību reāllaikā, paātrinot problēmu diagnostiku un uzlabojot stabilitāti un uzticamību.
Metrikas apkopojums nodrošina kvantitatīvus datus par sistēmas veiktspēju, piemēram, latentumu, kļūdu biežumu, resursu izmantošanu un daudz ko citu. Metrikas uzraudzība reāllaikā ļauj operatīvi reaģēt uz veiktspējas izmaiņām, novērst kļūmes un resursu izsmelšanu, kā arī nodrošināt lietotājiem augstu lietojumprogrammas pieejamību un uzticamību.
Integrācija ar metrikas glabāšanas un vizualizācijas sistēmām, piemēram, Prometheus un Grafana, atvieglo šo datu vizualizāciju, ievērojami vienkāršojot uzraudzību.
OpenTelemetry metrikas savācēji ir saderīgi ar Prometheus un OpenMetrics standartiem, ļaujot viegli pāriet uz OpenTelemetry risinājumiem bez būtiskām izmaiņām. OpenTelemetry SDK ļauj eksportēt trace_id piemērus kopā ar metriku, tādējādi ļaujot saistīt metriku ar žurnālu piemēriem un izsekošanas.
Kopā žurnāli, metrika un izsekošana veido visaptverošu priekšstatu par sistēmas stāvokli:
Papildus trim pamatkomponentiem OpenTelemetry ietver iztveršanas, bagāžas un darbības konteksta pārvaldības jēdzienus.
Augstas slodzes sistēmās žurnālu un izsekojumu apjoms kļūst milzīgs, prasot ievērojamus resursus infrastruktūrai un datu glabāšanai. Lai risinātu šo problēmu, OpenTelemetry standarti ietver signālu paraugu ņemšanu — iespēju eksportēt tikai daļu izsekojumu un žurnālu. Piemēram, varat eksportēt detalizētus signālus no pieprasījumu procentuālās daļas, ilgstošiem pieprasījumiem vai kļūdu pieprasījumiem. Šī pieeja ļauj veikt pietiekamu izlasi, lai izveidotu statistiku, vienlaikus ietaupot ievērojamus resursus.
Tomēr, ja katra sistēma neatkarīgi izlemj, kurus pieprasījumus detalizēti pārraudzīt, mēs iegūstam sadrumstalotu katra pieprasījuma skatījumu. Dažas sistēmas var eksportēt detalizētus datus, savukārt citas var eksportēt tikai daļēji vai neeksportēt vispār.
Lai atrisinātu šo problēmu, OpenTelemetry konteksta izplatīšanas mehānismi kopā ar trace_id/span_id nosūta izlases karodziņu. Tas nodrošina, ka gadījumā, ja sākotnējais pakalpojums, kas saņem lietotāja pieprasījumu, nolemj, ka pieprasījums ir rūpīgi jāuzrauga, visas pārējās sistēmas sekos šim piemēram. Pretējā gadījumā visām sistēmām vajadzētu daļēji vai neeksportēt signālus, lai taupītu resursus. Šo pieeju sauc par "galvas paraugu ņemšanu" — lēmums, kas pieņemts pieprasījuma apstrādes sākumā, nejauši vai pamatojoties uz dažiem ievades atribūtiem.
Turklāt OpenTelemetry atbalsta "Astes paraugu ņemšanu", kur visas lietojumprogrammas vienmēr detalizēti eksportē visus signālus, bet pastāv starpposma buferis. Pēc visu datu apkopošanas šis buferis izlemj, vai saglabāt visus datus vai tikai daļēju paraugu. Šī metode ļauj iegūt reprezentatīvāku katras pieprasījuma kategorijas paraugu (veiksmīgs/garš/kļūda), taču tai ir nepieciešama papildu infrastruktūras iestatīšana.
Bagāžas mehānisms ļauj pārsūtīt patvaļīgus atslēgu vērtību pārus kopā ar trace_id
/ span_id
, pieprasījuma apstrādes laikā automātiski pārejot starp visiem mikropakalpojumiem. Tas ir noderīgi, lai pārsūtītu papildu informāciju, kas nepieciešama visā pieprasījuma ceļā, piemēram, lietotāja informāciju vai izpildlaika vides iestatījumus.
Bagāžas pārsūtīšanas galvenes piemērs saskaņā ar W3C standartu: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5
Šeit ir daži bagāžas izmantošanas piemēri:
Biznesa konteksta informācijas nodošana, piemēram, userId
, productId
vai deviceId
var tikt nodota caur visiem mikropakalpojumiem. Lietojumprogrammas var automātiski reģistrēt šo informāciju, ļaujot meklēt žurnālā pēc sākotnējā pieprasījuma lietotāja konteksta.
Īpaši konfigurācijas parametri SDK vai infrastruktūras iestatījumi.
Maršrutēšanas karogi Karogi, kas palīdz slodzes līdzsvarotājiem pieņemt lēmumus par maršrutēšanu. Pārbaudes laikā daži pieprasījumi, iespējams, būs jānovirza, lai imitētu aizmugurprogrammas. Tā kā bagāža tiek automātiski pārsūtīta, izmantojot visus pakalpojumus, nav nepieciešams izveidot papildu protokolus — vienkārši iestatiet kārtulu slodzes balansētājā.
Ņemiet vērā: lai gan bagāžas ietekme uz veiktspēju ir minimāla, pārmērīga lietošana var ievērojami palielināt tīkla un pakalpojumu slodzi. Lai izvairītos no veiktspējas problēmām, rūpīgi izvēlieties, kuri dati jums patiešām ir jāiesniedz caur bagāžu.
OpenTelemetry ieviešana infrastruktūras līmenī ietver OpenTelemetry aizmugursistēmas integrēšanu lietojumprogrammas arhitektūrā un infrastruktūras konfigurēšanu datu apkopošanai.
Process sastāv no četriem posmiem:
Lietojumprogrammu integrācija Pirmajā posmā OpenTelemetry SDK tiek tieši integrēti lietojumprogrammās, lai apkopotu metriku, žurnālus un izsekošanas datus, nodrošinot nepārtrauktu datu plūsmu par katra sistēmas komponenta veiktspēju.
Eksportētāju konfigurēšana Apkopotie dati tiek maršrutēti no lietojumprogrammām caur eksportētājiem uz ārējām sistēmām tālākai apstrādei, piemēram, reģistrēšanas, uzraudzības, izsekošanas vai analītikas sistēmām atkarībā no jūsu vajadzībām.
Apkopošana un glabāšana Šis posms var ietvert datu normalizēšanu, bagātināšanu ar papildu informāciju un datu apvienošanu no dažādiem avotiem, lai izveidotu vienotu priekšstatu par sistēmas stāvokli.
Datu vizualizācija Visbeidzot, apstrādātie dati tiek parādīti kā informācijas paneļi tādās sistēmās kā Grafana (metrikai un izsekojamībai) vai Kibana (žurnāliem). Tas ļauj komandām ātri novērtēt sistēmas stāvokli, noteikt problēmas un tendences un iestatīt brīdinājumus, pamatojoties uz ģenerētajiem signāliem.
Lai integrētu ar lietojumprogrammu, jums ir jāpievieno atbilstošais OpenTelemetry SDK izmantotajai programmēšanas valodai vai jāizmanto bibliotēkas un ietvari, kas tieši atbalsta OpenTelemetry. OpenTelemetry bieži ievieš plaši izmantotas saskarnes no zināmām bibliotēkām, ļaujot veikt nomaiņas. Piemēram, mikrometru bibliotēku parasti izmanto metriku apkopošanai Java ekosistēmā. OpenTelemetry SDK nodrošina mikrometru saskarņu implementācijas, kas ļauj eksportēt metriku, nemainot galveno lietojumprogrammas kodu. Turklāt OpenTelemetry piedāvā vecāku OpenTracing un OpenCensus saskarņu ieviešanu, atvieglojot vienmērīgu migrāciju uz OpenTelemetry.
IT sistēmās OpenTelemetry var kļūt par uzticamu un efektīvu aizmugursistēmu nākotnes atslēgu. Šis rīks vienkāršo atkļūdošanu un uzraudzību, kā arī paver iespējas dziļi izprast lietojumprogrammu veiktspēju un optimizāciju jaunā līmenī. Pievienojieties OpenTelemetry kopienai, lai palīdzētu veidot nākotni, kurā aizmugursistēmas izstrāde ir vienkāršāka un efektīvāka!