6min

Tags in dit artikel

, , , , ,

Nieuwe paradigma’s in cloud-native development zorgen voor meer behoefte aan observability. OpenTelemetry moet hier een centrale rol in gaan spelen.

Zonder inzicht kun je geen gefundeerde beslissingen nemen. Dat gegeven is de basis voor de stortvloed aan observability-oplossingen en -benaderingen die momenteel over ons heen komt. Ook tijdens KubeCon 2023 in Amsterdam was er heel veel om te doen. Zeker nu applicaties en daarmee omgevingen van organisaties steeds verder versplinteren, wordt het belangrijker om iets te gebruiken wat inzicht kan geven in de prestaties ervan.

Om dit inzicht te krijgen, is telemetrie nodig. OpenTelemetry (oftewel OTel) speelt hierbij een belangrijke rol, betoogt Austin Parker, Head of Developer Relations bij Lightstep from ServiceNow, zoals het bedrijf officieel heet. Vanaf hier zullen we het Lightstep noemen, voor de leesbaarheid. Dat bedrijf heeft zich sinds de oprichting door voormalige Google-engineers zo’n zeven jaar geleden gespecialiseerd in OpenTelemetry en observability. Inmiddels is het onderdeel van het portfolio van ServiceNow. Het doel van het bedrijf is simpel, volgens Parker: “We willen telemetrie onderdeel maken van cloud-native.”

Van monitoring naar observability

Organisaties monitoren doorgaans wat af. Er komt telemetrie en logs binnen van de gehele infrastructuur. Als je daar echter verder niet zoveel mee doet of kan doen, dan heb je alleen meer een heleboel data. Dat is nog geen observability. Dat is echter wel waar we heen moeten. Met de opkomst van Kubernetes en de serverless architecturen waar we hierna naartoe gaan, wordt het alleen maar belangrijker om dit goed in te richten.

Als we het hebben over observability, gaat het dus niet alleen maar om zoveel mogelijk data verzamelen. Het gaat er ook om dat daar zinvolle inzichten uitkomen. Aangezien het hier om een enorme hoeveelheid data gaat, moet dit ook op een slimme manier gebeuren. Dat wil zeggen, er moet een zekere mate van intelligentie in een oplossing zitten, maar het moet ook op basis van een standaard gebeuren, op een overkoepelende manier. Alleen dan kun je de nodige verbanden leggen en die omzetten in acties.

Lightstep is volgens Parker het ontbrekende stuk voor deze puzzel. Een dergelijke oplossing had hij in ieder geval graag gehad toen hij als DevOps-engineer werkte: “Ik werd ’s nachts wakker gemaakt, omdat een build kapot was gegaan en moest door release-certificeringen gaan zonder dat ik wist wat er kapot was. Ik moest op afstand inloggen om te zoeken naar die ene regel code die stuk was.”

UQL en OpenTelemetry

Tijdens ons gesprek met Parker komen twee zaken regelmatig naar boven. Aan de ene kant is er OpenTelemetry, waar we het al even over hebben gehad. Aan de andere kant heeft hij het ook over UQL, de query language die Lightstep heeft ontwikkeld. Dat is in principe waar “the magic happens”, geeft hij aan. Dat is waar de observability van Lightstep zich onderscheidt van wat veel andere partijen bieden. Die bieden volgens hem vaak puntoplossingen van derde partijen. Met Lightstep is dat dankzij UQL niet nodig, stelt hij. “We hebben alleen de goede data, traces, metrics en logs in eenzelfde format, die we met eenzelfde query language aanspreken.” Je kunt de telemetrie dan samenvoegen in een enkel platform.

De query language in de quote van Parker hierboven is bij Lightstep vanzelfsprekend UQL. Het format waarin het geheel wordt gevat is OpenTelemetry. Als het format globaal hetzelfde is, kan UQL zijn kunstje doen, in combinatie met wat Parker change intelligence noemt. Als voorbeeld van dat laatste noemt hij het analyseren van outliers in de telemetrie. De oplossing van Lightstep geeft aan waar er een SLI (Service Level Indicator) spike zit, waarna je niet meer naar de logs hoeft te kijken, maar simpelweg de traces kunt analyseren. Dit zorgt ervoor dat je een probleem veel sneller op kunt lossen. Het gevolg van de benadering zoals Lightstep die voorstaat is dat je geen telemetrie meer genereert die je toch niet nodig hebt. De change intelligence geeft inzicht in data over meerdere datastromen heen. Op basis hiervan kun je bepalen welke data wel en welke niet bewaard wordt. Alleen de relevante metrics gaan naar een decisioning engine, waar wordt bepaald wat er gedaan moet worden.

De markt moet over naar OpenTelemetry

