Metrikker

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.

Prometheus 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.

Indsamling 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.

Nyttige 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.