Wat is OpenTelemetry en hoe dit u agterkantkwaliteit kan verbeter?

In die verlede, toe ons oor die backend gepraat het, het ons gewoonlik verwys na een groot toepassing met 'n enkele, groot databasis, en aantekening was voldoende vir monitering. Nou, danksy tegnologie soos Kubernetes , het mikrodienste die standaard geword. Toepassings is meer en meer versprei, en tradisionele aantekening is nie meer genoeg vir ontfouting en diagnose van probleme in ons toepassings nie.

'n Uitstekende oplossing vir die organisering van monitering is OpenTelemetry - 'n moderne gereedskapstel wat gebruik kan word vir ontfouting en prestasie-analise van verspreide stelsels.

Hierdie artikel is bedoel vir IT-professionele persone wat hul kennis in backend-optimering wil uitbrei. Hieronder sal ons uiteensit wat OpenTelemetry is, sy sleutelkonsepte en die probleme wat dit help oplos. As jy belangstel in hoe OpenTelemetry jou benadering tot monitering en ontfouting van backend-stelsels kan verander, wat hul betroubaarheid en doeltreffendheid verbeter – lees verder.

'n Kort geskiedenis van OpenTelemetry

Groot tegnologiemaatskappye het die eerste keer in die laat 2000's die uitdaging van verspreide aanteken en opsporing in die gesig gestaar. In 2010 het Google 'n koerant gepubliseer, Dapper, 'n grootskaalse verspreide stelselopsporing-infrastruktuur , wat die grondslag gelê het vir Twitter se opsporingsinstrument, Zipkin, wat in 2012 vrygestel is.

In 2014 het Kubernetes ontstaan, wat die ontwikkeling van mikrodienste en ander wolkverspreide stelsels aansienlik vereenvoudig het. Dit het daartoe gelei dat baie maatskappye probleme ondervind met verspreide aantekening en opsporing in mikrodienste. Om verspreide opsporing te standaardiseer, is die OpenTracing-standaard, wat deur CNCF aanvaar is, en Google se OpenCensus-projek geskep.

In 2019 het die OpenTracing- en OpenCensus-projekte 'n samesmelting onder die naam OpenTelemetry aangekondig. Hierdie platform kombineer die beste praktyke wat oor baie jare opgehoop is, wat naatlose integrasie van opsporing, logging en metrieke in enige stelsel moontlik maak, ongeag hul kompleksiteit.

Vandag is OpenTelemetry nie net 'n projek nie; dit is 'n industriestandaard vir die insameling en oordrag van telemetriedata. Dit word ontwikkel en ondersteun deur 'n gemeenskap van spesialiste en markleidende maatskappye soos Google en Microsoft. Die projek gaan voort om te ontwikkel en kry nuwe vermoëns om die integrasie- en gebruiksproses te vereenvoudig.

Wat is binne?

OpenTelemetry is 'n omvattende stel praktyke en gereedskap wat definieer watter seine 'n toepassing kan genereer om met die buitewêreld te kommunikeer, en hoe hierdie seine versamel en gevisualiseer kan word om die toestand van toepassings en die stelsel as geheel te monitor. Die drie hooftipes seine is opsporing, logging en metriekeversameling .

**Kom ons kyk van naderby na elke komponent: \

Kontekste

OpenTelemetry stel die konsep van operasiekontekste bekend. 'n Kontekst sluit hoofsaaklik kenmerke in soos `trace_id` (identifiseerder vir die huidige bewerking) en `span_id` (identifiseerder vir 'n sub-versoek, met elke herprobering van 'n sub-versoek wat 'n unieke `span_id` het).

Boonop kan 'n konteks statiese inligting bevat, soos die nodusnaam waar die toepassing ontplooi word of die omgewingsnaam (prod/qa). Hierdie velde, bekend as hulpbronne in OpenTelemetry-terminologie, word aan elke log, metriek of spoor geheg vir makliker soekbaarheid. Kontekste kan ook dinamiese data insluit, soos die identifiseerder van die huidige eindpunt ( `http_path: "GET /user/:id/info"` ), wat selektief aan groepe logs, metrieke of spore geheg kan word.

