Wat is OpenTelemetry en hoe kan het de kwaliteit van uw backend verbeteren?

Vroeger, als we het over de backend hadden, verwezen we meestal naar één grote applicatie met één grote database, en was logging voldoende voor monitoring. Nu zijn microservices de standaard geworden dankzij technologieën als Kubernetes . Applicaties zijn talrijker en gedistribueerder, en traditionele logging is niet langer voldoende voor het debuggen en diagnosticeren van problemen in onze applicaties.

Een uitstekende oplossing voor het organiseren van monitoring is OpenTelemetry: een moderne toolkit die kan worden gebruikt voor het debuggen en analyseren van prestaties van gedistribueerde systemen.

Dit artikel is bedoeld voor IT-professionals die hun kennis over backend-optimalisatie willen uitbreiden. Hieronder leggen we uit wat OpenTelemetry is, wat de belangrijkste concepten zijn en welke problemen het helpt oplossen. Als u geïnteresseerd bent in hoe OpenTelemetry uw aanpak van het monitoren en debuggen van backend-systemen kan veranderen en hun betrouwbaarheid en efficiëntie kan verbeteren, lees dan verder.

Een korte geschiedenis van OpenTelemetry

Grote techbedrijven werden eind jaren 2000 voor het eerst geconfronteerd met de uitdaging van gedistribueerde logging en tracing. In 2010 publiceerde Google een paper, Dapper, een grootschalige infrastructuur voor het traceren van gedistribueerde systemen , die de basis legde voor Twitters traceertool Zipkin, die in 2012 werd uitgebracht.

In 2014 ontstond Kubernetes, wat de ontwikkeling van microservices en andere cloud-gedistribueerde systemen aanzienlijk vereenvoudigde. Dit leidde ertoe dat veel bedrijven problemen ondervonden met gedistribueerde logging en tracering in microservices. Om gedistribueerde tracering te standaardiseren, werd de OpenTracing-standaard, overgenomen door CNCF, en het OpenCensus-project van Google gecreëerd.

In 2019 kondigden de projecten OpenTracing en OpenCensus een fusie aan onder de naam OpenTelemetry. Dit platform combineert de best practices die in de loop der jaren zijn verzameld, waardoor tracering, logging en metrics naadloos kunnen worden geïntegreerd in elk systeem, ongeacht de complexiteit ervan.

Tegenwoordig is OpenTelemetry niet alleen een project; het is een industriestandaard voor het verzamelen en verzenden van telemetriegegevens. Het wordt ontwikkeld en ondersteund door een community van specialisten en marktleidende bedrijven zoals Google en Microsoft. Het project blijft evolueren en krijgt nieuwe mogelijkheden om het integratie- en gebruiksproces te vereenvoudigen.

Wat zit erin?

OpenTelemetry is een uitgebreide set van praktijken en tools die definiëren welke signalen een applicatie kan genereren om te interacteren met de buitenwereld, en hoe deze signalen kunnen worden verzameld en gevisualiseerd om de status van applicaties en het systeem als geheel te monitoren. De drie belangrijkste typen signalen zijn tracering, logging en metrics collection .

**Laten we elk onderdeel eens nader bekijken: \

Contexten

OpenTelemetry introduceert het concept van operationele contexten. Een context omvat voornamelijk kenmerken zoals `trace_id` (identifier voor de huidige bewerking) en `span_id` (identifier voor een sub-request, waarbij elke herhaling van een sub-request een unieke `span_id` heeft).

Bovendien kan een context statische informatie bevatten, zoals de knooppuntnaam waar de applicatie is geïmplementeerd of de omgevingsnaam (prod/qa). Deze velden, in OpenTelemetry-terminologie bekend als resources, worden aan elk logbestand, elke metriek of trace gekoppeld voor eenvoudigere doorzoekbaarheid. Contexten kunnen ook dynamische gegevens bevatten, zoals de id van het huidige eindpunt ( `http_path: "GET /user/:id/info"` ), die selectief aan groepen logbestanden, metrieken of traces kunnen worden gekoppeld.

