Vad är observability? Så skiljer den sig från monitoring

Vad är observability? Det är förmågan att förklara varför ditt system beter sig fel, enbart med hjälp av telemetrin det redan skickar ut, även för fel som ingen förutsåg. Monitoring säger att checkout-latensen passerade 800 ms. Observability låter dig fråga vilken kund, vilket beroende och vilken deploy som orsakade det, utan att skicka ny kod klockan tre på natten för att ta reda på det.

Scenen gör skillnaden konkret. Larmet går: p99 på betalnings-API:et har gått från 180 ms till 1,4 sekunder. Dashboarden är grön på CPU, minne och felfrekvens. Varje förbyggd panel säger att tjänsten mår bra, och varje kund säger motsatsen. Det du gör under de närmaste tio minuterna är hela ämnet för den här artikeln.

Varför spelar definitionen roll före verktygen?

Begreppet kommer från reglerteknik: ett system är observerbart om du kan sluta dig till dess inre tillstånd utifrån dess yttre utsignaler. Mjukvarubranschen lånade begreppet, och sedan sträckte leverantörerna ut det tills det betydde "en dashboardprodukt". Strunta i den utsträckningen.

Den arbetsdefinition som är användbar för ett ingenjörsteam är smalare. Ett system är observerbart när du kan ställa en ny fråga om sitt beteende, i produktion, utan att driftsätta ny instrumentering. Ordet som spelar roll är "ny". Ett tröskelvärde i ett larm svarar på en fråga som någon skrev ner förra kvartalet. Ett observerbart system svarar på den du ställer just nu.

Det här är inget renhetstest. Ingen har ett helt observerbart system, och målet är inte en poäng. Målet är en kortare väg från "något är fel" till "det här är ändringen som orsakade det". Mean time to detect och mean time to understand är olika tal, och de flesta team följer bara det första.

Hur skiljer sig observability från monitoring?

Monitoring är en uppsättning kontroller mot felmoder du redan känner till. CPU över 90 procent i fem minuter, felfrekvens över 1 procent, kölängd över 10 000. Den är billig, pålitlig, och du behöver den fortfarande. Observability ersätter den inte.

Skillnaden syns när felet är nytt. Monitoring byggs av dina tidigare incidenter. Observability byggs för nästa, som per definition du ännu inte har sett.

Ett användbart test: titta på dina tre senaste incidenter och fråga hur grundorsaken hittades.

• Om någon läste en förbyggd dashboard och svaret stod där, gjorde monitoringen sitt jobb.

• Om någon sökte i loggar på sex värdar, gissade en hypotes, lade till en loggrad och deployade om för att bekräfta den, var det ett gap i observability.

• Om det verkliga svaret kom från en kunds skärmdump har du båda problemen.

Diskussionen om huruvida de två är rivaler är onödig. De är lager. Monitoring är brandlarmet. Observability är förmågan att gå igenom huset efteråt och räkna ut vilken krets som startade branden.

Vilka är de tre signalerna, och var brister var och en?

Loggar, metrics och traces är den vanliga trion. Var och en besvarar en annan fråga, och var och en har en felmod som leverantörernas guider brukar hoppa över.

Metrics är numeriska mätvärden som aggregeras över tid: anropsfrekvens, felfrekvens, latenspercentiler, mättnad. De är billiga att lagra och snabba att söka i, och därför ligger larmen där. Felmoden är aggregering. Ett p99 på 1,4 sekunder säger att något är långsamt. Det kan inte säga att varje långsam förfrågan tillhör en enda kund på en enda shard.

Loggar är tidsstämplade poster över diskreta händelser. De bär mest detalj och minst struktur, om du inte tvingar fram struktur. Felmoden är volym och kostnad. Ostrukturerade loggar går bara att söka i för den som redan vet vilken sträng som ska letas efter, vilket gör dem till ett monitoringverktyg i felsökningskläder.

Traces följer en enskild förfrågan över tjänstegränserna, med ett span för varje hopp och dess tidsåtgång. De är den enda signalen som visar förfrågans form: det här anropet väntade 900 ms på ett nedströmsberoende som försökte igen tre gånger. Felmoden är täckning. En tjänst som tappar trace-kontexten bryter kedjan, och en trace med ett hål i sig är värre än användbar eftersom den ser auktoritativ ut.

