Vad är en observabilitetsstrategi för loggar, mätvärden och spår i stor skala?

Question

Accepted Answer

Observabilitet vilar på **tre pelar** — **loggar**, **mätvärden** och **spår** — och målet är att svara "vad är fel och varför" för ett system som är för stort för att inspektera för hand. I stor skala handlar strategin om korrelation, sampling och kostnad.

## De tre pelarna

| Pel | Svar | Verktyg |
|---|---|---|
| Mätvärden | Är något fel? (hastigheter, latens) | Prometheus, Grafana |
| Spår | Var i flödet? | OpenTelemetry, Jaeger |
| Loggar | Vad hände exakt? | ELK, Loki |

```text
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
   (broad)              (path)                          (detail)
```

## Gör dem korrelerade

Spår-/korrelations-ID:t måste gå igenom måttetikett, logglinjer och spans, så du kan pivotera mellan dem.

```text
log line:  level=error trace_id=abc123 service=payments msg="gateway timeout"
                       ^^^^^^^^^^^^^^^ same id appears in the trace + metrics
```

## Tankar i stor skala

```text
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
```

## Fallgrop

Att logga allt på 100% är överkomligt och dränker signal. Sampla, strukturera och varna på SLO:er istället.

## Varför det är viktigt

Med hundratals tjänster kan du inte SSH in och titta — observabilitet är det enda sättet att förstå produktionsbeteende.

Den vinnande strategin är korrelerad, sampelad och SLO-driven: den ytar verkliga problem snabbt utan att slå dig på telemetrilagring eller begrava on-call i brus.

Mätvärden	Är något fel? (hastigheter, latens)	Prometheus, Grafana
Spår	Var i flödet?	OpenTelemetry, Jaeger
Loggar	Vad hände exakt?	ELK, Loki