VictoriaMetrics - het creëren van de beste externe opslag voor Prometheus

Dag Allemaal! VictoriaMetrics-oprichters hier:

  • valyala
  • hagen1778
  • tenmozes

We werpen graag wat licht op VictoriaMetrics.

Een beetje geschiedenis

We zijn Prometheus en Grafana twee jaar geleden gaan gebruiken. Dit was een verademing vergeleken met Zabbix. Nu konden ontwikkelaars willekeurige metrics rond hun code verspreiden, aangepaste dashboards bouwen in Grafana en hun apps volgen zonder speciale sysadmins / DevOps.

Het aantal unieke statistieken dat door onze Prometheus-instantie werd bijgehouden, groeide snel van een paar honderd naar meer dan 300.000 in een half jaar. We zijn tijdens de groei overgeschakeld naar Prometheus 2.0, omdat Prometheus vóór 2.0 te langzaam werd voor onze metrische volumes. Maar de nieuwe Prometheus had een paar problemen:

  • Het was niet zo snel op zoekbereiken van meer dan een paar dagen. We hebben dergelijke reeksen gebruikt voor langetermijntrends en dashboards voor capaciteitsplanning.
  • Het begon met het eten van veel opslagruimte na de geleidelijke verhoging van de standaardwaarde van 15 dagen tot een jaar.
  • Het was onduidelijk hoe het verlies van Prometheus-gegevens in het geval van opslagcrash kon worden voorkomen. We eindigen met twee verschillende Prometheus-instanties die dezelfde set doelen schrapen (ook bekend als HA-paar). Dit heeft onze controlekosten verdubbeld.

We begonnen mogelijke oplossingen te verkennen en ontdekten dat Prometheus externe opslag ondersteunt. Maar alle bestaande oplossingen waren om verschillende redenen onbevredigend:

  • Complexe installatie en fragiele werking.
  • Gemelde crashes en gegevensverlies.
  • Traagheid.
  • Nul- of suboptimale schaalbaarheid.

Tegelijkertijd hebben we met succes ClickHouse gebruikt voor het opslaan en analyseren van enorme evenementenstromen - tot 300 miljard evenementen per dag. We waren verbaasd over de operationele eenvoud, de queriesnelheid en het compressieniveau van de MergeTree-tabelmotor.

Onze ervaring met ClickHouse was zo geweldig, dus we hebben er de volgende projecten voor geopend:

  • clickhouse-grafana - Grafana-gegevensbron voor ClickHouse.
  • chproxy - load balancer en cacheproxy voor ClickHouse.
  • chclient - fast Go-client voor ClickHouse.

We hebben geprobeerd ClickHouse te gebruiken als externe opslag voor Prometheus. De eerste resultaten waren geweldig - ClickHouse kon miljarden datapunten per seconde scannen op een enkele server. Helaas konden we geen goede oplossing vinden voor het bouwen van een efficiënte index voor Prometheus-labels.

Toen is een gek idee naar voren gekomen - laten we onze eigen TSDB maken met de volgende vereisten:

  • Efficiënte index voor Prometheus-labels aka Metrics 2.0-tags, die gemakkelijk miljarden verschillende labels opslaat en opvraagt.
  • Hoge snelheid voor vragen over grote datumbereiken, een groot aantal unieke statistieken en een groot aantal gegevenspunten.
  • Goede opslagcompressie, dus meer gegevens kunnen worden opgeslagen op de beperkte schijfruimte.
  • Eenvoudige en snelle online back-ups vergelijkbaar met FREEZE PARTITION in ClickHouse.

Het prototype van deze TSDB was veelbelovend, dus ik (valyala) verliet mijn werk bij VertaMedia en begon fulltime aan de TSDB te werken. Later kreeg de TSDB een mooie naam - VictoriaMetrics.

Technische details

VictoriaMetrics is geschreven in Go. Go is gekozen om de volgende redenen:

  • Veel bestaande TSDB-oplossingen zijn geschreven in Go - Prometheus, InfluxDB, Thanos, M3, Cortex, enz. Deze hints Go is vrij goed voor het schrijven van TSDB.
  • Ik heb een goede ervaring in Go. Bekijk mijn repo's op GitHub.
  • Ik ben de auteur van fasthttp, dus ik weet hoe ik efficiënte apps moet schrijven in Go.

