De 30-seconden versie#

Monitoring: Werkt mijn systeem? (Ja/Nee)
Observability: Waarom ging mijn systeem stuk? (Root cause analysis)
Logging: Wat is er gebeurd? (Eventregistratie)

Monitoring beantwoordt JA/NEE-vragen. Observability stelt je in staat elke vraag over je systeem te stellen. Logging is dataverzameling; monitoring en observability zijn analyse.

De meeste teams gebruiken de termen door elkaar. Dat zorgt voor verwarring, opgeblazen budgetten en — erger — blinde vlekken tijdens noodgevallen.

Waarom dit ertoe doet (de echte kosten van verwarring)#

Je engineering-team heeft net nieuwe code gedeployed. 30 minuten later wordt de paymentverwerking traag. Drie dingen gebeuren:

Zonder Observability (de oude manier):

Alert gaat af: "Payment API response time >3 seconden"
Oncall-engineer opent dashboard: ziet de response-time-grafiek. Meer niet.
Engineer begint te gokken: "Is het de database? Het netwerk? Een recente deploy?"
Engineer checkt logs handmatig: 500.000 logregels in 30 minuten. Waar te beginnen?
45 minuten debuggen later: nieuwe code voegde een trage SQL-query toe
Duur incident: 1 uur. Verlies aan omzet: ~$7.000

Met Observability (de moderne manier):

Alert gaat af: "Payment API response time >3 seconden"
Oncall-engineer opent observability-dashboard
Dashboard suggereert automatisch: "Nieuwe code voegde een N+1 query toe op tabel payment_verification"
Engineer springt direct naar de query en optimaliseert deze
Duur incident: 5 minuten. Verlies aan omzet: ~$600

Het verschil: 55 minuten bespaard + $6.400 omzet bespaard met één incident.

Voor een bedrijf met 2-3 incidenten per maand is de ROI van observability eenvoudig $100K+/jaar.

Wat is monitoring? (Het oude fundament)#

Monitoring beantwoordt: Werkt mijn systeem op dit moment?

Monitoring = booleaanse (Ja/Nee) vragen#

Reageert de server op verzoeken? (Ja/Nee)
Is de response time <2 seconden? (Ja/Nee)
Is database-CPU <80%? (Ja/Nee)
Is de error rate <1%? (Ja/Nee)
Is deze synthetische test geslaagd? (Ja/Nee)

Hoe monitoring werkt#

Verzamel een metric: Check elke 60 seconden de response time
Vergelijk met drempel: Als response time >2s, vuur alert
Alert bij overschrijding: Stuur de oncall-engineer een melding

Monitoring is binair. Jij definieert regels; het systeem dwingt ze af. Wanneer een regel breekt, krijg je een melding. Dat is monitoring.

De beperking van monitoring#

Monitoring vertelt je dat er iets mis is, maar niet waarom het misgaat.

Voorbeeld:

Alert: "Database-CPU op 95%"
Monitoring toont: een CPU-grafiek die piekt
Maar je weet niet: Waarom is CPU hoog? Welke query? Welke gebruiker? Nieuwe code? Plotse trafficpiek?

Je moet handmatig gaan graven om dat te ontdekken. Hier komt observability om de hoek kijken.

Wat is observability? (De moderne aanpak)#

Observability beantwoordt: Waarom werkt mijn systeem niet?

Observability = oneindig veel vragen#

In plaats van "Is X waar?" te vragen, kun je elke vraag stellen over je systeem:

"Welke query veroorzaakte de CPU-piek?"
"Waarom nam de response time toe na deze deploy?"
"Welke gebruikers zijn getroffen?"
"Wat veranderde er 2 minuten voordat het alert afging?"
"Welke requests duurden langer dan 5 seconden in het laatste uur?"
"Hoe verhoudt de error rate van vandaag zich tot vorige week op dit moment?"

Met observability kun je ELKE vraag over systeemgedrag beantwoorden.

De 3 pijlers van observability#

Pijler 1: Metrics (Wat er gebeurde, in cijfers)

Response time: 1,2s
Error rate: 0,5%
Database queries per seconde: 1.200
Geheugengebruik: 4,2GB
Dit zijn geaggregeerde, samengevatte datapunten

Pijler 2: Logs (Wat er gebeurde, in detail)

"User john@example.com logged in"
"Payment verification query took 1.2s"
"Database connection closed due to timeout"
Gedetailleerde, granulaire events. Veel volume.

