Vad är observability? En praktisk guide för utvecklingsteam

Klockan två på natten returnerar checkout-endpointen 500-fel för ungefär en av tjugo förfrågningar, och alla dashboards är gröna. Gapet mellan "systemet säger att allt är bra" och "användarna säger att det är trasigt" är precis det som observability finns till för att stänga. Vad är observability? Det är förmågan att förstå vad ditt system gör internt genom att titta på datan det skickar ut, alltså loggar, mätvärden och spårningar. Förmågan ska vara tillräckligt god för att du ska kunna svara på frågor du inte planerade i förväg.

Den sista bisatsen är hela poängen. Allt annat i det här inlägget är detaljer.

Observability mot övervakning: frågan du inte skrev något larm för

Monitoring besvarar frågor du redan visste att ställa. Över 90 % CPU? Felfrekvens över 2 %? Växer kön? Du väljer mätvärdena, sätter gränserna, och en pipsignal går när någon av dem passeras.

Observability besvarar frågan du inte visste att ställa. Varför tar bara förfrågningar från en kund, på en viss appversion, efter en viss deploy, fyra sekunder längre? Ingen har ett larm för det, eftersom ingen förutsåg det.

De två är inte rivaler. Monitoring är larmlagret. Observability är det som gör att du kan undersöka när larmet går, eller när en kund skriver och inget larm gick alls. Om ditt enda verktyg är en vägg av färdiga dashboards har du monitoring. Om du kan dela upp produktionsdata på valfri dimension och följa en förfrågan genom flera tjänster utan att skicka ut ny kod har du observability.

De tre signalerna: mätvärden, loggar och spårningar

De flesta definitioner börjar med "tre pelare". Etiketten är lite stel, men de tre datatyperna är verkliga, och var och en är bra på ett specifikt jobb.

• Mätvärden är siffror över tid: antal förfrågningar per sekund, p95-latens, minnesanvändning. De är billiga att lagra och snabba att fråga, och bra på frågan "är något fel?". De är dåliga på frågan "vilken förfrågan, och varför?".

• Loggar är tidsstämplade poster över diskreta händelser: en betalning misslyckades, en retry startade, en feature flag slogs på. De bär detaljerna, men ostrukturerade loggar på en belastad tjänst blir snabbt en höstack.

• Spårningar följer en enskild förfrågan när den går mellan tjänster. Varje hopp är ett span med starttid, varaktighet och några attribut. En trace är det närmaste du kommer en stacktrace för ett distribuerat system.

Grafanas enkät om observability visar var team faktiskt står. Bland 1,255 utövare använde 95% mätvärden och 87% loggar, men bara 57% använde spårningar. Spårningar är den signal som mest sannolikt hjälper till med en distribuerad bugg, och den som färst team har satt upp.

Hoppa över den korta versionen som säger att mätvärden berättar vad, loggar berättar varför och spårningar berättar var. Den låter städad men faller i praktiken: en bra strukturerad logg säger ofta mer om "var" än en dåligt instrumenterad spårning.

Vad gör ett system observerbart i praktiken

Att skicka ut data är nödvändigt. Det räcker inte. Ett system är observerbart när datan har tre egenskaper.

Hög kardinalitet. Du kan filtrera på användar-ID, tenant, build-SHA, region och feature flag. Om ditt verktyg tvingar dig att föraggregera på tjänstenamn och statuskod hittar du inte den enda tenanten som är i dåligt läge.

Kontext som länkar signalerna. Ett trace-ID på varje loggrad gör att du kan hoppa från ett långsamt span till exakt de loggar det producerade. Utan den länken läser du två separata historier och gissar hur de hänger ihop.

Tillräckligt med detaljer för att vara användbart, men inte så mycket att det blir ohanterbart. Här fastnar de flesta team. I samma Grafana-enkät nämnde respondenterna mer än 100 olika verktyg, tjänster och projekt, och ett genomsnittligt team använde åtta. Kostnad var ett av de viktigaste kriterierna när man valde verktyg. Att samla in allt är lätt. Att betala för det är något man upptäcker senare.

Så här ser startpunkten ut med OpenTelemetry, den leverantörsoberoende standarden för instrumentering. Det här är ett minimalt Python-exempel som skapar ett span och lägger till de attribut du vill ha klockan två på natten:

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

Tre attribut är skillnaden mellan "checkout är långsam" och "checkout är långsam för tenant 4412 på version 3.8.1". OpenTelemetrys primer om observability förklarar koncepten bakom detta mer utförligt, och den är värd att läsa en gång, även om din leverantör sköter kopplingen.

Var observability-verktygen skiljer sig (och var de inte gör det)

Under marknadsföringen tar de flesta plattformar emot samma tre signaler. De skiljer sig i prismodell, frågekraft och hur mycket instrumentering de gör åt dig.

• Allt-i-ett-plattformar samlar mätvärden, loggar, spårningar, larm och mer. Det är bekvämt, med den avvägningen att användningsbaserade fakturor växer i takt med trafiken.

• Öppen källkod som Prometheus, Loki, Tempo och Grafana ger dig kontroll och ingen licens per värd, till priset av att du kör och finjusterar dem själv.

• OpenTelemetry-nativa backends tar emot standardformatet direkt, så ett byte av leverantör innebär inte att du måste instrumentera om varje tjänst.

Datadog är referenspunkten för allt-i-ett-kategorin: bred täckning, ett polerat gränssnitt och en faktura som förtjänar en månatlig genomgång. Värt det om du vill ha en leverantör och har budgeten. Hoppa över det om kostnadsförutsägbarhet är din viktigaste begränsning.

