Hifadhidata ya mfululizo wa wakati (TSDB) katika Prometheus 2 ni mfano bora wa suluhisho la kihandisi ambalo hutoa maboresho makubwa juu ya hifadhi ya v2 katika Prometheus 1 kwa suala la kasi ya kukusanya data, utekelezaji wa hoja, na ufanisi wa rasilimali. Tulikuwa tunatekeleza Prometheus 2 katika Percona Monitoring and Management (PMM) na nilipata fursa ya kuelewa utendakazi wa Prometheus 2 TSDB. Katika makala hii nitazungumzia kuhusu matokeo ya uchunguzi huu.
Wastani wa Mzigo wa Kazi wa Prometheus
Kwa wale waliozoea kushughulika na hifadhidata za madhumuni ya jumla, mzigo wa kawaida wa Prometheus unavutia sana. Kiwango cha mkusanyiko wa data huwa thabiti: kwa kawaida huduma unazofuatilia hutuma takriban idadi sawa ya vipimo, na miundombinu hubadilika polepole.
Maombi ya habari yanaweza kutoka kwa vyanzo anuwai. Baadhi yao, kama vile arifa, pia hujitahidi kupata thamani thabiti na inayoweza kutabirika. Nyingine, kama vile maombi ya watumiaji, zinaweza kusababisha milipuko, ingawa sivyo ilivyo kwa mizigo mingi ya kazi.
Mtihani wa mzigo
Wakati wa kupima, nilizingatia uwezo wa kukusanya data. Nilisambaza Prometheus 2.3.2 iliyokusanywa na Go 1.10.1 (kama sehemu ya PMM 1.14) kwenye huduma ya Linode kwa kutumia hati hii: . Kwa kizazi cha kweli cha mzigo, kwa kutumia hii Nilizindua nodi kadhaa za MySQL na mzigo halisi (Sysbench TPC-C Test), ambayo kila moja iliiga nodi 10 za Linux/MySQL.
Majaribio yote yafuatayo yalifanywa kwenye seva ya Linode yenye cores nane virtual na 32 GB ya kumbukumbu, inayoendesha simuleringar 20 za ufuatiliaji wa matukio mia mbili ya MySQL. Au, kwa maneno ya Prometheus, malengo 800, mikwaruzo 440 kwa sekunde, rekodi elfu 380 kwa sekunde, na mfululizo wa saa amilifu milioni 1,7.
Design
Mbinu ya kawaida ya hifadhidata za kitamaduni, pamoja na ile inayotumiwa na Prometheus 1.x, ni . Ikiwa haitoshi kushughulikia mzigo, utapata latencies ya juu na maombi mengine yatashindwa. Utumiaji wa kumbukumbu katika Prometheus 2 unaweza kusanidiwa kupitia ufunguo storage.tsdb.min-block-duration, ambayo huamua muda gani rekodi zitawekwa kwenye kumbukumbu kabla ya kusambaza kwenye diski (chaguo-msingi ni saa 2). Kiasi cha kumbukumbu kinachohitajika kitategemea idadi ya mfululizo wa saa, lebo na mikwaruzo iliyoongezwa kwenye mtiririko wa wavu unaoingia. Kwa upande wa nafasi ya diski, Prometheus inalenga kutumia byte 3 kwa rekodi (sampuli). Kwa upande mwingine, mahitaji ya kumbukumbu ni ya juu zaidi.
Ingawa inawezekana kusanidi saizi ya kizuizi, haipendekezi kusanidi kwa mikono, kwa hivyo unalazimika kumpa Prometheus kumbukumbu nyingi kama inavyohitaji kwa mzigo wako wa kazi.
Ikiwa hakuna kumbukumbu ya kutosha kusaidia mtiririko unaoingia wa metriki, Prometheus atasahaulika au muuaji wa OOM ataifikia.
Kuongeza ubadilishaji ili kuchelewesha ajali Prometheus inapoishiwa na kumbukumbu haisaidii, kwa sababu kutumia chaguo hili la kukokotoa husababisha matumizi ya kumbukumbu kulipuka. Nadhani inahusiana na Go, mtoaji wake wa taka na jinsi inavyoshughulika na ubadilishaji.
Njia nyingine ya kuvutia ni kusanidi kizuizi cha kichwa ili kusafishwa kwa diski kwa wakati fulani, badala ya kuhesabu tangu mwanzo wa mchakato.
Kama unaweza kuona kutoka kwa grafu, flushes hadi diski hutokea kila masaa mawili. Ukibadilisha parameter ya min-block-duration hadi saa moja, basi hizi upya zitatokea kila saa, kuanzia baada ya nusu saa.
Ikiwa unataka kutumia grafu hii na nyingine katika usakinishaji wako wa Prometheus, unaweza kutumia hii . Iliundwa kwa ajili ya PMM lakini, pamoja na marekebisho madogo, inafaa katika usakinishaji wowote wa Prometheus.
Tuna block amilifu inayoitwa block block ambayo imehifadhiwa kwenye kumbukumbu; vitalu vilivyo na data ya zamani vinapatikana kupitia mmap(). Hii inaondoa hitaji la kusanidi kashe kando, lakini pia inamaanisha kuwa unahitaji kuacha nafasi ya kutosha kwa kashe ya mfumo wa uendeshaji ikiwa unataka kuuliza data ya zamani kuliko kile ambacho kizuizi cha kichwa kinaweza kubeba.
Hii pia inamaanisha kuwa utumiaji wa kumbukumbu ya Prometheus utaonekana juu sana, ambayo sio jambo la kuwa na wasiwasi.
Jambo lingine la kuvutia la kubuni ni matumizi ya WAL (andika mbele ya kumbukumbu). Kama unavyoweza kuona kutoka kwa hati za uhifadhi, Prometheus hutumia WAL kuzuia ajali. Mbinu mahususi za kuhakikisha usalama wa data, kwa bahati mbaya, hazijarekodiwa vyema. Toleo la Prometheus 2.3.2 husafisha WAL kwenye diski kila baada ya sekunde 10 na chaguo hili haliwezekani kusanidiwa na mtumiaji.
Kuunganishwa
Prometheus TSDB imeundwa kama duka la LSM (Log Structured Merge): kizuizi cha kichwa husukumwa mara kwa mara hadi kwenye diski, huku utaratibu wa kubana unachanganya vizuizi vingi pamoja ili kuepuka kuchanganua vizuizi vingi sana wakati wa hoja. Hapa unaweza kuona idadi ya vitalu ambavyo niliona kwenye mfumo wa mtihani baada ya siku ya mzigo.
Ikiwa unataka kujifunza zaidi kuhusu duka, unaweza kuchunguza faili ya meta.json, ambayo ina taarifa kuhusu vitalu vinavyopatikana na jinsi vilikuja.
{
"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
}Compactions katika Prometheus ni amefungwa kwa wakati block ya kichwa ni flushed kwa disk. Katika hatua hii, shughuli kadhaa kama hizo zinaweza kufanywa.
Inaonekana kwamba compactions sio mdogo kwa njia yoyote na inaweza kusababisha spikes kubwa za disk I/O wakati wa utekelezaji.
Vipimo vya upakiaji wa CPU
Bila shaka, hii ina athari mbaya kwa kasi ya mfumo, na pia inaleta changamoto kubwa kwa hifadhi ya LSM: jinsi ya kufanya compaction kusaidia viwango vya juu vya ombi bila kusababisha overhead nyingi?
Matumizi ya kumbukumbu katika mchakato wa compaction pia inaonekana kuvutia kabisa.
Tunaweza kuona jinsi, baada ya kubana, nyingi ya kumbukumbu hubadilika kutoka hali ya Kache hadi Bure: hii inamaanisha kuwa habari inayoweza kuwa muhimu imeondolewa hapo. Ninashangaa ikiwa inatumika hapa fadvice() au mbinu nyingine ya kupunguza, au ni kwa sababu kashe iliachiliwa kutoka kwa vizuizi vilivyoharibiwa wakati wa kubana?
Ahueni baada ya kushindwa
Kupona kutoka kwa kushindwa huchukua muda, na kwa sababu nzuri. Kwa mkondo unaoingia wa rekodi milioni kwa sekunde, nililazimika kusubiri kama dakika 25 wakati urejeshaji ulifanyika kwa kuzingatia gari la 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."Tatizo kuu la mchakato wa kurejesha ni matumizi ya juu ya kumbukumbu. Licha ya ukweli kwamba katika hali ya kawaida seva inaweza kufanya kazi kwa utulivu na kiasi sawa cha kumbukumbu, ikiwa inaanguka haiwezi kupona kutokana na OOM. Suluhisho pekee nililopata lilikuwa kulemaza mkusanyiko wa data, kuleta seva, kuiruhusu irejeshe na kuwasha tena na mkusanyiko umewezeshwa.
Kuongeza joto
Tabia nyingine ya kukumbuka wakati wa joto ni uhusiano kati ya utendaji wa chini na matumizi ya juu ya rasilimali mara baada ya kuanza. Wakati fulani, lakini sio wote kuanza, niliona mzigo mkubwa kwenye CPU na kumbukumbu.
Mapungufu katika utumiaji wa kumbukumbu yanaonyesha kuwa Prometheus haiwezi kusanidi makusanyo yote tangu mwanzo, na habari zingine zimepotea.
Sijapata sababu halisi za CPU ya juu na mzigo wa kumbukumbu. Ninashuku kuwa hii ni kwa sababu ya uundaji wa safu mpya ya wakati kwenye kizuizi cha kichwa na mzunguko wa juu.
Upakiaji wa CPU huongezeka
Kwa kuongezea michanganyiko, ambayo huunda mzigo wa juu wa I/O, niliona spikes kubwa katika mzigo wa CPU kila dakika mbili. Mipasuko huwa ndefu wakati mtiririko wa uingizaji unapokuwa mwingi na inaonekana kusababishwa na kikusanya takataka cha Go, na angalau baadhi ya korombo zikiwa zimepakiwa kikamilifu.
Rukia hizi sio duni sana. Inaonekana kwamba haya yanapotokea, mahali pa kuingilia na vipimo vya Prometheus havipatikani, hivyo kusababisha mapungufu ya data katika vipindi hivi vya wakati.
Unaweza pia kugundua kuwa muuzaji nje wa Prometheus huzima kwa sekunde moja.
Tunaweza kutambua uhusiano na ukusanyaji wa takataka (GC).
Hitimisho
TSDB katika Prometheus 2 ni ya haraka, yenye uwezo wa kushughulikia mamilioni ya mfululizo wa saa na wakati huo huo maelfu ya rekodi kwa sekunde kwa kutumia maunzi ya kawaida kabisa. Utumiaji wa CPU na diski I/O pia ni ya kuvutia. Mfano wangu ulionyesha hadi metrics 200 kwa sekunde kwa kila msingi uliotumiwa.
Ili kupanga upanuzi, unahitaji kukumbuka kuhusu kiasi cha kutosha cha kumbukumbu, na hii lazima iwe kumbukumbu halisi. Kiasi cha kumbukumbu iliyotumiwa ambayo niliona ilikuwa karibu GB 5 kwa rekodi 100 kwa sekunde ya mkondo unaoingia, ambao pamoja na kashe ya mfumo wa uendeshaji ilitoa takriban 000 GB ya kumbukumbu iliyochukuliwa.
Kwa kweli, bado kuna kazi nyingi ya kufanya kudhibiti spikes za CPU na diski I/O, na hii haishangazi ukizingatia jinsi TSDB Prometheus 2 mchanga inalinganishwa na InnoDB, TokuDB, RocksDB, WiredTiger, lakini zote zilikuwa na sifa sawa. matatizo mapema katika mzunguko wa maisha yao.
Chanzo: mapenzi.com