VictoriaMetrics - skaper den beste fjernlagringen for Prometheus

Hei alle sammen! VictoriaMetrics grunnleggere her:

  • valyala
  • hagen1778
  • tenmozes

Vi kaster gjerne lys over VictoriaMetrics.

Litt historie

Vi begynte å bruke Prometheus og Grafana for to år siden. Dette var et friskt pust sammenlignet med Zabbix. Nå kunne utviklere spre vilkårlige beregninger rundt koden sin, bygge tilpassede dashboards i Grafana og overvåke appene sine uten dedikerte sysadmins / DevOps.

Antallet unike beregninger skrapet av vår Prometheus-instans vokste raskt opp fra noen hundre til mer enn 300 000 på et halvt år. Vi byttet til Prometheus 2.0 under veksten, siden Prometheus før 2.0 ble for treg for våre metriske volumer. Men den nye Prometheus hadde noen få utgaver:

  • Det gikk ikke så raskt på spørringsområder som oversteg noen dager. Vi brukte slike områder for langsiktige trender og kapasitetsplanleggingspaneler.
  • Det begynte å spise mye lagringsplass etter den gradvise opprettholdelsesøkningen fra standard 15 dager til et år.
  • Det var uklart hvordan man kan forhindre tap av Prometheus i tilfelle lagringsulykke. Vi ender opp med to distinkte Prometheus-forekomster som skraper det samme settet med mål (også kalt HA-par). Dette doblet overvåkingskostnadene våre.

Vi begynte å utforske mulige løsninger og oppdaget at Prometheus støtter fjernlagring. Men alle de eksisterende løsningene var utilfredsstillende på grunn av forskjellige årsaker:

  • Kompleks oppsett og skjør drift.
  • Rapporterte krasj og tap av data.
  • Treghet.
  • Null eller suboptimal skalerbarhet.

I løpet av den samme tiden brukte vi ClickHouse for å lagre og analysere store begivenhetsstrømmer - opptil 300 milliarder arrangementer per dag. Vi ble overrasket over den operative enkelheten, spørringshastigheten og komprimeringsnivået til den 'MergeTree-bordmotoren.

Vår erfaring med ClickHouse var så flott, så vi åpnet for følgende prosjekter for det:

  • clickhouse-grafana - Grafana datakilde for ClickHouse.
  • chproxy - load balancer og cache-proxy for ClickHouse.
  • chclient - rask Go-klient for ClickHouse.

Vi prøvde å bruke ClickHouse som en ekstern lagring for Prometheus. De første resultatene var gode - ClickHouse klarte å skanne milliarder av datapunkter per sekund på en enkelt server. Dessverre kunne vi ikke finne en god løsning for å bygge effektiv indeks for Prometheus-etiketter.

Så har en gal ide kommet frem - la oss lage vår egen TSDB med følgende krav:

  • Effektiv indeks for Prometheus-etiketter alias Metrics 2.0-tagger, som enkelt lagrer og spør om milliarder av distinkte etiketter.
  • Rask hastighet for spørsmål på store datoperioder, stort antall unike beregninger og stort antall datapunkter.
  • God lagringskomprimering, slik at mer data kan lagres på den begrensede plassen.
  • Enkel og rask online sikkerhetskopi som ligner på FREEZE PARTITION i ClickHouse.

Prototypen på denne TSDB var lovende, så jeg (valyala) forlot arbeidet mitt på VertaMedia og begynte å jobbe på TSDB på heltid. Senere fikk TSDB fint navn - VictoriaMetrics.

Tekniske detaljer

VictoriaMetrics er skrevet i Go. Go er valgt på grunn av følgende grunner:

  • Mange eksisterende TSDB-løsninger er skrevet i Go - Prometheus, InfluxDB, Thanos, M3, Cortex, etc. Dette antyder Go er ganske bra for TSDB-skriving.
  • Jeg har god erfaring i Go. Se reposene mine på GitHub.
  • Jeg er forfatteren av fasthttp, så jeg vet hvordan jeg skriver effektive apper i Go.