OpenTelemetry-contexten kunnen worden doorgegeven tussen verschillende applicaties met behulp van contextpropagatieprotocollen. Deze protocollen bestaan uit headersets die worden toegevoegd aan elke HTTP- of gRPC-aanvraag of de headers van berichten voor wachtrijen. Dit stelt downstream-applicaties in staat om de operationele context te reconstrueren op basis van deze headers.

Hier zijn enkele voorbeelden van contextpropagatie:

1. B3-Propagation Dit is een set headers ( x-b3-* ) die oorspronkelijk is ontwikkeld voor het Zipkin-traceringssysteem. Het is aangepast in OpenTracing en wordt door veel tools en bibliotheken gebruikt. B3-Propagation draagt trace_id / span_id en een vlag die aangeeft of bemonstering noodzakelijk is.

   
   

2. W3C Trace Context Deze standaard is ontwikkeld door de W3C-werkgroep en verenigt verschillende benaderingen van contextpropagatie in één standaard en is de standaard in OpenTelemetry. Een goed voorbeeld van het toepassen van deze standaarden is het volgen van de uitvoering van een verzoek dat via microservices gaat die met verschillende technologieën zijn geïmplementeerd, zonder dat dit ten koste gaat van de nauwkeurigheid van monitoring en debuggen.

Traceren

Traceren is het proces van het vastleggen en vervolgens visualiseren van de tijdlijn van het pad van een aanvraag door meerdere microservices.

In de visualisatie wordt elke balk een "span" genoemd en heeft een unieke "span_id" . De root span wordt een "trace" genoemd en heeft een "trace_id" , die dient als de identifier voor de gehele aanvraag.

Met dit type visualisatie kunt u:

• Analyseer de uitvoeringstijd van aanvragen in verschillende systemen en databases om knelpunten te identificeren die geoptimaliseerd moeten worden.
• Cyclische afhankelijkheden tussen services detecteren.
• Vind dubbele verzoeken. Met behulp van traceringsgegevens kunt u ook aanvullende analyses maken, zoals het maken van een microservices-kaart of het verdelen van tijd over verschillende systemen tijdens de verwerking van de bewerking. Zelfs als u geen traceringsgegevens gebruikt om tijdlijnen te visualiseren, genereert OpenTelemetry nog steeds trace_id en span_id voor gebruik in andere signalen.

Logboeken

Ondanks de schijnbare eenvoud blijft logging een van de krachtigste tools voor het diagnosticeren van problemen. OpenTelemetry verbetert traditionele logging door contextuele informatie toe te voegen. Specifiek, als er een actieve trace aanwezig is, worden de kenmerken `trace_id` en `span_id` automatisch toegevoegd aan logs, waardoor ze worden gekoppeld aan de trace-tijdlijn. Bovendien kunnen logkenmerken statische informatie bevatten van de OpenTelemetry-context, zoals de node-identifier, evenals dynamische informatie, zoals de huidige HTTP-endpoint-identifier (`http_path: "GET /user/:id"`).

Met behulp van de `trace_id` kunt u logs vinden van alle microservices die aan de huidige aanvraag zijn gekoppeld, terwijl u met de `span_id` onderscheid kunt maken tussen subaanvragen. Bijvoorbeeld, in het geval van retries, zullen logs van verschillende pogingen verschillende `span_id`s hebben. Met behulp van deze identifiers kunt u het gedrag van het hele systeem snel analyseren in realtime, wat de probleemdiagnose versnelt en de stabiliteit en betrouwbaarheid verbetert.

Metrieken

Metrics collection biedt kwantitatieve gegevens over systeemprestaties, zoals latentie, foutpercentages, resourcegebruik en meer. Realtime monitoring van metrics stelt u in staat om snel te reageren op prestatieveranderingen, storingen en resource-uitputting te voorkomen en een hoge beschikbaarheid en betrouwbaarheid van de applicatie voor gebruikers te garanderen.

