Wat is observability? Uitleg voor wie incidenten oplost

Wat is observability? Het is het vermogen om te verklaren waarom je systeem zich misdraagt, uitsluitend op basis van de telemetrie die het al uitstuurt, ook bij storingen die niemand had voorzien. Monitoring vertelt je dat de latency bij het afrekenen boven de 800 ms uitkwam. Observability laat je vragen welke klant, welke afhankelijkheid of welke deploy de oorzaak was, zonder om 03:00 nieuwe code te moeten uitrollen om dat uit te zoeken.

Het scenario maakt het verschil concreet. De alert gaat af: de p99 van de payments-API is gestegen van 180 ms naar 1,4 s. Het dashboard is groen op CPU, geheugen en foutpercentage. Elk vooraf gebouwd paneel zegt dat de service in orde is, en elke klant zegt dat dat niet klopt. Wat je in de volgende tien minuten doet, is het onderwerp van dit artikel.

Waarom de definitie belangrijk is voor je tooling

Het begrip komt uit de regeltheorie: een systeem is observeerbaar als je de interne toestand kunt afleiden uit de externe uitvoer. Software heeft die term overgenomen, en leveranciers hebben hem zo ver opgerekt dat hij nu vooral "een dashboardproduct" betekent. Negeer die rek.

De werkdefinitie voor een engineeringteam is smaller en bruikbaarder. Een systeem is observeerbaar wanneer je in productie een nieuwe vraag over zijn gedrag kunt beantwoorden, zonder nieuwe instrumentatie uit te rollen. Het woord dat ertoe doet is "nieuwe". Een drempelalert beantwoordt een vraag die iemand vorig kwartaal heeft opgeschreven. Een observeerbaar systeem beantwoordt de vraag die je nu stelt.

Dit is geen zuiverheidstest. Niemand heeft een perfect observeerbaar systeem, en het doel is geen score. Het doel is een kortere weg van "er is iets mis" naar "deze wijziging heeft het veroorzaakt". Mean time to detect en mean time to understand zijn verschillende getallen, en de meeste teams volgen alleen het eerste.

Hoe verschilt observability van monitoring?

Monitoring is een reeks controles op faalwijzen die je al kent: CPU boven 90% gedurende vijf minuten, een foutpercentage boven 1%, een wachtrij boven 10.000 items. Het is goedkoop, betrouwbaar en je hebt het nodig. Observability vervangt het niet.

Het verschil zie je bij een nieuwe storing. Monitoring is opgebouwd uit je vorige incidenten. Observability is bedoeld voor het volgende incident, dat je per definitie nog niet hebt gezien.

Een bruikbare test: kijk naar de laatste drie incidenten en vraag je af hoe de oorzaak is gevonden.

• Als iemand een vooraf gebouwd dashboard las en het antwoord erop stond, deed monitoring zijn werk.

• Als iemand logs over zes hosts doorzocht, een hypothese bedacht, een logregel toevoegde en opnieuw uitrolde om die te bevestigen, was dat een gat in je observability.

• Als het echte antwoord uit de screenshot van een klant kwam, heb je beide problemen.

Of monitoring en observability elkaars concurrenten zijn, is een discussie die je kunt overslaan. Het zijn lagen. Monitoring is de rookmelder. Observability is het vermogen om achteraf door het gebouw te lopen en uit te zoeken welke kabel de brand is begonnen.

Wat zijn de drie signalen, en waar faalt elk ervan?

Logs, metrics en traces vormen het standaardtrio. Elk beantwoordt een andere vraag, en elk heeft een faalwijze die leveranciersgidsen meestal overslaan.

Metrics zijn numerieke metingen die over de tijd worden samengevat: aanvraagsnelheid, foutpercentage, latency-percentielen, verzadiging. Ze zijn goedkoop om op te slaan en snel te bevragen, daarom draait alerting erop. De faalwijze is aggregatie. Een p99 van 1,4 s vertelt je dat er iets traag is. Het kan niet vertellen dat elke trage aanvraag bij één klant op één shard hoort.

Logs zijn tijdgestempelde registraties van afzonderlijke gebeurtenissen. Ze bevatten de meeste detail en de minste structuur, tenzij je die structuur afdwingt. De faalwijze is volume en kosten. Ongestructureerde logs kun je alleen doorzoeken als je al weet welke tekst je zoekt, waardoor ze een monitoringtool worden die zich als debugtool voordoet.

