Observability och logging: att förstå vad din app gör i produktion

När din applikation körs i produktion behöver du kunna se vad som händer inuti den – utan att behöva stoppa den och inspektera koden. Det är precis vad observability handlar om. I den här lektionen går vi igenom hur svenska DevOps-team arbetar med logging, metrics och tracing för att förstå, övervaka och felsöka sina system.

De tre pelarna av observability

Observability brukar delas upp i tre delar: loggar, metrics och traces. Varje del ger dig en annan typ av insikt om systemets beteende.

Loggar är textbaserade händelseregistreringar som berättar vad som har hänt. Metrics är numeriska mätvärden som samlas in kontinuerligt – till exempel antalet HTTP-requests per sekund eller CPU-användning. Traces spårar ett enskilt anrop genom hela systemet, från frontend till databas, och visar hur lång tid varje steg tog.

Tillsammans ger dessa tre perspektiv en heltäckande bild av applikationens hälsa och prestanda.

Strukturerad logging i praktiken

I moderna svenska team loggar man strukturerat – det innebär att varje loggpost skrivs som JSON istället för fritext. Fördelen är att loggarna blir maskinläsbara och lätta att söka och filtrera i. En typisk loggpost kan innehålla tidsstämpel, loggnivå (INFO, WARNING, ERROR), ett meddelande och relevant kontextdata som användar-ID och request-ID.

Populära bibliotek för strukturerad logging är Winston i Node.js, structlog i Python och Logback i Java. Oavsett bibliotek gäller principen att loggar ska vara informativa utan att innehålla känslig data som lösenord eller personnummer.

Centraliserad log-hantering

I ett system med många tjänster och containers behöver man aggregera loggarna på ett ställe. Svenska team använder ofta en ELK-stack (Elasticsearch, Logstash, Kibana) eller molntjänster som Datadog, Grafana Loki eller Google Cloud Logging. Det möjliggör kraftfulla sökningar och visualiseringar utan att behöva SSH:a in i varje server.

En viktig princip är att loggarna ska vara sökbara i realtid. När en kund rapporterar ett problem ska man kunna filtrera fram relevanta loggar inom minuter – inte timmar.

Metrics och dashboards

Metrics samlas in och visualiseras med hjälp av verktyg som Prometheus och Grafana – en kombination som är mycket populär i svenska DevOps-team. Prometheus scrapar metrics från applikationen med jämna mellanrum, och Grafana visar dem som grafer och dashboards.

Vanliga metrics att övervaka är svarstid (latency), felfrekvens (error rate), antalet requests per sekund (throughput) och resursutnyttjande (CPU, minne, disk). Det är standard i välfungerande team att ha ett dashboard som alltid är synligt för hela teamet.

Distribuerad tracing

I mikrotjänstearkitekturer kan ett enda HTTP-anrop trigga ett dussintal interna anrop mellan tjänster. Distribuerad tracing låter dig följa hela kedjan och se exakt var flaskhalsar uppstår. Verktyg som Jaeger och Zipkin, eller molnintegrerade lösningar som AWS X-Ray, är vanliga i svenska team med komplexa arkitekturer.

Varje anrop i kedjan tilldelas ett unikt trace-ID som följer med hela vägen. Det gör det möjligt att rekonstruera exakt vad som hände under ett specifikt användaranrop, även om det involverade tio olika mikrotjänster.

Larm och incidenthantering

Observability är inte bara för att förstå vad som hänt – det handlar också om att reagera snabbt när något går fel. Svenska team sätter upp larm (alerts) som triggas automatiskt när ett metric överstiger ett tröskelvärde – till exempel om felfrekvensen stiger över 5% eller om svarstiden överstiger en sekund.

Larm skickas ofta till Slack, PagerDuty eller liknande tjänster. En bra larmstrategi undviker larmmättnad (alert fatigue) – för många falska larm gör att teamet börjar ignorera dem. Fokusera på larm som kräver åtgärd och som representerar ett verkligt problem för användaren.