Alarmering

En alarmeringskæde har to forskellige led, som ofte blandes sammen. Regelevaluering kører med faste mellemrum en forespørgsel mod en tidsseriedatabase eller et logindeks og gør resultatet til alarminstanser; i Prometheus er en alarmregel et PromQL-udtryk plus en "for:"-varighed, og en instans går fra inactive over pending til firing, først når udtrykket har givet et ikke-tomt resultat ved hver evaluering i hele den periode. Routing af notifikationer er en separat komponent, fx Alertmanager, som deduplikerer instanser, grupperer dem efter labels (group_by, group_wait, group_interval, repeat_interval), anvender silences og inhibition-regler (fx undertrykkes alle alarmer pr. tjeneste, mens en alarm for hele datacentret er aktiv) og leverer til modtagere som et paging-system, chat eller en ticketkø. Labels som severity og team styrer routingen; annotations bærer resuméet, et link til dashboardet og som regel en runbook_url.

Googles SRE-bog skelner mellem tre slags output fra overvågning: alarmer, hvor et menneske skal handle straks; tickets, hvor et menneske skal handle, men ikke nu; og logning, som ingen behøver læse, medmindre der skal undersøges noget. En alarm, der vækker folk uden at kræve handling, eller hvor handlingen kunne scriptes, er en fejl i alarmdesignet. Samme kilde anbefaler at alarmere på symptomer, som brugerne mærker (de fire gyldne signaler: latenstid, trafik, fejl og mætning), frem for på årsager som høj CPU, der måske ikke skader nogen. Årsagsbaserede alarmer er stadig nyttige ved forudsigelig udtømning, fx en disk, der forventes at blive fuld inden for få timer, hvor ekstrapolering à la predict_linear giver forvarsel.

SLO-baseret alarmering forfiner symptomalarmer ved at alarmere på, hvor hurtigt fejlbudgettet bruges. En burn rate på 1 bruger præcis budgettet over SLO-perioden; SRE Workbook foreslår for en SLO på 99,9 % over 30 dage at tilkalde vagten, når burn rate overstiger 14,4 over én time (2 % af budgettet brugt) eller 6 over seks timer (5 %), og at oprette en ticket ved burn rate 1 over tre døgn (10 %). Hver betingelse parres med et kort vindue på cirka en tolvtedel af det lange, så alarmen også hurtigt nulstilles, når problemet ophører.

Typiske fejl er alarmtræthed fra støjende tærskler, flapping omkring en tærskel uden hysterese, manglende alarmer, når selve metrikken forsvinder (en tidsserie, der ikke længere indsamles, giver ingen data frem for et brud, og derfor findes absent()-tjek og en dead man's switch-alarm, der altid skal fyre), og et overvågningssystem, der deler skæbne med det, det overvåger. Alarmering adskiller sig også fra korrelation i et SIEM: SIEM-detektioner retter sig mod sikkerhedshændelser på tværs af heterogene logs, men begge afhænger af samme disciplin med tuning, ejerskab og dokumenteret respons.