Traces volgen één aanvraag over servicegrenzen heen, met een span voor elke hop en de timing ervan. Ze zijn het enige signaal dat de vorm van een aanvraag toont: deze call wachtte 900 ms op een afhankelijkheid die drie keer opnieuw probeerde. De faalwijze is dekking. Eén service die de trace-context laat vallen, breekt de keten, en een trace met een gat is erger dan nutteloos, omdat hij gezaghebbend lijkt.

Drie signalen hebben is niet hetzelfde als observeerbaar zijn. Het gaat om correlatie. Je moet van een piek in een metric naar de traces die eraan bijdroegen, en van een trace naar de logs van precies die aanvraag. Staan de drie in aparte tools zonder gedeelde identifier, dan heb je drie monitoringsystemen en een engineer die als join fungeert.

Waarom cardinaliteit bepaalt of je iets kunt debuggen

Cardinaliteit is het aantal verschillende waarden dat een veld kan aannemen. status_code heeft er misschien twintig. customer_id heeft er honderdduizenden. request_id heeft er één per aanvraag.

De velden die je tijdens een incident het hardst nodig hebt, zijn de velden met hoge cardinaliteit. "Welke klant is getroffen?" is een vraag over customer_id. "Welke build bedient de trage aanvragen?" is een vraag over deploy_version. Als je opslagmodel hoge cardinaliteit bestraft, door per unieke reeks te laten betalen of door de velden stilzwijgend weg te laten, kun je de vraag die het incident oplost niet stellen.

Dit is de echte architectuurlijn tussen een opstelling met alleen metrics en een observeerbare opstelling. Vooraf geaggregeerde metrics gooien de dimensies weg die je later nog wilt. Brede, gestructureerde events bewaren ze, en je snijdt achteraf.

Zo ziet een bruikbaar event aan de rand van een service eruit. Één gestructureerd record per aanvraag, met genoeg context om op alles te kunnen filteren waar je later om geeft:

logger.info("request.completed", {
  trace_id: span.traceId,
  route: "/v1/payments",
  customer_id: ctx.customerId,
  deploy_version: process.env.BUILD_SHA,
  flag_variant: flags.get("new-ledger-path"),
  db_ms: timings.db,
  upstream_ms: timings.upstream,
  status: res.statusCode,
  duration_ms: elapsed,
});

Let op de variant van de featureflag erin. De helft van de incidenten in de gepubliceerde post-mortems die wij bekijken, begint met een wijziging, en een flag-evaluatie is een wijziging. Staat de variant niet op het event, dan kun je niet nagaan of de trage aanvragen juist die zijn die over het nieuwe pad lopen.

Hoe ziet een incident eruit met en zonder observability?

Neem het betalingsscenario opnieuw. Dezelfde alert, dezelfde p99 van 1,4 s.

Zonder observability ziet de lus er zo uit: je opent het dashboard van de service, vindt niets, opent het dashboard van de database, vindt ook niets, en vraagt in het incidentkanaal of er iets is uitgerold. Iemand herinnert zich een configuratiewijziging. Iemand anders is het er niet mee eens. Veertig minuten later draai je de laatste deploy terug om te zien of dat helpt. Dat helpt niet, want de oorzaak was een featureflag-uitrol naar een deel van de tenants.

Met observability ziet de lus er anders uit. Je groepeert de trage aanvragen op flag_variant en ziet dat 100% ervan op new-ledger-path staat. Je groepeert op customer_id en ziet dat drie grote tenants het grootste deel van het volume vormen. Je opent één trace en ziet de ledger-call uitwaaieren in 40 sequentiële queries. Totale tijd: enkele minuten. Je zet de flag uit, niet de deploy.

Let op wat die tweede lus niet nodig had. Hij had geen voorbereid dashboard nodig. Niemand moest vooraf "flag-variant" voorspellen als interessante dimensie. Hij had data nodig die er was, breed en bevraagbaar.

Dat is in één alinea het Honeycomb-argument, en het houdt stand. Wat het niet zegt, is dat dit gratis is.

Wat kost het, en wie kan de dure versie overslaan?

Telemetrie is eerst een probleem van datavolume en pas daarna een probleem van tooling. Volgens de observability-enquête van Grafana Labs onder 1.255 professionals uit 2025 draait de gemiddelde organisatie acht verschillende observability-tools, en kosten is het criterium dat het vaakst wordt genoemd bij de keuze van nieuwe tools. Die twee feiten hangen samen. Teams stapelen tools op omdat elk een stuk van het probleem oplost, en betalen daarna voor overlappende ingestie in al die tools.