VictoriaMetrics lagring er bygget fra bunnen av ved å bruke ideer fra Clickhouse's MergeTree-bordmotor:

  • Lagre navn på tidsskrifter, tidsstempler og verdier (også lagring av søyler). Dette fremskynder spørsmål ved bare å skanne de nødvendige kolonnene.
  • Lagre hver kolonne i en datastruktur som ligner loggstrukturert fusjonstre (LSM). Dette reduserer tilfeldig I / O når du legger til / skanner sorterte verdier sammenlignet med B-tre-lignende datastrukturer. Dette gir raskere lagring på harddisker. LSM-filer er uforanderlige. Dette forenkler å lage raske stillbilder og sikkerhetskopier. LSM har en ulempe som sammenlignes med B-tre - de lagrede dataene skrives om flere ganger når mindre filer slås sammen til større filer. Dette sløser med båndbredde på disken, men ClickHouse-praksis viser at dette er ganske bra avveining.
  • Behandle data i biter som passer til CPU-cache. Dette maksimerer CPU-ytelsen, siden den ikke venter på data fra treg RAM. Se latensnummer hver programmerer bør vite for detaljer.

Opprinnelig har indeks for Prometheus-etiketter blitt bygget på toppen av LevelDB-porten i Go. Senere prøvde jeg å erstatte det med et mer effektivt alternativ - RocksDB. Men det var ikke vellykket på grunn av høyt belastningskostnad, som må betales på hver skannede etikett. Etter hvert har LevelDB blitt erstattet av en tilpasset datastruktur - sammensett. Denne datastrukturen er spesielt optimalisert for indeksen for Prometheus-etiketter.

mergeset har følgende forskjeller sammenlignet med LevelDB:

  • Den fungerer bare på nøkler. Den er ikke klar over verdier.
  • Det har lavere skriveforsterkning.
  • Den har raskere søk etter mange bestilte nøkler.
  • Den komprimerer tastene bedre, slik at de krever mindre lagringsplass.
  • Det gir øyeblikksbilder av data og enkle sikkerhetskopieringer.
  • Den bruker ideer fra ClickHouses MergeTree-tabellmotor.

Vi planlegger å åpne sammenslåing med åpen kildekode i nærmeste fremtid, slik at andre kan ha nytte av det.

Opprinnelig var VictoriaMetrics en enkeltserverløsning. Senere har den blitt omgjort til en klynget løsning. En enkelt tjeneste har blitt delt inn i tre tjenester under transformasjonen:

  • vmstorage - lagrer metriske verdier mottatt fra vminsert, returnerer rå metriske verdier for spørsmål fra vmselect.
  • vminsert - aksepterer metriske verdier via Prometheus remote_write API og sender dem til vmstorage.
  • vmselect - implementerer Prometheus spørrings API. Henter rå data fra vmstorage.

Delingen gir følgende fordeler:

  • Hver tjeneste kan skalere uavhengig av hverandre.
  • Hver tjeneste kan kjøres på maskinvare ideelt optimalisert for tjenestebehovene.
  • Tunge innsatser forstyrrer ikke tunge utvalg.
  • Feil i vminsert bryter ikke vmselect og omvendt.
  • Bedre vmstorage holdbarhet, siden den laster av kompleks spørringslogikk for å vmselect.

Nå kjører VictoriaMetrics i Google Cloud. Vi bruker Infrastructure as Code tilnærming for ressursstyring og -levering via Deployment Manager.

Forespørsel motor

Opprinnelig ga vmselect Prometheus fjernleser API. Men dette var suboptimalt, siden API krevde å overføre alle rå datapunkter til Prometheus for hvert spørsmål. Hvis for eksempel Prometheus bygger respons over 1K-beregninger med 10K datapunkter hver, så skal vmselect sende 1K * 10K = 10M datapunkter til Prometheus på hver spørring. Dette er bortkastet utgangstrafikk og penger. Så senere har den eksterne lese-APIen blitt erstattet av spørsmotoren som er fullt kompatibel med PromQL.

Spørsmotoren støtter tilleggsfunksjoner som er rettet mot forenkling av komplekse spørsmål. Nedenfor er noen eksempler:

  • MED maler som ligner vanlige tabelluttrykk:
MED (
      commonFilters = {job = ~ "$ jobb", instans = ~ "$ instans"}
  ) node_filesystem_size_bytes {commonFilters} / node_filesystem_avail_bytes {commonFilters}

Les mer om MED maler og spill med dem på LEKER med maler.

  • Mange nyttige funksjoner. For eksempel fagfunksjon for å kombinere spørreresultater:
union (
    node_filesystem_size_bytes,
    node_filesystem_avail_bytes,
)

Den komplette listen over tilleggsfunksjoner er tilgjengelig her.

