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
