Observability i praktiken – loggar, metrics och spårning

Observability har blivit ett modeord, men skillnaden mellan ett team som löser en produktionsincident på 10 minuter och ett team som gör det på 3 timmar handlar sällan om verktygsval — den handlar om huruvida loggar, metrics och spårning faktiskt är kopplade till varandra. Vi ser gott om miljöer med Prometheus, Grafana, och ett ELK-stack, men där ett fel i produktion ändå kräver att en utvecklare manuellt korrelerar tidsstämplar mellan tre olika verktyg för att hitta grundorsaken. Det är inte observability — det är bara insamlad data.

Den här guiden går igenom de tre pelarna i praktiken: strukturerad loggning, metrics-instrumentering, distribuerad spårning med OpenTelemetry, och — viktigast — hur du binder ihop dem så de faktiskt gör en incident snabbare att lösa istället för bara mer data att bläddra i.

Strukturerad loggning — sluta logga strängar

Det enskilt största steget de flesta team kan ta för bättre observability är att sluta logga fritextsträngar och börja logga strukturerad JSON. En logg som console.log("User " + userId + " failed login") går inte att effektivt söka, filtrera eller aggregera i skala. En strukturerad logg med explicita fält (user_id, event, trace_id, severity) gör det möjligt att fråga "visa alla misslyckade inloggningar för denna användare de senaste 24 timmarna" på under en sekund istället för att grep:a genom terabyte av textloggar.

Använd ett strukturerat loggbibliotek (Pino för Node.js, structlog för Python, Zap för Go) och sätt en konsekvent loggnivåpolicy: debug för utvecklingsdetaljer (avstängt i produktion), info för normala affärshändelser, warn för avvikelser som inte kräver omedelbar åtgärd, och error för fel som kräver uppmärksamhet. Logga aldrig känslig data i klartext — personnummer, lösenord, API-nycklar eller fullständiga betalkortsnummer. Centralisera loggarna i Loki, ELK Stack eller en molnleverantörs loggtjänst, och sätt en rimlig retention (30-90 dagar varmt, längre kallt lagrat för compliance).

Metrics — de fyra gyllene signalerna

Metrics ger dig aggregerad, tidsseriedata som är billig att lagra och snabb att fråga — perfekt för dashboards och larm, men för grov för att felsöka ett enskilt fel. Google SRE:s "fyra gyllene signaler" är fortfarande den bästa utgångspunkten: latens (hur lång tid tar requests), trafik (hur många requests), felfrekvens (andel misslyckade requests), och mättnad (hur nära resursgränser är systemet). Instrumentera dessa på varje tjänst innan ni lägger till mer specifika affärsmetrics.

Prometheus med Grafana är fortfarande standardkombinationen 2026 för self-hosted metrics, med Grafana Cloud, Datadog eller New Relic som hanterade alternativ för team som inte vill drifta insamlingslagret själva. Sätt SLO:er (Service Level Objectives) på de viktigaste tjänsterna — t.ex. 99,5 procent av requests under 300ms — och koppla larm till felbudget snarare än enskilda tröskelvärden. Ett larm som går varje gång en enskild request tar 500ms skapar bara larmtrötthet; ett larm som går när felbudgeten för månaden är på väg att ta slut är faktiskt actionable.

Distribuerad spårning — följ en request genom hela systemet

I en mikrotjänstarkitektur räcker varken loggar eller metrics för att förstå varför en enskild request tog 4 sekunder när den passerade genom sex tjänster. Distribuerad spårning med OpenTelemetry löser det genom att ge varje request ett trace_id som följer med genom hela anropskedjan, med varje tjänst som lägger till en span som visar hur lång tid just den delen tog. Resultatet är ett vattenfallsdiagram som visar exakt var tiden gick — databasfrågan som tog 3,2 av de 4 sekunderna, till exempel.

OpenTelemetry har blivit branschstandarden 2026 eftersom det är leverantörsoberoende — instrumentera koden en gång, skicka data till valfri backend (Jaeger, Tempo, Honeycomp, Datadog) utan att byta instrumenteringskod om ni byter verktyg senare. Instrumentera automatiskt där det går (HTTP-klienter, databasdrivrutiner har ofta färdiga auto-instrumentation-paket) och lägg till manuella spans bara för affärskritisk logik som inte fångas automatiskt.

Binda ihop de tre pelarna

Det här är steget de flesta miljöer missar. Värdet av observability kommer inte från att ha loggar, metrics och spårning separat — det kommer från att kunna hoppa mellan dem för samma händelse. En utvecklare som ser en felspik i en Grafana-dashboard ska kunna klicka sig direkt till de exakta spåren och loggraderna för de misslyckade requesten, inte behöva manuellt korrelera tidsstämplar mellan tre system.

Praktiskt innebär det: injicera samma trace_id i både loggar och spans, exponera trace_id som en exemplar-länk i Prometheus-metrics (Grafana stöder detta direkt mot Tempo/Jaeger), och centralisera allt i en gemensam observability-plattform där det är tekniskt möjligt (Grafana LGTM-stacken — Loki, Grafana, Tempo, Mimir — är ett populärt self-hosted val 2026 just för den tighta integrationen). Den investeringen betalar sig första gången en on-call-utvecklare löser en incident på 15 minuter istället för 2 timmar klockan tre på natten.

Var börjar man om man har noll observability idag?

Börja med strukturerad loggning — det är billigast att införa och ger omedelbart värde för felsökning. Lägg sedan till de fyra gyllene signalerna som metrics på era mest kritiska tjänster innan ni breddar till alla tjänster. Spara distribuerad spårning till sist, eftersom det kräver mest instrumenteringsarbete och ger störst värde först när ni faktiskt har flera tjänster som pratar med varandra — för en monolit är det sällan värt investeringen initialt. Koppla detta till er CI/CD-pipeline så att deploy-händelser syns som annoteringar i dashboards, och till er Kubernetes-plattform så att observability-stacken provisioneras som infrastruktur redan från start.

Vi hjälper svenska team bygga observability-plattformar som faktiskt gör incidenter snabbare att lösa, från grundläggande instrumentering till fullständig OpenTelemetry-integration — läs mer om våra tjänster eller boka ett samtal.