3:12 uur, PagerDuty: "Schijf 75% staging-db." De snooze op afroep. 3:28 uur: “Prometheus-dev hoog geheugen”. Snoozen. 04.05 uur: “Betalingsfoutpercentage 15% prod” – verdronken in lawaai, gelezen om 09.00 uur. Geschat verlies: vier uur verkoop.
Alertvermoeidheid is geen gereedschapsprobleem. Het is een contract-probleem: te veel signalen zonder zwaartekracht, zonder runbook, zonder manager – totdat het kanaal spam wordt en de echte urgentie onopgemerkt blijft. Prometheus, Datadog of Grafana creëren geen ruis: bij gebrek aan bestuur stapelt het zich op.
Ernst, routing en paginaregel
| Niveau | Kanaal | Voorbeeld |
|---|---|---|
| P1 kritisch | Telefoonpager | Aanbetaling, gegevensverlies |
| P2 | Slack @oncall | p95 x2 30 minuten |
| P3 | Kaartje | Schijftrend 7 dagen |
| Informatie | Dashboard | Capaciteitsplanning |
Een waarschuwing zonder runbook-koppeling en zonder servicemanager moet in productie worden verboden. Als de oproeper binnen zestig seconden niet weet wat hij moet doen, is er geen sprake van een waarschuwing, maar van een melding.
Elke nachtelijke pagina moet een concrete actie veranderen – anders had deze nooit mogen verdwijnen.
Gebruikerssymptomen versus ijdelheidsstatistieken
Goed: 5xx foutenpercentage bij het afrekenen; SLO-brandsnelheid voor meerdere vensters. Slecht: CPU boven de zestig procent zonder correlatie; certificaat verloopt over dertig dagen (één ticket is voldoende).
Prometheus Alertmanager staat 'group_by' en inhibitie toe: als het datacenter niet beschikbaar is, voorkomt het blokkeren van kindwaarschuwingen een onnodige lawine. Maar de tool vervangt niet de keuze van signalen – zie Prometheus Metrics om te bepalen wat er toe doet.
Ramen, hysteresis en klapperen
voor: 10m vermijdt een enkele piek. Drempels met marge: alleen herhalen als de situatie slechter is dan gisteren en boven de SLO. Fladderen duidt op een slechte drempel of metriek: repareer de wortel, herhaal de stilte niet.
Een waarschuwing die elke tien minuten schommelt tussen geactiveerd en opgelost, verzwakt het team meer dan een daadwerkelijke storing. Meet elk kwartaal het percentage fout-positieve resultaten.
Eigendom en driemaandelijkse evaluatie
Audit: geactiveerd in de afgelopen negentig dagen? Actie ondernomen? Vals-positief cijfer? Onderdruk geluid meedogenloos. Pre-productie mag niet dezelfde productrotatie gebruiken – label env=staging → alleen ticket.
Elke waarschuwing moet een benoemde eigenaar hebben, niet het ‘infrateam’. Zonder eigenaarschap pleit niemand voor het verwijderen van ruis of het verbeteren van het runbook.
Menselijke beperking: slaap en rotatie
Rotatie van minimaal drie personen, gedocumenteerde overdracht, tijdscompensatie. Post-incident: alert gemist? te luidruchtig? aanpassen – zonder schuld. Een uitgeputte wachtdienst mist echte noodsituaties net zo goed als een slecht gekalibreerd alarm. Documenteer ook wie een waarschuwing kan uitzetten en voor hoe lang. Permanente stilte tijdens enscenering is gezond; permanent stilzwijgen over de betaling is een onbehandelde mislukking.
De top: monitoren wie wolf roept
Beslis en ga vooruit zonder blinde vlek
Herclassificeer eerst bestaande waarschuwingen op werkelijke ernst en gebruikersimpact. Vervang vervolgens de processordrempels door waarschuwingen op basis van de SLO's van gebruikers wanneer correlatie dit toelaat. Voeg een runbook toe aan elke waarschuwing waardoor iemand 's nachts wakker wordt. Plan een driemaandelijkse evaluatie met expliciete ruisonderdrukking. Isoleer de preproductie van de nachtelijke productierotatie. Vergelijk de monitoring die wordt beheerd via de overzicht en de vergelijker. Streef naar meer dan tachtig procent bruikbare nachtelijke pagina's.
Veelgestelde vragen
Hoeveel pagerwaarschuwingen zijn er in productie?
Klein: elke pagina vereist onmiddellijke actie. De rest gaat naar ticket of dashboard. Minder dan vijf pagina's per week wakker indien goed gekalibreerd; verder normaliseert het team het geluid.
Wat is het verschil tussen waarschuwend en kritisch?
Kritieke pagina met runbook en manager; waarschuwing alleen tijdens kantooruren. Meng nooit de twee nachtkanalen; dit vernietigt de geloofwaardigheid van de wachtdienst.
Hoe test ik een waarschuwing?
Mock-oefening, foutinjectie, trigger en runbook-verificatie. Een waarschuwing die nooit wordt getest, is waarschijnlijk onwaar of wordt genegeerd. Plan elk kwartaal een speeldag.
Infra-waarschuwingen versus gebruikers-SLO?
Gebruikerssymptomen eerst; processor alleen als bewezen correlatie. Een hoge CPU zonder impact op de gebruiker zou niemand wakker moeten maken.
Een waarschuwing die een nachtelijke actie niet verandert, mag niemand wakker maken.