De opslag van VictoriaMetrics is helemaal opnieuw opgebouwd met behulp van ideeën uit de MergeTree-tafelengine van Clickhouse:

  • Bewaar afzonderlijk tijdreeksen namen, tijdstempels en waarden (ook bekend als kolomopslag). Dit versnelt vragen door alleen de vereiste kolommen te scannen.
  • Bewaar elke kolom in een datastructuur vergelijkbaar met log-gestructureerde merge tree (LSM). Dit vermindert willekeurige I / O bij het toevoegen / scannen van gesorteerde waarden in vergelijking met B-boomachtige gegevensstructuren. Dit versnelt de opslag op harde schijven. LSM-bestanden zijn onveranderlijk. Dit vereenvoudigt het maken van snelle snapshots en back-ups. LSM heeft een nadeel vergeleken met B-tree - de opgeslagen gegevens worden meerdere keren herschreven wanneer kleinere bestanden worden samengevoegd tot grotere bestanden. Dit verspilt schijfbandbreedte, maar de praktijk van ClickHouse toont aan dat dit een vrij goede afweging is.
  • Verwerk gegevens in brokken die in de cache van de CPU passen. Dit maximaliseert CPU-prestaties, omdat het niet wacht op gegevens van langzaam RAM. Zie latentienummers die elke programmeur moet weten voor meer informatie.

Aanvankelijk werd de index voor Prometheus-labels gebouwd bovenop de LevelDB-poort in Go. Later probeerde ik het te vervangen door een efficiënter alternatief - RocksDB. Maar het was niet succesvol vanwege de hoge cgo-overhead, die op elk gescand etiket moet worden betaald. Uiteindelijk is LevelDB vervangen door een aangepaste gegevensstructuur - mergeset. Deze gegevensstructuur is speciaal geoptimaliseerd voor de index van Prometheus-labels.

mergeset heeft de volgende verschillen met LevelDB:

  • Het werkt alleen op toetsen. Het is zich niet bewust van waarden.
  • Het heeft een lagere schrijfversterking.
  • Het zoekt sneller naar veel bestelde sleutels.
  • Het comprimeert sleutels beter, zodat ze minder opslagruimte nodig hebben.
  • Het biedt onmiddellijke gegevensmomentopnamen en eenvoudige back-ups.
  • Het maakt gebruik van ideeën uit de MergeTree-tafelengine van ClickHouse.

We zijn van plan om in de nabije toekomst mergeset te openen, zodat anderen hiervan kunnen profiteren.

Aanvankelijk was VictoriaMetrics een oplossing met één server. Later is het omgezet in een geclusterde oplossing. Een enkele service is tijdens de transformatie opgesplitst in drie services:

  • vmstorage - slaat metrische waarden op die zijn ontvangen van vminsert, retourneert ruwe metrische waarden voor query's van vmselect.
  • vminsert - accepteert metrische waarden via Prometheus remote_write API en stuurt deze naar vmstorage.
  • vmselect - implementeert Prometheus-query-API. Haalt onbewerkte gegevens op van vmstorage.

Het splitsen geeft de volgende voordelen:

  • Elke service kan onafhankelijk worden geschaald.
  • Elke service kan worden uitgevoerd op hardware die optimaal is geoptimaliseerd voor de servicebehoeften.
  • Zware inzetstukken interfereren niet met zware selecties.
  • Bugs in vminsert breken vmselect niet en vice versa.
  • Betere duurzaamheid van vmstorage, omdat het complexe querylogica naar vmselect verplaatst.

Nu draait VictoriaMetrics in Google Cloud. We gebruiken Infrastructure as Code-benadering voor resourcebeheer en provisioning via Deployment Manager.

Zoekopdracht motor

In eerste instantie bood vmselect de aangeboden Prometheus remote read API. Maar dit was suboptimaal, omdat de API voor elke zoekopdracht de overdracht van alle onbewerkte gegevenspunten naar Prometheus vereiste. Als Prometheus bijvoorbeeld een respons opbouwt over 1K-statistieken met elk 10K datapunten, dan moet vmselect 1K * 10K = 10M datapunten naar Prometheus sturen voor elke query. Dit is verspilling van uitgangsverkeer en geld. Dus later is de API voor lezen op afstand vervangen door een query-engine die volledig compatibel is met PromQL.

De query-engine ondersteunt extra functies die zijn gericht op de vereenvoudiging van complexe zoekopdrachten. Hieronder enkele voorbeelden:

  • MET sjablonen die lijken op veelgebruikte tabelexpressies:
MET (
      commonFilters = {job = ~ "$ job", instance = ~ "$ instance"}
  ) node_filesystem_size_bytes {commonFilters} / node_filesystem_avail_bytes {commonFilters}

Lees meer over WITH-sjablonen en speel ermee op de MET-sjablonen.

  • Vele handige functies. Bijvoorbeeld de uniefunctie voor het combineren van queryresultaten:
unie(
    node_filesystem_size_bytes,
    node_filesystem_avail_bytes,
)

De volledige lijst met extra functies is hier beschikbaar.

