Databasa rêzeya demê (TSDB) di Prometheus 2 de mînakek hêja ya çareseriyek endezyariyê ye ku di warê leza berhevkirina daneyê, pêkanîna pirsê, û karbidestiya çavkaniyê de li ser hilanîna v2 ya li Prometheus 1 çêtirkirinên mezin pêşkêşî dike. Me Prometheus 2 di Çavdêrî û Rêvebiriya Percona (PMM) de bicîh dikir û min fersend dît ku performansa Prometheus 2 TSDB fam bikim. Di vê gotarê de ez ê li ser encamên van çavdêriyan biaxivim.
Average Prometheus Workload
Ji bo yên ku bi databasên mebesta gelemperî re mijûl dibin, xebata tîpîk Prometheus pir balkêş e. Rêjeya berhevkirina daneyan aram dibe: bi gelemperî karûbarên ku hûn çavdêriyê dikin bi qasî heman hejmarê metrîkan dişînin, û binesaziya bi hêdî hêdî diguhezîne.
Daxwazên agahdariyê dibe ku ji çavkaniyên cihêreng werin. Hin ji wan, wekî hişyarî, di heman demê de ji bo nirxek aram û pêşbînîkirî jî hewl didin. Yên din, wekî daxwazên bikarhêner, dibe ku bibe sedema teqînan, her çend ev ji bo piraniya barkêşan ne wusa ye.
Testa barkirinê
Di dema ceribandinê de, min bal kişand ser şiyana berhevkirina daneyan. Min Prometheus 2.3.2 ku bi Go 1.10.1 (wek beşek ji PMM 1.14) hatî berhev kirin li ser karûbarê Linode bi karanîna vê skrîptê vekir: . Ji bo nifşa barkirinê ya herî rastîn, vê bikar bînin Min gelek girêkên MySQL bi barek rastîn (Sysbench TPC-C Test) dest pê kir, ku her yek ji wan 10 girêkên Linux/MySQL emûl kirin.
Hemî ceribandinên jêrîn li ser serverek Linode bi heşt navgînên virtual û 32 GB bîranîn hatin kirin, 20 simulasyonên barkirinê yên du sed mînakên MySQL-ê çavdêrî dikin. An jî, li gorî Prometheus, 800 hedef, di çirkeyê de 440 şop, di çirkeyê de 380 hezar tomar û 1,7 mîlyon rêzikên dema çalak.
design
Nêzîkatiya asayî ya databasên kevneşopî, di nav de ya ku ji hêla Prometheus 1.x ve hatî bikar anîn, ev e . Ger hilgirtina barkirinê ne bes be, hûn ê derengmayînên mezin biceribînin û hin daxwaz dê têk biçin. Bikaranîna bîranînê di Prometheus 2 de bi bişkojkê ve tê mîheng kirin storage.tsdb.min-block-duration, ku diyar dike ka dê çiqas tomar di bîranînê de werin hilanîn berî ku li ser dîskê were hilanîn (pêşniyaz 2 saet e). Hêjmara bîranîna ku hewce dike dê bi hejmara rêzikên dem, etîket, û xêzên ku li tevna hatina torê ve hatine zêdekirin ve girêdayî be. Di warê cîhê dîskê de, Prometheus armanc dike ku her tomar (nimûne) 3 byte bikar bîne. Ji hêla din ve, hewcedariyên bîranînê pir zêde ne.
Her çend gengaz e ku meriv mezinahiya blokê mîheng bike jî, nayê pêşniyar kirin ku meriv wê bi destan mîheng bike, ji ber vê yekê hûn neçar in ku hûn Prometheus bi qasî ku ji bo xebata we hewce dike bîranînê bidin.
Ger bîranînek têr tune ku piştgirî bide herika hatina metrîkan, Prometheus dê ji bîrê derkeve an jî kujerê OOM wê bigihîje wê.
Zêdekirina swap-ê ji bo derengxistina qezayê dema ku Prometheus ji bîrê xilas bibe bi rastî ne arîkar e, ji ber ku karanîna vê fonksiyonê dibe sedema vexwarina bîranîna teqemenî. Ez difikirim ku ew tiştek bi Go, berhevkarê wê yê çopê û awayê ku ew bi guheztinê re mijûl dibe re têkildar e.
Nêzîkatiyek din a balkêş ev e ku meriv bloka serê xwe mîheng bike da ku di demek diyarkirî de li ser dîskê were rijandin, li şûna ku ew ji destpêka pêvajoyê ve were jimartin.
Wekî ku hûn ji grafîkê jî dibînin, her du demjimêran carekê rijandina dîskê çêdibe. Heke hûn pîvana min-block-demjimêr biguhezînin yek saetê, wê hingê ev vesazkirin dê her demjimêrek çêbibin, piştî nîv saetê dest pê bikin.
Heke hûn dixwazin vê û grafikên din di sazkirina Prometheus de bikar bînin, hûn dikarin vê bikar bînin . Ew ji bo PMM-ê hate sêwirandin lê, bi guheztinên piçûk, di her sazkirina Prometheus de cih digire.
Blokek me ya çalak heye ku jê re dibêjin bloka serê ku di bîranînê de tê hilanîn; blokên bi daneyên kevntir bi rê ve têne peyda kirin mmap(). Ev hewcedariya mîhengkirina cache-ê ji hev cuda ji holê radike, lê di heman demê de tê vê wateyê ku hûn hewce ne ku cîhê têra xwe ji cacheya pergala xebitandinê re bihêlin ger hûn dixwazin daneya ji ya ku bloka serê dikare tê de kevintir bipirsin.
Ev jî tê vê wateyê ku vexwarina bîranîna virtual ya Prometheus dê pir zêde xuya bike, ku ne tiştek e ku meriv pê xemgîn bibe.
Xalek din a sêwiranê ya balkêş karanîna WAL-ê ye (qeyda pêşîn binivîsin). Wekî ku hûn ji belgeyên hilanînê dibînin, Prometheus WAL bikar tîne da ku ji qezayan dûr bixe. Mekanîzmayên taybetî yên ji bo garantîkirina zindîbûna daneyê, mixabin, baş nehatine belge kirin. Guhertoya Prometheus 2.3.2 her 10 saniyeyan carekê WAL-ê li ser dîskê dişewitîne û ev vebijark ji bikarhêner nayê mîheng kirin.
Compactions
Prometheus TSDB wekî dikanek LSM (Log Structured Merge) hatiye sêwirandin: bloka serî dem bi dem li ser dîskê tê şûştin, dema ku mekanîzmayek berhevkirinê gelek blokan bi hev re digihîne hev da ku di dema pirsan de pir blokan nexebitîne. Li vir hûn dikarin hejmara blokên ku min li ser pergala ceribandinê piştî rojek barkirinê dît, bibînin.
Heke hûn dixwazin di derheqê firotgehê de bêtir fêr bibin, hûn dikarin pelê meta.json, ku agahdariya di derheqê blokên berdest û çawaniya wan de hene, lêkolîn bikin.
{
"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
}Tevlihevkirinên di Prometheus de bi dema ku bloka serî bi dîskê ve tê rijandin ve girêdayî ye. Di vê demê de, dibe ku çend operasyonên weha bêne kirin.
Wusa dixuye ku berhevok bi ti awayî ne sînorkirî ne û dikarin di dema darvekirinê de bibin sedema çîpên mezin ên dîska I/O.
Barkirina CPU-ê zêde dibe
Bê guman, ev bandorek neyînî li ser leza pergalê dike, û di heman demê de ji bo hilanîna LSM-ê jî pirsgirêkek ciddî derdixe holê: meriv çawa berhevokê dike da ku rêjeyên daxwaziya bilind piştgirî bike bêyî ku bibe sedema pir zêde?
Bikaranîna bîranînê di pêvajoya berhevkirinê de jî pir balkêş xuya dike.
Em dikarin bibînin ka çawa, piştî berhevkirinê, piraniya bîranînê ji Cached berbi Belaş rewşa diguhezîne: ev tê vê wateyê ku agahdariya potansiyel hêja ji wir hatine rakirin. Meraq e gelo ew li vir tê bikar anîn fadvice() an teknîkek din a piçûkkirinê, an ji ber ku cache ji blokên ku di dema berhevkirinê de hatine hilweşandin xilas bû?
Vejandina piştî têkçûnê
Vejandina ji têkçûn dem digire, û ji ber sedemek baş. Ji bo pêvekek gihîştî ya mîlyonek tomar di çirkeyê de, ez neçar bûm ku nêzîkê 25 hûrdeman li bendê bim dema ku başbûn bi hesabê ajokera SSD-ê hate kirin.
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."Pirsgirêka sereke ya pêvajoya başbûnê vexwarina bîranîna zêde ye. Tevî vê rastiyê ku di rewşek normal de server dikare bi heman mîqdara bîranînê re bi îstîqrar bixebite, heke ew têk biçe dibe ku ji ber OOM-ê xelas nebe. Yekane çareya ku min dît ev bû ku berhevkirina daneyan neçalak bikim, serverê rakim, bihêlim ku ew vegere û bi berhevkirina çalak re ji nû ve dest pê bike.
Germ kirin
Tevgerek din a ku divê di dema germbûnê de ji bîr mekin têkiliya di navbera performansa kêm û vexwarina çavkaniyê ya zêde piştî destpêkê de ye. Di dema hin, lê ne hemî destpêkirinan de, min barek cidî li ser CPU û bîranînê dît.
Valahiyên di karanîna bîranînê de destnîşan dikin ku Prometheus ji destpêkê ve nikare hemî berhevokan mîheng bike, û hin agahdarî winda dibin.
Min sedemên tam ji bo barkirina CPU û bîranîna bilind fam nekir. Ez guman dikim ku ev ji ber afirandina rêzikên dema nû yên di bloka serî de bi frekansa bilind e.
Barkirina CPU zêde dibe
Ji bilî berhevkirinan, ku bargiraniyek I/O ya pir zêde diafirîne, min her du hûrdeman carekê di barkirina CPU-yê de pêlên cidî dît. Teqîn dirêjtir in dema ku herikîna têketinê zêde ye û dixuye ku ji ber berhevkara çopê ya Go-yê çêdibe, bi kêmî ve hin core bi tevahî hatine barkirin.
Ev bazdan ne ew qas kêm in. Wusa dixuye ku gava ev çêdibin, xala têketina hundurîn a Prometheus û metrîkên ne berdest dibin, di heman demê de dibe sedema qutbûna daneyan.
Her weha hûn dikarin bala xwe bidin ku hinardekarê Prometheus ji bo yek saniyeyê disekine.
Em dikarin pêwendiyan bi berhevkirina çopê (GC) re bibînin.
encamê
TSDB di Prometheus 2 de bilez e, ku karibe bi mîlyonan rêzikên demê û di heman demê de bi hezaran tomar di çirkeyê de bi karanîna nermalava pir nerm bi kar bîne. Bikaranîna I/O ya CPU û dîskê jî balkêş e. Mînaka min ji bo her bingehek ku hatî bikar anîn heya 200 metrîk di çirkeyê de nîşan da.
Ji bo plansazkirina berfirehbûnê, hûn hewce ne ku têra bîranînê bi bîr bînin, û divê ev bîranînek rastîn be. Rêjeya bîranîna ku min dîtiye bi qasî 5 GB ji her 100 tomar di her çirkeyek dahatûyê de ye, ku digel cacheya pergala xebitandinê nêzîkê 000 GB bîranîna dagirkirî da.
Bê guman, hîn jî gelek kar heye ku were kirin ji bo ku meriv çîpên CPU û dîskê I/O rabike, û ev ne ecêb e ji ber ku meriv çawa ciwan TSDB Prometheus 2 bi InnoDB, TokuDB, RocksDB, WiredTiger re tê berhev kirin, lê ew hemî jî mîna hev bûn. pirsgirêkên di destpêka jiyana xwe de.
Source: www.habr.com