Prometheus 2 ۾ ٽائيم سيريز ڊيٽابيس (TSDB) هڪ انجنيئرنگ حل جو هڪ بهترين مثال آهي جيڪو پروميٿيس 2 ۾ v1 اسٽوريج تي ڊيٽا گڏ ڪرڻ جي رفتار، سوالن تي عمل ڪرڻ، ۽ وسيلن جي ڪارڪردگي جي لحاظ کان وڏيون واڌايون پيش ڪري ٿو. اسان Percona مانيٽرنگ اينڊ مئنيجمينٽ (PMM) ۾ Prometheus 2 کي لاڳو ڪري رهيا هئاسين ۽ مون کي Prometheus 2 TSDB جي ڪارڪردگي کي سمجهڻ جو موقعو مليو. هن آرٽيڪل ۾ آئون انهن مشاهدن جي نتيجن بابت ڳالهائيندس.
اوسط Prometheus ڪم لوڊ
انهن لاءِ جيڪي عام مقصد جي ڊيٽابيس سان ڊيل ڪرڻ لاءِ استعمال ڪندا آهن ، عام پرومٿيوس ڪم لوڊ ڪافي دلچسپ آهي. ڊيٽا گڏ ڪرڻ جي شرح مستحڪم ٿيندي آهي: عام طور تي اهي خدمتون جيڪي توهان مانيٽر ڪندا آهن تقريبن ساڳئي تعداد ۾ ميٽرڪ موڪليندا آهن، ۽ انفراسٽرڪچر نسبتاً سست رفتاري سان تبديل ٿيندو آهي.
معلومات لاء درخواستون مختلف ذريعن کان اچي سگھن ٿيون. انهن مان ڪجهه، جهڙوڪ الرٽ، پڻ هڪ مستحڪم ۽ پيش گوئي جي قيمت لاءِ ڪوشش ڪندا آهن. ٻيا، جهڙوڪ صارف جون درخواستون، شايد فٽ ٿي سگهن ٿيون، جيتوڻيڪ اهو معاملو اڪثر ڪم لوڊ لاء ناهي.
لوڊ ٽيسٽ
جاچ دوران، مون ڊيٽا گڏ ڪرڻ جي صلاحيت تي ڌيان ڏنو. مون Prometheus 2.3.2 مرتب ڪيو Go 1.10.1 سان گڏ (PMM 1.14 جي حصي جي طور تي) لينوڊ سروس تي هن اسڪرپٽ استعمال ڪندي: . سڀ کان وڌيڪ حقيقي لوڊ نسل لاء، هي استعمال ڪندي مون ڪيترن ئي MySQL نوڊس کي حقيقي لوڊ سان لانچ ڪيو (Sysbench TPC-C ٽيسٽ)، جن مان هر هڪ 10 لينڪس/MySQL نوڊس کي نقل ڪيو.
هيٺ ڏنل سڀئي ٽيسٽ لينوڊ سرور تي ڪيا ويا اٺ ورچوئل ڪور ۽ 32 GB ميموري سان، هلندڙ 20 لوڊ سموليشنز مانيٽرنگ ٻن سو MySQL مثالن تي. يا، Prometheus جي اصطلاحن ۾، 800 ٽارگيٽ، 440 اسڪراپ في سيڪنڊ، 380 هزار ريڪارڊ في سيڪنڊ، ۽ 1,7 ملين فعال ٽائيم سيريز.
خاڪي
روايتي ڊيٽابيس جي معمولي طريقي سان، جنهن ۾ هڪ استعمال ڪيو ويو آهي Prometheus 1.x، آهي . جيڪڏهن اهو لوڊ سنڀالڻ لاءِ ڪافي نه آهي، توهان کي وڏي دير جو تجربو ٿيندو ۽ ڪجهه درخواستون ناڪام ٿينديون. Prometheus 2 ۾ ميموري جو استعمال ڪنجي ذريعي ترتيب ڏئي سگهجي ٿو storage.tsdb.min-block-duration، جيڪو طئي ڪري ٿو ته ڊسڪ تي فلش ڪرڻ کان اڳ ڪيتري عرصي تائين رڪارڊنگ ميموري ۾ رکي ويندي (ڊفالٽ 2 ڪلاڪ آهي). گهربل ميموري جي مقدار تي منحصر هوندو ٽائيم سيريز جي تعداد، ليبلز، ۽ اسڪريپس خالص ايندڙ وهڪرو ۾ شامل ڪيو ويو. ڊسڪ اسپيس جي لحاظ کان، Prometheus جو مقصد 3 بائيٽ في رڪارڊ (نموني) استعمال ڪرڻ آهي. ٻئي طرف، ياداشت جي گهرج تمام گهڻي آهي.
جيتوڻيڪ بلاڪ جي سائيز کي ترتيب ڏيڻ ممڪن آهي، ان کي دستي طور تي ترتيب ڏيڻ جي سفارش نه ڪئي وئي آهي، تنهنڪري توهان کي مجبور ڪيو وڃي ٿو Prometheus کي ايتري ميموري ڏيو جيترو اهو توهان جي ڪم لوڊ لاءِ گهربل آهي.
جيڪڏهن ميٽرڪس جي ايندڙ وهڪرو کي سپورٽ ڪرڻ لاءِ ڪافي ميموري نه آهي، پرومٿيوس ياداشت کان ٻاهر ٿي ويندو يا OOM قاتل ان کي حاصل ڪندو.
حادثي کي دير ڪرڻ لاءِ ادل شامل ڪرڻ جڏهن پروميٿيس جي ياداشت ختم ٿي وڃي ٿي ته واقعي ڪا مدد نه ٿي ٿئي، ڇاڪاڻ ته هن فنڪشن کي استعمال ڪندي ڌماڪيدار ميموري استعمال ٿئي ٿي. مان سمجهان ٿو ته اهو Go سان ڪرڻ لاءِ ڪجهه آهي ، ان جو گند ڪچرو گڏ ڪندڙ ۽ اهو طريقو جيڪو ادل سان معاملو ڪري ٿو.
هڪ ٻيو دلچسپ طريقو اهو آهي ته هيڊ بلاڪ کي ترتيب ڏيڻ لاءِ هڪ خاص وقت تي ڊسڪ کي فلش ڪيو وڃي، ان کي پروسيس جي شروعات کان شمار ڪرڻ بدران.
جيئن توهان گراف مان ڏسي سگهو ٿا، ڊسڪ ڏانهن فلش هر ٻن ڪلاڪن ۾ ٿيندي آهي. جيڪڏهن توهان منٽ-بلاڪ-ڊوريشن پيٽرولر کي هڪ ڪلاڪ ۾ تبديل ڪريو ٿا، ته پوءِ اهي ري سيٽون هر ڪلاڪ ٿينديون، اڌ ڪلاڪ کان پوءِ شروع ٿينديون.
جيڪڏھن توھان چاھيو ٿا استعمال ڪريو ھي ۽ ٻيا گراف پنھنجي Prometheus تنصيب ۾، توھان ھي استعمال ڪري سگھو ٿا . اهو PMM لاءِ ٺهيل هو پر، معمولي ترميمن سان، ڪنهن به Prometheus تنصيب ۾ ٺهڪي اچي ٿو.
اسان وٽ هڪ فعال بلاڪ آهي جنهن کي هيڊ بلاڪ سڏيو ويندو آهي جيڪو ياداشت ۾ ذخيرو ٿيل آهي. پراڻن ڊيٽا سان بلاڪ ذريعي دستياب آهن mmap(). هي ڪيش کي الڳ الڳ ترتيب ڏيڻ جي ضرورت کي ختم ڪري ٿو، پر ان جو مطلب اهو پڻ آهي ته توهان کي آپريٽنگ سسٽم ڪيش لاءِ ڪافي جاءِ ڇڏڻ جي ضرورت آهي جيڪڏهن توهان چاهيو ٿا ته ڊيٽا جي پڇا ڳاڇا ڪرڻ کان وڌيڪ پراڻا جيڪو هيڊ بلاڪ ترتيب ڏئي سگهي ٿو.
ان جو مطلب اهو به آهي ته Prometheus ورچوئل ميموري جو استعمال تمام گهڻو نظر ايندو، جنهن جي باري ۾ پريشان ٿيڻ جي ڪا ڳالهه ناهي.
هڪ ٻيو دلچسپ ڊزائين پوائنٽ WAL جو استعمال آهي (اڳتي لاگ لکو). جئين توهان اسٽوريج دستاويزن مان ڏسي سگهو ٿا، Prometheus حادثن کان بچڻ لاء WAL استعمال ڪري ٿو. ڊيٽا جي بقا جي ضمانت لاءِ مخصوص ميکانيزم، بدقسمتي سان، چڱي طرح دستاويز ٿيل نه آهن. Prometheus ورجن 2.3.2 هر 10 سيڪنڊن ۾ WAL کي ڊسڪ ڪري ٿو ۽ هي اختيار استعمال ڪندڙ کي ترتيب ڏيڻ جي قابل ناهي.
Compactions
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 ۾ Compactions ان وقت سان ڳنڍيل آهن جڏهن هيڊ بلاڪ کي ڊسڪ تي فلش ڪيو ويندو آهي. هن موقعي تي، اهڙا ڪيترائي آپريشن ڪيا ويندا.
اهو ظاهر ٿئي ٿو ته ٺهڪندڙ ڪنهن به طريقي سان محدود نه آهن ۽ عمل جي دوران وڏي ڊسڪ I/O اسپيڪس سبب ڪري سگهن ٿا.
سي پي يو لوڊ اسپيڪس
يقينن، اهو سسٽم جي رفتار تي هڪ بدران منفي اثر آهي، ۽ LSM اسٽوريج لاء هڪ سنگين چئلينج پڻ آهي: تمام گهڻي اوور هيڊ سبب بغير اعلي درخواست جي شرحن کي سپورٽ ڪرڻ لاء ڪمپيشن ڪيئن ڪجي؟
compaction عمل ۾ ياداشت جو استعمال به ڪافي دلچسپ لڳندي آهي.
اسان ڏسي سگھون ٿا ته ڪھڙيءَ طرح، ٺاھڻ کان پوءِ، اڪثر ميموري حالت کي ڪيشڊ کان فري ۾ تبديل ڪري ٿي: ان جو مطلب آھي ته ممڪن طور تي قيمتي معلومات اتان ھٽي وئي آھي. دلچسپ جيڪڏهن اهو هتي استعمال ڪيو وڃي fadvice() يا ڪا ٻي مائنسائيزيشن ٽيڪنڪ، يا ڇا اهو آهي ڇو ته ڪيش کي ڪمپيڪشن دوران تباهه ٿيل بلاڪن کان آزاد ڪيو ويو هو؟
هڪ ناڪامي کان پوء بحالي
ناڪامين مان وصولي وقت وٺندو آهي، ۽ سٺو سبب لاء. هڪ ملين رڪارڊ في سيڪنڊ جي ايندڙ وهڪري لاءِ، مون کي تقريباً 25 منٽ انتظار ڪرڻو پيو جڏهن ته وصولي ڪئي وئي 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."بحالي جي عمل جو بنيادي مسئلو اعلي ميموري واپرائڻ آهي. ان حقيقت جي باوجود ته هڪ عام حالت ۾ سرور ڪم ڪري سگهي ٿو مستحڪم ميموري جي ساڳئي مقدار سان، جيڪڏهن اهو حادثو ٿئي ٿو ته اهو OOM جي ڪري بحال نه ٿي سگھي. مون کي صرف هڪ حل مليو ته ڊيٽا گڏ ڪرڻ کي غير فعال ڪرڻ، سرور کي آڻڻ، ان کي بحال ڪرڻ ۽ گڏ ڪرڻ سان گڏ ريبوٽ ڪرڻ لاء فعال ڪيو ويو.
گرم ڪرڻ
وارم اپ دوران ذهن ۾ رکڻ لاءِ هڪ ٻيو رويو اهو آهي ته شروعات کان پوءِ گهٽ ڪارڪردگي ۽ اعلي وسيلن جي استعمال جي وچ ۾ تعلق آهي. ڪجھ دوران، پر سڀ شروع نه ٿيو، مون سي پي يو ۽ ميموري تي سنجيده لوڊ ڏٺو.
ميموري جي استعمال ۾ خال ظاھر ڪري ٿو ته Prometheus شروع کان سڀني مجموعن کي ترتيب نه ڏئي سگھي ٿو، ۽ ڪجھ معلومات گم ٿي وئي آھي.
مون اعليٰ سي پي يو ۽ ميموري لوڊ ڪرڻ جا صحيح سبب نه ڳوليا آهن. مون کي شڪ آهي ته اهو هڪ اعلي تعدد سان هيڊ بلاڪ ۾ نئين ٽائيم سيريز ٺاهڻ جي سبب آهي.
سي پي يو لوڊ وڌي ٿو
ڪمپيڪشنن کان علاوه، جيڪي ڪافي تيز I/O لوڊ ٺاهيندا آهن، مون هر ٻن منٽن ۾ CPU لوڊ ۾ سنگين اسپيڪس محسوس ڪيا. دفن ڊگھا ٿيندا آھن جڏھن ان پٽ جو وهڪرو گھڻو ھوندو آھي ۽ گو جي گاربيج ڪليڪٽر جي ڪري ھوندو آھي، گھٽ ۾ گھٽ ڪجھ ڪور مڪمل طور تي لوڊ ٿيل ھوندا آھن.
اهي جمپ ايترا غير معمولي نه آهن. اهو ظاهر ٿئي ٿو ته جڏهن اهي واقع ٿين ٿا، پروميٿيس جي اندروني داخلا نقطي ۽ ميٽرڪس غير دستياب ٿي ويندا آهن، انهن ساڳئي عرصي دوران ڊيٽا جي خال پيدا ڪري ٿي.
توهان اهو پڻ نوٽيس ڪري سگهو ٿا ته Prometheus برآمد ڪندڙ هڪ سيڪنڊ لاء بند ڪري ٿو.
اسان گندگي گڏ ڪرڻ (GC) سان لاڳاپا محسوس ڪري سگهون ٿا.
ٿڪل
Prometheus 2 ۾ TSDB تيز آهي، لکين ٽائيم سيريز کي هٿي ڏيڻ جي قابل آهي ۽ ساڳئي وقت هزارين رڪارڊ في سيڪنڊ کي معمولي هارڊويئر استعمال ڪندي. سي پي يو ۽ ڊسڪ I/O استعمال پڻ شاندار آهي. منهنجو مثال ڏيکاريو ويو 200 ميٽرڪس في سيڪنڊ في ڪور استعمال ڪيو ويو.
توسيع جي منصوبابندي ڪرڻ لاءِ، توهان کي ياد رکڻ جي ضرورت آهي ته ڪافي مقدار ۾ ميموري، ۽ اهو ضرور هجڻ گهرجي حقيقي ياداشت. استعمال ڪيل ميموري جي مقدار جيڪا مون ڏٺو آهي اٽڪل 5 GB في 100 رڪارڊ في سيڪنڊ ايندڙ ايندڙ وهڪرو، جنهن سان گڏ آپريٽنگ سسٽم ڪيش تقريبا 000 GB جي قبضي واري ميموري ڏني.
يقينن، سي پي يو ۽ ڊسڪ I/O اسپيڪس کي ختم ڪرڻ لاءِ اڃا تمام گهڻو ڪم ڪرڻو آهي، ۽ اها حيرت جي ڳالهه ناهي ته ڪيئن نوجوان TSDB Prometheus 2 InnoDB، TokuDB، RocksDB، WiredTiger جي مقابلي ۾ آهي، پر انهن سڀني ۾ هڪجهڙائي هئي. انهن جي زندگيء جي شروعات ۾ مسئلا.
جو ذريعو: www.habr.com