Pijler 3: Traces (Hoe een request door het systeem bewoog)

Gebruiker dient betaling in → API-handler → Database query → Payment-gateway-call → E-mailservice
Toont het volledige pad van een request en waar tijd verloren ging
Distributed tracing tussen services

Hoe observability werkt#

Instrumenteer alles: Voeg logging toe aan alle codepaden
Verzamel data: Vang metrics, logs en traces op
Sla data op: Lange-termijn opslag (weken/maanden geschiedenis)
Bevraag vrij: Stel elke vraag over systeemgedrag
Correleer automatisch: "Deze CPU-piek correleert met dit codepad; deze fout correleert met deze gebruikersactie"

Monitoring vs Observability: naast elkaar#

Aspect	Monitoring	Observability
Type vraag	Is X waar?	Waarom gebeurt X?
Datapunten	10-50 metrics	Miljoenen datapunten
Setup-tijd	Snel (1 uur)	Langer (1-2 weken)
Leercurve	Simpel (dashboard)	Steil (querytaal)
MTTR (Mean Time To Repair)	30-60 min	5-10 min
Kosten	$100-500/maand	$1.000-5.000/maand
Geschikt voor	"Is mijn systeem up?"	"Waarom ging mijn systeem stuk?"
Wanneer ontgroeid	>5 services, >10 alerts	Werkt nog op schaal

Het 3-laagse systeem (hoe de meeste teams écht werken)#

Laag 1: Monitoring (de basis — heb je nodig)#

Standaard uptime monitoring voor iedereen:

Beschikbaarheid van de website: Reageert de homepage in <2s?
API-gezondheid: Reageren kritieke endpoints?
Third-party-dependencies: Is Stripe bereikbaar?
Infrastructuurbasis: CPU, geheugen, schijfruimte

Voorbeelden van tools: UptimeRobot, Pingdom, Hyperping, Datadog (basistier)

Kosten: $20-100/maand

Setup-tijd: 1-2 uur

Wanneer nodig: Vanaf dag 1, kleine startup met 1-2 services

Laag 2: Basis-logging (de details — heb je waarschijnlijk nodig)#

Wanneer monitoring zegt dat er iets mis is, waar kijk je dan?

Logs laten zien wat er gebeurde:

Foutmeldingen: "Database connection timeout"
Request-details: User ID, request-pad, response-code
Business events: "User purchased item", "Payment failed"
Systeemevents: "Server started", "Memory pressure detected"

Voorbeelden van tools: Datadog, New Relic, Better Stack, ELK Stack

Kosten: $100-500/maand

Setup-tijd: 2-4 uur (basis), 1-2 weken (uitgebreid)

Wanneer nodig: Wanneer monitoring 5+ keer per dag een alert stuurt en je de oorzaak niet kunt vinden

Laag 3: Volledige observability (het inzicht — heb je nodig op schaal)#

Zodra je logs hebt, wil je ze correleren met metrics en traces.

Observability laat je:

Zien welk codepad het alert veroorzaakte
Begrijpen hoe een request door 10 services bewoog
Gebruikersgedrag → applicatiegedrag → infrastructuurimpact correleren

Voorbeelden van tools: Datadog (full stack), Dynatrace, New Relic, Splunk

Kosten: $1.000-10.000+/maand

Setup-tijd: 2-4 weken (uitgebreid)

Wanneer nodig: >10 microservices, >5 engineers, complex distributed system

Praktijkvoorbeeld: API response-time alert#

Scenario: De response time van je payment-API is gepiekt naar 3 seconden (normaal: 500ms)

Met alleen monitoring#

Alert gaat af: "Payment API response time 3000ms"
Je ziet: een grafiek met een response-time-piek
Je denkt: "Is het de database? Een belastingpiek? Een bug?"
Je checkt: Server-CPU (normaal), geheugen (normaal), connecties (normaal)
Je checkt: Recente deploys (geen in de laatste 2 uur)
Je checkt: Traffic-logs (verkeer is verdubbeld)
Je checkt: Database-logs (veel queries op payment_verification)
EINDELIJK: trage query gevonden in de logs
Verstreken tijd: 45 minuten

Met observability#

