Çfarë është OpenTelemetry dhe si mund të përmirësojë cilësinë tuaj të backend?

Në të kaluarën, kur flisnim për backend-in, zakonisht i referoheshim një aplikacioni të madh me një bazë të dhënash të vetme, të madhe dhe regjistrimi ishte i mjaftueshëm për monitorim. Tani, falë teknologjive si Kubernetes , mikroshërbimet janë bërë standardi. Aplikacionet janë më të shumta dhe më të shpërndara, dhe regjistrimi tradicional nuk mjafton më për korrigjimin dhe diagnostikimin e problemeve në aplikacionet tona.

Një zgjidhje e shkëlqyer për organizimin e monitorimit është OpenTelemetry - një vegël moderne që mund të përdoret për korrigjimin dhe analizën e performancës së sistemeve të shpërndara.

Ky artikull është menduar për profesionistët e IT-së që kërkojnë të zgjerojnë njohuritë e tyre në optimizimin e backend-it. Më poshtë, do të detajojmë se çfarë është OpenTelemetry, konceptet kryesore të tij dhe problemet që ndihmon në zgjidhjen e saj. Nëse jeni të interesuar se si OpenTelemetry mund të ndryshojë qasjen tuaj ndaj monitorimit dhe korrigjimit të sistemeve të backend-it, duke rritur besueshmërinë dhe efikasitetin e tyre - lexoni më tej.

Një histori e shkurtër e OpenTelemetry

Kompanitë e mëdha të teknologjisë së pari u përballën me sfidën e prerjeve dhe gjurmimit të shpërndarë në fund të viteve 2000. Në vitin 2010, Google publikoi një punim, Dapper, një infrastrukturë e gjurmimit të sistemeve të shpërndara në shkallë të gjerë , i cili hodhi themelet për mjetin gjurmues të Twitter, Zipkin, i lëshuar në 2012.

Në vitin 2014, Kubernetes u shfaq, duke thjeshtuar ndjeshëm zhvillimin e mikroshërbimeve dhe sistemeve të tjera të shpërndara në renë kompjuterike. Kjo bëri që shumë kompani të hasin probleme me prerjet dhe gjurmimin e shpërndarë në mikroshërbime. Për të standardizuar gjurmimin e shpërndarë, u krijua standardi OpenTracing, i miratuar nga CNCF dhe projekti OpenCensus i Google.

Në vitin 2019, projektet OpenTracing dhe OpenCensus njoftuan një bashkim me emrin OpenTelemetry. Kjo platformë kombinon praktikat më të mira të grumbulluara gjatë shumë viteve, duke lejuar integrimin pa probleme të gjurmimit, regjistrimit dhe matjeve në çdo sistem, pavarësisht nga kompleksiteti i tyre.

Sot, OpenTelemetry nuk është thjesht një projekt; është një standard i industrisë për mbledhjen dhe transmetimin e të dhënave telemetrike. Është zhvilluar dhe mbështetur nga një komunitet specialistësh dhe kompanish lider në treg si Google dhe Microsoft. Projekti vazhdon të evoluojë, duke fituar aftësi të reja për të thjeshtuar procesin e integrimit dhe përdorimit.

Çfarë ka Brenda?

OpenTelemetry është një grup gjithëpërfshirës praktikash dhe mjetesh që përcaktojnë se çfarë sinjalesh mund të gjenerojë një aplikacion për të ndërvepruar me botën e jashtme dhe se si këto sinjale mund të mblidhen dhe vizualizohen për të monitoruar gjendjen e aplikacioneve dhe të sistemit në tërësi. Tre llojet kryesore të sinjaleve janë gjurmimi, regjistrimi dhe mbledhja e metrikës .

**Le t'i hedhim një vështrim më të afërt secilit komponent: \

Kontekste

OpenTelemetry prezanton konceptin e konteksteve të funksionimit. Një kontekst përfshin kryesisht atribute të tilla si `trace_id` (identifikues për operacionin aktual) dhe `span_id` (identifikues për një nënkërkesë, me çdo riprovim të një nënkërkese që ka një `span_id` unik).

Për më tepër, një kontekst mund të përmbajë informacion statik, siç është emri i nyjës ku është vendosur aplikacioni ose emri i mjedisit (prod/qa). Këto fusha, të njohura si burime në terminologjinë OpenTelemetry, janë bashkangjitur në çdo regjistër, metrikë ose gjurmë për kërkim më të lehtë. Kontekstet mund të përfshijnë gjithashtu të dhëna dinamike, si p.sh. identifikuesin e pikës përfundimtare aktuale ( `http_path: "GET /user/:id/info"` ), të cilat mund t'i bashkëngjiten në mënyrë selektive grupeve të regjistrave, metrikave ose gjurmëve.

