![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
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.
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,
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.
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: \
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:
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.
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 ä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:
trace_id
och span_id
för användning i andra signaler.
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.
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.
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.
Tillsammans skapar loggar, mätvärden och spårning en heltäckande bild av systemets tillstånd:
Utöver de tre kärnkomponenterna inkluderar OpenTelemetry koncepten Sampling, Bagage och operationskontexthantering.
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.
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.
Observera att även om inverkan på prestanda av bagage är minimal, kan överdriven användning avsevärt öka nätverks- och tjänstebelastningen. Välj noga vilken data du verkligen behöver för att passera genom Bagage för att undvika prestandaproblem.
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:
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.
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.
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.
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.
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.
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!