Systemet fungerar. Tills det inte gör det
Föreställ dig en webbutik där kunder kan bläddra bland produkter, lägga dem i varukorgen och gå vidare till betalning. Servern svarar, sidan öppnas och de grundläggande infrastruktursignalerna visar inga allvarliga problem. Vid första anblick verkar allt fungera som det ska.
Samtidigt kan vissa kunder inte slutföra sin beställning. För några tar betalningen flera sekunder, för andra uppstår ett fel. Det tekniska teamet får rapporter, men vet ännu inte om orsaken är betalningsgatewayen, databasen, den senaste applikationsuppdateringen eller kanske ett problem i kommunikationen mellan tjänsterna.
Det är en situation där vanlig övervakning kan visa sig otillräcklig. Den kan påvisa att antalet fel har ökat eller att svarstiden har blivit längre, men den ger inte alltid den information som behövs för att snabbt hitta orsaken.
Det är just denna lucka som observability, alltså systemets observerbarhet, fyller. Dess mål är inte bara att konstatera att applikationen beter sig felaktigt. Det handlar om att kunna analysera dess beteende, återskapa händelseförloppet och hitta källan till problemet, även när man inte tidigare förutsett ett specifikt felscenario.
Övervakning och observability - liknande mål, olika möjligheter
Övervakning och observability hänger nära ihop, men betyder inte samma sak.
Övervakning handlar om att systematiskt samla in och analysera data om applikationens och infrastrukturen tillstånd. Det gör det möjligt att följa vissa parametrar, upptäcka avvikelser från uppsatta normer och utlösa larm när en situation kräver åtgärd.
Exempel på frågor som övervakning besvarar är:
- Är servern tillgänglig?
- Vad är den genomsnittliga svarstiden för API:t?
- Överstiger antalet HTTP 500-fel den fastställda gränsen?
- Hur hög är minnes- och processoranvändningen?
- Växer kön av uppgifter snabbare än systemet hinner hantera den?
Observability går längre. Det gör det möjligt att analysera data från olika delar av systemet och koppla ihop dem i ett sammanhang som hjälper till att förstå varför ett visst beteende uppstod.
Det kan sammanfattas i tre frågor:
- Övervakning: Är något fel?
- Diagnostik: Var uppstod problemet?
- Observability: Vad hände, varför och vilken påverkan hade det på systemets drift?
Observerbarhet ersätter inte övervakning. Det är ett angreppssätt som använder övervakning och rätt förberedd telemetridata för att möjliggöra djupare analys av applikationens beteende. OpenTelemetry beskriver observability som möjligheten att ställa frågor till systemet om dess beteende utifrån signaler som loggar, metrik och distribuerade spår. <Cite ref="turn154932search0"/>
De tre pelarna i observability: loggar, metrik och spårning
Grunden för observerbarhet är tre typer av telemetridata: logs, metrics och traces. Var och en visar en annan aspekt av applikationens funktion. Först när de korreleras får man en bredare bild av situationen.
1. Loggar - vad hände i applikationen?
Loggar (logs) är strukturerade registreringar av händelser som genereras av applikationen, operativsystemet, servrar, databaser och andra delar av infrastrukturen.
De kan till exempel registrera:
- start och slut på en process,
- en användares inloggningsförsök,
- skickande av en begäran till ett externt API,
- ett fel i valideringen av data,
- en misslyckad transaktion,
- ett undantag som rapporterats av applikationen,
- en ändring av beställningens status.
En logg kan innehålla tidsstämpel, allvarlighetsnivå, tjänstens namn, meddelande, begäringsidentifierare och ytterligare attribut som beskriver händelsen.
Det är viktigt att skilja mellan textloggar och strukturerade loggar. En textpost kan till exempel se ut så här:Fel vid behandling av beställning
Ett sådant meddelande informerar om att ett problem har uppstått, men säger lite om dess sammanhang. En strukturerad logg kan däremot innehålla separata fält, såsom order-ID, operationens namn, felkod, exekveringstid och trace-ID. Tack vare detta kan data filtreras, grupperas och analyseras automatiskt.
God praxis: loggar bör utformas med tanke på senare analys, inte enbart för att lagra meddelanden. Det är värt att använda enhetlig terminologi, allvarlighetsnivåer och korrelations-ID:n som gör det möjligt att koppla samman händelser från olika komponenter.
Samtidigt kräver loggning omdöme. Att registrera varje operation i full omfattning kan generera enorma mängder data, öka lagringskostnaderna och försvåra att hitta relevant information. Lika viktigt är att loggar inte får avslöja lösenord, åtkomsttoken, betalkortsuppgifter eller annan känslig information. Man bör använda maskering, åtkomstkontroll, lämpliga lagringsperioder och säkra rutiner för databehandling.
2. Metrik - hur beter sig systemet över tid?
Metrik (metrics) är aggregerade numeriska data som beskriver systemets tillstånd, prestanda och beteende under en viss tidsperiod.
Exempel på metrik omfattar:
- antalet hanterade begäranden per sekund,
- andelen begäranden som avslutas med fel,
- API:ts svarstid,
- CPU- och minnesanvändning,
- antalet aktiva sessioner,
- längden på uppgiftskön,
- antalet avslutade transaktioner,
- väntetiden för anslutning till databasen.
Deras största fördel är möjligheten att observera trender. Ett enstaka fel kan vara en isolerad händelse, men en gradvis ökande svarstid, ett växande antal misslyckade transaktioner eller en växande uppgiftskö kan tyda på ett problem som håller på att utvecklas.
I praktiken hjälper metrik inte bara till att besvara frågan om applikationen fungerar, utan också om dess prestanda motsvarar användarnas förväntningar och affärskraven.
Särskilt användbara är svarstidspercentiler, till exempel p95 och p99. Ett medelvärde kan dölja en situation där majoriteten av användarna får svar snabbt, men en liten del upplever mycket stora fördröjningar. Percentiler visar hur lång tid det tar att hantera långsammare begäranden och hjälper till att upptäcka problem som inte syns i medelvärden.
God praxis: välj metrik som är betydelsefulla för användaren och affärsprocessen. Enbart information om processorbelastning säger inte om kunden kan lägga en beställning. Det är därför också värt att övervaka indikatorer kopplade till nyckelfunktioner, såsom betalningsframgång, orderhanteringstid eller tillgänglighet för de viktigaste operationerna.
3. Tracing - vilken väg tog begäran?
Tracing, och särskilt distributed tracing, alltså distribuerad spårning, gör det möjligt att följa vägen för en enskild begäran genom olika komponenter i systemet.
I en modern applikation kan en användaråtgärd omfatta många steg. Ett klick på knappen ”Lägg beställning” kan starta en begäran i webbläsaren, som går vidare till API:et, sedan till ordertjänsten, databasen, lagersystemet och en extern betalningsleverantör.
Om processen fördröjs kan informationen om hela API:ets svarstid i sig vara otillräcklig. Tracing gör det möjligt att bryta ned denna tid på enskilda operationer och se vilket steg som orsakar fördröjningen.
Det grundläggande elementet i ett spår (trace) är en span, alltså en registrering av en enskild operation. En span kan innehålla start- och stopptid, operationens namn, status och metadata. Sammanlänkade spans bildar ett spår som visar förloppet för hela begäran.
Till exempel:
- API:et tar emot en begäran och skickar den vidare.
- Ordertjänsten validerar uppgifterna.
- Databasen sparar beställningen.
- Lagertjänsten kontrollerar produktens tillgänglighet.
- Den externa betalningsgatewayen behandlar transaktionen.
- Applikationen returnerar resultatet till användaren.
Om hela processen tar 8 sekunder kan tracing visa att 6,5 sekunder gick åt till svar från den externa betalningsgatewayen, medan övriga operationer fungerade korrekt. Teamet får då en konkret punkt för vidare analys i stället för att börja felsökningen med slumpmässiga komponenter.
Tracing är särskilt användbart i mikroservicearkitekturer, distribuerade system, applikationer baserade på köer och lösningar som integrerar många externa tjänster. <Cite ref="turn154932search0"/>
Varningar - informationen ska nå rätt person
Telemetridata är bara användbar när den kan omsättas i handling. Därför är ett varningssystem en viktig del av observability.
Ett larm är en avisering om en händelse eller ett tillstånd som kräver uppmärksamhet. Det kan utlösas när ett tröskelvärde för en metrik överskrids, när ett visst felmönster upptäcks eller när det konstateras att en kritisk funktion i applikationen inte fungerar som förväntat.
Inte varje ökning av belastningen bör dock generera ett larm. Om systemet regelbundet hanterar hög trafik under rusningstid kommer en avisering för varje ökning av antalet begäranden att skapa informationsbrus. För många varningar leder till att de ignoreras, och därmed till att ett faktiskt allvarligt incident missas.
Det är därför värt att fastställa:
- vilka händelser som kräver omedelbar reaktion,
- vilka problem som kan analyseras i det ordinarie arbetssättet,
- vem som ansvarar för den specifika typen av varning,
- vilken information som bör ingå i aviseringen,
- vilka åtgärder som ska vidtas efter att den tagits emot.
En bra utgångspunkt är att definiera varningar utifrån påverkan på användaren och tillförlitlighetsmålen, inte enbart utifrån infrastruktursparametrar. Till exempel kan en varning om en ökande andel misslyckade betalningar vara affärsmässigt viktigare än en kortvarig topp i CPU-användning.
En varning ska leda till åtgärd. Om det inte är klart vem som ska hantera den eller vad som ska göras är den bara ytterligare ett meddelande i systemet.
Exempel från praktiken: hur hjälper observability att hitta orsaken till ett avbrott?
Anta att användare av en B2B-applikation rapporterar att genereringen av rapporter tar betydligt längre tid än vanligt. Övervakningen upptäcker en ökning av svarstiden och utlöser en varning.
Teamet börjar analysera:
- Metrik visar att problemet främst gäller rapporter som omfattar stora datamängder. Övriga funktioner fungerar normalt.
- Tracing visar att den största fördröjningen uppstår vid körningen av en databasfråga.
- Loggar innehåller detaljer om frågan, dess parametrar och information om fel, utan att avslöja känsliga data.
- Datakorelation gör det möjligt att koppla ett specifikt spår till relevanta loggposter och till förändringar som syns i metrikgraferna.
- Förändringsanalys visar att problemet uppstod efter att en ny version av rapporten infördes, vilken började köra en kostsam fråga.
Tack vare detta behöver teamet inte i blindo kontrollera hela infrastrukturen. Det kan fokusera på en specifik operation, jämföra beteendet före och efter driftsättningen och sedan optimera frågan eller rulla tillbaka förändringen.
Observability tar inte bort fel och garanterar inte att varje orsak hittas automatiskt. Det gör dock att sökområdet kan begränsas, att diagnostiden förkortas och att beslut kan baseras på data i stället för antaganden.
Datakorelation - det största värdet uppstår tillsammans
Loggar, metrik och tracing är användbara var för sig, men deras verkliga värde blir tydligt när de kan kopplas till varandra.
Föreställ dig att instrumentpanelen visar en plötslig ökning av svarstiden. Metriken visar när och i vilken omfattning problemet uppstod. Spåret visar vilka operationer som utgjorde den långsamma begäran. Loggarna gör det möjligt att kontrollera vilka händelser som inträffade i ett specifikt steg.
För att detta ska vara möjligt bör systemet konsekvent föra vidare begärans kontext mellan tjänsterna. Identifierare för trace och span kan användas för att länka loggposter till spår. Det är också viktigt att behålla konsekvent information om tjänstens namn, miljö, applikationsversion och andra attribut som beskriver datakällan.
Utan korrelation kan teamet ha tillgång till många dashboards, filer och verktyg, men ändå lägga tid på att manuellt fastställa vilka händelser som hör ihop. OpenTelemetry lyfter fram korrelation mellan loggar, spår och resurskontext som en viktig del i att bygga användbar telemetri. <Cite ref="turn154932search1"/>
OpenTelemetry - en gemensam standard för telemetridata
Införandet av observability behöver inte innebära beroende av en enda verktygsleverantör. En lösning som stödjer interoperabilitet är OpenTelemetry (OTel) - en öppen uppsättning standarder, API:er, bibliotek och verktyg för instrumentering, generering, insamling och export av telemetridata.
OpenTelemetry gör det möjligt för applikationen att sända metrik, loggar och spår i en enhetlig modell. Data kan därefter skickas till den valda observability-plattformen, som ansvarar för lagring, sökning, visualisering och analys.
En viktig del av ekosystemet är OpenTelemetry Collector. Den kan ta emot data från olika källor, bearbeta dem, berika dem med ytterligare kontext och exportera dem till konfigurerade system. På så sätt behöver applikationen inte vara direkt kopplad till varje verktyg som används för analys.
Detta tillvägagångssätt är särskilt användbart när företaget använder många tekniker, utvecklar systemarkitekturen eller vill behålla möjligheten att byta verktygsleverantör. Standarden i sig ger dock inte fullständig observability. Fortfarande krävs korrekt instrumentering, en genomtänkt strategi för datainsamling, lämpliga dashboards, varningar och rutiner för åtgärder. <Cite ref="turn154932search3"/>
När är det värt att införa observability?
Observability kan vara användbart både i stora distribuerade system och i mindre applikationer där driftstopp eller ett svårtupptäckt fel får betydande affärsmässiga konsekvenser.
Det är särskilt värt att överväga detta tillvägagångssätt när:
- applikationen består av många tjänster eller integrationer,
- problem uppstår oregelbundet och är svåra att återskapa,
- användare rapporterar fel som inte syns i standardtester,
- tiden för att diagnostisera incidenter är för lång,
- ytterligare driftsättningar leder till svårförutsägbara effekter,
- företaget utvecklar systemet och behöver data för kapacitetsplanering,
- applikationen hanterar viktiga försäljnings-, drifts- eller finansiella processer,
- teamet behöver bättre förstå externa tjänsters påverkan på hela lösningens funktion.
Det betyder dock inte att varje webbplats behöver en avancerad telemetrimiljö. I en liten, enkel tjänst kan grundläggande loggar, tillgänglighetsövervakning och några få nyckelmetrik räcka. Lösningens omfattning bör motsvara applikationens komplexitet, trafikens skala, tillförlitlighetskraven samt kostnaderna för potentiella driftstopp.
När kan observability bli för mycket av det goda?
Att införa avancerade verktyg utan ett tydligt definierat mål kan medföra fler kostnader än fördelar.
De vanligaste misstagen är:
- Att samla in allt utan en plan. Överflöd av data ökar kostnaderna och gör det svårare att hitta information som är viktig för diagnosen.
- Att inte ha frågor som systemet ska besvara. Dashboardar kan se imponerande ut, men ändå inte hjälpa till att lösa verkliga problem.
- Att larma om varje avvikelse. För många aviseringar leder till alarmtrötthet och ökar risken att en incident förbises.
- Brist på ansvar för åtgärd. Även ett väl upptäckt problem kan pågå länge om ingen vet vem som ska ta hand om det.
- Brist på dataskydd. Telemetri kan innehålla känslig information, användaridentifierare eller operativa data som kräver begränsad åtkomst och lämplig lagringstid.
- Att ignorera kostnaden för instrumentering. Insamling av detaljerade spår och loggar i stor skala kan påverka applikationens prestanda och generera betydande kostnader för lagring och bearbetning.
- Att behandla verktyget som en färdig lösning. Att bara installera en plattform säkerställer varken korrekt instrumentering eller en effektiv diagnosprocess.
Observability kräver därför inte bara teknik, utan också organisatoriska beslut: vilka data som behövs, vem som analyserar dem, hur teamet reagerar och på vilket sätt insikter från incidenter omsätts i förändringar i systemet.
Hur planerar man ett införande av observability?
Det säkraste är att utveckla observerbarheten stegvis, med start i de processer och funktioner vars fel har störst påverkan på användare och verksamhet.
1. Identifiera de viktigaste affärsprocesserna
Identifiera de viktigaste operationerna, såsom inloggning, orderläggning, betalningar, dokumentgenerering eller datasynkronisering. Det är de som bör vara utgångspunkten för att definiera vad korrekt drift av applikationen innebär.
2. Fastställ tillförlitlighetsmått
Välj metrik som speglar användarupplevelsen, till exempel tillgänglighet för nyckelfunktioner, svarstid eller andelen operationer som slutförs framgångsrikt. För viktiga tjänster kan man definiera SLI (Service Level Indicator), det vill säga en indikator för tjänstenivå, samt SLO (Service Level Objective), alltså målet för denna indikator.
3. Säkerställ strukturerade loggar
Enhetliggör loggformat, allvarlighetsnivåer och grundläggande attribut. Se till att korrelationsidentifierare finns och att det finns en policy för att radera eller maskera känsliga data. Loggarna ska vara läsbara för teamet och möjliga att bearbeta med verktyg.
4. Lägg till tracing i kritiska flöden
Börja med processer som omfattar många tjänster, databaser eller externa integrationer. Följ begärans väg genom systemet och se till att kontexten förs vidare mellan komponenterna.
5. Bygg dashboardar kring specifika frågor
I stället för att skapa en enda enorm panel, förbered vyer som svarar mot olika rollers behov. Det tekniska teamet kan behöva information om fel och fördröjningar, medan produktägaren behöver data om hur effektiva de viktigaste processerna är och hur driftstopp påverkar användarna.
6. Utforma larm och åtgärdsrutiner
Fastställ tröskelvärden, prioriteringar, ansvariga personer och instruktioner för hur man ska agera. Ett larm bör innehålla kontext som hjälper till att snabbt påbörja diagnosen, inte bara informera om att ett värde överskridits.
7. Testa observability
Kontrollera om teamet kan hitta orsaken till ett exempel-fel utifrån tillgängliga data. Man kan genomföra kontrollerade feltester i en testmiljö eller övningar i incidenthantering. Det är också värt att verifiera om larmen utlöses när de ska.
8. Utveckla lösningen utifrån incidenter
Efter varje betydande problem är det värt att kontrollera vilken information som fanns tillgänglig, vad som saknades och hur instrumentering, larmning eller rutiner kan förbättras. Observability är inte ett engångsprojekt, utan en process för att ständigt förbättra kunskapen om hur systemet fungerar.
Kostnader och säkerhet - två aspekter som inte får förbises
Telemetridata har ett pris. Kostnader kan uppstå genom instrumentering, överföring, indexering, lagring, retention och dataanalys. I system med hög trafik kan det vara särskilt dyrt att samla in alla spår eller mycket detaljerade loggar.
Därför är det klokt att använda retention anpassad efter behov, datafiltrering, spårsamplig (sampling) och olika detaljnivåer beroende på miljö. Till exempel kan ett produktionssystem samla fullständiga data för fel och utvalda kritiska operationer, medan en del lyckade begäranden samplas för att begränsa volymen.
Lika viktigt är dataskyddet. Loggar och spår kan omedvetet innehålla personuppgifter, sessionsidentifierare, delar av frågor eller information om infrastrukturen. Åtkomst till telemetri bör begränsas, onödiga data ska tas bort, känslig information maskeras och lagringsperioder kontrolleras. Det är också värt att behandla observability-system som en del av produktionsmiljön, som i sig kräver skydd, säkerhetskopior och behörighetskontroll.
Observability som ett ledningsverktyg, inte bara diagnostik
Även om observerbarhet oftast förknippas med utvecklare, DevOps och administratörer, sträcker sig dess värde långt utanför IT-området.
Data om svarstid, fel, tillgänglighet och processernas effektivitet kan hjälpa företaget att förstå vilka delar av tekniken som stödjer verksamheten och vilka som begränsar den. De gör det möjligt att identifiera återkommande problem, bedöma konsekvenserna av förändringar och planera utveckling utifrån systemets faktiska beteende.
Om till exempel ordersystemet regelbundet blir långsammare vid vissa tider, kan telemetridata hjälpa till att avgöra om det behövs optimering av frågor, en ändrad metod för att bearbeta uppgifter eller utbyggnad av infrastrukturen. I stället för att investera i ytterligare resurser utifrån intuition kan företaget först identifiera den verkliga flaskhalsen.
Observability stödjer också analysen av effekterna av driftsättningar. En jämförelse av metrik, spår och loggar före och efter en förändring gör det snabbare att upptäcka regressioner och bedöma om uppdateringen gav önskad effekt.
Man bör dock inte likställa observability med automatiskt beslutsfattande. Data visar systemets beteende, men tolkningen av dem kräver kunskap om arkitekturen, affärsprocesserna och kontexten i det aktuella incidenten.
Begreppsordlista
- Observability (observationbarhet) - förmågan att förstå ett systems interna beteende utifrån de data det avger.
- Monitoring - kontinuerlig övervakning av utvalda parametrar och upptäckt av definierade tillstånd som kräver uppmärksamhet.
- Telemetry (telemetri) - data som samlas in och skickas från applikationen och infrastrukturen för att analysera deras funktion.
- Logs (loggar) - registreringar av händelser som förekommer i applikationen eller infrastrukturen.
- Metrics (metrik) - numeriska mätningar av systemets tillstånd, prestanda eller beteende över tid.
- Tracing - spårning av en operations förlopp genom applikationens komponenter.
- Distributed tracing - spårning av en enskild begäran i ett system som består av många tjänster eller processer.
- Span - en registrering av en enskild operation som utgör en del av ett spår.
- Trace - en uppsättning relaterade span som visar operationens förlopp.
- Alert - ett meddelande om ett upptäckt tillstånd eller en händelse som kräver åtgärd.
- SLI - en indikator som mäter en specifik aspekt av en tjänsts funktion.
- SLO - ett definierat mål för en vald tillförlitlighetsindikator.
- Sampling - en teknik för att begränsa mängden insamlade telemetridata genom att välja en representativ del av händelserna.
- OpenTelemetry - en öppen uppsättning standarder och verktyg som stöder instrumentering och export av telemetridata.
Sammanfattning
Ett applikationsfel börjar inte alltid med en otillgänglig server eller ett felmeddelande. Ibland fungerar systemet formellt sett, men en viktig funktion blir för långsam, en del transaktioner lyckas inte eller en integration fallerar bara under vissa förhållanden.
Monitoring hjälper till att upptäcka avvikelser. Observability gör det möjligt att förstå vad som ledde till dem och vilken påverkan de hade på applikationens funktion. Loggar, metrik, tracing och väl utformade alertar skapar tillsammans en grund för effektivare diagnostik, medveten utveckling och minskad operativ risk.
Det handlar inte om att samla in så mycket data som möjligt eller att skapa de mest avancerade dashboarderna. Det handlar om att, när ett problem uppstår, inte bara fråga: ”Fungerar systemet?”, utan kunna fastställa: ”Vad hände egentligen i systemet, varför och vad bör vi göra härnäst?”
En mogen applikation är inte bara en som fungerar. Det är också en vars beteende kan förstås, diagnostiseras och förbättras.