Praktische regels die bij de meeste teamgroottes standhouden:

• Instrumenteer met OpenTelemetry, niet met een propriëtaire agent. De collector geeft je één plek om te samplen, filteren en routeren. Overstappen naar een andere backend wordt dan een configuratiewijziging en geen herinstrumentatieproject.

• Sample traces bewust. Bewaar elke fout en elke trage aanvraag, en sample de gezonde, snelle. Head-based sampling op een vaste 1% gooit precies de trace weg die je nodig hebt.

• Breng structuur aan in logs op het moment van schrijven. Vrije tekst parsen op het moment van bevragen is de dure manier om aan velden te komen.

• Stel per signaal een retentiebeleid vast. Metrics een jaar, brede events twee weken, debuglogs drie dagen. Niemand heeft ooit de debuglogs van vorig kwartaal nodig gehad.

Sla de volledige platformaanpak over als je een handvol services draait en één on-callrooster hebt. Een klein team haalt het grootste deel van het voordeel uit gestructureerde logs, RED-metrics en traces op de twee of drie hete paden. Het dure, alles-in-één-contract loont pas als je zoveel services hebt dat niemand de hele topologie nog in het hoofd heeft, wat in onze ervaring ergens na de 30 à 40 services is.

Welke tools zijn het bekijken waard?

De keuze hangt af van hoeveel je zelf wilt beheren, hoe je cardinaliteit eruitziet en wat je rekening aankan. Een korte, eigenzinnige rondleiding:

Datadog is de breedste commerciële optie: metrics, logs, traces en profiling onder één dak, met sterke correlatie tussen die signalen. De prijs van die integratie is een rekening die meegroeit met hosts, custom metrics en het volume aan logs. Het loont als je één leverancier wilt en het budget hebt om die rekening te dragen. Controleer de regel voor custom metrics voordat je tekent.

Grafana is de standaardkeuze als je open componenten wilt die je zelf kunt hosten of als beheerde stack kunt afnemen. Het werkt goed met Prometheus-achtige metrics en OpenTelemetry-pijplijnen. De afweging is operationeel: je beheert meer van de samenstelling zelf, en de wildgroei uit de enquête geldt ook voor jou.

SigNoz is een open source, OpenTelemetry-native optie die logs, metrics en traces in één datastore zet. Dat is belangrijk voor het correlatiepunt van eerder, want een gedeelde store maakt de sprong van metric naar trace naar log een query in plaats van een tabwissel. Het is redelijk voor teams die zelf willen hosten zonder vier projecten aan elkaar te knopen.

Better Stack combineert uptimemonitoring, incidentalerting en logbeheer tegen een prijs die is afgestemd op kleinere teams. Het is een verstandige eerste stap als je overstapt van "we horen het van klanten" naar iets gestructureerds, en minder geschikt voor een grote service mesh met zware eisen aan traces.

Hoe begin je zonder alles in één keer aan te pakken?

Begin niet met een toolevaluatie. Begin met de laatste drie incidenten en één eerlijke vraag: wat hadden we graag willen kunnen vragen?

Een volgorde die werkt voor een team van 50 tot 200 engineers:

1. Kies één kritiek aanvraagpad en instrumenteer het van begin tot eind met OpenTelemetry. Afrekenen, inloggen, wat je ook om 03:00 wakker maakt.

2. Stuur één breed gestructureerd event per aanvraag aan de rand van de service, met klant, versie, flagvarianten en downstream-timings.

3. Definieer één SLO op dat pad en alarmeer op burn rate, niet op ruwe drempels. Burn-rate-alerts roepen je op bij impact op gebruikers, en de telemetrie uit stap twee vertelt je waarom.

4. Organiseer een game day. Injecteer een storing waar je geen alert op hebt en kijk hoe lang het duurt voordat iemand die de code niet schreef haar vindt. Dat getal is je uitgangspunt.

5. Breid uit, één pad tegelijk, pas nadat het eerste pad zich in een echt incident heeft terugverdiend.

Observability wordt als platform aangeschaft en als gewoonte overgenomen. De gewoonte is de vraag "wat zou ik moeten weten om dit te verklaren?" stellen bij de code review, vóór het incident in plaats van tijdens het incident.

Kijk naar je laatste incidentreview. Zoek de zin die zegt "we hebben daarna logging toegevoegd om het te bevestigen". Elk van die zinnen is een vraag die je systeem in productie niet kon beantwoorden. Hoeveel ervan heb je genoteerd, en welke zouden vandaag nog steeds onbeantwoordbaar zijn?