Tímaraðargagnagrunnurinn (TSDB) í Prometheus 2 er frábært dæmi um verkfræðilega lausn sem býður upp á miklar endurbætur á v2 geymslunni í Prometheus 1 hvað varðar gagnasöfnunarhraða, framkvæmd fyrirspurna og skilvirkni auðlinda. Við vorum að innleiða Prometheus 2 í Percona Monitoring and Management (PMM) og ég fékk tækifæri til að skilja frammistöðu Prometheus 2 TSDB. Í þessari grein mun ég tala um niðurstöður þessara athugana.
Meðal vinnuálag Prometheus
Fyrir þá sem eru vanir að fást við almenna gagnagrunna er dæmigerð Prometheus vinnuálag nokkuð áhugavert. Hraði gagnasöfnunar hefur tilhneigingu til að vera stöðugt: venjulega sendir þjónustan sem þú fylgist með um það bil sama fjölda mælikvarða og innviðirnir breytast tiltölulega hægt.
Beiðnir um upplýsingar geta komið úr ýmsum áttum. Sum þeirra, eins og viðvaranir, leitast einnig við stöðugt og fyrirsjáanlegt gildi. Aðrir, eins og notendabeiðnir, geta valdið springum, þó það sé ekki raunin fyrir flest vinnuálag.
Hleðslupróf
Við prófun lagði ég áherslu á getu til að safna gögnum. Ég setti Prometheus 2.3.2 saman með Go 1.10.1 (sem hluti af PMM 1.14) á Linode þjónustunni með því að nota þetta handrit: . Fyrir raunhæfustu álagsframleiðsluna með því að nota þetta Ég setti af stað nokkra MySQL hnúta með raunverulegu álagi (Sysbench TPC-C Test), sem hver líkti eftir 10 Linux/MySQL hnútum.
Allar eftirfarandi prófanir voru gerðar á Linode netþjóni með átta sýndarkjörnum og 32 GB af minni, sem keyrir 20 álagslíkingar sem fylgjast með tvö hundruð MySQL tilvikum. Eða, í Prometheus skilmálum, 800 skotmörk, 440 skrap á sekúndu, 380 þúsund skrár á sekúndu og 1,7 milljónir virkra tímaraðir.
Hönnun
Venjuleg nálgun hefðbundinna gagnagrunna, þar á meðal þess sem Prometheus 1.x notar, er að . Ef það er ekki nóg til að takast á við álagið muntu upplifa mikla töf og sumar beiðnir mistakast. Minni notkun í Prometheus 2 er stillanleg með lykli storage.tsdb.min-block-duration, sem ákvarðar hversu lengi upptökur verða geymdar í minni áður en þær eru skolaðar á disk (sjálfgefið er 2 klukkustundir). Magn minnis sem krafist er fer eftir fjölda tímaraðir, merkimiða og skafa sem bætt er við netstrauminn. Hvað varðar diskpláss stefnir Prometheus á að nota 3 bæti á hverja skrá (sýnishorn). Aftur á móti eru minniskröfur miklu meiri.
Þó það sé hægt að stilla blokkastærðina er ekki mælt með því að stilla hana handvirkt, svo þú neyðist til að gefa Prometheus eins mikið minni og það þarf fyrir vinnuálag þitt.
Ef það er ekki nóg minni til að styðja við komandi straum mæligilda mun Prometheus falla úr minni eða OOM morðinginn kemst að því.
Það að bæta við skipti til að seinka hruninu þegar Prometheus verður uppiskroppa með minni hjálpar í raun ekki, því að nota þessa aðgerð veldur mikilli minnisnotkun. Ég held að það tengist Go, sorphirðu þess og hvernig það tekst á við skipti.
Önnur áhugaverð nálgun er að stilla höfuðblokkina þannig að hún sé skoluð yfir á disk á ákveðnum tíma, í stað þess að telja það frá upphafi ferlisins.
Eins og þú sérð á línuritinu eiga sér stað skolun á disk á tveggja tíma fresti. Ef þú breytir min-block-duration færibreytunni í eina klukkustund, þá munu þessar endurstillingar eiga sér stað á klukkutíma fresti og byrja eftir hálftíma.
Ef þú vilt nota þetta og önnur graf í Prometheus uppsetningunni þinni geturðu notað þetta . Það var hannað fyrir PMM en, með smávægilegum breytingum, passar það inn í hvaða Prometheus uppsetningu sem er.
Við erum með virkan blokk sem kallast höfuðblokk sem er geymd í minni; blokkir með eldri gögnum eru fáanlegar í gegnum mmap(). Þetta útilokar þörfina á að stilla skyndiminni sérstaklega, en þýðir líka að þú þarft að skilja eftir nægilegt pláss fyrir skyndiminni stýrikerfisins ef þú vilt spyrjast fyrir um gögn sem eru eldri en það sem höfuðblokkin rúmar.
Þetta þýðir líka að Prometheus sýndarminnisnotkun mun líta frekar hátt út, sem er ekki eitthvað til að hafa áhyggjur af.
Annar áhugaverður hönnunarpunktur er notkun WAL (skrifa fyrirfram log). Eins og þú sérð af geymsluskjölunum notar Prometheus WAL til að forðast hrun. Sérstakar aðferðir til að tryggja gagnaþol eru því miður ekki vel skjalfestar. Prometheus útgáfa 2.3.2 skolar WAL yfir á disk á 10 sekúndna fresti og það er ekki hægt að stilla þennan valkost.
Þjöppun
Prometheus TSDB er hannað eins og LSM (Log Structured Merge) verslun: höfuðblokkin er skoluð reglulega yfir á diskinn, á meðan þjöppunarbúnaður sameinar marga kubba saman til að forðast að skanna of marga kubba meðan á fyrirspurnum stendur. Hér má sjá fjölda blokka sem ég sá á prófunarkerfinu eftir álagsdag.
Ef þú vilt fræðast meira um verslunina geturðu skoðað meta.json skrána sem inniheldur upplýsingar um blokkirnar sem eru til og hvernig þær urðu til.
{
"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
}Samþjöppur í Prometheus eru bundnar við tímann sem höfuðblokkin er skoluð á diskinn. Á þessum tímapunkti geta nokkrar slíkar aðgerðir verið gerðar.
Svo virðist sem samþjöppanir séu ekki takmarkaðar á nokkurn hátt og geta valdið stórum I/O toppum á diskum meðan á framkvæmd stendur.
CPU hleðslu toppar
Auðvitað hefur þetta frekar neikvæð áhrif á hraða kerfisins og hefur einnig í för með sér alvarlega áskorun fyrir LSM geymslu: hvernig á að gera þjöppun til að styðja við háan beiðnihlutfall án þess að valda of miklum kostnaði?
Notkun minnis í þjöppunarferlinu lítur líka nokkuð áhugavert út.
Við getum séð hvernig, eftir þjöppun, breytist mest af minnisstöðu úr Cached í Free: þetta þýðir að hugsanlega verðmætar upplýsingar hafa verið fjarlægðar þaðan. Spennandi hvort það sé notað hér fadvice() eða einhver önnur lágmörkunartækni, eða er það vegna þess að skyndiminni var leyst úr kubbum sem eyðilögðust við þjöppun?
Bati eftir bilun
Að jafna sig eftir mistök tekur tíma og það er ekki að ástæðulausu. Fyrir komandi straum upp á milljón færslur á sekúndu, þurfti ég að bíða í um 25 mínútur á meðan endurheimt var framkvæmd að teknu tilliti til SSD drifsins.
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."Helsta vandamál bataferlisins er mikil minnisnotkun. Þrátt fyrir þá staðreynd að í venjulegum aðstæðum getur þjónninn unnið stöðugt með sama magni af minni, ef hann hrynur gæti hann ekki batnað vegna OOM. Eina lausnin sem ég fann var að slökkva á gagnasöfnun, koma upp þjóninum, láta hann batna og endurræsa með söfnun virkt.
Að hita upp
Önnur hegðun sem þarf að hafa í huga við upphitun er sambandið milli lítillar frammistöðu og mikillar auðlindanotkunar strax eftir ræsingu. Í sumum, en ekki öllum ræsingum, tók ég eftir alvarlegu álagi á CPU og minni.
Götur í minnisnotkun benda til þess að Prometheus geti ekki stillt öll söfn frá upphafi og sumar upplýsingar glatast.
Ég hef ekki fundið út nákvæmlega ástæðurnar fyrir miklu CPU og minni álagi. Mig grunar að þetta sé vegna þess að nýjar tímaraðir eru búnar til í höfuðblokkinni með hárri tíðni.
Örgjörvaálag hækkar
Auk þjöppunar, sem skapa nokkuð mikið I/O álag, tók ég eftir alvarlegum toppum í CPU álagi á tveggja mínútna fresti. Sprungurnar eru lengri þegar innflæðið er mikið og virðast vera af völdum sorphirðu Gos, þar sem að minnsta kosti sumir kjarna eru fullhlaðnir.
Þessi stökk eru ekki svo ómerkileg. Svo virðist sem þegar þetta gerist verði innri inngangspunktur og mælikvarðar Prometheus ótiltækur, sem veldur gagnaeyðum á þessum sömu tímabilum.
Þú getur líka tekið eftir því að Prometheus útflytjandinn slekkur á sér í eina sekúndu.
Við getum tekið eftir fylgni við sorphirðu (GC).
Ályktun
TSDB í Prometheus 2 er hröð, fær um að meðhöndla milljónir tímaraðir og á sama tíma þúsundir skráa á sekúndu með því að nota nokkuð hóflegan vélbúnað. CPU og diskur I/O nýting er líka áhrifamikil. Dæmið mitt sýndi allt að 200 mælikvarða á sekúndu á hvern kjarna sem notaður er.
Til að skipuleggja stækkun þarftu að muna um nægilegt magn af minni og þetta verður að vera raunverulegt minni. Minnismagnið sem ég sá var um 5 GB á hverjar 100 færslur á sekúndu af innstreymi, sem ásamt stýrikerfis skyndiminni gaf um 000 GB af uppteknu minni.
Auðvitað er enn mikið verk óunnið við að temja örgjörva og disk I/O toppa, og þetta kemur ekki á óvart miðað við hversu ungur TSDB Prometheus 2 er miðað við InnoDB, TokuDB, RocksDB, WiredTiger, en þeir voru allir með svipaða vandamál snemma á lífsferli þeirra.
Heimild: www.habr.com