Hvad er OpenTelemetry, og hvordan det kan forbedre din backend-kvalitet?

Tidligere, når vi talte om backend, henviste vi normalt til én stor applikation med en enkelt, stor database, og logning var tilstrækkelig til overvågning. Nu, takket være teknologier som Kubernetes , er mikrotjenester blevet standarden. Applikationerne er flere og mere distribuerede, og traditionel logning er ikke længere nok til at fejlfinde og diagnosticere problemer i vores applikationer.

En fremragende løsning til at organisere overvågning er OpenTelemetry - et moderne værktøjssæt, der kan bruges til fejlfinding og ydelsesanalyse af distribuerede systemer.

Denne artikel er beregnet til it-professionelle, der søger at udvide deres viden inden for backend-optimering. Nedenfor vil vi detaljere, hvad OpenTelemetry er, dets nøglekoncepter og de problemer, det hjælper med at løse. Hvis du er interesseret i, hvordan OpenTelemetry kan ændre din tilgang til overvågning og fejlretning af backend-systemer, hvilket forbedrer deres pålidelighed og effektivitet - læs videre.

En kort historie om OpenTelemetry

Store teknologivirksomheder stod først over for udfordringen med distribueret logning og sporing i slutningen af 2000'erne. I 2010 udgav Google et papir, Dapper, en distribueret systemsporingsinfrastruktur i stor skala , som lagde grunden til Twitters sporingsværktøj, Zipkin, udgivet i 2012.

I 2014 opstod Kubernetes, hvilket væsentligt forenklede udviklingen af mikrotjenester og andre cloud-distribuerede systemer. Dette førte til, at mange virksomheder stødte på problemer med distribueret logning og sporing i mikrotjenester. For at standardisere distribueret sporing blev OpenTracing-standarden, vedtaget af CNCF, og Googles OpenCensus-projekt oprettet.

I 2019 annoncerede OpenTracing- og OpenCensus-projekterne en fusion under navnet OpenTelemetry. Denne platform kombinerer den bedste praksis, der er akkumuleret over mange år, hvilket muliggør problemfri integration af sporing, logning og metrikker i ethvert system, uanset deres kompleksitet.

I dag er OpenTelemetry ikke kun et projekt; det er en industristandard til indsamling og transmission af telemetridata. Det er udviklet og understøttet af et fællesskab af specialister og markedsledende virksomheder som Google og Microsoft. Projektet fortsætter med at udvikle sig og får nye muligheder for at forenkle integrations- og brugsprocessen.

Hvad er der inde?

OpenTelemetry er et omfattende sæt af praksisser og værktøjer, der definerer, hvilke signaler en applikation kan generere for at interagere med omverdenen, og hvordan disse signaler kan indsamles og visualiseres for at overvåge applikationernes tilstand og systemet som helhed. De tre hovedtyper af signaler er sporing, logning og indsamling af metrics .

**Lad os se nærmere på hver komponent: \

Kontekster

OpenTelemetry introducerer begrebet operationskontekster. En kontekst inkluderer primært attributter som `trace_id` (identifikator for den aktuelle operation) og `span_id` (identifikator for en underanmodning, hvor hvert genforsøg af en underanmodning har et unikt `span_id` ).

Derudover kan en kontekst indeholde statisk information, såsom nodenavnet, hvor applikationen er installeret, eller miljønavnet (prod/qa). Disse felter, kendt som ressourcer i OpenTelemetry-terminologi, er knyttet til hver log, metrik eller sporing for lettere søgbarhed. Kontekster kan også omfatte dynamiske data, såsom identifikatoren for det aktuelle slutpunkt ( `http_path: "GET /user/:id/info"` ), som selektivt kan knyttes til grupper af logfiler, metrics eller spor.

OpenTelemetry-kontekster kan overføres mellem forskellige applikationer ved hjælp af kontekstudbredelsesprotokoller. Disse protokoller består af header-sæt, der tilføjes til hver HTTP- eller gRPC-anmodning eller overskrifterne på meddelelser til køer. Dette gør det muligt for downstream-applikationer at rekonstruere operationskonteksten fra disse overskrifter.

Her er nogle eksempler på kontekstudbredelse:

1. B3-propagation Dette er et sæt overskrifter ( x-b3-* ), der oprindeligt er udviklet til Zipkin-sporingssystemet. Det blev tilpasset til OpenTracing og brugt af mange værktøjer og biblioteker. B3-propagation bærer trace_id / span_id og et flag, der angiver, om prøvetagning er nødvendig.

   
   

2. W3C Trace Context Denne standard er udviklet af W3C-arbejdsgruppen og forener forskellige kontekstudbredelsestilgange til en enkelt standard og er standard i OpenTelemetry. Et godt eksempel på anvendelse af disse standarder er sporing af udførelsen af en anmodning, der passerer gennem mikrotjenester implementeret med forskellige teknologier uden at kompromittere overvågning og fejlretningsnøjagtighed.

