Oprettelse af alarmer og notifikationer

En CloudWatch-alarm overvåger én enkelt måling og skifter tilstand, når værdien overskrider en tærskel, du definerer, over en bestemt periode. Dens opgave er at omdanne et tal, der overskrider en grænse, til en handling, oftest en meddelelse. Alarmer er det, der gør overvågning til alarmering.

En alarm er altid i én af tre tilstande: OK, når målingen er inden for grænserne, ALARM, når tærsklen overskrides, og INSUFFICIENT_DATA, når der ikke er nok data til at træffe en afgørelse. Handlinger kan knyttes til alle tilstandsovergange, så du både kan få besked, når problemer begynder, og når de er løst.

Du konfigurerer statistikken (f.eks. Sum eller Average), perioden (længden af hvert datavindue) og antallet af evalueringsperioder, der skal overskride tærsklen, før alarmen udløses. Krav om flere dårlige perioder i træk reducerer falske alarmer fra kortvarige spidser, mens en enkelt periode giver den hurtigst mulige alarm.

Alarmer sender ikke selv e-mails. De publicerer til Amazon SNS (Simple Notification Service), en pub/sub-tjeneste. Et SNS-emne har abonnenter som e-mailadresser, SMS-numre eller Lambda-funktioner. Alarmen underretter emnet, og SNS videresender beskeden til alle abonnenter.

Underretning er ikke den eneste handling. En alarm kan udløse en EC2-handling, en Auto Scaling-handling eller via SNS eller EventBridge en Lambda-funktion. Det lader en sikkerhedsalarm gøre mere end at tilkalde nogen: Den kan starte et automatiseret indeslutningsforløb, så snart en tærskel overskrides.

En sammensat alarm kombinerer flere alarmer ved hjælp af AND/OR-logik til én overordnet alarm. Det reducerer alarmstøj: I stedet for tre separate alarmer udløses én, men kun når en meningsfuld kombination er sand. Det er nyttigt til at reducere alarmtræthed, samtidig med at hver underliggende alarm stadig er tilgængelig med flere detaljer.

SNS-emnet er en del af din alarmkæde, så beskyt det. Brug en adgangspolitik for emnet til at styre, hvem der må publicere og abonnere, og overvej kryptering på serversiden med KMS til følsomt alarmindhold. En angriber, der kan abonnere på dit alarmemne, lærer præcis, hvad du holder øje med.

I stedet for en fast tærskel kan en alarm bruge CloudWatch-anomalidetektion, som lærer en målings normale interval og alarmerer ved afvigelser fra et bånd. Det egner sig til målinger med daglige eller ugentlige mønstre, hvor et statisk tal enten ville overse problemer eller udløse alarmer konstant. Det tilpasser sig, når adfærden ændrer sig over tid.

Du bestemmer, hvordan en alarm håndterer manglende data: som god, dårlig, ignoreret eller som en fortsættelse af den aktuelle tilstand. Det er vigtigt for sikkerhedsalarmer. Hvis din logning stopper, fordi en angriber har deaktiveret den, kan behandling af manglende data som "overskridelse" gøre stilhed til et signal i stedet for en blind vinkel.

Gode sikkerhedsalarmer er specifikke, veljusterede og sendt til en kanal, som mennesker overvåger. For mange støjende alarmer lærer teams at ignorere dem. Brug få evalueringsperioder til kritiske hændelser som root-login, så alarmen er øjeblikkelig, og kombiner alarmer med automatisering, så de farligste hændelser får et svar, før nogen læser e-mailen.

Hele kæden er: En loglinje, der matches af et metrikfilter, øger en metrik, en CloudWatch-alarm overvåger denne metrik, og ved en overskridelse underretter den et SNS-emne, som tilkalder dit team og eventuelt udløser Lambda. Det er afgørende at beherske dette forløb inden for eksamensområdet logning og overvågning.

En CloudWatch-alarm overvåger én metrik og skifter mellem OK, ALARM og INSUFFICIENT_DATA baseret på en tærskel over evalueringsperioder. Ved en overskridelse publicerer den til et SNS-emne, som videresender beskeden til abonnenter eller udløser automatisering. Sammensatte alarmer reducerer støj, anomalidetektion tilpasser sig mønstre, og omhyggelig håndtering af manglende data omdanner huller i logningen til signaler.