Integratie met metrische opslag- en visualisatiesystemen zoals Prometheus en Grafana maakt het eenvoudiger om deze gegevens te visualiseren, wat de monitoring aanzienlijk vereenvoudigt.

Metrische verzamelaars

OpenTelemetry metric collectors zijn compatibel met Prometheus en OpenMetrics standaarden, wat een eenvoudige overgang naar OpenTelemetry oplossingen mogelijk maakt zonder significante veranderingen. De OpenTelemetry SDK maakt het mogelijk om trace_id voorbeelden te exporteren samen met metrics, wat het mogelijk maakt om metrics te correleren met log voorbeelden en traces.

Signaalcorrelatie

Samen creëren logboeken, statistieken en tracering een compleet overzicht van de status van het systeem:

• Logboeken verschaffen informatie over systeemgebeurtenissen, waardoor fouten snel kunnen worden geïdentificeerd en opgelost.
• Metrieken geven kwalitatieve en kwantitatieve prestatie-indicatoren van het systeem weer, zoals responstijden of foutpercentages.
• Tracering vult deze weergave aan door het pad van de uitvoering van verzoeken door verschillende systeemcomponenten te tonen, wat helpt om hun onderlinge relaties te begrijpen. De duidelijke correlatie tussen logs, traces en metrics is een onderscheidend kenmerk van OpenTelemetry. Zo stelt Grafana gebruikers in staat om de bijbehorende trace- en verzoekmetrics te zien wanneer ze een log bekijken, wat de bruikbaarheid en efficiëntie van het platform aanzienlijk verbetert.

Naast de drie kerncomponenten omvat OpenTelemetry de concepten van bemonstering, bagage en operationeel contextbeheer.

Bemonstering

In systemen met een hoge belasting wordt het volume aan logs en traces enorm, wat aanzienlijke middelen vereist voor infrastructuur en gegevensopslag. Om dit probleem aan te pakken, omvatten OpenTelemetry-standaarden signaalsampling: de mogelijkheid om slechts een deel van de traces en logs te exporteren. U kunt bijvoorbeeld gedetailleerde signalen exporteren van een percentage van de verzoeken, langlopende verzoeken of foutverzoeken. Deze aanpak maakt voldoende sampling mogelijk om statistieken op te bouwen en tegelijkertijd aanzienlijke middelen te besparen.

Als elk systeem echter onafhankelijk beslist welke verzoeken gedetailleerd moeten worden gemonitord, eindigen we met een gefragmenteerd beeld van elk verzoek. Sommige systemen kunnen gedetailleerde gegevens exporteren, terwijl andere slechts gedeeltelijk of helemaal niet exporteren.

Om dit probleem op te lossen, verzenden de contextpropagatiemechanismen van OpenTelemetry een samplingvlag samen met de `trace_id`/`span_id`. Dit zorgt ervoor dat als de eerste service die de gebruikersaanvraag ontvangt, besluit dat de aanvraag gedetailleerd moet worden gecontroleerd, alle andere systemen dit voorbeeld volgen. Anders zouden alle systemen signalen gedeeltelijk of helemaal niet moeten exporteren om bronnen te besparen. Deze aanpak wordt "Head Sampling" genoemd — een beslissing die aan het begin van de aanvraagverwerking wordt genomen, willekeurig of op basis van enkele invoerattributen.

Bovendien ondersteunt OpenTelemetry "Tail Sampling", waarbij alle applicaties altijd alle signalen in detail exporteren, maar er is een tussenliggende buffer. Nadat alle data is verzameld, beslist deze buffer of de volledige data moet worden bewaard of slechts een gedeeltelijke sample. Deze methode zorgt voor een representatievere sample van elke aanvraagcategorie (succesvol/lang/fout), maar vereist extra infrastructuurinstellingen.

Bagage

