# Vad är observability? En enkel guide för kalkylbladsfans URL: https://formula.dog/sv/journal/vad-ar-observability Type: blog Locale: sv Published: 2026-10-17 Updated: 2026-10-17 --- > Observability låter dig ställa nya frågor till ett system med hjälp av loggar, mätvärden och spårningar. Här är den enkla versionen, med formler du kan klistra in i Sheets eller Excel. Vad är observability? Det är förmågan att ta reda på vad ett system gör, och varför, enbart utifrån den data det skickar ut: loggar, mätvärden och spårningar. Om övervakning säger att något gick sönder låter observability dig ställa nästa fråga: var, för vilka och sedan när. Om du lever i kalkylblad gör du redan en liten version av detta varje gång du spårar ett konstigt tal tillbaka till sin källrad. ## Versionen på en minut för dig som lever i kalkylblad Tänk dig ett månatligt intäktsblad där totalsumman ser fel ut. En instrumentpanel som säger "totalen stämmer inte" är övervakning. Att kunna filtrera på region, dag och produkt och hitta den enda import som dubblerade 400 rader, det är observability. Mjukvaruteam stöter på samma vägg med system i drift. En kassasida blir långsam. Ett larm går. Nu måste någon ta reda på vilken tjänst, vilket kundsegment och vilken driftsättning som orsakade det. Datan som gör det möjligt kallas telemetri, och hur väl man kan använda den är det man menar med observability. Biscuit har en variant av detta också. Han behöver inte få veta att bollen är borta. Han behöver spåra var bollen senast sågs. ![Anteckningsbokskiss med tre parallella tidslinjer bredvid en stoppur i mässing](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/ddbb29-img1.webp) ## Övervakning mot observability: kända problem mot överraskningar Övervakning bevakar sådant du bestämt i förväg att du ska bevaka. CPU över 90 procent, felfrekvens över 2 procent, en sida som slutar svara. Du skriver regeln, och verktyget larmar när den bryts. Observability är till för problemen du aldrig skrev någon regel för. [OpenTelemetry-projektet beskriver det](https://opentelemetry.io/docs/concepts/observability-primer/) som ett sätt att förstå ett system utifrån, utan att känna till dess inre delar, vilket hjälper mot så kallade okända okända, alltså sådant du inte ens visste att du borde fråga om. Tänk inte att det ena ersätter det andra. Övervakning är brandlarmet. Observability är planritningen och övervakningsfilmen du tittar på i efterhand. Du behöver båda. ## Loggar, mätvärden och spårningar: de tre råa ingredienserna Nästan varje förklaring landar på samma tre signaler. Här är var och en i kalkylbladstermer. **Loggar** är tidsstämplade meddelanden om enskilda händelser. I ett kalkylblad är det en rad per händelse: tid, användare, åtgärd, resultat. De innehåller mest detaljer och tar mest plats. **Mätvärden** är siffror som sammanfattats över tid, till exempel felfrekvens, anrop per minut eller använt minne. I ett kalkylblad är det din sammanfattningsflik. Billiga att lagra och snabba att rita upp, men de kan inte säga vilket enskilt anrop som misslyckades. **Spårningar** följer ett enda anrop när det går genom flera tjänster, med tiden i varje steg. I ett kalkylblad tänker du dig ett order-ID som du följer över fem flikar och noterar hur länge det låg i varje. Den vanliga kortversionen: mätvärden säger att något är fel, spårningar säger ungefär var, och loggar ger detaljerna. Så här ser det ut i en riktig cell, på en minut. ## Du har 5,000 loggrader i en fil: ett genomgånget exempel i Sheets Säg att du har exporterat 5,000 rader applikationslogg till Google Sheets. Kolumn A innehåller tidsstämpeln, kolumn B tjänstens namn, kolumn C statuskoden och kolumn D svarstiden i millisekunder. Fungerar i Excel och Sheets om inget annat anges. Först felfrekvensen, ett klassiskt mätvärde: `=COUNTIF(C2:C5001, ">=500") / COUNTA(C2:C5001)` - Intervallet är C2:C5001, statuskoderna. - Kriteriet `">=500"` räknar alla serverfel. - Division med `COUNTA` ger andelen av alla anrop. Formatera cellen som procent. Det här är övervakning: ett tal, ett tröskelvärde. Nu observability-delen. Vilken tjänst står för felen? `=QUERY(A1:D5001, "select B, count(C) where C >= 500 group by B order by count(C) desc", 1)`Den här fungerar bara i Sheets, eftersom QUERY saknar motsvarighet i Excel. Argumenten: - Datan är A1:D5001, med rubrikerna med. - Texten är en kort SQL-liknande fråga: räkna felen per tjänst, störst först. - Den sista `1` säger att det finns en rubrikrad. I Excel 365 får du samma svar med ett annat recept: `=LET(s, FILTER(B2:B5001, C2:C5001>=500), u, UNIQUE(s), HSTACK(u, COUNTIF(s, u)))`Det kräver Excel 365 eller 2021, eftersom FILTER, UNIQUE och HSTACK inte finns i Excel 2016. Äldre versioner klarar sig bättre med en pivottabell. För de långsamma anropen är 95:e percentilen ärligare än medelvärdet: `=PERCENTILE(D2:D5001, 0.95)`Om medelsvarstiden är 180 ms men 95:e percentilen är 2,400 ms, så har en av tjugo användare en dålig dag. Medelvärden döljer just det, och det är precis den fälla som observability-verktygen försöker hjälpa dig undvika. ![Laptop med ett kalkylblad och en hundtass som vilar på skrivbordet](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/824719-img2.webp) Biscuit har redan hämtat den åt dig om formeln är den del du alltid glömmer. [Formula.dog](https://formula.dog) gör om en vanlig beskrivning på svenska till en formel som den här. ## Var observability dyker upp en vanlig arbetsdag Du behöver inte köra servrar för att stöta på det. En supportchef som frågar "varför fördubblades ärendena på tisdag?" gör det. Det gör också en ekonomianalytiker som spårar en avvikelse till en enda leverantörsfaktura, eller en driftansvarig som upptäcker att en nattlig import tyst hoppade över en fil. Inom mjukvara blir frågorna skarpare eftersom systemen är distribuerade. Ett klick på en knapp kan beröra en API-gateway, en autentiseringstjänst, en databas och en betalningsleverantör. När något går fel är felmeddelandet du ser sällan den plats där det började. En spårning visar hela kedjan, med den långsamma eller trasiga länken markerad, så att ingen behöver gissa. Tre termer dyker upp hela tiden, så här är de i klartext: - **Instrumentering** är att lägga till koden som skickar ut telemetri. Tänk dig det som att lägga till en tidsstämpel och en ID-kolumn i en rapport som aldrig hade dem. - **Kardinalitet** är hur många olika värden ett fält kan ha. Region har låg kardinalitet, användar-ID har väldigt hög. Fält med hög kardinalitet besvarar de skarpaste frågorna men kostar mest att behålla. - **SLO** (service level objective) är ett mål du lovar dig själv, till exempel "99.5 procent av kassaköpen blir klara på under två sekunder". Det förvandlar vag oro till ett tal du kan följa. ## Varför en hög med instrumentpaneler inte är samma sak som observability Här kommer åsikten som retar leverantörerna: att ha alla tre signalerna betyder inte att du har observability. Om mätvärdena ligger i ett verktyg, loggarna i ett annat och spårningarna i ett tredje, måste någon rada upp dem för hand klockan två på natten. Det är samma sak som tre arbetsböcker utan gemensam ID-kolumn. Testet är enkelt. När något oväntat går sönder: kan du ställa en ny fråga till din data utan att skicka ut ny kod? Om svaret är "vi måste lägga till loggning och driftsätta om", så har du övervakning med extra steg. Två saker gör skillnaden i praktiken: - **Kontext på varje händelse.** Varje loggrad bär ett anrops-ID, ett tjänstenamn och en version, så att du kan gruppera och filtrera senare. Det är ID-kolumnen du önskar att varje export hade. - **Detaljer sparade tillräckligt länge.** Data med hög kardinalitet (användar-ID, order-ID) är där svaren gömmer sig, och det är också den som driver upp notan. ## Verktygen folk faktiskt använder och vad var och en kostar dig Du behöver inte köpa något för att förstå idén, men marknaden är värd att känna till. [OpenTelemetry](https://opentelemetry.io/docs/concepts/observability-primer/) är den öppna standarden för att producera telemetri, inte en plats att lagra eller visa den på. Du instrumenterar en gång och skickar datan dit du vill. Grafana Cloud bygger på öppna standarder och har en gratisnivå med 10,000 aktiva mätserier och 50 GB vardera av loggar, spårningar och profiler per månad. Du kan också köra den öppna stacken själv på egna servrar, men då får du sätta ihop Prometheus, Loki och Tempo på egen hand. Datadog är det färdiga alternativet: installera agenten, få fungerande instrumentpaneler på några minuter och ha allt på ett ställe för infrastruktur, APM och loggar. Haken är faktureringen. Prissättning per värd (runt $15 per värd och månad enbart för infrastruktur) plus separata avgifter för loggar och egna mätvärden kan snabbt skena efter cirka 50 värdar, och det finns ingen permanent gratisnivå. New Relic ligger mittemellan när det gäller pris: 100 GB dataintag per månad gratis, sedan $0.40 per GB, och en fullständig plattformsanvändare ingår. Värt pengarna om du har ett litet plattformsteam och ingen lust att driva infrastruktur för din infrastruktur. Hoppa över det om du har två servrar och en utvecklare. Ett bra loggformat och formlerna ovan tar dig förvånansvärt långt. ![Golden retriever som vilar på en matta nära en skrivbordslampa en kväll](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/a1c8e7-img3.webp) ## Vad du gör på måndag om du inte är utvecklare Du kommer kanske aldrig att röra en spårning. Men tankesättet kring observability går bra att överföra till alla som rapporterar siffror för jobbet. - **Lägg till ett ID i varje export.** En kolumn du kan koppla på slår vilken smart formel som helst. - **Behåll rådatan.** Klistra inte över värden i detaljfliken. Sammanfattningar är mätvärden, rådata är loggar. - **Skriv ner vad "normalt" är.** Ett tröskelvärde du aldrig definierat kan aldrig utlösas. - **Ställ tredje frågan.** "Intäkterna sjunker" är larmet. "Var sjunker de?" är mätvärdet. "Sjunker de på grund av vilka rader?" är observability. Gör du det tar nästa konstiga summa i ditt kalkylblad tio minuter att förklara i stället för en eftermiddag. Good boy, kalkylblad. ## Snabba svar på frågorna folk faktiskt skriver Korta svar på de vanligaste följdfrågorna finns i FAQ:n nedan. Om du bara minns en sak: observability är inte en produkt du köper. Det är hur väl datan ditt system skickar ut låter dig besvara frågor du inte planerat för. ## FAQ ### Vad är observability med enkla ord? Det är hur väl du kan ta reda på vad som går fel inuti ett system genom att titta på den data det producerar, främst loggar, mätvärden och spårningar, utan att behöva ändra systemet först. ### Vad är skillnaden mellan övervakning och observability? Övervakning bevakar villkor du definierat i förväg och larmar när de bryts. Observability låter dig undersöka datan i efterhand för att besvara frågor du inte väntade dig. ### Vilka är de tre pelarna i observability? Loggar är tidsstämplade händelseposter, mätvärden är siffror som sammanfattas över tid och spårningar följer ett enda anrop genom flera tjänster. Tillsammans visar de att något är fel, ungefär var det är och i vilken detalj. ### Behöver jag specialverktyg för att komma igång med observability? Nej, inte för att lära dig idéerna. En strukturerad loggexport och ett kalkylblad räcker för frågor om felfrekvens och den långsammaste tjänsten. Verktyg som Grafana, Datadog eller New Relic blir viktiga när volymen och kraven på snabb felsökning växer. ### Vad är OpenTelemetry? OpenTelemetry är en öppen standard för att skapa och skicka telemetri, till exempel loggar, mätvärden och spårningar. Den lagrar eller visar inte datan, så du kombinerar den med en backend du väljer själv. ### Varför är observability dyrt? Kostnaden växer med datamängden och med fält med hög kardinalitet, till exempel användar- eller order-ID. Pris per värd och per signal kan staplas på varandra, så många team sätter därför regler för lagringstid och sampling.