{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/observability","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/observability/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/observability/"},"term":{"en":"Observability","da":"Observerbarhed"},"aka":{"en":["o11y"],"da":[]},"domain":["platform"],"cluster":"observability","layer":"observability","status":"current","summary":{"en":"How well you can work out what is going on inside a running system just from the signals it sends out.","da":"Hvor godt man kan regne ud, hvad der foregår inde i et kørende system, alene ud fra de signaler, det sender ud."},"body":{"formal":{"en":"A property of a system, reached by having it send out rich logs, metrics and traces, that lets people answer new questions about its inner state, including ones nobody thought of in advance, without changing the system.","da":"En egenskab ved et system, opnået ved at lade det udsende detaljerede logs, metrikker og sporinger, som gør det muligt at besvare nye spørgsmål om dets indre tilstand, også dem ingen havde tænkt på på forhånd, uden at ændre systemet."},"plain":{"en":"Like a doctor who can find out why you are ill from blood tests, scans and your own story, not just from whether you have a fever.","da":"Som en læge, der kan finde ud af, hvorfor du er syg, ud fra blodprøver, scanninger og din egen forklaring, ikke kun ud fra om du har feber."},"inPractice":{"en":"Checkout in a Danish web shop is slow for some customers only; by linking the traces and logs of those orders, a developer sees they all use one payment provider whose service answers slowly.","da":"I en dansk webshop er betalingen kun langsom for nogle kunder; ved at koble sporinger og logs for netop de ordrer ser en udvikler, at de alle bruger samme betalingsudbyder, hvis tjeneste svarer langsomt."},"whyItMatters":{"en":"Modern systems fail in new and strange ways, and during an incident you need to find the cause quickly without waiting to add new checks.","da":"Moderne systemer fejler på nye og mærkelige måder, og under en hændelse skal man hurtigt finde årsagen uden at vente på at tilføje nye målinger."}},"deepDive":{"en":"The term comes from control theory, where Rudolf Kálmán defined in 1960 that a linear system is observable if its internal state can be reconstructed from its outputs over a finite time. Software engineering borrowed the word in the mid-2010s, notably through Twitter's observability team and later Honeycomb, to describe the ability to explain arbitrary system behaviour from emitted telemetry without shipping new code. The distinction from monitoring is that monitoring covers known unknowns with predefined checks, whereas observability targets unknown unknowns in distributed systems whose failure modes cannot all be anticipated.\n\nThe popular three pillars framing (logs, metrics, traces) describes data types rather than the property itself, and is criticised for encouraging three disconnected silos. What makes a system observable in practice is correlation and dimensionality: every event carries the same identifiers (trace ID, service.name, deployment version, tenant, region) so an investigator can pivot from a latency spike on a metric to exemplar traces to the log lines of one span. A related approach stores wide structured events, one record per unit of work with dozens or hundreds of fields, and derives metrics from them at query time, which preserves high-cardinality fields such as customer ID that a pre-aggregated metric store would reject.\n\nOpenTelemetry, a CNCF project formed in 2019 from OpenTracing and OpenCensus, provides the vendor-neutral layer: language APIs and SDKs, semantic conventions for attribute names, the OTLP wire protocol and the Collector for receiving, processing and exporting telemetry. Its signals are traces, metrics, logs and baggage, with profiling being added as a further signal. Decoupling instrumentation from backend means the storage and analysis vendor can be changed without re-instrumenting code.\n\nObservability has real costs and failure modes. Telemetry volume grows with traffic and cardinality, so sampling, retention tiers and attribute budgets are engineering decisions with trade-offs in fidelity. Telemetry frequently contains personal data (IP addresses, user IDs, query parameters), which brings it within GDPR obligations on data minimisation and retention. Instrumentation that exists but is not queryable during an incident, because nobody knows the schema or the tooling is too slow, delivers little. Service level objectives give observability a purpose by defining which user-facing behaviour matters, and the same correlated data supports security investigation and threat hunting.","da":"Begrebet stammer fra reguleringsteknik, hvor Rudolf Kálmán i 1960 definerede, at et lineært system er observerbart, hvis dets indre tilstand kan rekonstrueres ud fra dets output over en endelig tid. Softwareverdenen lånte ordet i midten af 2010'erne, især via Twitters observability-team og senere Honeycomb, om evnen til at forklare vilkårlig systemadfærd ud fra udsendt telemetri uden at udrulle ny kode. Forskellen til overvågning er, at overvågning dækker kendte ukendte med foruddefinerede tjek, mens observerbarhed sigter mod ukendte ukendte i distribuerede systemer, hvis fejltyper ikke alle kan forudses.\n\nDen populære fremstilling med tre søjler (logs, metrikker, sporinger) beskriver datatyper frem for selve egenskaben og kritiseres for at fremme tre adskilte siloer. Det, der i praksis gør et system observerbart, er korrelation og dimensionalitet: hver hændelse bærer de samme identifikatorer (trace-ID, service.name, deploymentversion, tenant, region), så den, der undersøger, kan springe fra en latensspids i en metrik til exemplar-sporinger og videre til loglinjerne for ét span. En beslægtet tilgang gemmer brede strukturerede hændelser, én post pr. arbejdsenhed med snesevis eller hundredvis af felter, og afleder metrikker fra dem på forespørgselstidspunktet, hvilket bevarer felter med høj kardinalitet som kunde-ID, som et lager med forhåndsaggregerede metrikker ville afvise.\n\nOpenTelemetry, et CNCF-projekt dannet i 2019 ud fra OpenTracing og OpenCensus, udgør det leverandørneutrale lag: API'er og SDK'er til programmeringssprogene, semantiske konventioner for attributnavne, wire-protokollen OTLP og Collectoren til at modtage, behandle og eksportere telemetri. Signalerne er traces, metrics, logs og baggage, og profilering er ved at blive tilføjet som endnu et signal. Når instrumenteringen er afkoblet fra backenden, kan leverandøren af lager og analyse skiftes uden at instrumentere koden igen.\n\nObserverbarhed har reelle omkostninger og fejltyper. Mængden af telemetri vokser med trafik og kardinalitet, så sampling, opbevaringsniveauer og attributbudgetter er tekniske beslutninger med afvejninger i detaljegrad. Telemetri indeholder ofte personoplysninger (IP-adresser, bruger-ID'er, forespørgselsparametre), hvilket bringer den ind under databeskyttelsesforordningens krav om dataminimering og opbevaringsbegrænsning. Instrumentering, der findes, men ikke kan forespørges under en hændelse, fordi ingen kender skemaet, eller værktøjet er for langsomt, giver kun lidt værdi. Serviceniveaumål giver observerbarheden et formål ved at fastlægge, hvilken brugervendt adfærd der betyder noget, og de samme korrelerede data understøtter sikkerhedsundersøgelser og threat hunting."},"edges":[{"type":"requires","to":"cs/log","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/service-level-objective","confidence":"high","strength":"normal"}],"depth":1,"sources":[{"title":"OpenTelemetry - Observability primer","url":"https://opentelemetry.io/docs/concepts/observability-primer/","tier":"official-doc","publisher":"OpenTelemetry (CNCF)"}],"draft":true}