Hvordan fungerer overvågning med CloudWatch?

Question

Accepted Answer

**Amazon CloudWatch** er AWS's overvågnings- og observability-tjeneste — der indsamler **metrics**, **logs** og **events** fra AWS-ressourcer og applikationer, med **alarms** og dashboards. Det er essentielt for at forstå systemets sundhedstilstand, diagnosticere problemer og reagere på problemer.

## Hvad CloudWatch tilbyder

```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
```

## Metrics og alarms

```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)
```

## Logs og observability

```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 betyder noget

At forstå CloudWatch er værdifuldt, fordi **overvågning og observability er essentiellt for at drive systemer i produktion**, og CloudWatch er AWS's kernetjeneste for dette, så det er vigtig praktisk viden.

Drift af produktionssystemer kræver viden om deres sundhedstilstand, påvisning af problemer og hurtig reaktion — du kan ikke administrere det, du ikke kan se.

CloudWatch udgør fundamentet: **metrics** (numeriske data som CPU, latency og request counts, som automatisk publiceres af AWS-tjenester og kan tilpasses til applikationspecifikke målinger) til forståelse af ydeevne og sundhed, **logs** (centraliseret indsamling og søgning af applikations- og systemlogs) til diagnosticering af problemer, **alarms** til at handle på problemer og dashboards til visualisering.

At forstå **alarms** er særligt vigtig: de muliggør både **automatiserede reaktioner** (f.eks. høj CPU-udløser auto scaling for at tilføje kapacitet) og **alerting** (underretning af teamet via SNS til email/Slack/PagerDuty når fejlrater stiger eller ressourcer bliver usunde) — så problemer udløser handling hurtigt i stedet for at gå uopmærksomme forbi, hvilket er essentielt for pålidelighed og incident response.

At forstå **log-centralisering og analyse** (indsamling af logs fra EC2, Lambda og containers, forespørgsel af dem med Logs Insights for at finde fejl og fejlsøge) er nødvendig for diagnosticering af problemer i distribuerede systemer, og kombinering af metrics, logs og traces giver fuld **observability**.

Da drift af produktionssystemer pålideligt kræver overvågning (viden om sundhedstilstand, påvisning og reaktion på problemer) og CloudWatch er AWS's centrale observability-tjeneste (metrics, logs, alarms, dashboards), og da alarms muliggør kritiske automatiserede reaktioner og alerting, er det værdifuldt at forstå CloudWatch, praktisk vigtig AWS-viden til drift af systemer i produktion — essentiel observability, der gør AWS-systemer funktionsdygtige, debuggable og pålidelige, og en nøglekompetence for alle ansvarlige for produktions-AWS-arbejdsbelastninger.