Kontekset e OpenTelemetry mund të kalojnë ndërmjet aplikacioneve të ndryshme duke përdorur protokollet e përhapjes së kontekstit. Këto protokolle përbëhen nga grupe kokash që shtohen në çdo kërkesë HTTP ose gRPC ose titujt e mesazheve për radhët. Kjo i lejon aplikacionet e poshtme të rindërtojnë kontekstin e funksionimit nga këto tituj.

Këtu janë disa shembuj të përhapjes së kontekstit:

1. B3-Përhapja Ky është një grup kokash ( x-b3-* ) i zhvilluar fillimisht për sistemin e gjurmimit Zipkin. Ai u përshtat në OpenTracing dhe u përdor nga shumë mjete dhe biblioteka. B3-Përhapja mbart trace_id / span_id dhe një flamur që tregon nëse kampionimi është i nevojshëm.

   
   

2. W3C Trace Context I zhvilluar nga grupi i punës W3C, ky standard unifikon qasje të ndryshme të përhapjes së kontekstit në një standard të vetëm dhe është parazgjedhja në OpenTelemetry. Një shembull i mirë i aplikimit të këtyre standardeve është gjurmimi i ekzekutimit të një kërkese që kalon përmes mikroshërbimeve të implementuara me teknologji të ndryshme pa cenuar saktësinë e monitorimit dhe korrigjimit.

Gjurmimi

Gjurmimi është procesi i regjistrimit dhe më pas vizualizimit të afatit kohor të rrugës së një kërkese përmes mikroshërbimeve të shumta.

Në vizualizim, çdo shirit quhet "span" dhe ka një "span_id" unik. Hapësira e rrënjës referohet si "gjurmë" dhe ka një "trace_id" , e cila shërben si identifikues për të gjithë kërkesën.

Ky lloj vizualizimi ju lejon të:

• Analizoni kohën e ekzekutimit të kërkesave nëpër sisteme dhe baza të të dhënave të ndryshme për të identifikuar pengesat që kanë nevojë për optimizim.
• Zbuloni varësitë ciklike midis shërbimeve.
• Gjeni kërkesa të dyfishta. Duke përdorur të dhënat e gjurmimit, mund të ndërtoni gjithashtu analiza shtesë, të tilla si krijimi i një harte mikroshërbimesh ose shpërndarja e kohës nëpër sisteme të ndryshme gjatë përpunimit të funksionimit. Edhe nëse nuk përdorni të dhënat e gjurmimit për të vizualizuar afatet kohore, OpenTelemetry ende gjeneron trace_id dhe span_id për përdorim në sinjale të tjera.

Regjistrat

Megjithë thjeshtësinë e tij të dukshme, logging mbetet një nga mjetet më të fuqishme për diagnostikimin e problemeve. OpenTelemetry përmirëson prerjet tradicionale duke shtuar informacion kontekstual. Në mënyrë të veçantë, nëse një gjurmë aktive është e pranishme, atributet "trace_id" dhe "span_id" shtohen automatikisht në regjistrat, duke i lidhur ato me afatin kohor të gjurmimit. Për më tepër, atributet e regjistrit mund të përfshijnë informacion statik nga konteksti OpenTelemetry, siç është identifikuesi i nyjes, si dhe informacioni dinamik, si identifikuesi aktual i pikës fundore HTTP (`http_path: "GET /user/:id"`).

Duke përdorur "trace_id", ju mund të gjeni regjistra nga të gjitha mikroshërbimet e lidhura me kërkesën aktuale, ndërsa "span_id" ju lejon të bëni dallimin midis nënkërkesave. Për shembull, në rastin e riprovave, regjistrat nga përpjekje të ndryshme do të kenë `span_id` të ndryshme. Përdorimi i këtyre identifikuesve mundëson analizë të shpejtë të sjelljes së të gjithë sistemit në kohë reale, duke përshpejtuar diagnostikimin e problemit dhe duke rritur stabilitetin dhe besueshmërinë.

Metrikë

Mbledhja e matjeve ofron të dhëna sasiore për performancën e sistemit, si vonesa, shkallët e gabimeve, përdorimin e burimeve dhe më shumë. Monitorimi në kohë reale i metrikës ju lejon të përgjigjeni menjëherë ndaj ndryshimeve të performancës, të parandaloni dështimet dhe shterimin e burimeve dhe të siguroni disponueshmëri dhe besueshmëri të lartë të aplikacionit për përdoruesit.

