CloudWatch-alarmer og sammensatte alarmer

En CloudWatch-alarm overvåker én enkelt metrikk eller resultatet av et uttrykk for metrikkberegning over en tidsperiode som De angir. Når metrikken krysser en terskel De har definert, endrer alarmen tilstand og kan automatisk utløse en handling, for eksempel å sende et SNS-varsel, skalere en Auto Scaling-gruppe, stoppe en EC2-instans eller opprette et Systems Manager OpsItem. Alarmer er den primære mekanismen for automatiserte driftsreaksjoner i AWS.

En CloudWatch-alarm er alltid i én av tre tilstander: OK — metrikken er innenfor den definerte terskelen; ALARM — metrikken har overskredet terskelen i det nødvendige antallet evalueringsperioder; INSUFFICIENT_DATA — alarmen er nettopp opprettet, metrikken er ikke tilgjengelig, eller det er ennå ikke samlet inn nok data. Overganger mellom tilstander utløser handlinger som er konfigurert for den aktuelle tilstandsendringen — De kan ha ulike SNS-emner for tilstandene OK, ALARM og INSUFFICIENT_DATA.

Når De oppretter en alarm, angir De: metrikken og navneområdet, statistikken (Average, Sum, Maximum osv.), perioden (hvor ofte metrikken evalueres, i sekunder), evalueringsperiodene (hvor mange påfølgende perioder som må overskride terskelen), terskelverdien og sammenligningsoperatoren. Alarmen utløses når metrikken overskrider terskelen i det angitte antallet påfølgende evalueringsperioder.

Alarmhandlinger kan rette seg mot flere mål: Amazon SNS-emner (for å sende e-post eller SMS, eller utløse Lambda), Auto Scaling-policyer (for å skalere en ASG inn eller ut) og EC2-handlinger (for å stoppe, avslutte, starte på nytt eller gjenopprette en EC2-instans). For hver tilstand (OK, ALARM, INSUFFICIENT_DATA) kan De angi et annet sett med handlinger — for eksempel varsle teamet ved ALARM, varsle om gjenoppretting med OK og varsle ved INSUFFICIENT_DATA for å oppdage hull i overvåkingen.

Når CloudWatch evaluerer en alarm og enkelte datapunkter mangler, må De bestemme hvordan de skal behandles. Alternativene er: notBreaching (behandle manglende data som om de er innenfor terskelen — alarmen forblir OK hvis øvrige data er OK), breaching (behandle manglende data som om terskelen er overskredet — alarmen går til ALARM), ignore (alarmtilstanden endres ikke) og missing (alarmen går til INSUFFICIENT_DATA). Feil valg kan føre til falske positiver eller ubemerkede feil — en viktig nyanse på SAA-C03-eksamenen.

Alarmoppløsningen er produktet av periode × evalueringsperioder. En periode på 60 sekunder med 5 evalueringsperioder betyr for eksempel at alarmen vurderer 5 påfølgende datapunkter på 1 minutt. Alarmen går som standard bare over til ALARM når alle fem periodene overskrider terskelen. De kan konfigurere datapoints-to-alarm slik at bare M av N perioder må overskride terskelen — for eksempel 3 av 5 — noe som reduserer falske positiver fra kortvarige topper.

En sammensatt alarm evaluerer tilstanden til flere andre alarmer ved hjelp av boolsk logikk (AND, OR, NOT). Den går over til tilstanden ALARM bare når regeluttrykket evalueres til true. Sammensatte alarmer brukes til å redusere varselstøy — De kan for eksempel varsle bare hvis både alarmene for høy CPU-bruk og høy latenstid utløses samtidig, siden høy CPU-bruk alene kan være akseptabelt under batchbehandling. De kan også bruke sammensatte alarmer til å undertrykke underordnede alarmer under vedlikeholdsvinduer.

Sammensatte alarmer støtter handlinger for undertrykking av alarmer — De kan konfigurere en sammensatt alarm til å undertrykke de underordnede alarmene under planlagt vedlikehold. Under et distribusjonsvindu kan De for eksempel angi en sammensatt alarm som kombinerer en «MaintenanceMode»-alarm med OR-logikk, slik at alle varsler fra underordnede alarmer undertrykkes mens vedlikeholdet pågår. Dette hindrer en flom av varsler når De med hensikt tar tjenester offline for oppgraderinger.

Auto Scaling-grupper bruker CloudWatch-alarmer som utløsere for policyer for trinnvis skalering og enkel skalering. Når alarmen går over til tilstanden ALARM, utføres skaleringspolicyen. Ved trinnvis skalering definerer De flere skaleringsjusteringer for ulike terskelområder — for eksempel legg til 1 instans hvis CPU-bruken er 70–80 %, legg til 3 hvis den er 80–90 %, og legg til 5 hvis den er over 90 %. Alarmen utløser det første relevante trinnet basert på overskridelsesnivået ved evalueringstidspunktet.

De kan opprette faktureringsalarmer i CloudWatch for å bli varslet når de beregnede AWS-kostnadene overstiger en terskel. Faktureringsmetrikker publiseres bare i Region us-east-1, uavhengig av hvor ressursene kjører, og oppdateres omtrent hver sjette time. For å aktivere faktureringsalarmer må De først slå på Billing Alerts i AWS Billing-konsollen. Det mer presise verktøyet er AWS Budgets, men CloudWatch-faktureringsalarmer er fortsatt et gyldig alternativ som testes på eksamenen.

De kan angi alarmtilstanden manuelt ved hjelp av kommandoen set-alarm-state for å teste alarmhandlinger uten å vente på et reelt terskelbrudd. Dette er nyttig for å kontrollere at SNS-emnene, Auto Scaling-policyene og Lambda-funksjonene reagerer som de skal. Test alltid alarmhandlingene i et ikke-produksjonsmiljø, og kontroller at de riktige e-postabonnementene for SNS-emnet er bekreftet før De stoler på alarmer for varsling i produksjon.

I denne leksjonen har De lært at alarmer har tre tilstander (OK, ALARM, INSUFFICIENT_DATA) og kan utløse SNS-, Auto Scaling- og EC2-handlinger, at datapoints-to-alarm tillater M-av-N-evaluering for å redusere falske positiver, og at sammensatte alarmer bruker boolsk logikk til å kombinere flere alarmer og redusere varselstøy. Neste tema er CloudWatch Logs og Log Insights for sentralisert loggbehandling.