Observability

Observability er evnen til at forstå en applikations interne tilstand alene ud fra de signaler, den udsender. Begrebet kommer oprindeligt fra control theory og blev introduceret i softwareverdenen som en udvidelse af traditionel monitoring. Hvor monitoring svarer på "kører systemet?", svarer observability på "hvorfor opfører systemet sig sådan?".

De tre søjler i observability er metrics, logs og traces. Metrics er numeriske tidsserier: request rate, fejlrate, latency, ressourceforbrug. Logs er diskrete hændelser med kontekst: en bruger loggede ind, en database-query timed out. Traces følger en enkelt request gennem flere services og viser præcis hvor tid bliver brugt og hvor fejl opstår. Tilsammen giver de tre signaler det fundament, der gør debugging af distribuerede systemer muligt.

OpenTelemetry er den fremvoksende standard for instrumentering. Projektet er resultatet af en sammenlægning af OpenTracing og OpenCensus og er nu et CNCF-projekt. OpenTelemetry tilbyder SDK'er til alle store programmeringssprog, en fælles datamodel for de tre signaler, og en collector der modtager telemetri fra applikationer og videresender den til backends. Ved at instrumentere mod OpenTelemetry undgår teams vendor lock-in: backend kan skiftes uden at omskrive instrumenteringskoden.

Cardinality er en kritisk begrænsning i metrics. Hver unik kombination af label-værdier skaber en separat tidsserie, og databaser som Prometheus håndterer dårligt millioner af serier. Høj-cardinality data som user IDs eller request IDs hører ikke hjemme i metrics, men i logs og traces. En klassisk fejl er at tagge metrics med en attribute der har tusindvis af værdier, hvilket eksploderer storage og query-tid.

Distribueret tracing løser det største problem i microservices: at finde ud af hvor en langsom eller fejlende request fløj hen. En trace består af spans, der hver repræsenterer en enhed af arbejde (et HTTP-kald, en database-query, en kø-operation). Spans linkes via en trace ID der propageres gennem headers eller messaging-protokoller. Backends som Jaeger, Tempo, Honeycomb og Lightstep visualiserer traces som vandfaldsdiagrammer der viser præcis hvor flaskehalse opstår.

Struktureret logging er afgørende for at gøre logs søgbare. JSON-formaterede logs med konsistente felter (level, timestamp, service, trace_id, message) lader log-aggregators som Loki, Elasticsearch eller Splunk filtrere og korrelere på tværs af services. Korrelation mellem logs og traces sker via det fælles trace_id: en fejl-log i én service kan matches direkte til den trace der udløste den.

SLI'er (Service Level Indicators) bygges ovenpå observability-dataen og udgør grundlaget for Site Reliability Engineering. En SLI er en målbar egenskab af tjenesten: f.eks. "andel af requests der returnerer 200 OK inden for 200ms". SLO'er sætter mål for SLI'erne, og error budgets afleder den acceptable fejlmængde. Uden gode metrics er hele SLO-frameworket værdiløst, fordi SLI'erne ikke kan beregnes pålideligt.

Observability-driven development er en praksis hvor instrumentering tænkes ind fra start. I stedet for at tilføje logs og metrics efter en incident, instrumenteres koden så der altid kan svares på spørgsmål om dens adfærd. Det indebærer at tilføje attributes til spans der beskriver forretningskonteksten (customer_tier, feature_flag), strukturere logs så de kan parses automatisk, og emittere custom metrics for forretningsmæssige hændelser. Resultatet er et system hvor nye spørgsmål kan besvares uden ny kode.

Cost management bliver en central udfordring efterhånden som telemetri-volumen vokser. SaaS-leverandører som Datadog, New Relic og Splunk kan blive ekstremt dyre i skala (hundredvis af tusind kroner per måned er ikke usædvanligt). Strategier til omkostningsreduktion inkluderer sampling af traces (gem kun 1-10% af traces i normal drift, men 100% af fejlende), aggressive retention policies på metrics (rå data i 14 dage, downsampled i et år), og log levels der filtrerer DEBUG-logs i produktion. Self-hosted alternativer som Prometheus, Grafana, Loki og Tempo tilbyder fuld kontrol over omkostningerne på bekostning af driftsbyrde.

Best practices for moderne observability inkluderer at bruge OpenTelemetry som standard, korrelere alle tre signaler via trace ID, bygge SLO'er på SLI'er der reflekterer brugeroplevelsen ikke ressourcer, alerte på symptomer ikke årsager, og investere i dashboards der besvarer de mest stillede spørgsmål om systemet. Et team med god observability kan diagnosticere produktionsproblemer på minutter, hvor et team uden bruger timer eller dage på samme opgave.