Vad är observability? En enkel guide för kalkylbladsfans

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.

Ö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 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.

Biscuit har redan hämtat den åt dig om formeln är den del du alltid glömmer. 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 ä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.

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.

1. Lägg till ett ID i varje export. En kolumn du kan koppla på slår vilken smart formel som helst.

2. Behåll rådatan. Klistra inte över värden i detaljfliken. Sammanfattningar är mätvärden, rådata är loggar.

3. Skriv ner vad "normalt" är. Ett tröskelvärde du aldrig definierat kan aldrig utlösas.

4. 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.