Integrimi me sistemet e ruajtjes dhe vizualizimit metrik si Prometheus dhe Grafana e bën më të lehtë vizualizimin e këtyre të dhënave, duke thjeshtuar ndjeshëm monitorimin.

Mbledhësit metrikë

Koleksionistët metrikë OpenTelemetry janë të pajtueshëm me standardet Prometheus dhe OpenMetrics, duke mundësuar një kalim të lehtë në zgjidhjet OpenTelemetry pa ndryshime të rëndësishme. OpenTelemetry SDK lejon që shembujt e trace_id të eksportohen së bashku me metrikat, duke bërë të mundur lidhjen e metrikës me shembujt dhe gjurmët e regjistrave.

Korrelacioni i sinjalit

Së bashku, regjistrat, metrikat dhe gjurmimi krijojnë një pamje gjithëpërfshirëse të gjendjes së sistemit:

• Regjistrat ofrojnë informacion rreth ngjarjeve të sistemit, duke lejuar identifikimin dhe zgjidhjen e shpejtë të gabimeve.
• Metrikat pasqyrojnë tregues cilësorë dhe sasiorë të performancës së sistemit, të tilla si kohët e përgjigjes ose shkallët e gabimit.
• Gjurmimi e plotëson këtë pamje duke treguar rrugën e ekzekutimit të kërkesës përmes komponentëve të ndryshëm të sistemit, duke ndihmuar në kuptimin e ndërlidhjeve të tyre. Lidhja e qartë midis regjistrave, gjurmëve dhe matjeve është një tipar dallues i OpenTelemetry. Për shembull, Grafana i lejon përdoruesit të shohin gjurmët përkatëse dhe metrikat e kërkesave kur shikojnë një regjistër, duke rritur shumë përdorshmërinë dhe efikasitetin e platformës.

Përveç tre komponentëve thelbësorë, OpenTelemetry përfshin konceptet e kampionimit, bagazhit dhe menaxhimit të kontekstit të funksionimit.

Marrja e mostrave

Në sistemet me ngarkesë të lartë, vëllimi i regjistrave dhe gjurmëve bëhet i madh, duke kërkuar burime të konsiderueshme për infrastrukturën dhe ruajtjen e të dhënave. Për të adresuar këtë çështje, standardet e OpenTelemetry përfshijnë marrjen e mostrave të sinjalit - aftësinë për të eksportuar vetëm një pjesë të gjurmëve dhe regjistrave. Për shembull, mund të eksportoni sinjale të detajuara nga një përqindje e kërkesave, kërkesave afatgjata ose kërkesave për gabime. Kjo qasje lejon marrjen e mostrave të mjaftueshme për të ndërtuar statistika duke kursyer burime të konsiderueshme.

Megjithatë, nëse secili sistem vendos në mënyrë të pavarur se cilat kërkesa të monitorojë në detaje, ne përfundojmë me një pamje të fragmentuar të secilës kërkesë. Disa sisteme mund të eksportojnë të dhëna të detajuara ndërsa të tjerët mund të eksportojnë vetëm pjesërisht ose të mos eksportojnë fare.

Për të zgjidhur këtë problem, mekanizmat e përhapjes së kontekstit të OpenTelemetry transmetojnë një flamur të mostrës së bashku me `trace_id`/`span_id`. Kjo siguron që nëse shërbimi fillestar që merr kërkesën e përdoruesit vendos që kërkesa duhet të monitorohet në detaje, të gjitha sistemet e tjera do të ndjekin shembullin. Përndryshe, të gjitha sistemet duhet të eksportojnë pjesërisht ose jo sinjale për të ruajtur burimet. Kjo qasje quhet "Kampionimi i kokës" - një vendim i marrë në fillim të përpunimit të kërkesës, qoftë rastësisht ose bazuar në disa atribute hyrëse.

Përveç kësaj, OpenTelemetry mbështet "Tail Sampling", ku të gjitha aplikacionet gjithmonë eksportojnë të gjitha sinjalet në detaje, por ekziston një tampon i ndërmjetëm. Pas mbledhjes së të gjitha të dhënave, ky buffer vendos nëse do të mbajë të dhënat e plota ose do të mbajë vetëm një mostër të pjesshme. Kjo metodë lejon një mostër më përfaqësuese të secilës kategori të kërkesës (e suksesshme/e gjatë/gabim), por kërkon konfigurim shtesë të infrastrukturës.

Bagazhi