OpenTelemetry-kontekste kan tussen verskillende toepassings deurgegee word deur konteksvoortplantingsprotokolle te gebruik. Hierdie protokolle bestaan uit kopstelle wat by elke HTTP- of gRPC-versoek of die opskrifte van boodskappe vir toue gevoeg word. Dit laat stroomaf toepassings toe om die operasiekonteks vanaf hierdie opskrifte te rekonstrueer.

Hier is 'n paar voorbeelde van konteksverspreiding:

1. B3-voortplanting Dit is 'n stel opskrifte ( x-b3-* ) wat oorspronklik ontwikkel is vir die Zipkin-nasporingstelsel. Dit is in OpenTracing aangepas en deur baie instrumente en biblioteke gebruik. B3-Propagation dra trace_id / span_id en 'n vlag wat aandui of steekproefneming nodig is.

   
   

2. W3C Trace Context Hierdie standaard, wat deur die W3C-werkgroep ontwikkel is, verenig verskeie konteksverspreidingbenaderings in 'n enkele standaard en is die verstek in OpenTelemetry. 'n Goeie voorbeeld van die toepassing van hierdie standaarde is om die uitvoering van 'n versoek na te spoor wat deur mikrodienste geïmplementeer is met verskillende tegnologieë sonder om monitering en ontfoutingsakkuraatheid in te boet.

Opspoor

Opsporing is die proses om die tydlyn van 'n versoek se pad deur verskeie mikrodienste op te teken en daarna te visualiseer.

In die visualisering word elke balk 'n "span" genoem en het 'n unieke "span_id" . Daar word na die wortelspan verwys as 'n "trace" en het 'n "trace_id" , wat dien as die identifiseerder vir die hele versoek.

Hierdie tipe visualisering laat jou toe om:

• Ontleed die uitvoeringstyd van versoeke oor verskillende stelsels en databasisse om knelpunte te identifiseer wat geoptimaliseer moet word.
• Bespeur sikliese afhanklikhede tussen dienste.
• Soek duplikaatversoeke. Deur naspeurdata te gebruik, kan jy ook bykomende ontledings bou, soos die skep van 'n mikrodienstekaart of die verspreiding van tyd oor verskillende stelsels tydens operasieverwerking. Selfs as jy nie spoordata gebruik om tydlyne te visualiseer nie, genereer OpenTelemetry steeds trace_id en span_id vir gebruik in ander seine.

Logs

Ten spyte van die oënskynlike eenvoud daarvan, bly aanteken een van die kragtigste instrumente om probleme te diagnoseer. OpenTelemetry verbeter tradisionele aantekening deur kontekstuele inligting by te voeg. Spesifiek, as 'n aktiewe spoor teenwoordig is, word 'trace_id' en 'span_id' eienskappe outomaties by logs gevoeg, wat hulle aan die spoortydlyn koppel. Boonop kan log-kenmerke statiese inligting van die OpenTelemetry-konteks insluit, soos die nodusidentifiseerder, sowel as dinamiese inligting, soos die huidige HTTP-eindpuntidentifiseerder (`http_path: "GET /user/:id").

Deur die `trace_id` te gebruik, kan jy logs vind van alle mikrodienste wat met die huidige versoek geassosieer word, terwyl die `span_id` jou toelaat om tussen subversoeke te onderskei. Byvoorbeeld, in die geval van herprobasies, sal logs van verskillende pogings verskillende `span_id`s hê. Die gebruik van hierdie identifiseerders maak 'n vinnige ontleding van die hele stelsel se gedrag intyds moontlik, bespoedig probleemdiagnose en verbeter stabiliteit en betroubaarheid.

Metrieke

Metriekeversameling verskaf kwantitatiewe data oor stelselwerkverrigting, soos latensie, foutkoerse, hulpbrongebruik, en meer. Intydse monitering van metrieke stel jou in staat om stiptelik op prestasieveranderinge te reageer, mislukkings en hulpbronuitputting te voorkom en hoë beskikbaarheid en betroubaarheid van die toepassing vir gebruikers te verseker.