Alert gaat af: "Payment API response time 3000ms"
Je ziet: observability-dashboard toont automatisch:
  - Welk codepad traag is: payment_verification
  - Welke query: SELECT * FROM users ... (N+1 query gedetecteerd)
  - Welke gebruiker triggerde het: john@example.com
  - Wanneer het begon: precies bij de deploy van nieuwe code
  - Getroffen requests: 150 van de 2.000
Je ziet: een trace met de exacte stack trace van de trage code
Je fixt: de query optimaliseren
Verstreken tijd: 5 minuten

Het verschil:

Zonder observability: 45 minuten naar root cause
Met observability: 5 minuten naar root cause
Bespaarde omzet: ~$6.500 voor één incident

Logging: het fundament (maar het is geen monitoring of observability)#

Logging is dataverzameling. Monitoring en observability zijn data-analyse.

Wat logging is#

Events naar een centrale plek schrijven:

// In your application
logger.info("User logged in", {
  user_id: "12345",
  timestamp: "2026-02-20T14:23:45Z",
  ip_address: "203.0.113.42"
})

logger.error("Payment verification failed", {
  user_id: "12345",
  amount: 99.99,
  error: "Stripe API timeout",
  duration_ms: 5000
})

Logs worden geschreven. Opgeslagen. Beschikbaar voor zoekopdrachten.

Beperkingen van logging#

Te veel data: Een typische webapplicatie genereert 1.000+ logregels per seconde. Door 1M logregels per uur graven is pijnlijk.

Geen context: Een logregel zegt "Payment failed" maar zegt niet of het deel is van een aanval, een systemisch probleem of een geïsoleerd geval.

Geen correlatie: Eén payment-failure-log zien laat je niet de 500 vergelijkbare gelijktijdige fouten zien.

Logging is fundament voor observability#

Je hebt goede logging nodig om observability op te bouwen. Maar logging alleen is geen observability.

Wanneer wat gebruiken (beslisboom)#

Sta je net aan het begin?
├─ Ja → Gebruik alleen Monitoring
│       (UptimeRobot, Hyperping)
│       Focus: is het systeem up?
│       Kosten: $20-50/maand
│       Setup: 1 uur

Debug je 5+ incidenten per maand?
├─ Ja → Voeg Logging toe
│       (Datadog, Better Stack)
│       Focus: wat is er gebeurd?
│       Kosten: +$100-300/maand
│       Setup: 2-4 uur basis, 1-2 weken uitgebreid

Draai je >5 microservices of >10 engineers?
├─ Ja → Stap over op Observability
│       (Datadog full stack, Dynatrace, Splunk)
│       Focus: waarom gebeurde dit?
│       Kosten: $1.000+/maand
│       Setup: 2-4 weken

Zit je op enterprise-schaal (100+ engineers)?
└─ Ja → Je hebt alles nodig
        (Volledige observability + gespecialiseerde tools)
        Kosten: $5.000+/maand
        Setup: doorlopend, 1-2 toegewijde mensen

Veelvoorkomende misverstanden#

Misverstand 1: "Observability is gewoon dure logging"#

Realiteit: Observability is de combinatie van metrics + logs + traces, plus de mogelijkheid om ze automatisch te correleren.

Logging is een onderdeel van observability, maar niet het hele plaatje. Je hebt ook metrics nodig (response time, error rate) en traces (distributed tracing).

Misverstand 2: "Meer logging = betere observability"#

Realiteit: 1 miljoen logregels zijn waardeloos als je ze niet kunt doorzoeken. Kwaliteit > kwantiteit.

Log strategisch:

Log fouten (altijd)
Log business events (aankoop, login, betaling)
Log performanceproblemen (trage queries, timeouts)
Log niet elke functieaanroep (creëert ruis)

Misverstand 3: "Monitoring vangt elk probleem op"#

Realiteit: Monitoring vangt problemen op die overeenkomen met jouw regels. Problemen buiten die regels blijven onopgemerkt.

Voorbeeld: Je hebt een regel "alert als response time >3 seconden". Maar response time is normaal 1,5 seconde en na een deploy 2,5 seconde. Dat is een TOENAME van 67% maar overschrijdt jouw drempel niet. Monitoring slaat geen alarm. Observability wel.

Misverstand 4: "Observability vervangt monitoring"#

Realiteit: Observability vereist monitoring als fundament.

Je hebt nog steeds alerts nodig voor kritieke problemen. Maar je hebt ook de mogelijkheid nodig om te onderzoeken.

Misverstand 5: "Observability moet duur zijn"#

