Vad är observability?

Observability är ett ord som blivit allt vanligare i takt med att system blivit mer komplexa och uppbyggda av många samverkande delar. Det handlar om en enkel men avgörande sak: att kunna se in i sitt eget system och förstå varför det beter sig som det gör. Här är vad begreppet betyder och varför det spelar roll för dig som beställare.

Definitionen

Observability är förmågan att utifrån den information ett system lämnar ifrån sig – loggar, mätvärden och spårningar – förstå varför det beter sig som det gör, inte bara konstatera att något är fel. Ett system med god observability är genomskinligt: när något händer går det att följa spåren och reda ut orsaken.

Namnet kommer av att systemet är observerbart, alltså möjligt att se in i. Ju mer och ju bättre information det lämnar om sitt inre tillstånd, desto lättare är det att förstå vad som pågår. Motsatsen är en svart låda som fungerar tills den inte gör det, utan att någon kan säga varför.

De tre signaltyperna

Observability vilar på tre sorters signaler, och de kompletterar varandra.

• Loggar är detaljerade textnoteringar om vad som hänt, händelse för händelse. Man kan se dem som systemets dagbok: en löpande rad av “det här inträffade, vid den här tidpunkten, i det här sammanhanget”.
• Metrics, alltså mätvärden, är siffror över tid – svarstider, antal förfrågningar, andel fel per minut. De visar trender och gör det tydligt när något avviker från det normala.
• Traces, eller spårningar, följer en enskild förfrågan hela vägen genom systemets olika delar. De visar var tiden tog vägen och i vilket steg det stannade upp, vilket är ovärderligt när många komponenter samverkar.

Var för sig ger de bitar av bilden. Tillsammans gör de systemet begripligt.

Skillnaden mot klassisk övervakning

Här ligger en distinktion som är lätt att missa men viktig att förstå. Traditionell övervakning svarar på frågor man ställt i förväg. Man bestämmer att ett larm ska gå om en server slutar svara eller om felkvoten passerar en viss nivå – och sedan vaktar systemet just de kända gränserna. Det fungerar utmärkt för problem man kan förutse.

Observability handlar om något mer: att kunna ställa nya frågor i efterhand, om problem ingen tänkt på i förväg. När ett oväntat fel dyker upp – något som aldrig hänt förr – räcker det inte med förutbestämda larm. Då behöver man kunna gräva i loggar, mätvärden och spårningar för att förstå vad som faktiskt hände. Kort sagt: övervakning ser de kända felen, observability hjälper dig förstå de okända. De två utesluter inte varandra, utan hör ihop.

Ett konkret scenario

Tänk att kunder plötsligt börjar klaga på att en tjänst är långsam, fast ingenting är helt nere. Ett larm har inte gått, för ingen server har slutat svara – allt ser vid en första anblick normalt ut.

Med god observability börjar felsökningen ändå direkt. Mätvärdena visar att svarstiderna krupit uppåt den senaste timmen. En spårning av en enskild förfrågan avslöjar att tiden går åt i ett anrop till en extern tjänst. Loggarna bekräftar att just den tjänsten svarar trögt. Inom minuter vet teamet var problemet sitter och kan agera. Utan observability hade samma utredning börjat med rena gissningar, och avbrottet blivit långt mycket längre.

Beställarnyttan: kortare avbrott

Det scenariot är hela poängen. När något går fel är den dyra tiden inte reparationen i sig, utan tiden det tar att förstå vad som hänt. Ett system som är svårt att se in i tvingar teamet att gissa sig fram, och varje gissning kostar minuter eller timmar av driftstopp.

God observability vänder på det: felsökningen börjar med svar i stället för spekulation, och tjänsten är uppe igen snabbare. För en verksamhet där driftstopp betyder förlorade intäkter eller skadat förtroende är det en av de mest lönsamma egenskaperna ett system kan ha. Vi på Weapp bygger observability i lösningarna vi driftar, just för att det billigaste avbrottet är det som är över snabbast. Vill ni veta hur väl ni kan se in i era system i dag, hör av er.