Integrasie met metrieke berging- en visualiseringstelsels soos Prometheus en Grafana maak dit makliker om hierdie data te visualiseer, wat monitering aansienlik vereenvoudig.

Metrieke versamelaars

OpenTelemetry-metriekversamelaars is versoenbaar met Prometheus- en OpenMetrics-standaarde, wat 'n maklike oorgang na OpenTelemetry-oplossings moontlik maak sonder noemenswaardige veranderinge. Die OpenTelemetry SDK laat trace_id voorbeelde toe om saam met metrieke uitgevoer te word, wat dit moontlik maak om metrieke met log voorbeelde en spore te korreleer.

Sein Korrelasie

Saam skep logs, statistieke en opsporing 'n omvattende oorsig van die stelsel se toestand:

• Logs verskaf inligting oor stelselgebeurtenisse, wat voorsiening maak vir vinnige identifikasie en oplossing van foute.
• Metrieke weerspieël kwalitatiewe en kwantitatiewe prestasie-aanwysers van die stelsel, soos reaksietye of foutkoerse.
• Naspeuring komplementeer hierdie siening deur die pad van versoekuitvoering deur verskeie stelselkomponente te wys, wat help om hul onderlinge verwantskappe te verstaan. Die duidelike korrelasie tussen logs, spore en metrieke is 'n kenmerkende kenmerk van OpenTelemetry. Grafana stel gebruikers byvoorbeeld in staat om die ooreenstemmende spoor en versoekmaatstawwe te sien wanneer hulle 'n logboek bekyk, wat die platform se bruikbaarheid en doeltreffendheid aansienlik verbeter.

Benewens die drie kernkomponente, sluit OpenTelemetry die konsepte van monsterneming, bagasie en bedryfskonteksbestuur in.

Monsterneming

In hoëladingstelsels word die volume logs en spore enorm, wat aansienlike hulpbronne vir infrastruktuur en databerging benodig. Om hierdie probleem aan te spreek, sluit OpenTelemetry-standaarde seinmonsterneming in - die vermoë om slegs 'n gedeelte van spore en logs uit te voer. Byvoorbeeld, jy kan gedetailleerde seine uitvoer vanaf 'n persentasie versoeke, langlopende versoeke of foutversoeke. Hierdie benadering maak voorsiening vir voldoende steekproefneming om statistieke te bou terwyl aansienlike hulpbronne bespaar word.

As elke stelsel egter onafhanklik besluit watter versoeke om in detail te monitor, eindig ons met 'n gefragmenteerde siening van elke versoek. Sommige stelsels kan gedetailleerde data uitvoer terwyl ander slegs gedeeltelik kan uitvoer of glad nie uitvoer nie.

Om hierdie probleem op te los, stuur OpenTelemetry se konteksvoortplantingsmeganismes 'n steekproefvlag saam met die `trace_id`/`span_id`. Dit verseker dat indien die aanvanklike diens wat die gebruikerversoek ontvang, besluit dat die versoek in detail gemonitor moet word, alle ander stelsels die voorbeeld sal volg. Andersins moet alle stelsels seine gedeeltelik of nie uitvoer om hulpbronne te bespaar nie. Hierdie benadering word "Kopsteekproefneming" genoem - 'n besluit wat geneem word aan die begin van die verwerking van versoeke, hetsy lukraak of gebaseer op sekere insetkenmerke.

Boonop ondersteun OpenTelemetry "Tail Sampling," waar alle toepassings altyd alle seine in detail uitvoer, maar 'n tussenbuffer bestaan. Nadat al die data ingesamel is, besluit hierdie buffer of om die volle data te behou of slegs 'n gedeeltelike steekproef te hou. Hierdie metode maak voorsiening vir 'n meer verteenwoordigende steekproef van elke versoekkategorie (suksesvol/lank/fout), maar vereis bykomende infrastruktuuropstelling.

Bagasie