Sporing

Sporing er processen med at optage og efterfølgende visualisere tidslinjen for en anmodnings vej gennem flere mikrotjenester.

I visualiseringen kaldes hver søjle et "span" og har et unikt "span_id" . Rodspændet omtales som et "trace" og har et "trace_id" , som tjener som identifikator for hele anmodningen.

Denne type visualisering giver dig mulighed for at:

• Analyser eksekveringstiden for anmodninger på tværs af forskellige systemer og databaser for at identificere flaskehalse, der kræver optimering.
• Registrer cykliske afhængigheder mellem tjenester.
• Find duplikerede anmodninger. Ved at bruge sporingsdata kan du også bygge yderligere analyser, såsom oprettelse af et mikroservicekort eller fordeling af tid på tværs af forskellige systemer under operationsbehandling. Selvom du ikke bruger sporingsdata til at visualisere tidslinjer, genererer OpenTelemetry stadig trace_id og span_id til brug i andre signaler.

Logs

På trods af dens tilsyneladende enkelhed er logning fortsat et af de mest kraftfulde værktøjer til at diagnosticere problemer. OpenTelemetry forbedrer traditionel logning ved at tilføje kontekstuel information. Specifikt, hvis en aktiv sporing er til stede, tilføjes "trace_id" og "span_id" attributter automatisk til logfiler, der linker dem til sporingstidslinjen. Desuden kan log-attributter omfatte statisk information fra OpenTelemetry-konteksten, såsom node-id'en, såvel som dynamisk information, såsom den aktuelle HTTP-endepunkt-id ("http_path: "GET /user/:id").

Ved at bruge `trace_id` kan du finde logfiler fra alle mikrotjenester forbundet med den aktuelle anmodning, mens `span_id` giver dig mulighed for at skelne mellem underanmodninger. For eksempel, i tilfælde af genforsøg, vil logfiler fra forskellige forsøg have forskellige `span_id`s. Brug af disse identifikatorer muliggør hurtig analyse af hele systemets adfærd i realtid, hvilket fremskynder problemdiagnosticering og forbedrer stabilitet og pålidelighed.

Metrics

Indsamling af metrics giver kvantitative data om systemets ydeevne, såsom latens, fejlfrekvenser, ressourceforbrug og mere. Realtidsovervågning af metrikker giver dig mulighed for omgående at reagere på ændringer i ydeevnen, forhindre fejl og ressourceudmattelse og sikre høj tilgængelighed og pålidelighed af applikationen for brugerne.

Integration med metriske lagrings- og visualiseringssystemer som Prometheus og Grafana gør det nemmere at visualisere disse data, hvilket væsentligt forenkler overvågningen.

Metriske samlere

OpenTelemetry metriske samlere er kompatible med Prometheus og OpenMetrics standarder, hvilket muliggør en nem overgang til OpenTelemetry løsninger uden væsentlige ændringer. OpenTelemetry SDK tillader, at trace_id-eksempler kan eksporteres sammen med metrics, hvilket gør det muligt at korrelere metrics med log-eksempler og -spor.

Signalkorrelation

Sammen skaber logfiler, metrics og sporing et omfattende overblik over systemets tilstand:

• Logs giver information om systemhændelser, hvilket giver mulighed for hurtig identifikation og løsning af fejl.
• Metrics afspejler kvalitative og kvantitative præstationsindikatorer for systemet, såsom responstider eller fejlfrekvenser.
• Sporing supplerer denne visning ved at vise vejen for udførelse af anmodninger gennem forskellige systemkomponenter, hvilket hjælper med at forstå deres indbyrdes sammenhænge. Den klare sammenhæng mellem logfiler, spor og metrikker er et karakteristisk træk ved OpenTelemetry. For eksempel giver Grafana brugere mulighed for at se de tilsvarende sporings- og anmodningsmetrikker, når de ser en log, hvilket i høj grad forbedrer platformens anvendelighed og effektivitet.

Ud over de tre kernekomponenter inkluderer OpenTelemetry koncepterne Sampling, Bagage og driftskontekststyring.

Prøveudtagning

I højbelastningssystemer bliver mængden af logfiler og spor enorm, hvilket kræver betydelige ressourcer til infrastruktur og datalagring. For at løse dette problem inkluderer OpenTelemetry-standarder signalsampling - muligheden for kun at eksportere en del af spor og logfiler. For eksempel kan du eksportere detaljerede signaler fra en procentdel af anmodninger, langvarige anmodninger eller fejlanmodninger. Denne tilgang giver mulighed for tilstrækkelig stikprøve til at opbygge statistik og samtidig spare betydelige ressourcer.

Men hvis hvert system uafhængigt beslutter, hvilke anmodninger der skal overvåges i detaljer, ender vi med et fragmenteret billede af hver anmodning. Nogle systemer eksporterer muligvis detaljerede data, mens andre kun delvist eksporterer eller slet ikke eksporterer.

