Hvordan fungerer overvåking med CloudWatch?

Question

Accepted Answer

**Amazon CloudWatch** er AWS sin overvåkings- og observabilitetstjeneste — den samler **metrikker**, **logger** og **hendelser** fra AWS-ressurser og applikasjoner, med **alarmer** og instrumentbord. Det er essensielt for å forstå systemhelsen, diagnostisere problemer og respondere på problemer.

## Hva CloudWatch tilbyr

```text
METRICS → numerical data over time (CPU, memory, request count, latency, etc.)
  → AWS services publish metrics automatically; you can publish CUSTOM metrics too
LOGS → collect, store, and search application/system logs (CloudWatch Logs)
ALARMS → trigger actions when a metric crosses a threshold (alert, auto-scale, etc.)
DASHBOARDS → visualize metrics/logs in charts
EVENTS (EventBridge) → react to changes/events in your AWS environment
```

## Metrikker og alarmer

```text
→ Monitor key metrics: EC2 CPU, ALB request count/latency, RDS connections, Lambda
  errors/duration, custom application metrics
→ ALARMS act on thresholds:
  - "CPU > 80% for 5 min" → trigger auto scaling (add instances) OR notify the team
  - "error rate > 1%" → send an alert (SNS → email/Slack/PagerDuty)
  - "healthy hosts < 2" → page on-call
→ Alarms enable AUTOMATED responses and ALERTING (know about problems quickly)
```

## Logger og observabilitet

```text
✓ Centralize LOGS from EC2, Lambda, containers → search and analyze them
✓ Logs Insights → query logs (find errors, patterns, debug issues)
✓ Combine metrics + logs + traces (X-Ray) for full OBSERVABILITY
✓ Set RETENTION; create metric filters (turn log patterns into metrics/alarms)
```

## Hvorfor det er viktig

Å forstå CloudWatch er verdifullt fordi **overvåking og observabilitet er essensielt for å drive systemer i produksjon**, og CloudWatch er AWS sin kjernettjeneste for dette, så det er viktig praktisk kunnskap.

Å drive produksjonssystemer krever å kjenne deres helse, oppdage problemer og respondere raskt — du kan ikke administrere det du ikke kan se.

CloudWatch tilbyr grunnlaget: **metrikker** (numeriske data som CPU, latens og forespørselsantall, publisert automatisk av AWS-tjenester og kan tilpasses for applikasjonsspesifikke målinger) for å forstå ytelse og helse, **logger** (sentralisert innsamling og søk i applikasjons- og systemlogger) for å diagnostisere problemer, **alarmer** for å handle på problemer, og instrumentbord for visualisering.

Å forstå **alarmer** er spesielt viktig: de muliggjør både **automatiserte responser** (f.eks. høy CPU som utløser autoskalering for å legge til kapasitet) og **varsler** (varsle teamet via SNS til e-post/Slack/PagerDuty når feilrater øker eller ressurser blir utsatt) — slik at problemer utløser handling raskt i stedet for å gå ubemerket hen, noe som er essensielt for pålitelighet og hendelseshåndtering.

Å forstå **logg-sentralisering og -analyse** (samle logger fra EC2, Lambda og containere, spørre dem med Logs Insights for å finne feil og feilsøke) er nødvendig for å diagnostisere problemer i distribuerte systemer, og kombinering av metrikker, logger og spor gir full **observabilitet**.

Siden det å drive produksjonssystemer på pålitelig måte krever overvåking (kjenne helsen, oppdage og respondere på problemer) og CloudWatch er AWS sin sentrale observabilitetstjeneste (metrikker, logger, alarmer, instrumentbord), og siden alarmer muliggjør kritiske automatiserte responser og varsler, er det verdifullt, praktisk viktig AWS-kunnskap å forstå CloudWatch for å drive systemer i produksjon — essensielt observabilitet som gjør AWS-systemer driftbare, feilsøkbare og pålitelige, og en nøkkelkompetanse for alle som er ansvarlige for AWS-arbeidsbelastninger i produksjon.