Prometheus 2 дээрх хугацааны цуврал мэдээллийн сан (TSDB) нь Prometheus 2 дээрх v1 санах ойтой харьцуулахад өгөгдөл хуримтлуулах хурд, асуулгын гүйцэтгэл, нөөцийн үр ашгийн хувьд томоохон сайжруулалтыг санал болгодог инженерийн шийдлийн гайхалтай жишээ юм. Бид Prometheus 2-г Percona Monitoring and Management (PMM)-д хэрэгжүүлж байсан бөгөөд надад Prometheus 2 TSDB-ийн гүйцэтгэлийг ойлгох боломж олдсон. Энэ нийтлэлд би эдгээр ажиглалтын үр дүнгийн талаар ярих болно.
Прометейгийн дундаж ачаалал
Ерөнхий зориулалтын мэдээллийн сантай ажиллаж байсан хүмүүсийн хувьд Prometheus-ийн ердийн ажлын ачаалал нэлээд сонирхолтой байдаг. Мэдээллийн хуримтлалын хурд тогтвортой байх хандлагатай байдаг: ихэвчлэн таны хянадаг үйлчилгээнүүд ойролцоогоор ижил тооны хэмжүүр илгээдэг бөгөөд дэд бүтэц харьцангуй удаан өөрчлөгддөг.
Мэдээлэл авах хүсэлт янз бүрийн эх сурвалжаас ирж болно. Тэдгээрийн зарим нь, тухайлбал сэрэмжлүүлэг нь тогтвортой, урьдчилан таамаглах боломжтой утгыг эрэлхийлдэг. Хэрэглэгчийн хүсэлт гэх мэт бусад нь тэсрэлт үүсгэж болзошгүй ч ихэнх ажлын ачаалалд энэ нь тийм биш юм.
Ачааллын туршилт
Туршилтын явцад би өгөгдөл хуримтлуулах чадварт анхаарлаа хандуулсан. Би энэ скриптийг ашиглан Go 2.3.2 (PMM 1.10.1-ийн нэг хэсэг)-ээр эмхэтгэсэн Prometheus 1.14-г Linode үйлчилгээнд суулгасан: . Хамгийн бодит ачаалал үүсгэхийн тулд үүнийг ашиглана Би жинхэнэ ачаалалтай хэд хэдэн MySQL зангилаа (Sysbench TPC-C тест) эхлүүлсэн бөгөөд тэдгээр нь тус бүр нь 10 Linux/MySQL зангилаа дууриасан.
Дараах бүх туршилтыг найман виртуал цөм, 32 ГБ санах ой бүхий Linode сервер дээр хийж, хоёр зуун MySQL инстанцыг хянах 20 ачааллын симуляцийг ажиллуулсан. Эсвэл Прометей хэлээр бол 800 бай, секундэд 440 хусах, секундэд 380 мянган бичлэг, 1,7 сая идэвхтэй цагийн цуваа.
Зураг төсөл
Prometheus 1.x-ийн ашигладаг өгөгдлийн санг оролцуулан уламжлалт мэдээллийн сангийн ердийн арга бол to . Хэрэв энэ нь ачааллыг даван туулахад хангалтгүй бол та өндөр хоцрогдолтой тулгарч, зарим хүсэлт амжилтгүй болно. Prometheus 2 дээрх санах ойн ашиглалтыг товчлуураар тохируулж болно storage.tsdb.min-block-duration, энэ нь диск рүү угаахаас өмнө бичлэгийг санах ойд хэр удаан хадгалахыг тодорхойлдог (анхдагчаар 2 цаг). Шаардлагатай санах ойн хэмжээ нь цэвэр ирж буй урсгалд нэмсэн хугацааны цуваа, шошго, хусах тооноос хамаарна. Дискний зайны хувьд Prometheus нь бичлэг бүрт 3 байт (дээж) ашиглахыг зорьдог. Нөгөө талаар санах ойн шаардлага хамаагүй өндөр байдаг.
Хэдийгээр блокийн хэмжээг тохируулах боломжтой боловч гараар тохируулахыг зөвлөдөггүй тул та Prometheus-д ажлын ачаалалд шаардагдах хэмжээний санах ойг өгөхөөс өөр аргагүй болно.
Хэрэв ирж буй хэмжигдэхүүнийг дэмжих хангалттай санах ой байхгүй бол Prometheus санах ойгүй болох эсвэл OOM алуурчин түүнд хүрэх болно.
Prometheus-ийн санах ой дуусах үед сүйрлийг хойшлуулахын тулд своп нэмэх нь үнэхээр тус болохгүй, учир нь энэ функцийг ашиглах нь санах ойн хэрэглээг ихэсгэдэг. Энэ нь Go-той холбоотой, хог цуглуулагч, солилцооны арга барилтай холбоотой гэж би бодож байна.
Өөр нэг сонирхолтой арга бол толгойн блокыг процессын эхнээс тоолохын оронд тодорхой цагт диск рүү угаахаар тохируулах явдал юм.
Графикаас харахад диск рүү зайлах нь хоёр цаг тутамд тохиолддог. Хэрэв та min-block-runation параметрийг нэг цаг болгон өөрчилвөл эдгээр дахин тохируулга нь хагас цагийн дараа эхлэх болно.
Хэрэв та Prometheus суулгацдаа энэ болон бусад графикуудыг ашиглахыг хүсвэл үүнийг ашиглаж болно . Энэ нь PMM-д зориулагдсан боловч бага зэргийн өөрчлөлттэй, ямар ч Prometheus суулгацад тохирно.
Бид санах ойд хадгалагдсан толгой блок гэж нэрлэгддэг идэвхтэй блоктой; хуучин өгөгдөл бүхий блокуудыг дамжуулан авах боломжтой mmap(). Энэ нь кэшийг тусад нь тохируулах шаардлагагүй бөгөөд хэрэв та толгой блокийн багтаамжаас илүү хуучин өгөгдлийг асуухыг хүсвэл үйлдлийн системийн кэшэд хангалттай зай үлдээх хэрэгтэй гэсэн үг юм.
Энэ нь Prometheus виртуал санах ойн хэрэглээ нэлээд өндөр харагдах болно гэсэн үг бөгөөд энэ нь санаа зовох зүйл биш юм.
Загварын өөр нэг сонирхолтой зүйл бол WAL (урд бичих бүртгэл) ашиглах явдал юм. Хадгалах баримт бичгээс харахад Prometheus эвдрэлээс зайлсхийхийн тулд WAL ашигладаг. Өгөгдлийн амьдрах чадварыг баталгаажуулах тусгай механизмууд харамсалтай нь сайн баримтжуулаагүй байна. Prometheus хувилбар 2.3.2 нь WAL-г 10 секунд тутамд диск рүү зайлуулдаг ба энэ сонголтыг хэрэглэгчээр тохируулах боломжгүй.
Нягтруулга
Prometheus TSDB нь LSM (Log Structured Merge) дэлгүүр шиг бүтээгдсэн: толгойн блокыг диск рүү үе үе угаадаг бол нягтруулах механизм нь асуулга хийх явцад хэт олон блок скан хийхээс зайлсхийхийн тулд олон блокуудыг нэгтгэдэг. Эндээс та ачааллын өдрийн дараа туршилтын систем дээр миний ажигласан блокуудын тоог харж болно.
Хэрэв та дэлгүүрийн талаар илүү ихийг мэдэхийг хүсвэл meta.json файлыг шалгаж үзэх боломжтой бөгөөд үүнд байгаа блокууд болон тэдгээр нь хэрхэн үүссэн тухай мэдээлэл байдаг.
{
"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
}Prometheus дахь нягтрал нь толгойн блокыг диск рүү угаах хугацаатай холбоотой байдаг. Энэ үед хэд хэдэн ийм үйл ажиллагаа явуулж болно.
Нягтруулах нь ямар ч байдлаар хязгаарлагдахгүй бөгөөд гүйцэтгэлийн явцад дискний оролт гаралтын огцом өсөлтийг үүсгэж болзошгүй юм.
CPU-ийн ачаалал огцом нэмэгддэг
Мэдээжийн хэрэг, энэ нь системийн хурдад сөргөөр нөлөөлж, LSM хадгалахад ноцтой сорилт үүсгэдэг: хэт их ачаалал үүсгэхгүйгээр өндөр хүсэлтийн хувь хэмжээг дэмжихийн тулд шахалтыг хэрхэн хийх вэ?
Нягтруулах явцад санах ойг ашиглах нь бас сонирхолтой харагдаж байна.
Нягтруулсны дараа ихэнх санах ойн төлөв Кэшээс Чөлөөт болж өөрчлөгддөгийг бид харж байна: энэ нь үнэ цэнэтэй мэдээлэл тэндээс устгагдсан гэсэн үг юм. Үүнийг энд ашигласан эсэх нь сонин байна fadvice() эсвэл бусад багасгах арга техник, эсвэл нягтруулах явцад устгагдсан блокуудаас кэшийг чөлөөлсөнтэй холбоотой юу?
Амжилтгүй болсоны дараа сэргээх
Алдаа дутагдлыг сэргээхэд цаг хугацаа шаардагддаг бөгөөд энэ нь сайн шалтгаантай байдаг. Секундэд нэг сая бичлэг орж ирэхийн тулд би SSD дискийг харгалзан сэргээх ажиллагааг 25 минут хүлээх шаардлагатай болсон.
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."Сэргээх үйл явцын гол асуудал бол санах ойн өндөр зарцуулалт юм. Ердийн нөхцөлд сервер ижил хэмжээний санах ойтой тогтвортой ажиллах боломжтой хэдий ч гацсан тохиолдолд OOM-ийн улмаас сэргээгдэхгүй байж магадгүй юм. Миний олсон цорын ганц шийдэл бол өгөгдөл цуглуулах ажиллагааг идэвхгүй болгож, серверийг ажиллуулж, сэргээхийг зөвшөөрч, цуглуулгыг идэвхжүүлсэн үед дахин ачаалах явдал байв.
Дулаацаж байна
Халаалтын үеэр санаж байх ёстой өөр нэг зан үйл бол эхэлсний дараа бага гүйцэтгэл, нөөцийн өндөр зарцуулалтын хоорондын хамаарал юм. Зарим, гэхдээ бүгдийг нь эхлүүлэхгүй байх үед би CPU болон санах ойд ноцтой ачааллыг ажиглав.
Санах ойн ашиглалтын цоорхой нь Prometheus бүх цуглуулгыг эхнээс нь тохируулах боломжгүй, зарим мэдээлэл алдагдсан болохыг харуулж байна.
CPU болон санах ойн ачаалал их байгаагийн яг шалтгааныг би олж чадаагүй байна. Энэ нь өндөр давтамжтай толгойн блокт шинэ цагийн цуваа үүссэнтэй холбоотой гэж би сэжиглэж байна.
CPU-ийн ачаалал ихсэж байна
Нэлээд өндөр оролт гаралтын ачааллыг бий болгодог нягтаршлаас гадна CPU-ийн ачаалал хоёр минут тутамд огцом нэмэгдэж байгааг би анзаарсан. Оролтын урсгал их байх үед тэсрэлтүүд илүү урт бөгөөд Go-ийн хог цуглуулагчаас үүдэлтэй мэт харагддаг ба ядаж зарим цөм бүрэн ачаалалтай байдаг.
Эдгээр үсрэлтүүд нь тийм ч ач холбогдолгүй биш юм. Эдгээр нь тохиолдоход Prometheus-ийн дотоод нэвтрэх цэг болон хэмжүүрүүд боломжгүй болж, ижил хугацаанд өгөгдлийн цоорхойг үүсгэдэг.
Prometheus экспортлогч нэг секундын турш унтарсныг та анзаарч болно.
Хог цуглуулах (GC) хоорондын хамаарлыг бид анзаарч болно.
дүгнэлт
Prometheus 2 дээрх TSDB нь маш хурдан бөгөөд маш энгийн техник хангамж ашиглан сая сая цагийн цуваа, тэр үед секундэд олон мянган бичлэг хийх чадвартай. CPU болон дискний оролт гаралтын ашиглалт нь бас гайхалтай. Миний жишээ ашигласан цөм тутамд секундэд 200 хэмжигдэхүүнийг харуулсан.
Өргөтгөлийг төлөвлөхийн тулд хангалттай хэмжээний санах ойн талаар санах хэрэгтэй бөгөөд энэ нь жинхэнэ санах ой байх ёстой. Миний ажигласан санах ойн хэмжээ нь ирж буй урсгалын секундэд 5 бичлэг тутамд 100 ГБ орчим байсан бөгөөд энэ нь үйлдлийн системийн кэштэй хамт 000 ГБ орчим эзлэгдсэн санах ойг өгдөг.
Мэдээжийн хэрэг, CPU болон дискний оролт гаралтын огцом өсөлтийг дарахын тулд хийх ажил их байгаа бөгөөд TSDB Prometheus 2-ийг InnoDB, TokuDB, RocksDB, WiredTiger-тэй харьцуулбал энэ нь гайхмаар зүйл биш боловч бүгд ижил төстэй байсан. амьдралын мөчлөгийн эхэн үеийн асуудлууд.
Эх сурвалж: www.habr.com