Vad är OpenTelemetry och hur det kan förbättra din backend-kvalitet?

Tidigare, när vi pratade om backend, hänvisade vi vanligtvis till en stor applikation med en enda, stor databas, och loggning var tillräcklig för övervakning. Nu, tack vare teknologier som Kubernetes , har mikrotjänster blivit standarden. Applikationerna är fler och mer distribuerade, och traditionell loggning räcker inte längre för att felsöka och diagnostisera problem i våra applikationer.

En utmärkt lösning för att organisera övervakning är OpenTelemetry — en modern verktygslåda som kan användas för felsökning och prestandaanalys av distribuerade system.

Den här artikeln är avsedd för IT-proffs som vill utöka sina kunskaper inom backend-optimering. Nedan kommer vi att beskriva vad OpenTelemetry är, dess nyckelbegrepp och de problem det hjälper till att lösa. Om du är intresserad av hur OpenTelemetry kan förändra ditt tillvägagångssätt för att övervaka och felsöka backend-system och förbättra deras tillförlitlighet och effektivitet — läs vidare.

En kort historia av OpenTelemetry

Stora teknikföretag stod först inför utmaningen med distribuerad loggning och spårning i slutet av 2000-talet. 2010 publicerade Google en tidning, Dapper, en storskalig distribuerad systemspårningsinfrastruktur , som lade grunden för Twitters spårningsverktyg, Zipkin, som släpptes 2012.

Under 2014 uppstod Kubernetes, vilket avsevärt förenklade utvecklingen av mikrotjänster och andra molndistribuerade system. Detta ledde till att många företag stötte på problem med distribuerad loggning och spårning i mikrotjänster. För att standardisera distribuerad spårning skapades OpenTracing-standarden, antagen av CNCF, och Googles OpenCensus-projekt.

2019 tillkännagav OpenTracing- och OpenCensus-projekten en sammanslagning under namnet OpenTelemetry. Denna plattform kombinerar bästa praxis som samlats under många år, vilket möjliggör sömlös integration av spårning, loggning och mätvärden i alla system, oavsett deras komplexitet.

Idag är OpenTelemetry inte bara ett projekt; det är en industristandard för insamling och överföring av telemetridata. Det utvecklas och stöds av en grupp specialister och marknadsledande företag som Google och Microsoft. Projektet fortsätter att utvecklas och får nya möjligheter för att förenkla integrations- och användningsprocessen.

Vad finns inuti?

OpenTelemetry är en omfattande uppsättning metoder och verktyg som definierar vilka signaler en applikation kan generera för att interagera med omvärlden, och hur dessa signaler kan samlas in och visualiseras för att övervaka applikationernas tillstånd och systemet som helhet. De tre huvudtyperna av signaler är spårning, loggning och insamling av mätvärden .

**Låt oss ta en närmare titt på varje komponent: \

Sammanhang

OpenTelemetry introducerar begreppet operationskontexter. En kontext inkluderar i första hand attribut som `trace_id` (identifierare för den aktuella operationen) och `span_id` (identifierare för en underbegäran, där varje nytt försök av en underbegäran har ett unikt `span_id` ).

Dessutom kan en kontext innehålla statisk information, såsom nodnamnet där applikationen distribueras eller miljönamnet (prod/qa). Dessa fält, kända som resurser i OpenTelemetry-terminologi, är kopplade till varje logg, mätvärde eller spårning för enklare sökbarhet. Kontexter kan också inkludera dynamiska data, som identifieraren för den aktuella slutpunkten ( `http_path: "GET /user/:id/info"` ), som selektivt kan kopplas till grupper av loggar, mätvärden eller spår.

OpenTelemetry-kontexter kan skickas mellan olika applikationer med hjälp av kontextutbredningsprotokoll. Dessa protokoll består av rubrikuppsättningar som läggs till i varje HTTP- eller gRPC-begäran eller rubrikerna för meddelanden för köer. Detta tillåter nedströmsapplikationer att rekonstruera operationskontexten från dessa rubriker.

Här är några exempel på kontextspridning:

1. B3-propagation Detta är en uppsättning rubriker ( x-b3-* ) som ursprungligen utvecklades för Zipkin-spårningssystemet. Den anpassades till OpenTracing och användes av många verktyg och bibliotek. B3-propagation bär trace_id / span_id och en flagga som indikerar om sampling är nödvändig.

   
   

2. W3C Trace Context Denna standard har utvecklats av W3C-arbetsgruppen och förenar olika tillvägagångssätt för kontextutbredning till en enda standard och är standard i OpenTelemetry. Ett bra exempel på tillämpning av dessa standarder är att spåra exekveringen av en begäran som passerar genom mikrotjänster implementerade med olika teknologier utan att kompromissa med övervaknings- och felsökningsnoggrannheten.

