{"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/metrics","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/metrics/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/metrics/"},"term":{"en":"Metrics","da":"Metrikker"},"aka":{"en":["metric","time series"],"da":["metrik","måletal"]},"domain":["platform"],"cluster":"observability","layer":"observability","status":"current","summary":{"en":"Numbers a system records at regular times, such as requests per second or memory used, so trends can be charted and compared.","da":"Tal, som et system måler med faste mellemrum, fx forespørgsler pr. sekund eller brugt hukommelse, så udviklingen kan følges."},"body":{"formal":{"en":"Measurements stored as a name, a number and a time, often with labels such as server or region, that are cheap to keep for long periods and can be added up, averaged and compared across many systems.","da":"Målinger gemt som et navn, et tal og et tidspunkt, ofte med etiketter som server eller region, der er billige at gemme længe og kan lægges sammen, gennemsnitsberegnes og sammenlignes på tværs af mange systemer."},"plain":{"en":"Like the readings on your electricity meter taken every hour; one number on its own says little, but the curve over a week shows when something unusual happened.","da":"Som at skrive tallet på elmåleren ned hver time; ét tal alene siger ikke meget, men kurven over en uge viser, hvornår der skete noget usædvanligt."},"inPractice":{"en":"At a municipality, a chart of failed logins to the staff portal usually shows about twenty a minute; one night it jumps to four thousand, pointing to someone guessing passwords.","da":"I en kommune viser en kurve over mislykkede login på medarbejderportalen normalt omkring tyve i minuttet; en nat springer den til fire tusind, hvilket tyder på, at nogen gætter adgangskoder."},"whyItMatters":{"en":"Because they are small and fast to search, metrics are what most alarms and service targets are built on; they show that something changed, while logs and traces help show why.","da":"Fordi de er små og hurtige at søge i, er metrikker grundlaget for de fleste alarmer og servicemål; de viser, at noget har ændret sig, mens logs og sporinger hjælper med at vise hvorfor."}},"deepDive":{"en":"In the dominant dimensional data model, popularised by Prometheus and adopted by OpenTelemetry, a time series is identified by a metric name plus a set of label key-value pairs, and holds a sequence of (timestamp, value) samples. Every distinct combination of label values is a separate series, so the cost of a metric is roughly the product of its label cardinalities. Putting unbounded values such as user IDs, request IDs or raw URLs into labels is the classic way to exhaust memory in a time-series database; such detail belongs in logs, traces or exemplars instead.\n\nPrometheus defines four metric types. A counter only increases, apart from resets to zero when a process restarts, and is queried with rate() or increase(), which detect and compensate for resets; a gauge goes up and down (queue depth, memory in use); a histogram counts observations into cumulative buckets (le labels) plus a sum and a count, so quantiles can be estimated server-side with histogram_quantile() and aggregated across instances; a summary computes quantiles in the client, which is precise per instance but cannot be meaningfully averaged across instances. Bucket boundaries fix the achievable precision, which is why OpenTelemetry exponential histograms and Prometheus native histograms use automatically scaled bucket layouts. OpenTelemetry instruments (Counter, UpDownCounter, Histogram, Gauge and asynchronous observable variants) map onto these, with an additional choice of cumulative or delta aggregation temporality that must match what the backend expects.\n\nCollection is either pull, where Prometheus scrapes an HTTP endpoint exposing the text or OpenMetrics format at a scrape interval (the global default is one minute, commonly set to 15 or 30 seconds), or push, as with OTLP export, StatsD or remote write. Pull makes a missing target visible through the synthetic up series; push suits short-lived jobs and crosses network boundaries more easily. Storage engines compress samples heavily with delta-of-delta timestamp and XOR value encoding, derived from Facebook's Gorilla paper, and long retention is handled by downsampling in systems such as Thanos, Mimir or VictoriaMetrics.\n\nUseful selection frameworks are the four golden signals (latency, traffic, errors, saturation) for services, Brendan Gregg's USE method (utilisation, saturation, errors) for resources, and the RED method (rate, errors, duration) for request-driven services. Common analytical errors include averaging percentiles, which is mathematically invalid, alerting on averages that hide tail latency, and computing rate() over a range shorter than two scrape intervals. Metrics are aggregates by design: they show that the error rate rose but not which request failed, which is why they are the basis for SLIs and alerts while traces and logs carry per-event detail.","da":"I den dominerende dimensionelle datamodel, som Prometheus gjorde udbredt, og som OpenTelemetry har overtaget, identificeres en tidsserie af et metriknavn plus et sæt label-par af nøgle og værdi og indeholder en række samples af (tidsstempel, værdi). Hver særskilt kombination af labelværdier er en selvstændig serie, så prisen for en metrik er groft sagt produktet af dens labels' kardinalitet. At lægge ubegrænsede værdier som bruger-ID'er, forespørgsels-ID'er eller rå URL'er i labels er den klassiske måde at opbruge hukommelsen i en tidsseriedatabase på; den slags detaljer hører hjemme i logs, sporinger eller exemplars.\n\nPrometheus definerer fire metriktyper. En counter vokser kun, bortset fra nulstillinger, når en proces genstarter, og forespørges med rate() eller increase(), som opdager og kompenserer for nulstillinger; en gauge går op og ned (kødybde, brugt hukommelse); et histogram tæller observationer i kumulative buckets (le-labels) plus en sum og et antal, så fraktiler kan estimeres på serversiden med histogram_quantile() og aggregeres på tværs af instanser; en summary beregner fraktiler i klienten, hvilket er præcist pr. instans, men ikke meningsfuldt kan gennemsnitsberegnes på tværs af instanser. Bucket-grænserne fastlægger den opnåelige præcision, og derfor bruger OpenTelemetrys eksponentielle histogrammer og Prometheus' native histograms automatisk skalerede bucket-inddelinger. OpenTelemetrys instrumenter (Counter, UpDownCounter, Histogram, Gauge og asynkrone observable-varianter) svarer til disse, med et ekstra valg mellem kumulativ eller delta-aggregeringstemporalitet, som skal passe til det, backenden forventer.\n\nIndsamling sker enten ved pull, hvor Prometheus scraper et HTTP-endpoint, der udstiller tekst- eller OpenMetrics-formatet, med et scrape-interval (den globale standard er ét minut, ofte sat til 15 eller 30 sekunder), eller ved push, som ved OTLP-eksport, StatsD eller remote write. Pull gør et manglende target synligt via den syntetiske up-serie; push passer til kortlivede jobs og krydser lettere netværksgrænser. Lagringsmotorer komprimerer samples kraftigt med delta-of-delta-kodning af tidsstempler og XOR-kodning af værdier, afledt af Facebooks Gorilla-artikel, og lang opbevaring håndteres med nedsampling i systemer som Thanos, Mimir eller VictoriaMetrics.\n\nNyttige rammer for valg af metrikker er de fire gyldne signaler (latenstid, trafik, fejl, mætning) for tjenester, Brendan Greggs USE-metode (udnyttelse, mætning, fejl) for ressourcer og RED-metoden (rate, fejl, varighed) for forespørgselsdrevne tjenester. Typiske analysefejl er at tage gennemsnit af percentiler, hvilket er matematisk ugyldigt, at alarmere på gennemsnit, der skjuler halelatens, og at beregne rate() over et interval, der er kortere end to scrape-intervaller. Metrikker er aggregater af natur: de viser, at fejlraten steg, men ikke hvilken forespørgsel der fejlede, og derfor er de grundlaget for SLI'er og alarmer, mens sporinger og logs bærer detaljen for den enkelte hændelse."},"edges":[{"type":"part-of","to":"platform/observability","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/service-level-objective","confidence":"high","strength":"normal"}],"depth":0,"sources":[{"title":"OpenTelemetry - Metrics","url":"https://opentelemetry.io/docs/concepts/signals/metrics/","tier":"official-doc","publisher":"OpenTelemetry (CNCF)"},{"title":"Google SRE book - Chapter 6, Monitoring Distributed Systems","url":"https://sre.google/sre-book/monitoring-distributed-systems/","tier":"reference","publisher":"Google"}],"draft":true}