For at løse dette problem transmitterer OpenTelemetrys kontekstudbredelsesmekanismer et samplingsflag sammen med `trace_id`/`span_id`. Dette sikrer, at hvis den første tjeneste, der modtager brugeranmodningen, beslutter, at anmodningen skal overvåges i detaljer, vil alle andre systemer følge trop. Ellers bør alle systemer delvist eller ikke eksportere signaler for at spare ressourcer. Denne tilgang kaldes "Head Sampling" - en beslutning, der træffes i begyndelsen af anmodningsbehandlingen, enten tilfældigt eller baseret på nogle input-attributter.

Desuden understøtter OpenTelemetry "Tail Sampling", hvor alle applikationer altid eksporterer alle signaler i detaljer, men der findes en mellembuffer. Efter at have indsamlet alle data, beslutter denne buffer, om den skal beholde de fulde data eller kun beholde en delvis prøve. Denne metode giver mulighed for et mere repræsentativt udsnit af hver anmodningskategori (vellykket/lang/fejl), men kræver yderligere infrastrukturopsætning.

Bagage

Bagage-mekanismen gør det muligt at transmittere vilkårlige nøgleværdi-par sammen med trace_id / span_id , der automatisk passerer mellem alle mikrotjenester under anmodningsbehandling. Dette er nyttigt til at overføre yderligere information, der er nødvendig gennem hele anmodningsstien - såsom brugeroplysninger eller indstillinger for runtime-miljø.

Eksempel på en header til transmission af bagage i henhold til W3C-standarden: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Her er nogle eksempler på bagagebrug:

• Videregivelse af forretningskontekstoplysninger såsom userId , productId eller deviceId kan sendes gennem alle mikrotjenester. Programmer kan automatisk logge disse oplysninger, hvilket giver mulighed for logsøgning efter brugerkontekst for den oprindelige anmodning.

• Specifikke konfigurationsparametre Indstillinger for SDK'er eller infrastruktur.

• Routingflag Flag, der hjælper load balancers med at træffe routingbeslutninger. Under testning skal nogle anmodninger muligvis omdirigeres til falske backends. Da bagage transmitteres automatisk gennem alle tjenester, er der ingen grund til at oprette yderligere protokoller – du skal bare opsætte en regel på lastbalanceren.

  
  

Implementering af infrastruktur

Implementering af OpenTelemetry på infrastrukturniveau involverer integration af OpenTelemetry-backends i applikationsarkitekturen og konfiguration af infrastrukturen til dataaggregering.

Processen består af fire faser:

1. Applikationsintegration I den første fase er OpenTelemetry SDK'er direkte integreret i applikationer for at indsamle metrikker, logfiler og spor, hvilket sikrer en kontinuerlig strøm af data om hver systemkomponents ydeevne.

   
   

2. Konfiguration af eksportører Indsamlede data dirigeres fra applikationer gennem eksportører til eksterne systemer til yderligere behandling, såsom logning, overvågning, sporing eller analysesystemer, afhængigt af dine behov.

   
   

3. Aggregation og lagring Dette trin kan involvere normalisering af data, berigelse af dem med yderligere information og sammenlægning af data fra forskellige kilder for at skabe et samlet billede af systemets tilstand.

   
   

4. Datavisualisering Endelig præsenteres behandlede data som dashboards i systemer som Grafana (til metrik og spor) eller Kibana (til logfiler). Dette giver teams mulighed for hurtigt at vurdere systemets helbred, identificere problemer og tendenser og opsætte alarmer baseret på genererede signaler.

Applikationsimplementering

For at integrere med en applikation skal du tilslutte det relevante OpenTelemetry SDK til det programmeringssprog, der er i brug, eller bruge biblioteker og rammer, der direkte understøtter OpenTelemetry. OpenTelemetry implementerer ofte udbredte grænseflader fra kendte biblioteker, hvilket tillader drop-in-erstatninger. For eksempel er Micrometer-biblioteket almindeligvis brugt til metrikindsamling i Java-økosystemet. OpenTelemetry SDK leverer sine implementeringer af Micrometer-grænseflader, hvilket muliggør metrisk eksport uden at ændre hovedapplikationskoden. Desuden tilbyder OpenTelemetry implementeringer af ældre OpenTracing- og OpenCensus-grænseflader, hvilket letter en smidig migrering til OpenTelemetry.

Konklusion

I it-systemer kan OpenTelemetry blive nøglen til fremtiden for pålidelige og effektive backends. Dette værktøj forenkler fejlfinding og overvågning og åbner også muligheder for en dyb forståelse af applikationsydelse og optimering på et nyt niveau. Tilmeld dig OpenTelemetry-fællesskabet for at hjælpe med at forme en fremtid, hvor backend-udvikling er enklere og mere effektiv!