Baza e të dhënave të serive temporale (TSDB, time series database) në Prometheus 2 është një shembull i shkëlqyer i një zgjidhjeje inxhinierike, e cila ofron përmirësime të rëndësishme në krahasim me ruajtjen v2 në Prometheus 1, në aspektin e shpejtësisë së grumbullimit të të dhënave dhe ekzekutimit të kërkesave, si dhe efikasitetit të përdorimit të burimeve. Ne kemi implementuar Prometheus 2 në Percona Monitoring and Management (PMM), dhe kam pasur mundësinë të shqyrtoj performancën e TSDB të Prometheus 2. Në këtë artikull do të flas për rezultatet e këtyre vëzhgimeve.
Teprica mesatare e punës në Prometheus
Për ata që janë mësuar të punojnë me bazat e të dhënave të qëllimit të përgjithshëm, teprica e zakonshme e punës në Prometheus është mjaft interesante. Shpejtësia e grumbullimit të të dhënave tendencion të arrijë një vlerë të qëndrueshme: zakonisht shërbimet që po monitoroni dërgojnë një numër të ngjashëm metrike, dhe infrastruktura ndryshon relativisht ngadalë.
Kërkesat për informacion mund të vijnë nga burime të ndryshme. Disa nga ato, siç janë alarmin, gjithashtu tendencion për të arritur në një vlerë të qëndrueshme dhe parashikueshme. Të tjerët, siç janë kërkesat e përdoruesve, mund të shkaktojnë shpërthime, edhe pse kjo nuk është karakteristike për shumicën e ngarkesës.
Testi i ngarkesës
Gjatë testimit, u përqendrova në aftësinë për të grumbulluar të dhëna. Kam zhvilluar Prometheus 2.3.2, e cila është përpiluar me Go 1.10.1 (si pjesë e PMM 1.14) në shërbimin Linode, duke përdorur këtë skript: . Për të gjeneruar ngarkesën në mënyrë sa më realiste, duke përdorur këtë Kam aktivizuar disa nodo MySQL me ngarkesë reale (Testi Sysbench TPC-C), secila prej të cilave emulonte 10 nodo Linux/MySQL.
Të gjitha testet e mëposhtme u realizuan në serverin Linode me tetë bërthama virtuale dhe 32 GigaByte memorie, mbi të cilin funksiononin 20 simulime ngarkese për monitorimin e dyqind instancave MySQL. Ose, në terma të Prometheus, 800 target-e, 440 mbledhje (scrapes) në sekondë, 380 mijë regjistrime (samples) në sekondë dhe 1.7 milion seri temporale aktive.
Dizajni
Qasje e zakonshme e bazave të dhënave tradicionale, përfshirë atë që përdorte Prometheus 1.x, është e bazuar në . Nëse nuk është e mjaftueshme për të përballuar ngarkesën, do të përballeni me vonesa të mëdha dhe disa kërkesa nuk do të realizohen. Përdorimi i memories në Prometheus 2 konfiguronohet përmes çelësit storage.tsdb.min-block-duration, i cili përcakton se sa kohë do të ruhen të dhënat në memorie para se të scrabbohen në disk (me një standard të paracaktuar prej 2 orësh). Sasia e memories që nevojitet do të varet nga numri i serive të përkohshme, etiketat (labels) dhe intensiteti i mbledhjes së të dhënave (scrapes) së bashku me fluksin e pastër të hyrjes. Në planin e hapësirës në disk, Prometheus synon të përdorë 3 bytes për çdo shënim (sample). Nga ana tjetër, kërkesat për memorie janë shumë më të larta.
Megjithatë, edhe pse ka mundësi për të konfiguruar madhësinë e bllokut, nuk rekomandohet ta përcaktoni atë manualisht, prandaj jeni përballë nevojës për t'i dhënë Prometheus aq memorie sa i kërkohet për ngarkesën tuaj.
Nëse ka mungesë të memories për të mbështetur fluksin e hyrjes së metrikeve, Prometheus do të dështojë me out of memory ose do të arrihet nga OOM killer.
Të shtoni swap për të shtyrë momentin e dështimit kur Prometheus nuk ka më memorie, nuk ndihmon shumë, sepse përdorimi i kësaj funksionaliteti shkakton konsum të dhunshëm të memories. Mendoj se ka të bëjë me Go, me menaxhimin e plehrave dhe me mënyrën sesi punon me swap.
Një qasje tjetër interesante është të konfigurosh resetimin e bllokut të kokës në disk në një kohë të caktuar, në vend që ta numërosh atë nga koha e fillimit të procesit.
Siç mund ta shihni nga grafiku, resetimet në disk ndodhin çdo dy orë. Nëse e ndryshoni parametrin min-block-duration në një orë, këto resetime do të ndodhin çdo orë, duke filluar pas gjysmë ore.
Nëse dëshironi të përdorni këtë dhe grafika të tjera në instalimin tuaj të Prometheus, mund të përdorni këtë . Ai është zhvilluar për PMM, por, me disa ndryshime të vogla, i përgjigjet çdo instalimi të Prometheus.
Ne kemi një bllok aktiv, të quajtur bllok i kokës, i cili ruhet në memorie; blloqet me të dhënat më të vjetra janë të disponueshme përmes mmap(). Kjo eliminon nevojën për të konfiguruar cache veçmas, por gjithashtu do të thotë se ju duhet të lëvizni hapësirë të mjaftueshme për cache-in e sistemit operativ, nëse dëshironi të bëni kërkesa për të dhënat më të larta se ato që përfshin blloku i kokës.
Gjithashtu, kjo do të thotë se konsumimi i memories virtuale nga Prometheus do të duket mjaft i lartë, për të cilin nuk duhet të shqetësoheni.
Një moment tjetër interesant në dizajn është përdorimi i WAL (write ahead log). Siç tregohet në dokumentacionin për ruajtjen, Prometheus përdor WAL për të shmangur humbjet gjatë crashes. Mekanizmat specifikë për garantimin e qëndrueshmërisë së të dhënave, fatkeqësisht, nuk janë dokumentuar mjaftueshëm. Versioni Prometheus 2.3.2 shtron WAL në diskut çdo 10 sekonda, dhe ky parametr nuk konfigurohet nga përdoruesi.
Kombinimet (Compactions)
Prometheus TSDB është projektuar sipas modelit të ruajtjes LSM (Log Structured Merge): blloku i kryesor shkarkohet periodikisht në disk, ndërkohë që mekanizmi i kombinimit bashkon disa blloqe për të shmangur skanimin e shumë blloqeve gjatë kërkesave. Këtu tregohet numri i blloqeve që kam vëzhguar në sistemin testues pas një dite ngarkese.
Nëse dëshironi të dini më shumë për ruajtjen, mund të shqyrtoni skedarin meta.json, i cili ka informacion mbi blloqet ekzistuese dhe se si u shfaqën ato.
{
"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
}Kombinimet në Prometheus lidhen me kohën e shkarkimit të bllokut kryesor në disk. Në këtë moment mund të kryhen disa operacione të tilla.
Duket se kompresimet nuk kanë asnjë kufizim dhe mund të shkaktojnë ngritje të mëdha të I/O të diskut gjatë ekzekutimit.
Ngritjet e ngarkesës së CPU
Sigurisht, kjo ndikon në mënyrë negative në shpejtësinë e sistemit dhe përbën një sfidë të madhe për magazinat LSM: si të realizohet kompresimi për të mbajtur një shpejtësi të lartë të kërkesave dhe njëkohësisht të mos shkaktohet një overhead të tepërt?
Përdorimi i memories gjatë procesit të kompresimit gjithashtu duket mjaft interesant.
Mund të shohim se pas kompresimit, pjesa më e madhe e memories ndryshon gjendjen nga Cached në Free: kjo do të thotë se informacioni potencialisht i çmuar është larguar nga aty. Është interesante nëse përdoret fadvice() apo ndonjë teknikë tjetër minimizimi, ose nëse kjo shkaktohet nga lëshimi i caches nga blloqet e shkatërruara gjatë kompresimit?
Rindërtimi pas dështimit
Rindërtimi pas dështimeve merr kohë, dhe kjo është e arsyeshme. Për një fluks hyrës prej një milioni regjistrimesh në sekondë, më duhej të prisja rreth 25 minuta derisa të kryhej rindërtimi duke marrë parasysh diskun SSD.
nivel=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Duke Prometheusin" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
nivel=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)"
nivel=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))"
nivel=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
nivel=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Fill për lidhje" address=:9090
nivel=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Duke filluar TSDB ..."
nivel=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="gjetur bllok të shëndetshëm" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
nivel=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="prefiksi i routerit" prefix=\/prometheus
nivel=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="gjetur bllok të shëndetshëm" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
nivel=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="gjetur bllok të shëndetshëm" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
nivel=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="gjetur bllok të shëndetshëm" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
nivel=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="gjetur bllok të shëndetshëm" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
nivel=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="Korrupsioni i WAL u zbulua; duket" err="kontrolli i papritur CRC32 d0465484, duhen 0" file=\/opt\/prometheus\/data\/prom2-data\/wal\/007357 pos=15504363
nivel=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB e filluar"
nivel=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Duke ngarkuar skedarin e konfigurimit" filename=\/etc\/prometheus.yml
nivel=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Ngarkimi përfundoi i skedarit të konfigurimit" filename=\/etc\/prometheus.yml
nivel=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Serveri është gati për të pranuar kërkesat web."Problemi kryesor i procesit të rikuperimit është konsumimi i lartë i memorie. Megjithatë, kur serveri funksionon normalisht me të njëjtin sasi memorie, në rast të rënies ai mund të mos ngrihet për shkak të OOM. Zgjidhja e vetme që kam gjetur është të çaktivizoj mbledhjen e të dhënave, të ngre serverin, t'i lejoj atij të rikuperohet dhe ta rindez dërguar me mbledhjen e aktivizuar.
Ngritja
Një sjellje tjetër që duhet mbajtur mend gjatë ngrohjes është raporti midis performancës së ulët dhe konsumit të lartë të burimeve menjëherë pas nisjes. Gjatë disa, por jo të gjitha ngjyrave kam vërejtur ngarkesë të madhe të CPU-së dhe memories.
Rëniet në përdorimin e memories tregojnë se Prometheus nuk mund të konfigurojë të gjitha mbledhjet që në fillim, dhe disa informacione përfundojnë duke humbur.
Nuk nuk kam zbuluar arsyet e sakta për ngarkesën e lartë në procesor dhe kujtesë. Dyshoj se është e lidhur me krijimin e serive të reja përkohësore në bllokun kryesor me një frekuencë të lartë.
Shkëputjet e ngarkesës në CPU
Përveç vulave që krijojnë një ngarkesë të konsiderueshme në I/O, kam vënë re shkëputje serioze të ngarkesës në procesor çdo dy minuta. Shkëputjet zgjaten më gjatë kur ka njëyshe të lartë të hyrjes dhe duket se shkaktohen nga mbledhësi i mbeturinave Go, të paktën disa bërthama janë të ngarkuara plotësisht.
Këto shkëputje nuk janë aq të papërfillshme. Duket se kur ndodhin, pika e brendshme e hyrjes dhe metrikat Prometheus bëhen të paarritshme, duke shkaktuar boshllëqe në të dhëna në ato po ato periudha.
Gjithashtu, mund të vërehet se eksportuesi Prometheus ngre një blokim për një sekondë.
Mund të vërejmë korelacionet me pastrimin e mbeturinave (GC).
Përfundim
TSDB në Prometheus 2 vepron shpejt, duke qenë në gjendje të përballojë miliona seri përkohësore dhe njëkohësisht mijëra regjistrime, duke përdorur pajisje mjaft modeste. Shfrytëzimi i CPU dhe I/O disk është gjithashtu impresionues. Shembulli im tregoi deri në 200,000 metrika në sekondë për një bërthamë të përdorur.
Për planifikimin e zgjerimit, duhet të kemi parasysh sasinë e mjaftueshme të kujtesës, dhe kjo duhet të jetë kujtesë reale. Sasia e kujtesës që kam vërejtur ishte rreth 5 GB për 100,000 regjistrime në sekondë të fluksit të hyrjes, që së bashku me memorizimin e sistemit operativ përbënte rreth 8 GB të zënë të kujtesës.
Sigurisht, ende ka shumë punë për të kontrolluar shkëputjet e CPU dhe I/O disk, dhe kjo nuk është befasi, duke parë se sa e re është TSDB Prometheus 2 krahasuar me InnoDB, TokuDB, RocksDB, WiredTiger, por të gjitha ato kishin probleme të ngjashme në fillim të ciklit të jetës.
Burimi: habr.com