Prestatiefeiten

  • Eerste tests tonen aan dat VictoriaMetrics 10x minder opslagruimte gebruikt in vergelijking met Prometheus 2.0-0.4 bytes per gegevenspunt versus 4 bytes per gegevenspunt in ons geval. Gegevenspunt is (timestamp, metric_value) tuple.
  • Een enkele vmstorage-service accepteert tot 4 miljoen datapunten per seconde op een 8xCPU-server.
  • Een enkele vmselect-service scant tot 500 miljoen datapunten per seconde op een 8xCPU-server.
  • VictoriaMetrics gebruikt 70x keer minder opslagruimte in vergelijking met TimescaleDB op testgegevens van Time Series Benchmark Suite - 250 MB versus 18 GB. De testgegevens bestaan ​​uit 1B-gegevenspunten - zie TSBS-beschrijving op GitHub.
  • Er is ruimte voor prestatieverbeteringen. Alle VictoriaMetrics-services zijn uitgerust met pprof-handler, dus we zijn klaar om hun prestaties af te stemmen op de productiebelasting.

VictoriaMetrics-functies

  • Ondersteunt volledige PromQL plus uitgebreide PromQL met WITH-sjablonen. Uitgebreide PromQL kan worden geprobeerd op Grafana-speeltuin.
  • Eenvoudige installatie - kopieer en plak de meegeleverde remote_write URL gewoon naar Prometheus config.
  • Lagere operationele kosten. Prometheus kan worden omgezet in een staatloze service nadat extern schrijven naar VictoriaMetrics is ingeschakeld.
  • Breed scala aan bewaartermijnen is beschikbaar - van 1 maand tot 5 jaar.
  • Prestatieschalen invoegen tot miljoenen metrische waarden per seconde.
  • Selecteer prestatieschalen tot miljarden metrische waarden per seconde.
  • Opslag kan worden opgeschaald naar triljoenen metrische waarden en miljoenen unieke metrieken (ook wel hoge kardinaliteit genoemd).
  • Biedt een algemene queryweergave voor een willekeurig aantal verschillende Prometheus-instanties als ze dezelfde URL voor remote_write gebruiken.

Wie heeft baat bij VictoriaMetrics?

  • Iedereen die Prometheus gebruikt. Stel VictoriaMetrics in als een externe opslag en houd u niet langer bezig met operationele problemen met lokale opslag, zoals back-ups, replicatie, capaciteitsplanning en andere onderhoudsbelastingen.
  • Gebruikers die Prometheus in Kubernetes implementeren. Momenteel moeten dergelijke gebruikers zorgvuldig aanhoudende volumes beheren voor Prometheus lokale opslag. Meestal stellen ze Prometheus in als een stateful app, die Kubernetes kan beperken bij het plannen van beslissingen. Gebruik VictoriaMetrics gewoon als externe opslag en voer Prometheus uit als een stateless app.
  • Gebruikers met veel verschillende Prometheus-instanties in verschillende netwerken / datacenters. VictoriaMetrics biedt een globaal queryoverzicht voor alle Prometheus-instanties.

Toekomstige functies

We zijn van plan de volgende functies in de toekomst te implementeren:

  • Automatische downsampling van oude gegevens.
  • Laatste waarden voor de gegeven labelfilters.
  • Tellers met tijdvenster.

Gevolgtrekking

We zijn ervan overtuigd dat VictoriaMetrics de beste externe opslag voor Prometheus wordt.

Blijf het verkennen. Lees de veelgestelde vragen. Registreer u in de VictoriaMetrics-speeltuin, gebruik het als testopslag op afstand voor uw Prometheus-instanties. Het is absoluut veilig, omdat Prometheus gegevens naar lokale opslag blijft schrijven naast externe opslag, zodat uw lokale gegevens niet verloren gaan wanneer externe opslag wordt ingeschakeld. Zie Quick Start voor meer details.

Bewerk dashboards en grafieken op Grafana-speelplaats. Deze speeltuin gebruikt VictoriaMetrics-gegevensbron die verwijst naar interne metrieken van VictoriaMetrics-speeltuin, dus alle functies van Extended PromQL zijn daar beschikbaar.

Productie VictoriaMetrics zal binnenkort beschikbaar zijn. Blijf op de hoogte en vertel het verder!

Update: Docker-afbeeldingen met VictoriaMetrics met één server zijn hier beschikbaar. Als je Docker niet bevalt, gebruik dan gewoon de overeenkomstige statische binaries.

Update2: Lees onze nieuwe post - TSDB-benchmarks voor hoge cardinaliteit: VictoriaMetrics vs TimescaleDB vs InfluxDB.

Update3: VictoriaMetrics is nu open source!

Word lid van onze community Slack en lees onze wekelijkse Faun-onderwerpen ⬇

Als dit bericht nuttig was, klik dan een paar keer op de klap -knop hieronder om je steun voor de auteur te tonen! ⬇