Bovenstaande klinkt leuk, maar dit gaat Lightstep alleen niet voor elkaar krijgen. Nu het onderdeel is van ServiceNow, kan het veel harder doorontwikkelen dan voorheen. ServiceNow lijkt ook echt een prioriteit te maken van observability. Naast de overname van Lightstep enkele jaren geleden, was er ook nog de overname van Era Software. Sinds Knowledge 23, de jaarlijkse conferentie van ServiceNow, is er verder ook ServiceNow Cloud Observability. Dat bestaat niet alleen uit de Lightstep  observability-component, maar ook uit de cloud-logging-functionaliteit van Era Software. Het doel van ServiceNow is duidelijk. Het wil hiermee een end-to-end observability-oplossing voor cloudapplicaties bieden.

Het succes van wat Lightstep en ServiceNow willen op het gebied van observability is niet alleen afhankelijk van wat ze zelf doen. De markt als geheel moet natuurlijk ook mee. Als niet iedereen OpenTelemetry ondersteunt, dan heb je alsnog niet het inzicht dat je nodig hebt. Dat realiseert Parker zich uiteraard ook. Volgens hem is het ook helemaal niet onrealistisch om een dergelijke overstap te maken. Er zit weinig verschil tussen de telemetrie van de ene leverancier en de andere. Het is min of meer een commodity. Dan is de stap naar OpenTelemetry niet zo heel groot, in theorie in ieder geval.

Hoever is de markt?

Volgens Parker zitten we aan het einde van het begin van de standaardisatie die nodig is. Er zijn al duizenden ontwikkeltalen, beheeromgevingen en tools die het gebruiken. Java en .NET gebruiken het bijvoorbeeld al, maar ook C++, Golang. JavaScript (NodeJS en Browser), Erlang, Rust, Swift. Het worden er alleen maar meer. Bij Kubernetes is het inmiddels ook goed op gang gekomen. Daar zat in het begin ook geen ondersteuning in voor OpenTelemetry, maar dat gaat nu met sprongen vooruit.

Voor OpenTelemetry geldt vanzelfsprekend ook dat het door blijft ontwikkelen. Daar is men tot nu toe vooral bezig geweest met het metrics-gedeelte. De focus gaat nu richting het ontwikkelen van zogeheten logging bridges. Deze bruggen kunnen ontwikkelaars bouwen via een door OpenTelemetry aangeboden bridge API. Als voorbeeld haalt Parker Log4j aan, de logging tool die door heel veel software gebruikt wordt. “Wij gaan geen betere tool dan Log4j kunnen bouwen, daar willen we ook helemaal niet mee concurreren”, geeft hij aan. Vandaar dat ze een brug aanbieden tussen de OpenTelemetry SDK en Log4j.

Niet te stoppen

Hoe snel OpenTelemetry de standaard wordt, is lastig in te schatten. “Maar de geest gaat niet meer terug in de fles”, is Parker van mening. We zitten nu stevig in de wereld van Kubernetes en de volgende generatie wordt serverless. “Dan wordt OpenTelemetry nog belangrijker dan het nu al is, omdat het dan allemaal echt veel te complex wordt”, geeft hij aan. Daar komt zo ontzaglijk veel telemetrie uit, dat moet wel in een gedeeld format beschikbaar worden gesteld aan observability-tools. “Het belang van OpenTelemetry neemt evenredig toe met de toename in adoptie van Kubernetes en serverless”, vat hij het samen.

Als de samenvatting van Parker hierboven klopt, dan gaan we nog veel horen rondom OpenTelemetry en de observability-voordelen die het kan bieden. Een belangrijke vraag richting de toekomst zal zijn of OpenTelemetry onderaan de streep betere inzichten biedt dan native (niet-standaard) telemetrie. Naast het binden van klanten aan een specifiek platform, biedt native telemetrie vaak ook net wat meer, omdat het specifiek voor de software van een leverancier is geschreven. Het geeft die leveranciers ook een streepje voor bij gesprekken met (potentiële) klanten.

Het is aan partijen zoals Lightstep om aan te tonen dat OpenTelemetry uiteindelijk toch beter is. In combinatie met de data van het ServiceNow-platform ziet het er op zich goed uit op dat punt. Hiermee kan het observability bieden voor onderdelen van organisaties waar het normaal gesproken niet komt. Het wordt dan mogelijk om data rondom change management, assets en de mensen die bij een organisatie werken, te koppelen aan de prestaties van applicaties. Het wordt dan ook eenvoudiger om de koppeling te leggen tussen verschillen in prestaties van applicaties en de prestaties van de organisatie en de omzet. De contouren van wat ServiceNow en Lightstep bedoelen met end-to-end observability worden hiermee al zichtbaar. Ze zullen de komende tijd alleen maar duidelijker worden.

Lees ook: Knowledge23: Weet men inmiddels wat ServiceNow is en doet?