Spårning

Spårning är processen att spela in och därefter visualisera tidslinjen för en begärans väg genom flera mikrotjänster.

I visualiseringen kallas varje stapel ett "span" och har ett unikt "span_id" . Rotspannet hänvisas till som ett "spår" och har ett "trace_id" , som fungerar som identifierare för hela begäran.

Denna typ av visualisering låter dig:

• Analysera exekveringstiden för förfrågningar över olika system och databaser för att identifiera flaskhalsar som behöver optimeras.
• Upptäck cykliska beroenden mellan tjänster.
• Hitta dubbletter av förfrågningar. Med hjälp av spårningsdata kan du också bygga ytterligare analyser, som att skapa en mikroservicekarta eller fördela tid över olika system under operationsbehandling. Även om du inte använder spårningsdata för att visualisera tidslinjer, genererar OpenTelemetry fortfarande trace_id och span_id för användning i andra signaler.

Loggar

Trots sin uppenbara enkelhet är loggning fortfarande ett av de mest kraftfulla verktygen för att diagnostisera problem. OpenTelemetry förbättrar traditionell loggning genom att lägga till kontextuell information. Specifikt, om en aktiv spårning finns, läggs attributen "trace_id" och "span_id" automatiskt till i loggar och länkar dem till spårningstidslinjen. Dessutom kan loggattribut inkludera statisk information från OpenTelemetry-kontexten, såsom nodidentifieraren, såväl som dynamisk information, som den aktuella HTTP-slutpunktsidentifieraren (`http_path: "GET /user/:id").

Med hjälp av `trace_id` kan du hitta loggar från alla mikrotjänster som är associerade med den aktuella begäran, medan `span_id` låter dig skilja mellan underförfrågningar. Till exempel, i fallet med omförsök, kommer loggar från olika försök att ha olika `span_id`s. Att använda dessa identifierare möjliggör snabb analys av hela systemets beteende i realtid, vilket påskyndar problemdiagnostik och förbättrar stabilitet och tillförlitlighet.

Metrik

Insamling av mätvärden tillhandahåller kvantitativa data om systemets prestanda, såsom latens, felfrekvenser, resursanvändning och mer. Realtidsövervakning av mätvärden gör att du snabbt kan svara på prestandaförändringar, förhindra fel och resursutmattning och säkerställa hög tillgänglighet och tillförlitlighet för applikationen för användare.

Integration med metriska lagrings- och visualiseringssystem som Prometheus och Grafana gör det lättare att visualisera dessa data, vilket avsevärt förenklar övervakningen.

Metriska samlare

OpenTelemetry-metriksamlare är kompatibla med Prometheus- och OpenMetrics-standarder, vilket möjliggör en enkel övergång till OpenTelemetry-lösningar utan betydande förändringar. OpenTelemetry SDK tillåter att trace_id-exempel exporteras tillsammans med mätvärden, vilket gör det möjligt att korrelera mätvärden med loggexempel och spår.

Signalkorrelation

Tillsammans skapar loggar, mätvärden och spårning en heltäckande bild av systemets tillstånd:

• Loggar ger information om systemhändelser, vilket möjliggör snabb identifiering och lösning av fel.
• Mätvärden återspeglar kvalitativa och kvantitativa prestandaindikatorer för systemet, såsom svarstider eller felfrekvenser.
• Spårning kompletterar denna vy genom att visa sökvägen för exekvering av begäran genom olika systemkomponenter, vilket hjälper till att förstå deras inbördes samband. Den tydliga korrelationen mellan loggar, spår och mätvärden är en utmärkande egenskap hos OpenTelemetry. Till exempel tillåter Grafana användare att se motsvarande spårnings- och begärandemått när de tittar på en logg, vilket avsevärt förbättrar plattformens användbarhet och effektivitet.

Utöver de tre kärnkomponenterna inkluderar OpenTelemetry koncepten Sampling, Bagage och operationskontexthantering.

Provtagning

I högbelastningssystem blir volymen loggar och spår enorma, vilket kräver betydande resurser för infrastruktur och datalagring. För att lösa detta problem inkluderar OpenTelemetry-standarder signalsampling - möjligheten att exportera endast en del av spår och loggar. Du kan till exempel exportera detaljerade signaler från en procentandel av förfrågningar, långvariga förfrågningar eller felförfrågningar. Detta tillvägagångssätt möjliggör tillräckligt med urval för att bygga statistik samtidigt som man sparar betydande resurser.

Men om varje system självständigt bestämmer vilka förfrågningar som ska övervakas i detalj, slutar vi med en fragmenterad bild av varje förfrågan. Vissa system kan exportera detaljerad data medan andra endast delvis exporterar eller inte exporterar alls.

För att lösa detta problem sänder OpenTelemetrys kontextutbredningsmekanismer en samplingsflagga tillsammans med `trace_id`/`span_id`. Detta säkerställer att om den första tjänsten som tar emot användarförfrågan beslutar att begäran ska övervakas i detalj, kommer alla andra system att följa efter. Annars bör alla system delvis eller inte exportera signaler för att spara resurser. Detta tillvägagångssätt kallas "Head Sampling" - ett beslut som fattas i början av begärandebehandlingen, antingen slumpmässigt eller baserat på vissa indataattribut.

Dessutom stöder OpenTelemetry "Tail Sampling", där alla applikationer alltid exporterar alla signaler i detalj, men det finns en mellanbuffert. Efter att ha samlat in all data, bestämmer denna buffert om den fullständiga informationen ska behållas eller bara ett partiellt urval. Den här metoden möjliggör ett mer representativt urval av varje förfrågningskategori (lyckad/lång/fel) men kräver ytterligare infrastrukturinställning.

Bagage

Bagagemekanismen tillåter att godtyckliga nyckel-värdepar överförs tillsammans med trace_id / span_id , som automatiskt passerar mellan alla mikrotjänster under förfrågningsbehandling. Det här är användbart för att överföra ytterligare information som behövs genom hela förfrågningsvägen – som användarinformation eller inställningar för körtidsmiljö.

Exempel på en rubrik för överföring av bagage enligt W3C-standarden: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Här är några exempel på bagageanvändning:

• Skicka affärskontext Information som userId , productId eller deviceId kan skickas genom alla mikrotjänster. Applikationer kan automatiskt logga denna information, vilket möjliggör loggsökningar efter användarkontext för den ursprungliga begäran.

• Specifika konfigurationsparametrar Inställningar för SDK:er eller infrastruktur.

• Routingflaggor Flaggor som hjälper lastbalanserare att fatta ruttbeslut. Under testning kan vissa förfrågningar behöva dirigeras till mock-backends. Eftersom bagage sänds automatiskt genom alla tjänster, finns det inget behov av att skapa ytterligare protokoll – ställ bara in en regel på lastbalanseraren.

  
  

Infrastrukturimplementering

Att implementera OpenTelemetry på infrastrukturnivå innebär att man integrerar OpenTelemetry-backends i applikationsarkitekturen och konfigurerar infrastrukturen för dataaggregering.

Processen består av fyra steg:

1. Applikationsintegrering I det första steget integreras OpenTelemetry SDK:er direkt i applikationer för att samla in mätvärden, loggar och spår, vilket säkerställer ett kontinuerligt flöde av data om varje systemkomponents prestanda.

   
   

2. Konfigurera exportörer Insamlad data dirigeras från applikationer genom exportörer till externa system för vidare bearbetning, såsom loggning, övervakning, spårning eller analyssystem, beroende på dina behov.

   
   

3. Aggregation och lagring Det här steget kan innebära att normalisera data, berika den med ytterligare information och slå samman data från olika källor för att skapa en enhetlig bild av systemets tillstånd.

   
   

4. Datavisualisering Slutligen presenteras bearbetad data som instrumentpaneler i system som Grafana (för mätvärden och spår) eller Kibana (för loggar). Detta gör att teamen snabbt kan utvärdera systemets hälsa, identifiera problem och trender och ställa in varningar baserat på genererade signaler.

Applikationsimplementering

För att integrera med en applikation måste du ansluta lämplig OpenTelemetry SDK för det programmeringsspråk som används eller använda bibliotek och ramverk som direkt stöder OpenTelemetry. OpenTelemetry implementerar ofta mycket använda gränssnitt från kända bibliotek, vilket möjliggör drop-in-ersättningar. Till exempel används Micrometer-biblioteket ofta för insamling av mätvärden i Java-ekosystemet. OpenTelemetry SDK tillhandahåller sina implementeringar av Micrometer-gränssnitt, vilket möjliggör metrisk export utan att ändra huvudapplikationskoden. Dessutom erbjuder OpenTelemetry implementeringar av äldre OpenTracing- och OpenCensus-gränssnitt, vilket underlättar en smidig migrering till OpenTelemetry.

Slutsats

I IT-system kan OpenTelemetry bli nyckeln till framtiden för pålitliga och effektiva backends. Detta verktyg förenklar felsökning och övervakning och öppnar också möjligheter för en djup förståelse av applikationsprestanda och optimering på en ny nivå. Gå med i OpenTelemetry-communityt för att hjälpa till att forma en framtid där backend-utveckling är enklare och effektivare!