Realiteit: Er zijn veel open-source observability-tools. Je kunt je eigen oplossing bouwen.

Maar die vereist engineering-inspanning om te onderhouden. Voor de meeste teams zijn SaaS-observability-platformen ($1.000-5.000/maand) goedkoper dan iemand inhuren om de infrastructuur te beheren.

Een observability-strategie opbouwen#

Fase 1: Fundament met monitoring (maand 1)#

Zet kern-uptime-monitoring op
Monitor kritieke endpoints
Verificatie vanuit 3 regio's (elimineer valse alarmen)
Alert-routing (kritiek = page, warning = Slack)

Kosten: $50/maand Tools: UptimeRobot, Hyperping of Nova Uptime

Fase 2: Logging toevoegen (maand 2-3)#

Instrumenteer code met gestructureerde logging
Log fouten, business events, performance-metrics
Zet log-aggregatie op
Bouw dashboards om logs te doorzoeken

Kosten: +$100-200/maand Tools: Datadog, Better Stack, ELK Stack

Fase 3: Distributed tracing (maand 4-6)#

Voeg tracing toe om requests over services heen te volgen
Correleer traces met logs
Identificeer bottlenecks in de request-flow

Kosten: +$200-500/maand Tools: Datadog, New Relic, Jaeger

Fase 4: Volledige observability (maand 6+)#

Combineer metrics + logs + traces
Geautomatiseerde alerts op basis van afwijkingen
ML-gedreven root cause analysis
Historische analyse en trenddetectie

Kosten: $1.000-5.000+/maand Tools: Datadog, Dynatrace, Splunk

Observability-tools vergeleken (2026)#

Tool	Monitoring	Logging	Tracing	Prijs	Geschikt voor
UptimeRobot	Uitstekend	Nee	Nee	$10/mnd	Simpele websites
Hyperping	Uitstekend	Beperkt	Nee	$24/mnd	SaaS, API-teams
Datadog	Uitstekend	Uitstekend	Uitstekend	$100+	Enterprise, all-in-one
Better Stack	Uitstekend	Uitstekend	Beperkt	$50/mnd	Mid-market
New Relic	Uitstekend	Uitstekend	Uitstekend	$100+	Enterprise APM
Splunk	Beperkt	Uitstekend	Uitstekend	$200+	Enterprise, data-analyse
ELK Stack	Nee	Uitstekend (self-hosted)	Beperkt	Self-hosted	Kostenbewuste teams
Dynatrace	Uitstekend	Uitstekend	Uitstekend	$500+	Grote enterprises
Grafana	Uitstekend	Beperkt	Beperkt	$50+ (self-hosted)	Voorkeur voor open source

Samenvatting: monitoring vs observability#

Monitoring = "Werkt mijn systeem?" (Ja/Nee)

10-50 metrics
Regelgebaseerde alerts
Simpele dashboards
Top voor websites, simpele apps
Kosten: $20-100/maand

Observability = "Waarom is mijn systeem stuk?" (Root cause)

Miljoenen datapunten
Vrije queries
Complexe dashboards
Essentieel voor microservices
Kosten: $1.000-5.000+/maand

Logging = "Wat is er gebeurd?" (Dataverzameling)

Ruwe events
Doorzoekbare geschiedenis
Fundament voor observability
Vereist voor debuggen

De meeste teams hebben nodig: Monitoring + Logging als fundament, en voegen Observability toe naarmate ze schalen.

Wanneer upgraden:

Alleen monitoring: werkt voor 1-2 services
- Logging: werkt voor 3-5 services, 2-3 engineers
- Observability: vereist voor >10 services, >5 engineers, complexe afhankelijkheden

Investeer niet te vroeg te zwaar in observability (duur en complex). Wacht ook niet te lang (MTTR wordt slechter naarmate de complexiteit toeneemt).

Volgende stappen#

Heb je alleen monitoring: Voeg deze week gestructureerde logging toe. Lage kosten, hoge impact.
Heb je logs: Bouw een dashboard dat fouten correleert met deploys. Begin oorzaken te begrijpen.
Werk je op schaal: Investeer in distributed tracing. Het is de sleutel tot het debuggen van complexe systemen.

Klaar om over te stappen van monitoring naar observability? Begin met Nova Uptime's uptime-monitoring als fundament en voeg daarna logging en tracing toe naarmate je groeit.