De meeste teams zeggen dat ze "productie monitoren" en gaan ervan uit dat ze daarmee weten wat er stuk is als er iets breekt. Op kleine schaal klopt die aanname meestal. Verspreid over tientallen services, kortlevende infrastructuur en externe afhankelijkheden houdt dat stilletjes op te kloppen - en juist in het gat tussen monitoring en observability lopen incidenttijdlijnen uit de hand. Voor directeuren die gereguleerde platforms met hoge volumes in de Benelux draaien, is dit geen woordenspel. Het bepaalt of je on-call engineer om 02:00 een vraag kan beantwoorden die niemand had voorzien, of vastzit voor een dashboard dat alleen de storingen kent die iemand vooraf bedacht. Hier is het onderscheid dat echt telt, wat er in 2026 veranderde, en waar het geld heen gaat.
Observability versus monitoring: wat is het echte verschil?
Monitoring is de praktijk van het verzamelen van vooraf gedefinieerde signalen en alarmeren wanneer ze drempels overschrijden die je van tevoren instelt. Het vertelt je dat er iets mis is, afgemeten aan een lijst storingsvormen die iemand al had bedacht: CPU boven 90%, foutpercentage boven 1%, oplopende wachtrijdiepte. Observability is het vermogen om willekeurige, nieuwe vragen te stellen aan de outputs van je systeem, zonder dat je daarvoor nieuwe code moet uitrollen. De primer van OpenTelemetry verwoordt het helder: "Observability lets you understand a system from the outside by letting you ask questions about that system without knowing its inner workings" (OpenTelemetry docs).
De praktische grens ligt in het type storing dat elk aanpakt. Monitoring beantwoordt bekende onbekenden - de problemen die je voorzag en waarvoor je instrumenteerde. Observability richt zich op onbekende onbekenden - de storing die je nooit eerder zag, in een codepad waar geen dashboard omheen is gebouwd. Monitoring vertelt je dat het foutpercentage bij het afrekenen piekte. Observability laat je die piek opdelen per klantsegment, regio, buildversie en een feature flag die je nooit vooraf had geaggregeerd, en springt vervolgens direct naar de falende request. Monitoring is een output; observability is een eigenschap van het systeem. Je koopt het niet, je instrumenteert ervoor.
Wat zijn de drie pijlers van observability - en is drie nog het juiste getal?
Het canonieke model kent drie signalen. In de definities van OpenTelemetry: een log is een bericht met tijdstempel dat door een service wordt uitgestuurd; een metric is een aggregatie over tijd van numerieke data over je infrastructuur of applicatie; en een trace legt het pad vast van een enkele request terwijl die zich door meerdere services voortbeweegt, opgebouwd uit losse werkeenheden die spans heten (OpenTelemetry docs). Metrics vertellen je dat er iets veranderde, logs vertellen je wat er op een punt gebeurde, traces vertellen je waar in een gedistribueerde aanroep de tijd of de fout daadwerkelijk heen ging.
In theorie draait elk serieus team alle drie. In de praktijk draaien de meeste er twee. Grafana Labs' Observability Survey 2025 onder 1.255 respondenten vond metrics in gebruik bij 95% van de organisaties en logs bij 87%, maar distributed tracing bij slechts 57% en continuous profiling bij 16% (Grafana Labs, 2025). Dat is een probleem, want tracing is de pijler die de vraag "welke downstream-aanroep vertraagde de request" beantwoordt - de vraag waar microservice-incidenten om draaien. De "drie pijlers"-framing wordt zelf inmiddels betwist: profiling komt op als vierde signaal, en critici betogen dat het model teams richting drie losse silotools duwt in plaats van gecorreleerde data. Het ging nooit om het aantal. Het gaat om correlatie - een metric die je laat doorklikken naar precies de trace en de logs van dezelfde request verslaat drie losse opslagplaatsen die je met de hand moet koppelen.
Is observability gewoon een nieuwe naam voor monitoring?
Het is een terechte vraag van de scepticus, want leveranciers hebben de twee maar al te graag vervaagd. Het eerlijke antwoord is nee. Het woord komt uit de regeltechniek: een systeem is observable als je de interne toestand puur uit de externe outputs kunt afleiden. Dat is een veel hogere lat dan "we hebben dashboards." Een bruikbare praktijktest voor elk platform: kan een nieuwe engineer een vraag beantwoorden die niemand voorzag, met telemetrie die al bestaat, zonder nieuwe instrumentatie uit te rollen? Zo ja, dan heb je observability. Als elke nieuwe vraag een nieuwe metric en een nieuwe release vereist, dan heb je monitoring met goede marketing.
De reden dat dit in 2026 zwaarder weegt dan vijf jaar geleden is structureel. Architecturen zijn opgesplitst in veel kleine services op kortlevende infrastructuur, en AI-ondersteunde ontwikkeling verhoogt het volume aan wijzigingen - waardoor meer van je storingen werkelijk nieuw zijn. Vooraf gedefinieerde dashboards dekken een krimpend deel van de storingsruimte, dus het vermogen om ruwe telemetrie achteraf te bevragen is geen luxe meer, maar het verschil tussen een incident van 20 minuten en een van drie uur.
Waarom OpenTelemetry zojuist de standaard werd
De grootste verschuiving dit jaar is bestuur, geen techniek. OpenTelemetry studeerde op 11 mei 2026 af bij de Cloud Native Computing Foundation, waarbij de foundation het de "de facto"-standaard voor open-source observability noemde en het op een na snelst bewegende CNCF-project na Kubernetes, met meer dan 12.000 bijdragers uit ruim 2.800 bedrijven (CNCF, 2026). Afstuderen is het signaal van CNCF voor productierijpheid, en voor een dwarsdoorsnijdende instrumentatiestandaard weegt dat signaal zwaar bij risico- en inkoopteams.
De reden dat directeuren hierom moeten geven, is lock-in. OpenTelemetry ontkoppelt de instrumentatie van de backend: je instrumenteert je code eenmaal tegen een leveranciersneutrale API, en kiest - of wisselt - vervolgens je observability-backend zonder opnieuw te instrumenteren. Dat verwijdert de grootste bron van pijn in observability-uitgaven, waar van leverancier wisselen vroeger betekende dat je elke service moest herbedraden. De adoptie weerspiegelt dit al. Enterprise Management Associates vond 48% van de organisaties die OpenTelemetry gebruiken, 25% die het van plan zijn, en 25% die het nog evalueren, terwijl meer dan 61% het een zeer belangrijke of kritische enabler van observability noemt (EMA / Elastic). De wrijving is ook eerlijk: datzelfde onderzoek noemt implementatiecomplexiteit, kosten en een tekort aan vaardige mensen als de voornaamste barrieres, dus behandel een OTel-uitrol als een echt engineeringprogramma, niet als een configuratiewijziging.
Waarom observability duur wordt - en hoe je de rekening eerlijk houdt
Observability heeft een kostenprobleem dat teams overvalt. In Grafana's onderzoek van 2025 noemde 74% kosten hun belangrijkste prioriteit bij het kiezen van tooling, stonden "kosten te hoog" (37%) en "onvoorspelbare kosten" (29%) bij de grootste zorgen, en beslaat observability nu gemiddeld 17% van de totale infrastructuuruitgaven, met een mediaan van 10% (Grafana Labs, 2025). Telemetrievolume groeit super-lineair met het verkeer, en het grootste deel van de rekening zijn logs - het luidruchtigste, meest redundante signaal - waar je betaalt om data in te nemen, op te slaan en te indexeren die je grotendeels nooit zult bevragen.
De oplossing is telemetrie te behandelen als een gebudgetteerd product in plaats van als uitlaatgas. Bemonster traces verstandig, stel bewaartermijnen per signaal in op basis van hun werkelijke waarde in plaats van een blanco standaard, en duw aggregatie en filtering naar de rand - de OpenTelemetry Collector bestaat juist zodat je kunt droppen of aggregeren voordat je voor opslag betaalt. Koppel de data die je bewaart aan vragen die je daadwerkelijk stelt bij incidenten en audits. De teams die solvabel blijven meten kosten per service en per signaal, niet als een ondoorzichtige regel op de platformrekening.
Wat dit betekent voor een gereguleerd Benelux-team
De rode draad is de vraag die elke capaciteit je laat beantwoorden. Monitoring voldoet aan "zijn we up?" Observability voldoet aan "waarom faalde deze specifieke transactie, voor deze klant, op deze build" - precies wat incidentevaluaties, SLA's en auditors eisen. De praktische agenda voor 2026 is kort: standaardiseer op OpenTelemetry om backend-lock-in te doden, ga voorbij de comfortabele basislijn van metrics en logs richting distributed tracing, en beheers de kosten vanaf de eerste dag in plaats van na de eerste verrassingsfactuur. Observability zonder kostenmodel is gewoon een hogere rekening. Monitoring zonder observability is een snellere manier om blind te blijven voor de storingen die je nooit voorzag.
Bronnen
- Cloud Native Computing Foundation Announces OpenTelemetry's Graduation - CNCF, 2026
- Observability Survey Report 2025 - Grafana Labs, 2025 (1.255 respondenten)
- Taking observability to the next level: OpenTelemetry's emerging role in IT performance and reliability - Enterprise Management Associates / Elastic
- Observability Primer - OpenTelemetry documentation
