Observabilitet hviler på tre søjler — logfiler, målinger og spor — og målet er at besvare "hvad er galt og hvorfor" for et system, der er for stort til at inspicere manuelt. I stor skala handler strategien om korrelation, sampling og omkostninger.
Observabilitet hviler på tre søjler — logfiler, målinger og spor — og målet er at besvare "hvad er galt og hvorfor" for et system, der er for stort til at inspicere manuelt. I stor skala handler strategien om korrelation, sampling og omkostninger.
| Pillar | Besvarer | Værktøjer |
|---|
| Metrics | Er der noget galt? (rates, latency) | Prometheus, Grafana |
| Traces | Hvor i flowet? | OpenTelemetry, Jaeger |
| Logs | Hvad skete der præcis? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
Trace/correlation ID skal gå gennem målingsetiketters, loglinjer og spans, så du kan dreje mellem 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)
Logging af alt med 100% er uoverkommeligt og oversvømmer signalet. Sample, strukturer og alert på SLOs i stedet.
Med hundredvis af tjenester kan du ikke SSH ind og kigge — observabilitet er den eneste måde at forstå produktionskod på.
Den vindende strategi er korreleret, samplet og SLO-drevet: den bringer rigtige problemer hurtigt frem uden at bankerotte dig på telemetrilagring eller begravet on-call i støj.