Hoe detecteer je problemen voordat gebruikers klagen?

Question

Accepted Answer

Het doel is problemen **voor de pagina** op te vangen — degradatie opsporen terwijl er nog ruimte is om dit op te vangen. Dat betekent dat je **leidende indicatoren** volgt, **SLOs met error budgets** definieert, en het systeem actief sondeert in plaats van te wachten tot het faalt.

## SLOs en error budgets

Een **SLO** zet betrouwbaarheid om in een getal (bijv. 99,9% van de verzoeken slagen). De resterende 0,1% is je **error budget**. Het bijhouden van **burn rate** stelt je in staat om te waarschuwen wanneer je het budget te snel opmaakt — lang voordat je daadwerkelijk de SLO hebt geschonden en gebruikers het opmerken.

```text
SLO 99.9% → 0.1% error budget/month (~43 min of downtime)
burn rate rising fast → you'll exhaust it in 2 days → alert NOW, while it's fixable
```

## Actief testen, niet alleen passieve metriek

```text
SYNTHETIC MONITORING  scripted checks hit critical paths on a schedule
                      (login, checkout) → fails even at 3am with zero real traffic
HEALTH CHECKS         /healthz endpoints + dependency checks → load balancer
                      pulls bad instances before users hit them
RUM (real-user mon.)  measure latency/errors from actual browsers/devices →
                      catches issues only some users/regions see
```

Synthetic monitoring is krachtig omdat het niet op een gebruiker wacht — het oefent het systeem voortdurend, dus een kapotte checkout wordt om 3 uur 's nachts gevonden, niet wanneer de ochtenddruk klaagt.

## Leidende indicatoren en trends

De eerste tekenen zitten in resources, nog niet in fouten die de gebruiker ziet. Waarschuw op basis van de **trend**, niet alleen op een statische lijn.

```text
LEADING INDICATORS   saturation (CPU/mem climbing), queue depth growing,
                     connection-pool nearing limit, latency CREEPING up
ANOMALY DETECTION    flag deviation from the normal baseline / seasonality
TREND ALERTS         "disk will fill in 4h at this rate" → act before it's full
```

Een langzaam stijgende p99 of een groeiende wachtrij is een waarschuwingsschot: door in te grijpen op de stijging, voorkom je de storing die eraan voorafging.

## Waarom het belangrijk is

Reactieve monitoring betekent dat gebruikers je waarschuwingssysteem zijn — op het moment dat ze klagen, is het incident al live en je error budget is op. Proactieve detectie (SLO burn rate, synthetics, health checks, RUM, leidende indicatoren, trend-/anomaliewaarschuwingen) geeft je voortijd: je lost een verzadigde wachtrij of toenemende latentie op voordat het een pagina om 2 uur 's nachts en een boze klant wordt. Die voortijd is het verschil tussen een stille fix en een storing.