Grafana är det pragmatiska valet med öppen källkod. Du kan börja med dashboards ovanpå datan du redan har och lägga till loggar och spårningar när du behöver dem. Räkna med att lägga en del ingenjörstid på det.

SigNoz är byggt kring OpenTelemetry från start och lägger mätvärden, loggar och spårningar i ett gränssnitt med öppen källkod. Ett rimligt val för ett team som vill ha allt på ett ställe utan allt-i-ett-prislappen.

New Relic ligger mellan de två världarna, med en hostad plattform och en gratisnivå som är generös nog att köra en riktig utvärdering. Döm den efter om ditt eget team faktiskt kan besvara en verklig produktionsfråga i den, inte efter demon.

Inget av dessa gör dig observerbar av sig självt. Verktyget är ett frågegränssnitt. Instrumenteringen är produkten.

Det de flesta guider hoppar över: observability slutar vid kodgränsen

Här är ett gap du kommer att märka första gången du använder något av verktygen på allvar. En spårning säger att charge_card tog 3,9 sekunder och att den långsamma biten var ett anrop till payment_client. Den säger inte vad payment_client faktiskt gör, vem som skrev det, eller varför det försöker igen tre gånger utan backoff.

För det lämnar du observability-verktyget och går och läser kod. I en liten tjänst tar det tio minuter. I ett repo med 100 000 rader som fyra team äger är läsningen ofta den längsta delen av incidenten. Du vet exakt vilket span som är långsamt, och ändå lägger du en timme på att räkna ut hur koden bakom det är kopplad.

Det är överlämningsproblemet mellan runtime-data och källkod, och det är anledningen till att vi ser observability och kodförståelse som två halvor av samma arbetsflöde:

1. Observability säger var i runtime: vilken tjänst, vilket span, vilken tenant.

2. Kodförståelse säger varför i källkoden: vilken funktion, vilken retry-policy, vilken konfiguration.

Team som sluter den loopen (spannamnet pekar på en fil, filen pekar på en ägare och en förklaring) kortar tiden mellan "larmet gick" och "fixen är förstådd". Det är mest en disciplinfråga. Namnge spans efter funktioner, lägg repots sökväg i ett span-attribut och håll en kort arkitekturnotis per tjänst. En AI-assistent som kan svara på frågor om ditt repo, som "var sätts retry-policyn för betalningsanrop?", får då något konkret att förankra i.

Tre misstag som får team att tro att observability inte fungerar

Att behandla dashboards som målet. En dashboard är ett sparat svar på en gammal fråga. Team som bygger fyrtio av dem och aldrig övar ad hoc-frågor hamnar med monitoring i en snyggare förpackning. Fråga dig på varje incident: svarade vi på det från en dashboard, eller genom att utforska rådatan?

Att samplea för tidigt, eller aldrig. Att behålla 100 % av spårningarna på en belastad tjänst blir dyrt snabbt, och att behålla 1 % slumpmässigt kastar bort just den sällsynta misslyckade förfrågan du bryr dig om. Tail-based sampling, som behåller långsamma och misslyckade spårningar och kastar bort de flesta friska, är den vanliga kompromissen. Bestäm det före första fakturan, inte efter.

Att låta attributnamnen glida isär. En tjänst skriver user_id, en annan userId och en tredje uid. Nu returnerar frågan som borde omfatta alla tre bara en tredjedel av bilden. Enas om en liten namnkonvention för tenant, användare, version och flaggor, och skriv ner den i repot där folk letar.

Inget av detta är verktygsproblem. Det är vanor, och vanor är billigare att fixa än leverantörer.

Ett realistiskt sätt att börja utan att koka havet

Om du inte har något alls idag, låt bli att instrumentera allt i vecka ett. En sekvens som fungerar för team på 5 till 50 ingenjörer:

1. Välj ett kritiskt användarflöde. Checkout, registrering eller det huvudsakliga API-anropet. Inte hela systemet.

2. Lägg till strukturerade loggar med ett request-ID. JSON, en händelse per rad, med trace- eller request-ID på varje rad.

3. Instrumentera flödet med OpenTelemetry-spårningar. Ta med tenant-, version- och flaggattributen från exemplet ovan.

4. Definiera två eller tre servicenivåmål (SLO). Till exempel att 99,5 % av checkout-förfrågningarna lyckas och svarar under 800 ms. Larmen hänger på dem, inte på CPU.

5. Gå igenom en verklig incident mot datan. Hade du kunnat hitta orsaken utan ny kod? Om inte är gapet du hittade nästa instrumenteringsuppgift.

Steg fem är det som brukar hoppas över, och det är det enda som visar om du faktiskt är observerbar. Allt annat är rörledningar.

Vad vi faktiskt skulle göra

Om ditt team har under 20 ingenjörer, börja med OpenTelemetry-instrumentering och en backend vars prissättning du kan förutse. Instrumenteringen är portabel, så valet av backend går att ångra. Köp inte den största plattformen bara för att en konkurrent gjorde det.

Om du redan betalar för ett allt-i-ett-verktyg, slit inte ut det. Granska vad du ingesterar, släpp loggarna som ingen frågar efter och lägg besparingen på att instrumentera de flöden som spelar roll.

Oavsett vilken väg du väljer: skriv ner hur ett span pekar tillbaka till kod. Dashboarden visar dig branden. Någon måste ändå läsa källkoden för att ta reda på varför den började.