Met het Baggage-mechanisme kunnen willekeurige sleutel-waardeparen worden verzonden samen met trace_id / span_id , die automatisch tussen alle microservices worden doorgegeven tijdens de verwerking van de aanvraag. Dit is handig voor het verzenden van aanvullende informatie die nodig is tijdens het aanvraagpad, zoals gebruikersinformatie of runtime-omgevingsinstellingen.

Voorbeeld van een header voor het verzenden van bagage volgens de W3C-standaard: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Hier zijn enkele voorbeelden van bagagegebruik:

• Zakelijke context doorgeven Informatie zoals userId , productId of deviceId kan via alle microservices worden doorgegeven. Applicaties kunnen deze informatie automatisch loggen, wat logzoekopdrachten op gebruikerscontext voor de oorspronkelijke aanvraag mogelijk maakt.

• Specifieke configuratieparameterinstellingen voor SDK's of infrastructuur.

• Routing Flags Flags die load balancers helpen bij het nemen van routingbeslissingen. Tijdens het testen moeten sommige verzoeken mogelijk worden gerouteerd naar mock-backends. Omdat bagage automatisch via alle services wordt verzonden, is het niet nodig om extra protocollen te maken. Stel gewoon een regel in op de load balancer.

  
  

Infrastructuur implementatie

Het implementeren van OpenTelemetry op infrastructuurniveau omvat het integreren van OpenTelemetry-backends in de applicatiearchitectuur en het configureren van de infrastructuur voor gegevensaggregatie.

Het proces bestaat uit vier fasen:

1. Integratie van applicaties In de eerste fase worden OpenTelemetry SDK's rechtstreeks geïntegreerd in applicaties om statistieken, logboeken en traceringen te verzamelen. Zo ontstaat een continue stroom van gegevens over de prestaties van elk systeemonderdeel.

   
   

2. Exporteurs configureren Verzamelde gegevens worden vanuit toepassingen via exporteurs naar externe systemen gerouteerd voor verdere verwerking, zoals logging, monitoring, tracering of analysesystemen, afhankelijk van uw behoeften.

   
   

3. Aggregatie en opslag In deze fase kunnen gegevens worden genormaliseerd, verrijkt met aanvullende informatie en samengevoegd uit verschillende bronnen om een eenduidig beeld van de status van het systeem te krijgen.

   
   

4. Data Visualisatie Tot slot worden verwerkte data gepresenteerd als dashboards in systemen zoals Grafana (voor statistieken en traces) of Kibana (voor logs). Hierdoor kunnen teams snel de status van het systeem beoordelen, problemen en trends identificeren en waarschuwingen instellen op basis van gegenereerde signalen.

Implementatie van applicaties

Om te integreren met een applicatie, moet u de juiste OpenTelemetry SDK voor de gebruikte programmeertaal verbinden of bibliotheken en frameworks gebruiken die OpenTelemetry rechtstreeks ondersteunen. OpenTelemetry implementeert vaak veelgebruikte interfaces van bekende bibliotheken, waardoor drop-in vervangingen mogelijk zijn. De Micrometer-bibliotheek wordt bijvoorbeeld veel gebruikt voor het verzamelen van metrische gegevens in het Java-ecosysteem. De OpenTelemetry SDK biedt zijn implementaties van Micrometer-interfaces, waardoor metrische export mogelijk is zonder de hoofdtoepassingscode te wijzigen. Bovendien biedt OpenTelemetry implementaties van oudere OpenTracing- en OpenCensus-interfaces, waardoor een soepele migratie naar OpenTelemetry mogelijk is.

Conclusie

In IT-systemen kan OpenTelemetry de sleutel worden tot de toekomst van betrouwbare en efficiënte backends. Deze tool vereenvoudigt debugging en monitoring en opent ook mogelijkheden voor een diepgaand begrip van applicatieprestaties en optimalisatie op een nieuw niveau. Sluit u aan bij de OpenTelemetry-community om een toekomst vorm te geven waarin backend-ontwikkeling eenvoudiger en effectiever is!