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.
Grote techbedrijven werden eind jaren 2000 voor het eerst geconfronteerd met de uitdaging van gedistribueerde logging en tracing. In 2010 publiceerde Google een paper,
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.
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: \
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:
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.
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 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:
trace_id
en span_id
voor gebruik in andere signalen.
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.
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.
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.
Samen creëren logboeken, statistieken en tracering een compleet overzicht van de status van het systeem:
Naast de drie kerncomponenten omvat OpenTelemetry de concepten van bemonstering, bagage en operationeel contextbeheer.
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.
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.
Houd er rekening mee dat hoewel de prestatie-impact van Baggage minimaal is, overmatig gebruik de netwerk- en servicebelasting aanzienlijk kan verhogen. Kies zorgvuldig welke gegevens u echt via Baggage wilt doorgeven om prestatieproblemen te voorkomen.
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:
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.
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.
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.
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.
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.
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!