Alert Fatigue Bestrijden: Effectieve Alerting Strategieën

Er is een monitoring stack. Prometheus draait, Grafana dashboards zijn ingericht, en er stromen alerts binnen. Tientallen per dag. Na een week klikt niemand ze meer open. Na een maand staan notificaties op mute. Herkenbaar?

Dat is alert fatigue. En het is een van de gevaarlijkste patronen in operations. Niet omdat de tooling faalt, maar omdat het vertrouwen in alerts verdwijnt. Als alles schreeuwt, luistert niemand meer.

Het Probleem met "Alert op Alles"

De reflex bij het opzetten van monitoring is om overal alerts op te plakken. CPU boven 80%? Alert. Disk boven 70%? Alert. Response time boven 200ms? Alert. Klinkt logisch, maar het resulaat is een systeem dat constant ruis produceert.

Het fundamentele probleem: de meeste van deze alerts vereisen geen actie. CPU op 85% gedurende drie minuten is vaak volstrekt normaal — een deployment, een cronjob, een korte burst. Pas als het structureel boven de 95% zit gedurende twintig minuten, is er een echt probleem.

Twee Simpele Regels

Elke alert moet aan twee criteria voldoen:

1. Vereist het menselijke actie? Als het antwoord nee is, mag het geen alert zijn. Maak er een dashboard panel van.
2. Is het urgent? Als het tot morgen kan wachten, hoort het in een daily review — niet in een PagerDuty notificatie om 3 uur 's nachts.

Alerts die niet aan beide criteria voldoen, worden ofwel verwijderd, ofwel gedemoted naar een informationele log.

Severity Levels Die Werken

Een veelgemaakte fout is het gebruik van te veel severity levels. Drie is genoeg:

Level	Betekenis	Reactie
Critical	Klanten worden geraakt, nu	Directe actie, ook 's nachts
Warning	Wordt een probleem als niemand ingrijpt	Binnen kantooruren oppakken
Info	Goed om te weten	Daily review, geen notificatie

Critical alerts mogen maximaal een paar keer per week afgaan. Gaat dat vaker, dan is er iets mis met de drempelwaarden — of met de architectuur.

Praktische Prometheus Alerting Tips

Een voorbeeld dat het verschil laat zien. Deze alert is te gevoelig:

# Slecht: reageert op elke korte spike
- alert: HighCPU
  expr: node_cpu_seconds_total > 80
  for: 1m

Dit werkt beter:

# Goed: filtert korte bursts eruit
- alert: HighCPUSustained
  expr: avg_over_time(node_cpu_seconds_total[15m]) > 90
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Sustained high CPU on {{ $labels.instance }}"
    description: "CPU gemiddeld boven 90% gedurende 25 minuten"

Het verschil zit in avg_over_time en een langere for periode. Korte spikes verdwijnen, structurele problemen niet.

Symptomen vs. Oorzaken

Alert op symptomen, niet op oorzaken. Dit klinkt contra-intuïtief, maar het werkt.

Symptoom-alert (goed): "Error rate op /api/orders is boven 5% gedurende 10 minuten." Dit vertelt direct: klanten hebben last. Actie is nodig.

Oorzaak-alert (minder goed): "Database connectie pool is vol." Misschien veroorzaakt dit problemen, misschien niet. De applicatie heeft wellicht retry logic. Zonder context op de impact is het moeilijk te prioriteren.

De symptoom-alert triggert altijd wanneer het er toe doet. De oorzaak-alert triggert soms voor niks.

Alert Routing en Ownership

Een alert zonder duidelijke eigenaar is een alert die genegeerd wordt. Elk alert rule moet een team of persoon gekoppeld hebben. In Alertmanager ziet dat er zo uit:

route:
  receiver: 'default-slack'
  routes:
    - match:
        team: platform
      receiver: 'platform-pagerduty'
    - match:
        team: backend
      receiver: 'backend-slack'
      routes:
        - match:
            severity: critical
          receiver: 'backend-pagerduty'

Platform alerts gaan naar het platform team. Backend alerts naar backend. Critical gaat naar PagerDuty, de rest naar Slack. Simpel, maar het voorkomt dat alerts in een gedeeld kanaal verdwijnen waar niemand zich verantwoordelijk voelt.

Wekelijkse Alert Review

Het opzetten van alerts is niet eenmalig. Reserveer een halfuur per week om door te lopen:

• Welke alerts zijn afgegaan?
• Hoeveel waren actionable?
• Welke zijn genegeerd of direct gedismissed?

Alerts die consequent genegeerd worden, moeten weg of aangepast. Een alert die drie weken op rij zonder actie wordt weggeknikt, voegt alleen ruis toe. Verwijder het of verhoog de drempel.

Runbooks: De Vergeten Schakel

Elke critical alert hoort een runbook te hebben. Niet een vage wiki-pagina, maar concrete stappen: wat check je eerst, welke commando's voer je uit, wanneer escaleer je.

annotations:
  runbook_url: "https://wiki.internal/runbooks/high-error-rate-orders"

Een runbook bespaart minuten in een stressvolle situatie. En het maakt het mogelijk voor teamleden die minder ervaring hebben om toch effectief te reageren op een nachtelijke page.

Samengevat

Goede alerting gaat niet over meer alerts. Het gaat over minder, betere alerts. Elke alert moet urgent zijn, actionable, en een eigenaar hebben. Alles wat daar niet aan voldoet, is ruis — en ruis is de vijand van betrouwbare operations.

Begin met een audit van de huidige alerts. Schrap alles wat geen actie vereist. Verscherp de drempelwaarden. En plan die wekelijkse review in. Na een maand is het verschil merkbaar: minder notificaties, snellere reactietijden, en een team dat weer vertrouwen heeft in het alerting systeem.