Observabilitet bygger på tre pilarer — logger, metrikker og spor — og målet er å svare på "hva går galt og hvorfor" for et system som er for stort til å inspisere for hånd. I stor skala handler strategien om korrelasjon, sampling og kostnad.
Observabilitet bygger på tre pilarer — logger, metrikker og spor — og målet er å svare på "hva går galt og hvorfor" for et system som er for stort til å inspisere for hånd. I stor skala handler strategien om korrelasjon, sampling og kostnad.
| Pilar | Svarer på | Verktøy |
|---|
| Metrikker | Går noe galt? (rates, latency) | Prometheus, Grafana |
| Spor | Hvor i flyten? | OpenTelemetry, Jaeger |
| Logger | Hva skjedde egentlig? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
Trace/korrelations-ID-en må gå gjennom metrikkbilder, logglinjer og spans, slik at du kan veksle mellom dem.
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ 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)
Å logge alt med 100% er uoverkommelig og drukner signalet. Sample, strukturer og alert på SLO-er i stedet.
Med hundrevis av tjenester kan du ikke SSH inn og se — observabilitet er den eneste måten å forstå produksjonsvirkemåte.
Den vinnende strategien er korrelert, samplet og SLO-drevet: den bringer fram virkelige problemer raskt uten å gjøre deg konkurs på telemetriilagring eller begrave on-call-teamet ditt i støy.