Mae'r gronfa ddata cyfres amser (TSDB) yn Prometheus 2 yn enghraifft wych o ddatrysiad peirianneg sy'n cynnig gwelliannau sylweddol dros storfa Prometheus 2 v1 o ran casglu data a chyflymder gweithredu ymholiadau, ac effeithlonrwydd adnoddau. Roeddem yn gweithredu Prometheus 2 yn Monitro a Rheoli Percona (PMM) a chefais gyfle i ddeall perfformiad Prometheus 2 TSDB. Yn yr erthygl hon byddaf yn siarad am ganlyniadau'r sylwadau hyn.
Llwyth Gwaith Cyfartalog Prometheus
I'r rhai sydd wedi arfer delio Γ’ chronfeydd data pwrpas cyffredinol, mae llwyth gwaith nodweddiadol Prometheus yn eithaf diddorol. Mae cyfradd cronni data yn tueddu i fod yn sefydlog: fel arfer mae'r gwasanaethau rydych chi'n eu monitro yn anfon tua'r un faint o fetrigau, ac mae'r seilwaith yn newid yn gymharol araf.
Gall ceisiadau am wybodaeth ddod o wahanol ffynonellau. Mae rhai ohonynt, fel rhybuddion, hefyd yn anelu at werth sefydlog a rhagweladwy. Gall eraill, megis ceisiadau defnyddwyr, achosi pigau, er nad yw hyn yn wir am y rhan fwyaf o'r llwyth gwaith.
Prawf llwyth
Yn ystod y profion, canolbwyntiais ar y gallu i gronni data. Defnyddiais Prometheus 2.3.2 a luniwyd gyda Go 1.10.1 (fel rhan o PMM 1.14) ar wasanaeth Linode gan ddefnyddio'r sgript hon: . Ar gyfer y genhedlaeth llwyth mwyaf realistig, gyda hyn Rhedais sawl nod MySQL gyda llwyth go iawn (Prawf Sysbench TPC-C), ac roedd pob un ohonynt yn efelychu nodau 10 Linux / MySQL.
Perfformiwyd yr holl brofion canlynol ar weinydd Linode gydag wyth vCores a 32 GB o gof yn rhedeg 20 efelychiad llwyth i fonitro 800 o achosion MySQL. Neu, o ran Prometheus, 440 o dargedau (targedau), 380 o ffioedd (crafiadau) yr eiliad, 1,7 mil o gofnodion (samplau) yr eiliad a XNUMX miliwn o gyfresi amser gweithredol.
Dylunio
Y dull cronfa ddata traddodiadol arferol, gan gynnwys yr un a ddefnyddir gan Prometheus 1.x, yw . Os nad yw'n ddigon i drin y llwyth, byddwch yn profi hwyrni uchel ac ni fydd rhai ceisiadau'n cael eu cyflawni. Mae modd ffurfweddu defnydd cof yn Prometheus 2 trwy allwedd storage.tsdb.min-block-duration, sy'n pennu pa mor hir y bydd cofnodion yn cael eu cadw yn y cof cyn eu fflysio i ddisg (diofyn yw 2 awr). Bydd faint o gof sydd ei angen yn dibynnu ar nifer y cyfresi amser, labeli, a sgrapiau, ynghyd Γ’'r mewnbwn net. O ran gofod disg, nod Prometheus yw defnyddio 3 beit fesul ysgrifennu (sampl). Ar y llaw arall, mae'r gofynion cof yn llawer uwch.
Er ei bod yn bosibl ffurfweddu maint y bloc, ni argymhellir ei osod Γ’ llaw, felly mae gennych y dasg o roi cymaint o gof i Prometheus ag sydd ei angen ar gyfer eich llwyth gwaith.
Os nad oes digon o gof i gefnogi'r llif metrigau sy'n dod i mewn, bydd Prometheus yn cwympo o'r cof neu'n cael ei ddal gan lofrudd OOM.
Nid yw ychwanegu cyfnewid i ohirio'r ddamwain pan fydd Prometheus yn rhedeg allan o gof yn helpu mewn gwirionedd, oherwydd mae defnyddio'r nodwedd hon yn achosi ffrwydradau cof. Rwy'n meddwl ei fod yn ymwneud Γ’ Go, ei gasglwr sbwriel, a sut mae'n gweithio gyda chyfnewid.
Ymagwedd ddiddorol arall yw gosod y bloc pen i gael ei fflysio i ddisg ar amser penodol, yn lle ei gyfrif o'r amser y dechreuodd y broses.
Fel y gwelwch o'r graff, mae fflysio i ddisg yn digwydd bob dwy awr. Os byddwch chi'n newid y paramedr hyd min-bloc i awr, yna bydd yr ailosodiadau hyn yn digwydd bob awr, gan ddechrau mewn hanner awr.
Os ydych chi eisiau defnyddio hwn a graffiau eraill yn eich gosodiad Prometheus, gallwch chi ddefnyddio hwn . Fe'i cynlluniwyd ar gyfer PMM, ond gydag ychydig o addasiadau mae'n cyd-fynd ag unrhyw osodiad Prometheus.
Mae gennym bloc gweithredol, a elwir yn y bloc pen, sy'n cael ei storio yn y cof; blociau gyda data hΕ·n ar gael trwy mmap(). Mae hyn yn dileu'r angen i ffurfweddu'r storfa ar wahΓ’n, ond mae hefyd yn golygu bod angen i chi adael digon o le ar gyfer storfa'r system weithredu os ydych chi am ymholi data sy'n hΕ·n na'r bloc pen.
Mae hefyd yn golygu y bydd defnydd cof rhithwir Prometheus yn edrych yn eithaf uchel, nad yw'n ddim byd i boeni amdano.
Pwynt dylunio diddorol arall yw'r defnydd o WAL (ysgrifennwch log ymlaen llaw). Fel y gwelwch o ddogfennaeth y gadwrfa, mae Prometheus yn defnyddio WAL i osgoi damweiniau. Yn anffodus, nid yw mecanweithiau penodol ar gyfer gwarantu goroesiad data wedi'u dogfennu'n dda. Mae Prometheus 2.3.2 yn fflysio WAL i ddisg bob 10 eiliad ac nid yw'r gosodiad hwn yn ddefnyddiwr.
Morloi
Mae Prometheus TSDB wedi'i ddylunio yn y ddelwedd o storfa LSM (Log Uno Strwythuredig - coeden uno Γ’ strwythur log): mae'r bloc pen yn cael ei fflysio o bryd i'w gilydd i ddisg, tra bod y mecanwaith cywasgu yn uno sawl bloc gyda'i gilydd er mwyn osgoi sganio gormod o flociau ar geisiadau. Yma gallwch weld nifer y blociau a welais ar y system brawf ar Γ΄l diwrnod o lwyth.
Os ydych chi eisiau dysgu mwy am storio, gallwch edrych ar y ffeil meta.json, sydd Γ’ gwybodaeth am y blociau sydd ar gael a sut y daethant i fodolaeth.
{
"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
}Mae morloi yn Prometheus yn gysylltiedig Γ’'r amser y mae'r bloc pen yn cael ei fflysio i ddisg. Ar y pwynt hwn, gellir cynnal nifer o weithrediadau o'r fath.
Mae'n ymddangos nad yw cywasgiadau'n gyfyngedig mewn unrhyw ffordd a gallant achosi pigau I/O disg mawr yn ystod gweithredu.
pigau llwyth CPU
Wrth gwrs, mae hyn yn cael effaith negyddol braidd ar gyflymder y system, ac mae hefyd yn her ddifrifol i storfeydd LSM: sut i wneud cywasgiadau i gefnogi cyflymder ymholiad uchel heb achosi gormod o orbenion?
Mae'r defnydd o gof yn y broses gywasgu hefyd yn edrych yn eithaf chwilfrydig.
Gallwn weld sut, ar Γ΄l cywasgu, mae'r rhan fwyaf o'r cof yn newid cyflwr o Cached i Free: mae'n golygu bod gwybodaeth a allai fod yn werthfawr wedi'i thynnu oddi yno. Rhyfedd os caiff ei ddefnyddio yma fadvice() neu ryw dechneg lleihau arall, neu ai oherwydd bod y celc wedi'i wagio o flociau a ddinistriwyd gan gywasgiad?
Adfer Methiant
Mae adferiad ar Γ΄l trychineb yn cymryd amser, ac am reswm da. Ar gyfer ffrwd sy'n dod i mewn o filiwn o gofnodion yr eiliad, bu'n rhaid i mi aros tua 25 munud tra bod yr adferiad yn cymryd i ystyriaeth y gyriant SSD.
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."Prif broblem y broses adfer yw defnydd cof uchel. Er y gall y gweinydd redeg yn sefydlog gyda'r un faint o gof mewn sefyllfa arferol, os yw'n damwain, efallai na fydd yn codi oherwydd OOM. Yr unig ateb rydw i wedi'i ddarganfod yw diffodd casglu data, dod Γ’'r gweinydd i fyny, gadael iddo adfer, ac ailgychwyn gyda chasgliad wedi'i alluogi.
Cynhesu
Ymddygiad arall i'w gadw mewn cof wrth gynhesu yw'r gymhareb perfformiad isel i ddefnydd uchel o adnoddau yn syth ar Γ΄l cychwyn. Yn ystod rhai cychwyniadau, ond nid pob un, sylwais ar lwyth difrifol ar y CPU a'r cof.
Mae gostyngiadau yn y defnydd o gof yn dangos na all Prometheus ffurfweddu'r holl ffioedd o'r cychwyn, a chollir rhywfaint o wybodaeth.
Nid wyf wedi darganfod yr union resymau dros y CPU uchel a'r defnydd o gof. Rwy'n amau ββββbod hyn oherwydd creu cyfresi amser newydd yn y bloc pen gydag amledd uchel.
pigau CPU
Yn ogystal Γ’ dwyseddau, sy'n creu llwyth I / O eithaf uchel, rwyf wedi sylwi ar bigau difrifol mewn llwyth CPU bob dwy funud. Mae'r pyliau'n hirach gyda thraffig uchel yn dod i mewn ac yn edrych fel eu bod yn cael eu hachosi gan y casglwr sbwriel Go, mae o leiaf rhai creiddiau wedi'u llwytho'n llawn.
Nid yw'r neidiau hyn mor ddi-nod. Mae'n ymddangos, pan fyddant yn digwydd, nad yw pwynt mynediad mewnol a metrigau Prometheus ar gael, gan achosi cwympiadau data o fewn yr un cyfnodau amser.
Efallai y byddwch hefyd yn sylwi bod yr allforiwr Prometheus yn cau i lawr am eiliad.
Gallwn weld cydberthynas Γ’ chasglu sbwriel (GC).
Casgliad
Mae TSDB yn Prometheus 2 yn gyflym, yn gallu trin miliynau o gyfresi amser ac ar yr un pryd miloedd o ysgrifenniadau yr eiliad gan ddefnyddio caledwedd eithaf cymedrol. Mae'r defnydd CPU a disg I/O hefyd yn drawiadol. Roedd fy enghraifft yn dangos hyd at 200 metrig yr eiliad fesul craidd a ddefnyddir.
Er mwyn cynllunio ar gyfer ehangu, mae angen i chi gofio bod digon o gof, a rhaid iddo fod yn gof go iawn. Roedd maint y cof a ddefnyddiwyd, a sylwais, tua 5 GB fesul 100 o gofnodion yr eiliad o'r ffrwd sy'n dod i mewn, a roddodd, ynghyd Γ’ storfa'r system weithredu, tua 000 GB o gof wedi'i feddiannu.
Wrth gwrs, mae llawer o waith i'w wneud o hyd i ddofi pigau I / O CPU a disg, ac nid yw hyn yn syndod, o ystyried pa mor ifanc mae TSDB Prometheus 2 yn cael ei gymharu ag InnoDB, TokuDB, RocksDB, WiredTiger, ond roedd ganddyn nhw i gyd. problemau tebyg ar ddechrau eu cylch bywyd.
Ffynhonnell: hab.com