Observability is al minstens het afgelopen decennium een dominante trend geweest in de ontwikkeling van de cloud, zo niet langer. Nu organiseren IT-specialisten op dit gebied grote events uitsluitend gewijd aan observability. Softwareontwikkelaars en hun collega’s in de operationele afdelingen zijn inmiddels ook overtuigd van gevirtualiseerde omgevingen, zodat ze orde en controle kunnen handhaven. Maar is het tijd voor observability om te evolueren en te groeien. Zouden observability warehouses de volgende grote ontwikkeling kunnen zijn?
Waarom zouden we ons überhaupt bezighouden met observability? Dat zou duidelijk onze eerste vraag moeten zijn. Experts zijn het erover eens dat we observability nodig hebben in alle systemen. Maar toch geldt dat vooral in de cloud, waar we realtime inzicht nodig hebben in de systeemconfiguratie, het gedrag, de prestaties en de status. Dit zodat softwareteams afwijkingen kunnen detecteren, storingen kunnen diagnosticeren en inzicht kunnen krijgen in de prestaties van de gedistribueerde infrastructuur waarop ze hun applicaties en dataservices draaien. We weten dat observability kan helpen om downtime te verminderen, de respons op incidenten te versnellen en betrouwbaarheid op schaal te waarborgen.
De observability-sector genereert enorme hoeveelheden telemetriedata. Dit gebeurt terwijl logs, metrics en traces door moderne systemen stromen. Naarmate organisaties groeien, neemt ook hun datavolume toe. In het afgelopen decennium is de hoeveelheid telemetriedata (de geautomatiseerde, realtime metingen die uit systemen worden verzameld om prestaties en gezondheid te monitoren) dramatisch toegenomen… en velen denken dat het komende decennium nog grotere schaalgrootte zal brengen.
Op opname gebaseerde prijsmodellen
Volgens Eric Tschetter, hoofdarchitect bij Imply, moeten we meer over dit onderwerp praten. Imply staat bekend om zijn realtime analyseplatforms, aangedreven door Apache Druid, een krachtige realtime analysedatabase die is ontworpen voor snelle data query’s binnen een fractie van een seconde. Tschetter herinnert ons aan recente discussies in de observability-sector, waaronder het debat usage-based prijsmodellen. Maar dit benadrukt eigenlijk alleen maar hoe moeilijk het voor organisaties is geworden om de kosten van moderne telemetrie te beheersen.
“De huidige telemetrievolumes zetten de traditionele economische aspecten van observability al onder druk. Volgens het rapport ‘Breaking Point for Observability Leaders’ van Imply filtert of archiveert bijna 80% van de teams nu telemetriedata om de kosten te beheersen. De gebruikelijke oplossing is het prijsmodel voor dataverzameling aan te passen, maar dat lost alleen het directe probleem op. Veel leveranciers richten zich op het aanpassen van op data-ingestie gebaseerde prijsmodellen om deze uitdaging aan te pakken. Maar prijswijzigingen alleen lossen het langetermijnprobleem niet op als de onderliggende architectuur niet economisch kan meegroeien met de toename van telemetrie,” legt Tschetter uit.
Maar hier liggen uitdagingen. Naarmate de telemetrievolumes blijven toenemen, beginnen veel strak gekoppelde observability-architecturen onder druk te staan.
Uitdagingen van monolithische observability-architecturen
Dit is hoe Imply de uitdaging voor de toekomst ziet. Veel traditionele observability-stacks koppelen verzameling, opslag, verwerking en visualisatie nauw aan elkaar in één enkel systeem. Dit model werkte goed toen de datavolumes nog kleiner waren, maar moderne gedistribueerde systemen genereren veel meer data dan waarvoor deze architecturen zijn ontworpen.
Naarmate de telemetrievolumes groeien, zeggen Tschetter en zijn team dat organisaties vaak reageren door de data die ze bewaren te snoeien of oudere telemetrie naar goedkopere opslag te verplaatsen. Deze benaderingen helpen de kosten te beheersen, maar ze kunnen het moeilijker maken om toegang te krijgen tot de volledige dataset wanneer incidenten een diepere analyse vereisen. Deze afwegingen weerspiegelen een diepere architecturale beperking. Wanneer opslag, verwerking en analyse nauw met elkaar zijn verweven, vereist het opschalen van één laag vaak het opschalen van alle lagen.
Lessen uit de ontkoppelingsontwikkeling van BI
“Observability lijkt vandaag de dag op business intelligence van 30 jaar geleden. Vroege BI-systemen van leveranciers als SAP BusinessObjects en IBM Cognos bundelden datapijplijnen, opslag, rekenkracht en dashboards in eigen stacks. Naarmate de datavolumes en use cases groeiden, werden deze architecturen steeds beperkender,” aldus Tschetter. “In de loop van de tijd schakelde de sector over op een meer modulair model waarin opslag, rekenkracht en visualisatie onafhankelijk van elkaar functioneren. Hierdoor konden teams systemen eenvoudig opschalen zonder data te verplaatsen of workflows te herschrijven.”
Zou het kunnen dat observability nu een vergelijkbare architecturale evolutie doormaakt? Het lijkt erop dat AI deze verschuiving versnelt, d.w.z. dat elk AI-gedreven systeem een producent en consument van telemetrie wordt. Deze workloads verhogen de telemetrievolumes en vereisen tegelijkertijd snelle querytoegang en langdurige opslag.
Bestaande observability-architecturen hebben vaak moeite om op een economische manier aan deze eisen te voldoen. Naarmate de acceptatie van AI toeneemt, zal de druk op traditionele systemen blijven groeien.
Op naar het observability-warehouse
Tschetter stelt dat de meeste observability-stacks een speciale datalaag missen die is ontworpen om mee te groeien met de toename van telemetrie en aansluit bij de bestaande workflows van gebruikers. In plaats daarvan wordt telemetrie vaak geladen in één enkel systeem dat één workflow ondersteunt, maar andere niet, waardoor uiteindelijk weer een andere set tools nodig is om de data naar andere systemen te verplaatsen ter ondersteuning van andere workflows.
“Een observability warehouse introduceert een speciaal gebouwde datalaag die is geoptimaliseerd voor logs, metrics en traces. Door opslag te scheiden van rekenkracht kunnen organisaties veel grotere volumes aan telemetrie bewaren, terwijl de querycapaciteit onafhankelijk kan worden geschaald naarmate de datavolumes groeien. Deze aanpak zorgt ervoor dat observability-data toegankelijk blijft voor alle tools en workflows, zonder dat duplicatie of kostbare rehydratie vanuit cold storage nodig is”, concludeerde Tschetter.
Het bedrijf merkt op dat Imply Lumi een observability warehouse introduceert dat is ontworpen om telemetrie met hoge volumes te ondersteunen met behoud van snelle queryprestaties. Door een schaalbare databasis te bieden onder bestaande observability-tools, stelt het organisaties in staat om meer telemetrie te bewaren en hun observability-architectuur te ontwikkelen naarmate de datavolumes blijven groeien.
Lees ook: OpenTelemetry accepteert Kotlin SDK voor mobiele observability