Splunk Observability: welke modules zitten erin en wat doen ze eigenlijk
“We hebben Splunk Observability” is een zin die verrassend weinig zegt. Het is namelijk geen enkel product maar een verzameling modules, en welke daarvan je gebruikt bepaalt volledig wat je ziet. De ene organisatie bedoelt ermee dat er infrastructuurmetrics binnenkomen. De andere heeft distributed tracing draaien tot in de laatste microservice. Beide zeggen hetzelfde.
Dat maakt het lastig te beoordelen wat je mist. Hieronder staan de modules van Splunk Observability op een rij: wat elk onderdeel doet, voor wie het bedoeld is, en belangrijker, wanneer je het níet nodig hebt.
Eerst de basis: metrics, traces en logs
De ruggengraat van Splunk Observability bestaat uit twee modules die zelden ter discussie staan. Infrastructure Monitoring verzamelt metrics uit servers, containers, Kubernetes en cloudservices. APM, application performance monitoring, volgt requests door je applicatielandschap heen met distributed tracing, zodat je bij een trage transactie kunt zien in welke service de tijd verdwijnt.
Daaronder ligt OpenTelemetry, de open standaard voor het verzamelen en versturen van telemetrie. Splunk gebruikt die als instrumentatielaag, wat praktisch betekent dat je data-instrumentatie niet exclusief aan Splunk vastzit. Dat is een relevante overweging bij een platformkeuze die je jaren meedraagt.
De modules hieronder bouwen hierop voort. Zonder deze basis leveren ze weinig.
Real User Monitoring: wat je gebruikers werkelijk ervaren
Splunk real user monitoring meet de prestaties van je applicatie zoals ze zich voordoen in de browser of app van je echte gebruikers. Laadtijd van de pagina, de tijd tot iets zichtbaar wordt, JavaScript-fouten, trage API-aanroepen, gemeten op het apparaat van de gebruiker, niet op je server.
Dat verschil is de hele reden dat RUM bestaat. Je backend kan in twintig milliseconden antwoorden terwijl een gebruiker op een matige mobiele verbinding vier seconden naar een leeg scherm kijkt. Serverzijdige monitoring ziet dat niet; RUM wel. En omdat het aan tracing gekoppeld is, kun je vanuit een trage paginaweergave doorklikken naar de backend-call die het veroorzaakte.
Waar het minder oplevert: bij interne applicaties met een kleine, homogene gebruikersgroep op hetzelfde netwerk. Dan meet je vooral je eigen kantoornetwerk.
Synthetic Monitoring: testen zonder op gebruikers te wachten
Splunk synthetic monitoring draait het om. In plaats van te meten wat gebruikers ervaren, laat je op vaste intervallen geautomatiseerde tests lopen vanaf verschillende locaties: is de site bereikbaar, werkt de inlogflow nog, geeft de API het juiste antwoord binnen de afgesproken tijd.
Het verschil met RUM is niet academisch. RUM vertelt je dat er iets misging nádat het misging, en alleen op de paden die gebruikers namen. Synthetic tests draaien ook om drie uur ’s nachts, ook op de betaalpagina waar vandaag weinig verkeer op zat, en ook vanaf een land waar je normaal weinig bezoekers vandaan krijgt. Je vangt er storingen mee vóór je klanten bellen, en je meet er beschikbaarheid mee op een manier die je in een SLA-rapportage kunt gebruiken.
In de praktijk zet je ze samen in: synthetic voor de kritieke paden en de baseline, RUM voor de werkelijkheid daarbuiten. Beide alleen is een halve waarheid.
Incident Intelligence: van melding naar iemand die iets doet
Detectie is één ding; zorgen dat de juiste persoon om drie uur ’s nachts wakker wordt, is een ander vak. Splunk incident intelligence richt zich op dat tweede: alerts groeperen tot één incident, on-call-roosters en escalatiepaden beheren, en de context meesturen die nodig is om te beginnen.
De winst zit in het samenvoegen. Eén uitgevallen database produceert in een gemiddelde omgeving tientallen losse meldingen uit verschillende modules. Als die allemaal apart bij een engineer landen, kost het onnodig tijd om te zien dat het één probleem is. Voor teams die met on-call werken is dat het verschil tussen een melding en een nacht.
Zonder een ingerichte on-call-organisatie is deze module overigens weinig waard. Het gereedschap lost geen ontbrekend proces op.
De AI-laag: anomaliedetectie zonder vaste drempels
Splunk ai observability is de nieuwste laag boven op het geheel, en tegelijk de laag waar de meeste verwarring over bestaat. In de kern gaat het om twee dingen die los van elkaar staan.
Het eerste is anomaliedetectie: in plaats van zelf drempelwaarden in te stellen, leert het systeem het normale patroon van een metric en slaat aan bij afwijkingen daarvan. Dat is vooral waardevol bij metrics met een duidelijk dag- of weekritme, waar een vaste drempel altijd verkeerd staat, te hoog tijdens de nachtelijke batch, te laag tijdens de ochtendpiek.
Het tweede is ondersteuning bij onderzoek: een assistent die helpt bepalen wat er is veranderd en waar je zou moeten kijken. Nuttig als versneller, geen vervanging van iemand die de omgeving kent.
Bedrijfsprocessen volgen, en wat er met Splunk Business Flow gebeurde
Technische monitoring beantwoordt de vraag of systemen draaien. Procesobservability beantwoordt een andere vraag: voltooit het proces dat over die systemen heen loopt ook daadwerkelijk? Hoeveel bestellingen zijn vandaag begonnen maar niet afgerond, waar vallen aanvragen uit, welke stap kost de meeste tijd. Technisch kan alles groen staan terwijl een kwart van de klanten halverwege afhaakt.
Splunk had daar ooit een apart product voor: Splunk Business Flow. Zoek je daar vandaag op, dan is het korte antwoord dat het niet meer bestaat, je kunt deze functionaliteit niet meer als losse module aanschaffen. Kom je een oudere presentatie of een verouderd vergelijkingsartikel tegen waarin het nog staat, dan weet je nu waarom je het in het portfolio niet terugvindt.
Dat betekent niet dat de vraag verdwenen is, alleen de kant-en-klare doos. Wat ervoor in de plaats komt, bouw je op de tracing die je voor APM toch al hebt draaien. Een trace volgt een request door je services heen; geef je die trace onderweg een bedrijfskenmerk mee, een ordernummer, een aanvraagtype, een klantsegment, dan kun je achteraf groeperen op iets waar de business op stuurt in plaats van op een servicenaam. Vanaf dat moment is “waar vallen aanvragen uit” een vraag die je op je bestaande data kunt beantwoorden.
De prijs staat in die zin: *geef je die trace een bedrijfskenmerk mee*. Dat is instrumentatiewerk in de applicatie zelf, en dus een gesprek met je ontwikkelteam en niet met je monitoringleverancier. Stuurt niemand dat attribuut mee, dan kun je het proces niet volgen, hoeveel modules je ook aanzet. Precies daar strandden de meeste procesobservability-trajecten ook toen er nog wel een product met die naam bestond.
De visualisatielaag
Dashboards zijn het onderdeel dat iedereen ziet en waar de meeste tijd in verdwijnt. Binnen Observability Cloud werk je met dashboards die op de ingekomen metrics en traces zijn gebouwd; aan de kant van Splunk Enterprise en Splunk Cloud Platform bouw je visualisaties met Dashboard Studio.
De valkuil is bekend: dashboards worden gebouwd voor een demo en daarna nooit meer aangepast, terwijl de omgeving wel verandert. Een dashboard waar niemand meer naar kijkt, is duurder dan geen dashboard, het wekt de indruk dat iets in de gaten wordt gehouden.
Wat er moet kloppen voordat modules waarde leveren
Modules aanzetten is niet hetzelfde als observability hebben. Drie dingen bepalen of het werkt.
Instrumentatie gaat vóór licenties. APM en RUM leveren pas iets op als je applicaties daadwerkelijk zijn geïnstrumenteerd. Bij eigen applicaties is dat ontwikkelwerk dat in een planning hoort, niet een vinkje in een beheerscherm.
Meer modules betekent meer meldingen. Elke module die je aanzet, produceert alerts. Zonder afspraken over wie waarop reageert, groeit het aantal meldingen sneller dan het aantal opgeloste problemen.
Kies op basis van een vraag die je nu niet kunt beantwoorden. De meest zinvolle volgorde is niet “welke module hebben we nog niet”, maar “welk incident kostte ons vorige maand het meeste tijd, en welke module had dat verkort”.
Wil je weten welke onderdelen in jouw omgeving daadwerkelijk iets toevoegen? Op onze Splunk-pagina lees je hoe we naar observability kijken, en in de case study van Vialis zie je hoe dat er in de praktijk uitziet.