Mekanizmi i Bagazhit lejon që çiftet arbitrare të vlerës-kyç të transmetohen së bashku me trace_id / span_id , duke kaluar automatikisht midis të gjitha mikroshërbimeve gjatë përpunimit të kërkesës. Kjo është e dobishme për transmetimin e informacionit shtesë të nevojshëm përgjatë shtegut të kërkesës—si p.sh. informacioni i përdoruesit ose cilësimet e mjedisit të kohës së ekzekutimit.

Shembull i një titulli për transmetimin e bagazheve sipas standardit W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Këtu janë disa shembuj të përdorimit të bagazheve:

• Kalimi i informacionit të kontekstit të biznesit si userId , productId ose deviceId mund të kalohet nëpër të gjitha mikroshërbimet. Aplikacionet mund të regjistrojnë automatikisht këtë informacion, duke lejuar kërkimet e regjistrave sipas kontekstit të përdoruesit për kërkesën origjinale.

• Cilësimet specifike të parametrave të konfigurimit për SDK-të ose infrastrukturën.

• Routing Flags Flamujt që ndihmojnë balancuesit e ngarkesës të marrin vendime për drejtimin. Gjatë testimit, disa kërkesa mund të kenë nevojë të drejtohen për tallën e backend-eve. Meqenëse bagazhet transmetohen automatikisht përmes të gjitha shërbimeve, nuk ka nevojë të krijoni protokolle shtesë - thjesht vendosni një rregull për balancuesin e ngarkesës.

  
  

Zbatimi i Infrastrukturës

Zbatimi i OpenTelemetry në nivelin e infrastrukturës përfshin integrimin e backend-eve të OpenTelemetry në arkitekturën e aplikacionit dhe konfigurimin e infrastrukturës për grumbullimin e të dhënave.

Procesi përbëhet nga katër faza:

1. Integrimi i aplikacionit Në fazën e parë, SDK-të e OpenTelemetry integrohen drejtpërdrejt në aplikacione për të mbledhur metrikë, regjistra dhe gjurmë, duke siguruar një rrjedhë të vazhdueshme të të dhënave për performancën e secilit komponent të sistemit.

   
   

2. Konfigurimi i eksportuesve Të dhënat e mbledhura drejtohen nga aplikacionet përmes eksportuesve në sisteme të jashtme për përpunim të mëtejshëm, si sistemet e regjistrimit, monitorimit, gjurmimit ose analitikës, në varësi të nevojave tuaja.

   
   

3. Mbledhja dhe ruajtja Kjo fazë mund të përfshijë normalizimin e të dhënave, pasurimin e tyre me informacion shtesë dhe bashkimin e të dhënave nga burime të ndryshme për të krijuar një pamje të unifikuar të gjendjes së sistemit.

   
   

4. Vizualizimi i të dhënave Më në fund, të dhënat e përpunuara paraqiten si panele kontrolli në sisteme si Grafana (për metrikat dhe gjurmët) ose Kibana (për regjistrat). Kjo i lejon ekipet të vlerësojnë shpejt shëndetin e sistemit, të identifikojnë çështjet dhe tendencat dhe të vendosin sinjalizime bazuar në sinjalet e krijuara.

Zbatimi i Aplikacionit

Për t'u integruar me një aplikacion, duhet të lidhni OpenTelemetry SDK-në e duhur për gjuhën e programimit në përdorim ose të përdorni biblioteka dhe korniza që mbështesin drejtpërdrejt OpenTelemetry. OpenTelemetry shpesh zbaton ndërfaqe të përdorura gjerësisht nga bibliotekat e njohura, duke lejuar zëvendësime të lëshuara. Për shembull, biblioteka Micrometer përdoret zakonisht për mbledhjen e metrikave në ekosistemin Java. OpenTelemetry SDK ofron implementimet e saj të ndërfaqeve Micrometer, duke mundësuar eksportimin metrik pa ndryshuar kodin kryesor të aplikacionit. Për më tepër, OpenTelemetry ofron implementime të ndërfaqeve më të vjetra OpenTracing dhe OpenCensus, duke lehtësuar një migrim të qetë në OpenTelemetry.

konkluzioni

Në sistemet e TI-së, OpenTelemetry mund të bëhet çelësi për të ardhmen e backend-eve të besueshme dhe efikase. Ky mjet thjeshton korrigjimin dhe monitorimin dhe gjithashtu hap mundësi për një kuptim të thellë të performancës dhe optimizimit të aplikacionit në një nivel të ri. Bashkohuni me komunitetin OpenTelemetry për të ndihmuar në formimin e një të ardhmeje ku zhvillimi i backend-it është më i thjeshtë dhe më efektiv!