Die bagasiemeganisme laat toe dat arbitrêre sleutel-waarde-pare saam met trace_id / span_id versend word, wat outomaties tussen alle mikrodienste verbygaan tydens versoekverwerking. Dit is nuttig vir die oordrag van bykomende inligting wat deur die versoekpad benodig word—soos gebruikerinligting of runtime-omgewinginstellings.

Voorbeeld van 'n opskrif vir die versend van bagasie volgens die W3C-standaard: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Hier is 'n paar voorbeelde van bagasiegebruik:

• Besigheidskonteksinligting soos userId , productId of deviceId kan deur alle mikrodienste deurgegee word. Toepassings kan hierdie inligting outomaties aanteken, wat logboeksoektogte volgens gebruikerskonteks vir die oorspronklike versoek moontlik maak.

• Spesifieke konfigurasieparameterinstellings vir SDK's of infrastruktuur.

• Roetingvlae Vlae wat vragbalanseerders help om roetebesluite te neem. Tydens toetsing sal sommige versoeke dalk na bespotlike agterkante herlei moet word. Aangesien bagasie outomaties deur alle dienste versend word, is dit nie nodig om bykomende protokolle te skep nie - stel net 'n reël op die lasbalanseerder op.

  
  

Infrastruktuur-implementering

Die implementering van OpenTelemetry op die infrastruktuurvlak behels die integrasie van OpenTelemetry-agtergronde in die toepassingsargitektuur en die opstel van die infrastruktuur vir data-aggregasie.

Die proses bestaan uit vier fases:

1. Toepassingsintegrasie In die eerste fase word OpenTelemetry SDK's direk in toepassings geïntegreer om metrieke, logs en spore te versamel, wat 'n deurlopende vloei van data oor elke stelselkomponent se werkverrigting verseker.

   
   

2. Konfigurasie van uitvoerders Versamelde data word van toepassings deur uitvoerders na eksterne stelsels herlei vir verdere verwerking, soos aanteken, monitering, opsporing of ontledingstelsels, afhangende van jou behoeftes.

   
   

3. Samevoeging en berging Hierdie stadium kan die normalisering van data behels, die verryking daarvan met bykomende inligting en die samevoeging van data van verskillende bronne om 'n verenigde siening van die stelsel se toestand te skep.

   
   

4. Datavisualisering Laastens word verwerkte data as dashboards in stelsels soos Grafana (vir metrieke en spore) of Kibana (vir logs) aangebied. Dit stel spanne in staat om vinnig die stelsel se gesondheid te assesseer, kwessies en neigings te identifiseer en waarskuwings op te stel gebaseer op gegenereerde seine.

Toepassingsimplementering

Om met 'n toepassing te integreer, moet jy die toepaslike OpenTelemetry SDK koppel vir die programmeertaal wat gebruik word of biblioteke en raamwerke gebruik wat OpenTelemetry direk ondersteun. OpenTelemetry implementeer dikwels wydgebruikte koppelvlakke van bekende biblioteke, wat inloopvervangings moontlik maak. Byvoorbeeld, die Micrometer-biblioteek word algemeen gebruik vir die versameling van metrieke in die Java-ekosisteem. Die OpenTelemetry SDK bied sy implementerings van Micrometer-koppelvlakke, wat metrieke uitvoer moontlik maak sonder om die hooftoepassingskode te verander. Boonop bied OpenTelemetry implementerings van ouer OpenTracing- en OpenCensus-koppelvlakke, wat 'n gladde migrasie na OpenTelemetry vergemaklik.

Gevolgtrekking

In IT-stelsels kan OpenTelemetry die sleutel word tot die toekoms van betroubare en doeltreffende backends. Hierdie instrument vereenvoudig ontfouting en monitering en maak ook geleenthede oop vir 'n diepgaande begrip van toepassingsprestasie en -optimalisering op 'n nuwe vlak. Sluit aan by die OpenTelemetry-gemeenskap om 'n toekoms te help vorm waar backend-ontwikkeling eenvoudiger en doeltreffender is!