OpenTelemetry (OTel) is een Observability-kader en -toolkit met een gedeelde taal, gegevensmodel en uniformiteit voor onderliggend propagatiegedrag. OTel is ook ontworpen voor het beheer van telemetriegegevens zoals traces, meetwaarden en logs. Het is bovendien open source, waardoor meer flexibiliteit mogelijk is.
OpenTelemetry is het resultaat van een fusie tussen twee eerdere projecten, OpenTracing en OpenCensus. Beide projecten zijn gemaakt om hetzelfde probleem op te lossen: het ontbreken van een standaard voor het instrueren van code en het verzenden van telemetriegegevens naar een back-end voor observeerbaarheid. Geen van beide projecten was echter volledig in staat om het probleem op zichzelf op te lossen, en daarom zijn de twee projecten samengevoegd tot OpenTelemetry. Zo zijn de sterke punten gecombineerd om werkelijk één standaard te bieden.
Cruciaal is dat OpenTelemetry leveranciers- en tool-agnostisch is. Dit betekent dat het kan worden gebruikt met een breed scala aan backends voor observeerbaarheid, waaronder open-source tools als Jaeger en Prometheus, en ook commerciële aanbiedingen. OTel is een Cloud Native Computing Foundation-project (CNCF), gebouwd om te functioneren als een robuuste, draagbare en eenvoudig te instrueren oplossing in vele talen. OTel biedt één set API's, bibliotheken, agents en collectorservices om gedistribueerde traces en meetwaarden van je toepassing vast te leggen. OpenTelemetry maakt echte observeerbaarheid mogelijk.
'Observeerbaarheid' is een term die veel aandacht heeft gekregen in de wereld van software-engineering en systeembeheer, bijna tot op het punt dat het concept een deel van zijn betekenis heeft verloren. Vandaag de dag gebruiken zelfs veel IT-medewerkers de term losjes om elk type systeemzichtbaarheid aan te geven. Maar wat is observeerbaarheid precies en hoe verschilt het van traditionele monitoring?
Monitoring is het proces waarbij de systeemstatus actief wordt bewaakt en gecontroleerd, meestal met behulp van vooraf gedefinieerde drempelwaarden en waarschuwingen. Hoewel je met deze aanpak aandacht kan vestigen op de getroffen systemen wanneer er iets mis gaat, biedt monitoring vaak geen inzicht in waarom het probleem zich voordoet of hoe je het probleem het beste kunt oplossen.
Observeerbaarheid biedt daarentegen een meer omvattende aanpak. Dit concept verwijst naar het vermogen om te begrijpen wat er binnen een systeem gebeurt door de externe outputs te analyseren. Met observeerbaarheid kun je elk type vraag stellen over wat er op elk moment is gebeurd, zonder vooraf te bepalen wat je wilt weten. Waar monitoring dus focust op de vraag wat er misgaat, geeft observeerbaarheid antwoord op de vragen hoe en waarom iets misgaat.
Er zijn drie hoofdpijlers die essentieel zijn voor observeerbaarheid:
- Traces
Een trace vertegenwoordigt het traject van een aanvraag door een systeem en kan een gedetailleerd beeld geven van service-interacties. OpenTelemetry-traces worden georganiseerd in spans die kenmerken en events bevatten en die het werk dat wordt uitgevoerd in verschillende processen en services beschrijven en contextualiseren. - Meetwaarden
Meetwaarden zijn numerieke weergaven van gegevens die zijn gemeten over tijdsintervallen. Ze maken de continue bewaking van systeemprestaties en -gedrag mogelijk. In OpenTelemetry kan de Metrics API worden gebruikt om systeemwaarden vast te leggen, in te stellen en toe te voegen. Ook biedt het tools om later analyses te kunnen filteren en samen te stellen. - Logs
Logs zijn op tekst gebaseerde records die worden gegenereerd door systemen en toepassingen. Ze bieden een chronologisch overzicht van events en kunnen van vitaal belang zijn voor het opsporen van fouten en het begrijpen van systeemgedrag.
Hoewel deze drie elementen al langer worden beschouwd als de meest essentiële factoren voor observeerbaarheid, is dit traditionele model noodgedwongen doorontwikkeld vanwege de toenemende schaal en complexiteit in moderne gedistribueerde systemen. Professionals beginnen in te zien dat de drie pijlers niet geïsoleerd zijn, maar fundamenteel met elkaar verbonden, en ook in coördinatie met elkaar moeten worden gebruikt.
OpenTelemetry speelt een cruciale rol bij het mogelijk maken van observeerbaarheid in gedistribueerde, microservicegebaseerde systemen. De nadruk op draagbaarheid, beschikbaarheid van implementaties en Software Development Kits (SDK's) in een groot aantal talen, en met name de export- en collectormodellen, maakt het een belangrijk hulpmiddel bij het verzamelen en distribueren van gegevens die geschikt zijn voor het systeem.
Met OpenTelemetry kunnen teams op efficiënte wijze de belangrijkste gegevens voor traces en meetwaarden verzamelen die nodig zijn om het gedrag van het systeem te analyseren. Deze afstemming met observeerbaarheidsmethoden maakt een diepgaander inzicht in de systeemprestaties mogelijk, waardoor problemen makkelijker kunnen worden gediagnosticeerd en opgelost.
Net zoals traces een van de drie pijlers van observeerbaarheid zijn, is tracering een cruciale methode binnen de softwareontwikkeling, die meestal wordt gebruikt om toepassingscode te profileren en te analyseren met gespecialiseerde foutopsporingstools. In de context van OpenTelemetry krijgt tracering een genuanceerdere betekenis, waarbij meestal wordt verwezen naar gedistribueerde tracering, een essentieel concept in de hedendaagse complexe architecturen.
Gedistribueerde tracering is de toepassing van traditionele traceringstechnieken op moderne, microservicegerichte toepassingen. In tegenstelling tot monolitische toepassingen, waarbij bij het diagnosticeren van een storing één stacktrace kan worden gevolgd, zijn gedistribueerde systemen gewoon te complex voor deze aanpak. Wanneer een toepassing bestaat uit mogelijk duizenden services die op talloze hosts worden uitgevoerd, zijn individuele traces ontoereikend. Gedistribueerde tracering lost dit probleem op door aanvragen te profileren terwijl ze zich over verschillende servicegrenzen verplaatsen. Op deze manier worden hoogwaardige gegevens voor analyse gegenereerd. Deze methode biedt mogelijkheden zoals:
- Afwijkingendetectie
- Workloadmodellering
- Steady-state probleemdiagnose
In OpenTelemetry is een trace een verzameling gekoppelde spans: benoemde en getimede bewerkingen die een eenheid van werk in een aanvraag vertegenwoordigen. Een span kan een bovenliggende span hebben, of zelf een root span zijn, die de end-to-end latentie van de gehele trace beschrijft. Onderliggende spans vertegenwoordigen subbewerkingen binnen de trace.
- Root span
De bovenliggende trace of beginpunt van de trace, die de latentie van de gehele aanvraag vertegenwoordigt. - Onderliggende span
Een specifieke subbewerking binnen de trace.
Spans bevatten essentiële informatie, waaronder de naam van de bewerking, begin- en eindtijdstempels, events en kenmerken die tijdens de periode zijn opgetreden. Ze bevatten ook koppelingen naar andere spans en de status van de bewerking.
Gezien de complexiteit van gedistribueerde systeemtraceringsgegevens, kan toegang tot context en andere relevante details een groot positief verschil maken in de gegevensanalyse. In OpenTelemetry staan deze tags bekend als kenmerken en events:
- Kenmerken
Dit zijn sleutelwaardeparen (in OpenTracing 'tags' genoemd) die kunnen worden toegevoegd aan een span om te helpen bij het analyseren van traceringsgegevens. - Events
Tekenreeksen met tijdstempel en een optionele set kenmerken die een verdere beschrijving geven, zodat een meer gedetailleerde analyse mogelijk is.
Spans in OpenTelemetry worden gegenereerd door de Tracer, een object dat de actieve span volgt en waarmee ook nieuwe spans kunnen worden gemaakt. Propagator-objecten ondersteunen de overdracht van context over procesgrenzen heen, een essentieel aspect van tracering in gedistribueerde systemen. De Tracer verzendt voltooide spans naar de SDK Exporter van OTel, die verantwoordelijk is voor het verzenden van de spans naar een back-endsysteem voor verdere analyse.
Tracering biedt gedetailleerde inzichten in individuele aanvragen en activiteiten, maar sluit ook aan bij de bredere context van observeerbaarheid binnen OpenTelemetry, inclusief meetwaarden. Door tracegegevens te koppelen aan relevante meetwaarden krijgen organisaties uitgebreid inzicht in het gedrag en de prestaties van hun systeem.
In de context van OpenTelemetry is de Metrics API ontworpen om onbewerkte metingen continu te verwerken en samen te vatten. Dit geeft organisaties een beter inzicht in essentiële operationele meetwaarden, waaronder het gebruik van procesgeheugen, foutpercentages en meer. Meetwaarden kunnen naar verschillende instrumenten worden verzonden voor aggregatie en registratie. De OpenTelemetry Metrics API classificeert metrische instrumenten op basis van hun semantische betekenis, en niet op basis van het uiteindelijke waardetype dat ze exporteren.
De Metrics API biedt zes verschillende metrische instrumenten die elk een specifieke functie vervullen. Deze instrumenten worden gecreëerd en gedefinieerd door oproepen naar een Meter API, het toegangspunt van de gebruiker tot de SDK. Metrische instrumenten zijn synchroon of asynchroon.
Synchrone instrumenten worden binnen een aanvraag aangeroepen en beschikken over een gekoppelde gedistribueerde context. Synchrone instrumenten omvatten:
- Counter
Het Counter-instrument accepteert positieve waarden met de functie Add(). Dit is ideaal voor het tellen van gegevens zoals het aantal ontvangen bytes, voltooide aanvragen en het meten van foutincidentie, en is daarom bijzonder geschikt voor het beoordelen van metingen. - UpDownCounter
UpDownCounter is een uitbreiding van de counterfunctionaliteit en verwerkt zowel positieve als negatieve stappen via de functie Add(). Dit is handig voor het bewaken van hoeveelheden zoals actieve aanvragen, het gebruikte geheugen en de wachtrijgrootte. - ValueRecorder
Het ValueRecorder-instrument registreert waarden voor discrete events met behulp van de functie Record(). Dit wordt gebruikt voor het vastleggen van latentie, aanvraaggrootte en wachtrijlengte, waarbij een verdeling van waarden wordt benadrukt
In tegenstelling tot synchrone instrumenten ontbreekt het asynchrone instrumenten aan een bijbehorende context. Deze instrumenten worden gerapporteerd door een callback en worden slechts één keer per collectie-interval opgeroepen. Synchrone instrumenten omvatten:
- SumObserver
Het SumObserver-instrument maakt gebruik van de functie Observing() voor asynchrone monotone sommen en is het meest geschikt voor gegevens zoals 'cache-misses' en systeem-CPU. - UpDownSumObserver
UpDownSumObserver is een asynchrone, niet-monotone teller die positieve en negatieve sommen accepteert met de functie Observing(). Dit instrument wordt gebruikt voor metingen die de stijging en daling van sommen vastleggen, zoals de grootte van de procesheap. - ValueObserver
Ten slotte biedt de ValueObserver organisaties nauwkeurige controle over niet-additieve metingen met behulp van de functie Observing(). Dit is ideaal wanneer de focus van de metingen een distributie is.
Metrische events die door een instrument worden vastgelegd, bestaan uit een tijdstempel, instrumentdefinitie (naam, soort, beschrijving, maateenheid), labelset (sleutels en waarden), waarde (geheel getal of floating-pointgetal), resources die zijn gekoppeld aan de SDK en gedistribueerde context (alleen voor synchrone events). De verscheidenheid aan beschikbare metrische instrumenten biedt flexibiliteit bij het vastleggen van verschillende soorten gegevens, wat helpt bij de analyse en bewaking van verschillende systeemkenmerken.
De metrische instrumenten van OpenTelemetry bieden diverse opties voor ontwikkelaars om kritische inzichten in hun toepassingen te verkrijgen, ongeacht of het gaat om het bewaken van foutpercentages, latentie of resourcegebruik.
De exporter is verantwoordelijk voor het batchen en transporteren van telemetriegegevens naar een back-endsysteem voor analyse en waarschuwingen. Het exportermodel van OpenTelemetry ondersteunt de integratie van instrumentatie op drie verschillende niveaus:
- Integratie op serviceniveau
Dit houdt in dat je afhankelijk bent van het relevante OpenTelemetry-pakket binnen je code en dat je het navenant implementeert. - Bibliotheekafhankelijkheden
Vergelijkbaar met integratie op serviceniveau, maar specifiek voor bibliotheken, die doorgaans alleen afhankelijk zijn van de OpenTelemetry API. - Platformafhankelijkheden
Dit zijn onafhankelijke softwarecomponenten die je service ondersteunen, zoals Envoy en Istio. Deze componenten implementeren hun exemplaar van OpenTelemetry en zenden tracecontext uit die nuttig is voor je service.
De exportinterface wordt geïmplementeerd door OpenTelemetry SDK's en maakt gebruik van een plug-in-model dat telemetriegegevens vertaalt naar de vereiste indeling voor een bepaald back-endsysteem voordat de gegevens worden verzonden. Dit model ondersteunt ook de samenstelling en koppeling van exporters, waardoor gedeelde functionaliteit in verschillende protocollen wordt vergemakkelijkt.
Een belangrijk voordeel van de benadering van OpenTelemetry is het gemak waarmee exportcomponenten kunnen worden geschakeld of toegevoegd. Dit onderscheidt het van OpenTracing, waarbij het wijzigen van het systeem de gehele tracercomponent moet vervangen.
Hoewel het exportmodel gebruiksvriendelijk is, kunnen bepaalde organisatorische of technische beperkingen de eenvoudige herimplementatie van een service verhinderen om een nieuwe exporter toe te voegen. De OpenTelemetry-collector is ontworpen als een 'gootsteen' voor telemetriegegevens uit meerdere processen, die worden geëxporteerd naar verschillende back-endsystemen zoals ServiceNow Cloud Observability, Jaeger of Prometheus. De collector kan worden geïmplementeerd als agent naast een service of als externe toepassing:
- Agent
Geïmplementeerd met je service, uitgevoerd als een afzonderlijk proces of 'sidecar'. - Externe collector
Afzonderlijk geïmplementeerd in een container of virtuele machine, waarbij telemetriegegevens van elke agent worden ontvangen en naar back-endsystemen worden geëxporteerd.
OpenTelemetry bestaat uit de volgende hoofdcomponenten:
- Een specificatie voor alle componenten
- Een standaardprotocol waarmee de vorm van telemetriegegevens wordt gedefinieerd
- Semantische conventies die een standaard naamgevingsschema definiëren voor gangbare telemetriegegevenstypen
- API's die definiëren hoe telemetriegegevens moeten worden gegenereerd
- Een ecosysteem van bibliotheken waarmee de instrumentatie van gemeenschappelijke bibliotheken en frameworks wordt geïmplementeerd
- Automatische instrumentatiecomponenten die telemetriegegevens genereren zonder dat code hoeft te worden gewijzigd
- Taal-SDK's die de specificatie, API's en export van telemetriegegevens implementeren
- De OpenTelemetry Collector, een proxy die telemetriegegevens ontvangt, verwerkt en exporteert
- Diverse andere tools, zoals de OpenTelemetry Operator for Kubernetes
OpenTelemetry is compatibel met een breed scala aan open source-integraties voor ecosystemen en wordt ook ondersteund door een groot aantal leveranciers, van wie er velen commerciële ondersteuning bieden voor OpenTelemetry en rechtstreeks bijdragen aan het project.
OpenTelemetry is ontworpen om uitbreidbaar te zijn. Enkele voorbeelden van hoe dit kan worden uitgebreid:
- Een ontvanger toevoegen aan de OpenTelemetry Collector om telemetriegegevens van een aangepaste bron te ondersteunen
- Aangepaste instrumenten laden in een SDK
- Het maken van een distributie van een SDK of de Collector die is aangepast aan een specifieke use case
- Een nieuwe exporter maken voor een aangepaste back-end die het OpenTelemetry-protocol (OTLP) nog niet ondersteunt
- Een aangepaste propagator maken voor een niet-standaard indeling voor contextpropagatie
Hoewel de meeste gebruikers OpenTelemetry niet hoeven uit te breiden, is het project ontworpen om dat toch op bijna elk niveau mogelijk te maken.
Met de opkomst van cloudcomputing, microservicearchitecturen en steeds complexere bedrijfsvereisten is de behoefte aan observeerbaarheid nog nooit zo groot geweest.
Om een systeem observeerbaar te maken, moet het worden geïnstrueerd. Dat wil zeggen, de code moet traces, meetwaarden en logs uitzenden. De instrumentgegevens moeten vervolgens naar een Observability-back-end worden gestuurd.
OpenTelemetry doet twee belangrijke dingen:
- Je kunt eigenaar zijn van de gegevens die je genereert in plaats van vast te zitten aan een gegevensindeling of -tool van derden.
- Je kunt hiermee één set API's en conventies leren
Deze twee dingen samen bieden teams en organisaties de flexibiliteit die ze nodig hebben in de moderne computerwereld van vandaag.
OpenTelemetry is geen Observability-back-end zoals Jaeger, Prometheus of commerciële leveranciers. OpenTelemetry is gericht op het genereren, verzamelen, beheren en exporteren van telemetriegegevens. De opslag en visualisatie van die gegevens wordt opzettelijk overgelaten aan andere tools.
De behoefte aan end-to-end zichtbaarheid is belangrijker dan ooit. OpenTelemetry biedt een gestandaardiseerde aanpak voor het verzamelen van telemetriegegevens in diverse toepassingen en programmeertalen. Door dat OTel uitgebreide inzichten in systeemgedrag biedt, kunnen organisaties prestaties optimaliseren, problemen oplossen en een naadloze gebruikerservaring bieden. Maar als het gaat om observeerbaarheid, is er altijd ruimte voor verbetering.
ServiceNow Cloud Observability, voorheen Lightstep genoemd, ondersteunt OpenTelemetry als dé manier om telemetriegegevens (traces, logs en meetwaarden) te verkrijgen wanneer aanvragen via services en andere infrastructuur worden verzonden. Cloud Observability neemt OpenTelemetry-gegevens op via het native OpenTelemetry Protocol (OTLP). OTLP-gegevens kunnen vervolgens via HTTP of gRPC naar Cloud Observability worden geëxporteerd.
Om de observeerbaarheid en governance in cloudomgevingen verder te verbeteren, heeft ServiceNow nu ook de Servicegrafiekconnector voor OpenTelemetry (SGC) gelanceerd. Met behulp van OpenTelemetry-gegevens en de ServiceNow Cloud Observability-back-end vormt deze oplossing een revolutie in de manier waarop bedrijven zicht krijgen op en inzicht krijgen in hun cloudtoepassingen en Kubernetes-infrastructuur. SGC detecteert automatisch serviceafhankelijkheden en brengt deze in kaart, waardoor een nauwkeurige en actuele servicetopologie wordt gecreëerd. Doordat organisaties nu de impact van wijzigingen kunnen beoordelen, incidentbeheer stroomlijnen en functionele samenwerking bevorderen, genieten ze meer efficiëntie, minder risico's en krijgen ze de best mogelijke observeerbaarheid in complexe IT-omgevingen.
Ervaar de transformatieve mogelijkheden van Servicegrafiekconnector voor OpenTelemetry; neem vandaag nog contact op met ServiceNow!