Prestasjonsfakta

  • Innledende tester viser at VictoriaMetrics bruker 10x mindre lagringsplass sammenlignet med Prometheus 2.0–0.4 byte per datapunkt vs 4 byte per datapunkt i vårt tilfelle. Datapunkt er (tidsstempel, metrisk verdi) tuple.
  • En enkelt vmstorage-tjeneste godtar opptil 4 millioner datapunkter per sekund på 8xCPU-server.
  • En enkelt vmselect-tjeneste skanner opptil 500 millioner datapunkter per sekund på 8xCPU-server.
  • VictoriaMetrics bruker 70 ganger mindre lagringsplass sammenlignet med TimescaleDB på testdata fra Time Series Benchmark Suite - 250MB vs 18GB. Testdataene består av 1B datapunkter - se TSBS beskrivelse på GitHub.
  • Det er et rom for ytelsesforbedringer. Alle VictoriaMetrics-tjenestene er utstyrt med pprof-handler, så vi er klare til å stille inn ytelsen deres på produksjonsbelastningen.

VictoriaMetrics funksjoner

  • Støtter full PromQL pluss utvidet PromQL med MED-maler. Utvidet PromQL kan prøves på Grafana lekeplass.
  • Enkelt oppsett - bare kopier og lim inn den medfølgende URL-adressen til fjernet til Prometheus config.
  • Reduserte driftskostnader. Prometheus kan bli konvertert til statsløs tjeneste etter at du har aktivert ekstern skriving til VictoriaMetrics.
  • Et bredt spekter av oppbevaringsperioder er tilgjengelig - fra 1 måned til 5 år.
  • Sett inn resultatskalaer til millioner metriske verdier per sekund.
  • Velg resultatskalaer til milliarder metriske verdier per sekund.
  • Lagring skalerer til billioner av metriske verdier og millioner unike beregninger (også høy kardinalitet).
  • Tilbyr global spørringsvisning på tvers av vilkårlige antall forskjellige Prometheus-forekomster hvis de bruker den samme remote_write URL.

Hvem kan ha nytte av VictoriaMetrics?

  • Alle som bruker Prometheus. Bare konfigurer VictoriaMetrics som en ekstern lagring, og slutt å bry deg om lokale driftsproblemer som sikkerhetskopiering, replikering, kapasitetsplanlegging og andre vedlikeholdsbelastninger.
  • Brukere som distribuerer Prometheus i Kubernetes. Foreløpig skal slike brukere nøye administrere vedvarende volumer for Prometheus lokale lagring. Vanligvis setter de opp Prometheus som en statlig app, noe som kan begrense Kubernetes i planleggingsvedtak. Bare bruk VictoriaMetrics som en ekstern lagring og kjør Prometheus som en statløs app.
  • Brukere med mange forskjellige Prometheus-forekomster som ligger i distinkte nettverk / datasentre. VictoriaMetrics gir global spørringsvisning i alle Prometheus-forekomster.

Fremtidige funksjoner

Vi planlegger å implementere følgende funksjoner i fremtiden:

  • Automatisk nedmontering av gamle data.
  • Siste verdier for de gitte etikettfiltrene.
  • Tidsvinduet tellere.

Konklusjon

Vi er sikre på at VictoriaMetrics vil bli den beste fjernlagringen for Prometheus.

Fortsett å utforske det. Les FAQ. Registrer deg på VictoriaMetrics lekeplass, bruk den som en ekstern testlagring for Prometheus-forekomstene dine. Det er helt trygt, siden Prometheus fortsetter å skrive data til lokal lagring ved siden av ekstern lagring, så dine lokale data går ikke tapt når du aktiverer ekstern lagring. Se hurtigstart for mer informasjon.

Rediger instrumentpaneler og grafer på Grafana lekeplass. Denne lekeplassen bruker VictoriaMetrics datakilde som peker til interne beregninger for VictoriaMetrics lekeplass, så alle funksjonene fra Extended PromQL er tilgjengelige der.

Produksjon VictoriaMetrics vil være tilgjengelig snart. Følg med og spre ordet om det!

Oppdatering: Docker-bilder med VictoriaMetrics-serveren på én server er tilgjengelige her. Hvis du ikke liker Docker, kan du bare bruke de statiske binærene som tilsvarer det.

Oppdatering2: Les vårt nye innlegg - TSDB-standarder med høy kardinalitet: VictoriaMetrics vs TimescaleDB vs InfluxDB.

Update3: VictoriaMetrics er åpen kildekode nå!

Bli med i samfunnet vårt Slack og les våre ukentlige Faun-emner ⬇

Hvis dette innlegget var nyttig, kan du klikke på klapp -knappen noen ganger for å vise din støtte til forfatteren! ⬇