Die tydreeksdatabasis (TSDB) in Prometheus 2 is 'n goeie voorbeeld van 'n ingenieursoplossing wat aansienlike verbeterings bied bo Prometheus 2-berging v1 in terme van data-insameling en navraaguitvoerspoed, en hulpbrondoeltreffendheid. Ons het Prometheus 2 in Percona Monitering en Bestuur (PMM) geïmplementeer en ek het die geleentheid gehad om die prestasie van Prometheus 2 TSDB te verstaan. In hierdie artikel sal ek praat oor die resultate van hierdie waarnemings.
Prometheus gemiddelde werklading
Vir diegene wat gewoond is aan die hantering van algemene doeldatabasisse, is die tipiese Prometheus-werklading nogal interessant. Die tempo van data-akkumulasie is geneig om stabiel te wees: gewoonlik stuur die dienste wat jy monitor ongeveer dieselfde hoeveelheid metrieke, en die infrastruktuur verander relatief stadig.
Versoeke vir inligting kan uit verskeie bronne kom. Sommige van hulle, soos waarskuwings, streef ook na 'n stabiele en voorspelbare waarde. Ander, soos gebruikersversoeke, kan stygings veroorsaak, hoewel dit nie die geval is vir die meeste van die werklading nie.
Laai toets
Tydens toetsing het ek gefokus op die vermoë om data te versamel. Ek het Prometheus 2.3.2 saamgestel met Go 1.10.1 (as deel van PMM 1.14) op 'n Linode-diens ontplooi deur hierdie skrif te gebruik: . Vir die mees realistiese vraggenerering, hiermee Ek het verskeie MySQL-nodes met 'n werklike las gehardloop (Sysbench TPC-C-toets), wat elkeen 10 Linux/MySQL-nodes nageboots het.
Al die volgende toetse is uitgevoer op 'n Linode-bediener met agt vCores en 32 GB geheue, wat 20 las-simulasies uitvoer wat 800 MySQL-gevalle monitor. Of, in terme van Prometheus, 440 teikens (teikens), 380 fooie (skrape) per sekonde, 1,7 duisend rekords (monsters) per sekonde en XNUMX miljoen aktiewe tydreekse.
Design
Die gewone tradisionele databasisbenadering, insluitend die een wat deur Prometheus 1.x gebruik word, is om . As dit nie genoeg is om die vrag te hanteer nie, sal jy hoë vertraging ervaar en sommige versoeke sal nie nagekom word nie. Geheuegebruik in Prometheus 2 is konfigureerbaar via 'n sleutel storage.tsdb.min-block-duration, wat bepaal hoe lank rekords in die geheue gehou sal word voordat dit na skyf gespoel word (verstek is 2 uur). Die hoeveelheid geheue wat benodig word, sal afhang van die aantal tydreekse, etikette en skrape, plus die netto invoer. Wat skyfspasie betref, beoog Prometheus om 3 grepe per skryf (monster) te gebruik. Aan die ander kant is die geheuevereistes baie hoër.
Alhoewel dit moontlik is om die blokgrootte op te stel, word dit nie aanbeveel om dit met die hand in te stel nie, so jy sit met die taak om Prometheus soveel geheue te gee as wat dit vir jou werklading benodig.
As daar nie genoeg geheue is om die inkomende stroom metrieke te ondersteun nie, sal Prometheus uit die geheue val of deur 'n OOM-moordenaar gevang word.
Om ruilmiddel by te voeg om die ongeluk te vertraag wanneer Prometheus se geheue opraak, help nie regtig nie, want die gebruik van hierdie kenmerk veroorsaak geheue-ontploffings. Ek dink dit gaan oor Go, sy vullisverwyderaar, en hoe dit met ruil werk.
Nog 'n interessante benadering is om die kopblok te stel om op 'n sekere tyd na skyf gespoel te word, in plaas daarvan om dit te tel vanaf die tyd dat die proses begin het.
Soos jy op die grafiek kan sien, vind spoeling na skyf elke twee uur plaas. As jy die min-blok-duur parameter verander na een uur, dan sal hierdie terugstellings elke uur gebeur, wat oor 'n halfuur begin.
As jy hierdie en ander grafieke in jou Prometheus-installasie wil gebruik, kan jy dit gebruik . Dit is ontwerp vir PMM, maar met 'n paar wysigings pas dit in enige Prometheus-installasie.
Ons het 'n aktiewe blok, genoem die kopblok, wat in die geheue gestoor word; blokke met ouer data is beskikbaar via mmap(). Dit verwyder die behoefte om die kas afsonderlik te konfigureer, maar dit beteken ook dat jy genoeg ruimte vir die bedryfstelsel-kas moet laat as jy data ouer as die kopblok wil navraag doen.
Dit beteken ook dat Prometheus se virtuele geheueverbruik redelik hoog sal lyk, wat niks is om oor bekommerd te wees nie.
Nog 'n interessante ontwerppunt is die gebruik van WAL (skryf vooruit log). Soos u uit die bewaarplekdokumentasie kan sien, gebruik Prometheus WAL om ineenstortings te vermy. Spesifieke meganismes om data-oorlewingbaarheid te waarborg, is ongelukkig nie goed gedokumenteer nie. Prometheus 2.3.2 spoel WAL elke 10 sekondes na skyf en hierdie instelling is nie gebruikerkonfigureerbaar nie.
Seëls
Prometheus TSDB is ontwerp in die beeld van LSM-berging (Log Structured merge - log-structured merge tree): die kopblok word periodiek na skyf gespoel, terwyl die verdigtingsmeganisme verskeie blokke saamsmelt om te verhoed dat te veel blokke op versoeke geskandeer word. Hier kan u die aantal blokke sien wat ek op die toetsstelsel na 'n dag van vrag waargeneem het.
As jy meer wil leer oor berging, kan jy na die meta.json-lêer kyk, wat inligting bevat oor die blokke wat beskikbaar is en hoe dit ontstaan het.
{
"ulid": "01CPZDPD1D9R019JS87TPV5MPE",
"minTime": 1536472800000,
"maxTime": 1536494400000,
"stats": {
"numSamples": 8292128378,
"numSeries": 1673622,
"numChunks": 69528220
},
"compaction": {
"level": 2,
"sources": [
"01CPYRY9MS465Y5ETM3SXFBV7X",
"01CPYZT0WRJ1JB1P0DP80VY5KJ",
"01CPZ6NR4Q3PDP3E57HEH760XS"
],
"parents": [
{
"ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
"minTime": 1536472800000,
"maxTime": 1536480000000
},
{
"ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
"minTime": 1536480000000,
"maxTime": 1536487200000
},
{
"ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
"minTime": 1536487200000,
"maxTime": 1536494400000
}
]
},
"version": 1
}Seëls in Prometheus is vasgemaak aan die tyd dat die kopblok na skyf gespoel word. Op hierdie stadium kan verskeie sulke operasies uitgevoer word.
Dit blyk dat verdigtings nie op enige manier beperk is nie en groot skyf I/O spykers tydens uitvoering kan veroorsaak.
SVE laai spykers
Dit het natuurlik 'n taamlik negatiewe uitwerking op die spoed van die stelsel, en is ook 'n ernstige uitdaging vir LSM-bergings: hoe om verdigtings te maak om hoë navraagspoed te ondersteun sonder om te veel oorhoofse koste te veroorsaak?
Die gebruik van geheue in die verdigtingsproses lyk ook nogal nuuskierig.
Ons kan sien hoe, na verdigting, die meeste van die geheue van toestand verander van Cached na Free: dit beteken dat potensieel waardevolle inligting daarvandaan verwyder is. Nuuskierig of dit hier gebruik word fadvice() of 'n ander minimaliseringstegniek, of is dit omdat die kas leeggemaak is van blokke wat deur verdigting vernietig is?
Herstel van mislukkings
Rampherstel neem tyd, en met goeie rede. Vir 'n inkomende stroom van 'n miljoen rekords per sekonde, moes ek ongeveer 25 minute wag terwyl die herstel die SSD-aandrywer in ag geneem het.
level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."Die hoofprobleem van die herstelproses is hoë geheueverbruik. Selfs al kan die bediener stabiel werk met dieselfde hoeveelheid geheue in 'n normale situasie, as dit ineenstort, sal dit dalk nie styg nie as gevolg van OOM. Die enigste oplossing wat ek gevind het, is om data-insameling af te skakel, die bediener op te bring, dit te laat herstel en te herlaai met versameling geaktiveer.
Opwarm
Nog 'n gedrag wat in gedagte gehou moet word tydens opwarming, is die verhouding van lae werkverrigting tot hoë hulpbronverbruik direk na opstart. Tydens sommige, maar nie alle begin nie, het ek 'n ernstige las op die SVE en geheue waargeneem.
Dalings in geheuegebruik dui daarop dat Prometheus nie alle fooie van die begin af kan instel nie, en sommige inligting gaan verlore.
Ek het nie die presiese redes vir die hoë SVE en geheuegebruik uitgevind nie. Ek vermoed dat dit te wyte is aan die skepping van nuwe tydreekse in die kopblok met 'n hoë frekwensie.
SVE spykers
Benewens verdigtings, wat 'n redelik hoë I/O-lading skep, het ek elke twee minute ernstige stygings in SVE-lading opgemerk. Die sarsies is langer met hoë inkomende verkeer en lyk of hulle deur die Go-vullisverwyderaar veroorsaak word, ten minste sommige kerns is vol gelaai.
Hierdie spronge is nie so onbeduidend nie. Dit blyk dat wanneer hulle voorkom, die Prometheus interne toegangspunt en metrieke onbeskikbaar word, wat veroorsaak dat data in dieselfde tydsintervalle daal.
U kan ook sien dat die Prometheus-uitvoerder vir een sekonde afskakel.
Ons kan korrelasies met vullisversameling (GC) sien.
Gevolgtrekking
TSDB in Prometheus 2 is vinnig, in staat om miljoene tydreekse te hanteer en terselfdertyd duisende skryfwerk per sekonde met taamlik beskeie hardeware. Die SVE en skyf I/O gebruik is ook indrukwekkend. My voorbeeld het tot 200 000 metrieke per sekonde per gebruikte kern getoon.
Om vir uitbreiding te beplan, moet jy onthou dat daar genoeg geheue is, en dit moet regte geheue wees. Die hoeveelheid geheue wat gebruik is, wat ek waargeneem het, was ongeveer 5 GB per 100 000 rekords per sekonde van die inkomende stroom, wat, in totaal met die bedryfstelsel-kas, ongeveer 8 GB se besette geheue gegee het.
Natuurlik is daar nog baie werk wat gedoen moet word om CPU- en skyf-I/O-pyle te tem, en dit is nie verbasend nie, gegewe hoe jong TSDB Prometheus 2 vergelyk word met InnoDB, TokuDB, RocksDB, WiredTiger, maar hulle het almal gehad soortgelyke probleme aan die begin van hul lewensiklus.
Bron: will.com