Att ha alla tre är inte detsamma som att vara observerbar. Poängen är korrelation. Du måste kunna gå från en topp i en metric till de traces som bidrog till den, och från en trace till loggarna för just den förfrågan. Om de tre ligger i separata verktyg utan gemensam identifierare har du tre monitoringsystem och en ingenjör som fungerar som limmet mellan dem.

Varför avgör kardinalitet om du kan felsöka något alls?

Kardinalitet är antalet distinkta värden ett fält kan ta. status_code har kanske tjugo. customer_id har hundratusentals. request_id har ett per förfrågan.

De fält du mest behöver under en incident är de med hög kardinalitet. "Vilken kund är drabbad" är en fråga om customer_id. "Vilket bygge serverar de långsamma förfrågningarna" är en fråga om deploy_version. Om din lagringsmodell straffar fält med hög kardinalitet, antingen genom att prissätta dem per unik serie eller genom att tyst kasta dem, kommer du inte kunna ställa frågan som knäcker incidenten.

Här går den verkliga arkitektoniska gränsen mellan en uppsättning med enbart metrics och en observerbar. Förhandsaggregerade metrics kastar bort de dimensioner du kommer att vilja ha senare. Breda, strukturerade händelser behåller dem, och du skär i dem i efterhand.

Så här kan en användbar händelse se ut i kanten av en tjänst. En strukturerad post per förfrågan, med tillräckligt med kontext för att kunna skära i den på allt du senare kommer att bry dig om:

logger.info("request.completed", {
  trace_id: span.traceId,
  route: "/v1/payments",
  customer_id: ctx.customerId,
  deploy_version: process.env.BUILD_SHA,
  flag_variant: flags.get("new-ledger-path"),
  db_ms: timings.db,
  upstream_ms: timings.upstream,
  status: res.statusCode,
  duration_ms: elapsed,
});

Lägg märke till feature flag-varianten där. Ungefär hälften av incidenterna i publicerade post-mortems börjar med en ändring, och en utvärdering av en flagga är en ändring. Om varianten inte finns på händelsen kan du inte fråga om de långsamma förfrågningarna är de som går den nya vägen.

Hur ser en incident ut med och utan det?

Ta betalningsscenariot igen. Samma larm, samma 1,4 sekunder i p99.

Utan observability ser loopen ut så här: öppna tjänstens dashboard, hitta ingenting, öppna databasdashboarden, hitta ingenting, fråga i incidentkanalen om något deployats. Någon minns en konfigurationsändring. Någon annan håller inte med. Fyrtio minuter senare återställer du den senaste deployen för att se om det hjälper. Det gör det inte, eftersom orsaken var en flaggutrullning till en delmängd av kunderna.

Med observability ser loopen i stället ut så här: gruppera de långsamma förfrågningarna efter flag_variant och se att 100 procent av dem ligger på new-ledger-path. Gruppera efter customer_id och se att tre stora kunder står för större delen av volymen. Öppna en trace och se hur ledger-anropet vecklas ut i 40 sekventiella frågor. Total tid: några minuter. Du stänger av flaggan, inte deployen.

Lägg märke till vad den andra loopen inte behövde. Den behövde ingen förberedd dashboard. Den behövde inte att någon i förväg förutsåg "flaggvariant" som en intressant dimension. Den behövde att datan fanns där, bred och sökbar.

Det är Honeycomb-argumentet i ett stycke, och det håller. Det den inte säger är att det är gratis.

Vad kostar det, och vem bör hoppa över den dyra varianten?

Telemetri är ett datavolymproblem innan det blir ett verktygsproblem. Enligt Grafana Labs observability-undersökning 2025 med 1 255 utövare kör en genomsnittlig organisation åtta olika observabilityverktyg, och kostnad är det kriterium som nämns oftast när nya verktyg väljs. De två fakta hänger ihop. Team samlar på sig verktyg eftersom varje ett löser en skiva, och betalar sedan för överlappande inmatning i alla.

Praktiska regler som håller för de flesta teamstorlekar:

• Instrumentera med OpenTelemetry, inte med en proprietär agent. Collectorn ger dig en plats att sampla, filtrera och routa. Byte av backend blir då en konfigurationsändring i stället för ett ominstrumenteringsprojekt.

• Sampla traces med eftertanke. Behåll varje fel och varje långsam förfrågan, och sampla de friska snabba. Huvudbaserad sampling på en platt 1 procent kastar bort exakt den trace du behöver.

• Lägg struktur på loggar vid skrivning. Att tolka fri text vid sökning är det dyra sättet att få fram fält.

• Sätt en retentionspolicy per signal. Metrics i ett år, breda händelser i två veckor, debuggloggar i tre dagar. Ingen har någonsin behövt förra kvartalets debuggloggar.

Hoppa över helplattformsvarianten om du kör en handfull tjänster och en enda on-call-rotation. Ett litet team får större delen av nyttan av strukturerade loggar, RED-metrics och traces på de två eller tre heta stigarna. Det dyra, allt-i-ett-avtalet lönar sig när du har så många tjänster att ingen håller hela topologin i huvudet, vilket i vår erfarenhet är någonstans över 30 eller 40 tjänster.

Vilka verktyg är värda att titta på?

Valet av verktyg beror på hur mycket du vill köra själv, hur din kardinalitet ser ut och vad din räkning tål. En kort, opinionsstyrd genomgång:

Datadog är det bredaste kommersiella alternativet: metrics, loggar, traces och profilering under samma tak, med stark korrelation mellan dem. Priset för den integrationen är en räkning som växer med antalet hostar, egna metrics och inmatad loggvolym. Värt det när du vill ha en leverantör och har budgeten för det. Kontrollera raden för egna metrics innan du binder dig.

Grafana är standardvalet när du vill ha öppna komponenter som du kan self-hosta eller köpa som en managed stack. Den fungerar bra med Prometheus-liknande metrics och OpenTelemetry-pipelines. Avvägningen är driften: du äger mer av sammansättningen, och sprawl-siffran från undersökningen ovan gäller även dig.

SigNoz är ett alternativ med öppen källkod och OpenTelemetry som grund, som lägger loggar, metrics och traces i ett gemensamt datalager. Det spelar roll för korrelationspoängen ovan, eftersom ett delat lager gör hoppet från metric till trace till logg till en fråga i stället för ett flikbyte. Rimligt för team som vill self-hosta utan att sy ihop fyra projekt.

Better Stack kombinerar uptime-övervakning, incidentlarm och logghantering till ett pris som riktar sig mot mindre team. Det är ett förnuftigt första steg om du går från "vi får reda på det från kunderna" till något strukturerat, och mindre lämpat för en stor servicemesh med tunga krav på traces.

Hur börjar du utan att koka havet?

Börja inte med en verktygsutvärdering. Börja med dina tre senaste incidenter och en ärlig fråga: vad önskade vi att vi hade kunnat fråga?

En sekvens som fungerar för ett team på 50 till 200 ingenjörer:

1. Välj en kritisk förfrågningsstig och instrumentera den från början till slut med OpenTelemetry. Checkout, inloggning, vad som än väcker dig klockan tre på natten.

2. Skicka en bred strukturerad händelse per förfrågan vid tjänstens kant, med kund, version, flaggvarianter och nedströmstider.

3. Definiera en SLO på den stigen och larma på burn rate, inte på råa tröskelvärden. Burn rate-larm pagear dig för användarpåverkan, och telemetrin från steg 2 säger varför.

4. Kör en game day. Injicera ett fel du inte har larmat på och se hur lång tid det tar för någon som inte skrev koden att hitta det. Det talet är din baslinje.

5. Expandera utåt en stig i taget, först när den första stigen har betalat sig i en verklig incident.

Observability köps som en plattform och tas i bruk som en vana. Vanan är att fråga "vad skulle jag behöva veta för att förklara det här?" vid kodgranskningen, före incidenten i stället för under den.

Titta på din senaste incidentgenomgång. Hitta meningen som säger "vi lade sedan till loggning för att bekräfta". Varje sådan är en fråga ditt system inte kunde besvara i produktion. Hur många har du dokumenterade, och vilka av dem skulle fortfarande vara obesvarbara idag?