Prometheus 2 میں ٹائم سیریز ڈیٹا بیس (TSDB) انجینئرنگ حل کی ایک بہترین مثال ہے جو ڈیٹا جمع کرنے کی رفتار، استفسار پر عمل درآمد، اور وسائل کی کارکردگی کے لحاظ سے پرومیتھیس 2 میں v1 اسٹوریج پر بڑی بہتری پیش کرتا ہے۔ ہم پرکونا مانیٹرنگ اینڈ مینجمنٹ (PMM) میں Prometheus 2 کو نافذ کر رہے تھے اور مجھے Prometheus 2 TSDB کی کارکردگی کو سمجھنے کا موقع ملا۔ اس مضمون میں میں ان مشاہدات کے نتائج کے بارے میں بات کروں گا۔
اوسط پرومیتھیس کام کا بوجھ
عام مقصد کے ڈیٹا بیس سے نمٹنے کے عادی افراد کے لیے، عام پرومیٹیس کام کا بوجھ کافی دلچسپ ہے۔ ڈیٹا جمع کرنے کی شرح مستحکم ہوتی ہے: عام طور پر جن سروسز کی آپ نگرانی کرتے ہیں وہ تقریباً اتنی ہی تعداد میں میٹرکس بھیجتی ہیں، اور انفراسٹرکچر نسبتاً آہستہ تبدیل ہوتا ہے۔
معلومات کے لیے درخواستیں مختلف ذرائع سے آ سکتی ہیں۔ ان میں سے کچھ، جیسے انتباہات، ایک مستحکم اور قابل پیشین قیمت کے لیے بھی کوشش کرتے ہیں۔ دیگر، جیسے صارف کی درخواستیں، پھٹنے کا سبب بن سکتی ہیں، حالانکہ زیادہ تر کام کے بوجھ کے لیے ایسا نہیں ہے۔
لوڈ ٹیسٹ
جانچ کے دوران، میں نے ڈیٹا جمع کرنے کی صلاحیت پر توجہ مرکوز کی۔ میں نے اس اسکرپٹ کا استعمال کرتے ہوئے لینوڈ سروس پر Go 2.3.2 (PMM 1.10.1 کے حصے کے طور پر) کے ساتھ مرتب کردہ Prometheus 1.14 کو تعینات کیا: . اس کا استعمال کرتے ہوئے، سب سے زیادہ حقیقت پسندانہ لوڈ جنریشن کے لیے میں نے ایک حقیقی بوجھ (Sysbench TPC-C ٹیسٹ) کے ساتھ کئی MySQL نوڈس لانچ کیے، جن میں سے ہر ایک نے 10 Linux/MySQL نوڈس کی تقلید کی۔
مندرجہ ذیل تمام ٹیسٹ آٹھ ورچوئل کور اور 32 جی بی میموری کے ساتھ لینوڈ سرور پر کیے گئے، جس میں دو سو MySQL مثالوں کی نگرانی کرنے والے 20 لوڈ سمولیشن چلائے گئے۔ یا، پرومیتھیس کی شرائط میں، 800 اہداف، 440 سکریپس فی سیکنڈ، 380 ہزار ریکارڈ فی سیکنڈ، اور 1,7 ملین ایکٹو ٹائم سیریز۔
ڈیزائن
روایتی ڈیٹا بیس کا معمول کا نقطہ نظر، بشمول Prometheus 1.x، کے ذریعے استعمال کیا جاتا ہے۔ . اگر یہ بوجھ کو سنبھالنے کے لیے کافی نہیں ہے، تو آپ کو زیادہ تاخیر کا سامنا کرنا پڑے گا اور کچھ درخواستیں ناکام ہو جائیں گی۔ Prometheus 2 میں میموری کا استعمال کلید کے ذریعے قابل ترتیب ہے۔ storage.tsdb.min-block-duration، جو اس بات کا تعین کرتا ہے کہ ڈسک پر فلش کرنے سے پہلے کتنی دیر تک ریکارڈنگ میموری میں رکھی جائے گی (ڈیفالٹ 2 گھنٹے ہے)۔ مطلوبہ میموری کی مقدار کا انحصار اس وقت کی تعداد، لیبلز، اور اسکریپس کی نیٹ آنے والی ندی میں شامل کیے جانے پر ہوگا۔ ڈسک کی جگہ کے لحاظ سے، Prometheus کا مقصد 3 بائٹس فی ریکارڈ (نمونہ) استعمال کرنا ہے۔ دوسری طرف، میموری کی ضروریات بہت زیادہ ہیں.
اگرچہ بلاک کے سائز کو ترتیب دینا ممکن ہے، لیکن اسے دستی طور پر ترتیب دینے کی سفارش نہیں کی جاتی ہے، اس لیے آپ پرومیٹیس کو اتنی میموری دینے پر مجبور ہیں جتنی آپ کے کام کے بوجھ کے لیے درکار ہے۔
اگر میٹرکس کے آنے والے سلسلے کو سپورٹ کرنے کے لیے کافی میموری نہیں ہے، تو Prometheus میموری سے باہر ہو جائے گا یا OOM قاتل اس تک پہنچ جائے گا۔
جب Prometheus کی میموری ختم ہو جاتی ہے تو کریش میں تاخیر کرنے کے لیے سویپ کو شامل کرنے سے واقعی کوئی فائدہ نہیں ہوتا، کیونکہ اس فنکشن کو استعمال کرنے سے میموری کا دھماکہ خیز استعمال ہوتا ہے۔ میرے خیال میں یہ گو، اس کے کوڑا کرکٹ جمع کرنے والے اور اس کے بدلے جانے کے طریقے سے کچھ لینا دینا ہے۔
ایک اور دلچسپ نقطہ نظر یہ ہے کہ ہیڈ بلاک کو کسی خاص وقت پر ڈسک پر فلش کرنے کے لیے ترتیب دیا جائے، بجائے اس کے کہ اسے عمل کے آغاز سے ہی شمار کیا جائے۔
جیسا کہ آپ گراف سے دیکھ سکتے ہیں، ہر دو گھنٹے بعد ڈسک پر فلش ہوتے ہیں۔ اگر آپ min-block-duration کے پیرامیٹر کو ایک گھنٹہ میں تبدیل کرتے ہیں، تو پھر یہ ری سیٹ ہر گھنٹے، آدھے گھنٹے کے بعد شروع ہوں گے۔
اگر آپ اپنی Prometheus تنصیب میں یہ اور دیگر گراف استعمال کرنا چاہتے ہیں، تو آپ اسے استعمال کر سکتے ہیں۔ . یہ PMM کے لیے ڈیزائن کیا گیا تھا لیکن، معمولی ترمیم کے ساتھ، کسی بھی Prometheus کی تنصیب میں فٹ بیٹھتا ہے۔
ہمارے پاس ایک فعال بلاک ہے جسے ہیڈ بلاک کہتے ہیں جو میموری میں محفوظ ہے۔ پرانے ڈیٹا والے بلاکس کے ذریعے دستیاب ہیں۔ mmap(). اس سے کیشے کو الگ سے کنفیگر کرنے کی ضرورت ختم ہو جاتی ہے، لیکن اس کا مطلب یہ بھی ہے کہ اگر آپ ہیڈ بلاک میں ایڈجسٹ کر سکتے ہیں اس سے زیادہ پرانے ڈیٹا سے استفسار کرنا چاہتے ہیں تو آپ کو آپریٹنگ سسٹم کیش کے لیے کافی جگہ چھوڑنی ہوگی۔
اس کا مطلب یہ بھی ہے کہ Prometheus ورچوئل میموری کی کھپت کافی زیادہ نظر آئے گی، جس کے بارے میں فکر کرنے کی کوئی بات نہیں ہے۔
ایک اور دلچسپ ڈیزائن پوائنٹ WAL کا استعمال ہے (آگے لاگ لکھیں)۔ جیسا کہ آپ اسٹوریج کی دستاویزات سے دیکھ سکتے ہیں، Prometheus کریشوں سے بچنے کے لیے WAL کا استعمال کرتا ہے۔ ڈیٹا کی بقا کی ضمانت کے لیے مخصوص طریقہ کار، بدقسمتی سے، اچھی طرح سے دستاویزی نہیں ہیں۔ Prometheus ورژن 2.3.2 WAL کو ہر 10 سیکنڈ میں ڈسک پر فلش کرتا ہے اور یہ آپشن صارف کے قابل نہیں ہے۔
کمپیکشنز
Prometheus TSDB کو LSM (لاگ سٹرکچرڈ مرج) اسٹور کی طرح ڈیزائن کیا گیا ہے: ہیڈ بلاک کو وقتاً فوقتاً ڈسک پر فلش کیا جاتا ہے، جب کہ ایک کمپیکشن میکانزم متعدد بلاکس کو اکٹھا کرتا ہے تاکہ استفسارات کے دوران بہت سے بلاکس کو اسکین کرنے سے بچا جا سکے۔ یہاں آپ بلاکس کی تعداد دیکھ سکتے ہیں جن کا میں نے ایک دن کے بوجھ کے بعد ٹیسٹ سسٹم پر مشاہدہ کیا۔
اگر آپ اسٹور کے بارے میں مزید جاننا چاہتے ہیں، تو آپ 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 میں مرکبات اس وقت سے منسلک ہوتے ہیں جب ہیڈ بلاک کو ڈسک پر فلش کیا جاتا ہے۔ اس وقت، اس طرح کے کئی آپریشن کیے جا سکتے ہیں۔
ایسا معلوم ہوتا ہے کہ کمپیکشنز کسی بھی طرح سے محدود نہیں ہیں اور عملدرآمد کے دوران بڑی ڈسک I/O اسپائکس کا سبب بن سکتے ہیں۔
CPU لوڈ اسپائکس
بلاشبہ، اس کا سسٹم کی رفتار پر منفی اثر پڑتا ہے، اور یہ LSM اسٹوریج کے لیے ایک سنگین چیلنج بھی پیش کرتا ہے: بہت زیادہ اوور ہیڈ بنائے بغیر اعلی درخواست کی شرح کو سپورٹ کرنے کے لیے کمپیکشن کیسے کیا جائے؟
کمپیکشن کے عمل میں میموری کا استعمال بھی کافی دلچسپ لگتا ہے۔
ہم دیکھ سکتے ہیں کہ کمپیکشن کے بعد، زیادہ تر میموری کیشڈ سے فری میں کیسے تبدیل ہوتی ہے: اس کا مطلب ہے کہ ممکنہ طور پر قیمتی معلومات کو وہاں سے ہٹا دیا گیا ہے۔ اگر اسے یہاں استعمال کیا جائے تو متجسس 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 کی وجہ سے ٹھیک نہیں ہو سکتا۔ میں نے صرف ایک ہی حل تلاش کیا تھا کہ ڈیٹا اکٹھا کرنے کو غیر فعال کیا جائے، سرور کو سامنے لایا جائے، اسے بازیافت کرنے دیں اور کلیکشن کو فعال کرنے کے ساتھ دوبارہ شروع کریں۔
تیار ہونا
وارم اپ کے دوران ذہن میں رکھنے کا ایک اور طرز عمل شروع ہونے کے فوراً بعد کم کارکردگی اور زیادہ وسائل کی کھپت کے درمیان تعلق ہے۔ کچھ کے دوران، لیکن سب شروع نہیں ہوتا، میں نے CPU اور میموری پر شدید بوجھ دیکھا۔
میموری کے استعمال میں فرق اس بات کی نشاندہی کرتا ہے کہ Prometheus شروع سے تمام مجموعوں کو ترتیب نہیں دے سکتا، اور کچھ معلومات ضائع ہو جاتی ہیں۔
میں نے زیادہ CPU اور میموری بوجھ کی صحیح وجوہات کا پتہ نہیں لگایا ہے۔ مجھے شک ہے کہ یہ ہیڈ بلاک میں ہائی فریکوئنسی کے ساتھ نئی ٹائم سیریز کی تخلیق کی وجہ سے ہے۔
CPU لوڈ بڑھتا ہے۔
کمپیکشنز کے علاوہ، جو کافی زیادہ I/O بوجھ پیدا کرتے ہیں، میں نے ہر دو منٹ میں CPU لوڈ میں سنگین اضافہ دیکھا۔ جب ان پٹ کا بہاؤ زیادہ ہوتا ہے تو برسٹ طویل ہوتے ہیں اور گو کے کوڑا کرکٹ جمع کرنے والے کی وجہ سے ہوتے ہیں، کم از کم کچھ کور مکمل طور پر لوڈ ہوتے ہیں۔
یہ چھلانگیں اتنی معمولی نہیں ہیں۔ ایسا معلوم ہوتا ہے کہ جب یہ واقع ہوتے ہیں، پرومیتھیس کا داخلی داخلی نقطہ اور میٹرکس دستیاب نہیں ہوتے ہیں، جس کی وجہ سے انہی وقفوں کے دوران ڈیٹا میں خلاء پیدا ہوتا ہے۔
آپ یہ بھی دیکھ سکتے ہیں کہ Prometheus برآمد کنندہ ایک سیکنڈ کے لیے بند ہو جاتا ہے۔
ہم کوڑا کرکٹ جمع کرنے (GC) کے ساتھ ارتباط کو دیکھ سکتے ہیں۔
حاصل يہ ہوا
Prometheus 2 میں TSDB تیز ہے، کافی معمولی ہارڈ ویئر کا استعمال کرتے ہوئے لاکھوں ٹائم سیریز اور ایک ہی وقت میں ہزاروں ریکارڈ فی سیکنڈ سنبھالنے کی صلاحیت رکھتا ہے۔ CPU اور ڈسک I/O کا استعمال بھی متاثر کن ہے۔ میری مثال نے 200 میٹرکس فی سیکنڈ فی کور استعمال کیا۔
توسیع کی منصوبہ بندی کرنے کے لیے، آپ کو میموری کی کافی مقدار کے بارے میں یاد رکھنے کی ضرورت ہے، اور یہ حقیقی میموری ہونی چاہیے۔ استعمال شدہ میموری کی مقدار جس کا میں نے مشاہدہ کیا وہ آنے والی سٹریم کے فی 5 ریکارڈ فی سیکنڈ کے بارے میں 100 GB تھی، جس نے آپریٹنگ سسٹم کیشے کے ساتھ مل کر تقریباً 000 GB مقبوضہ میموری دی تھی۔
بلاشبہ، CPU اور ڈسک I/O spikes پر قابو پانے کے لیے ابھی بہت کام کرنا باقی ہے، اور یہ حیرت کی بات نہیں ہے کہ نوجوان TSDB Prometheus 2 کا موازنہ InnoDB، TokuDB، RocksDB، WiredTiger سے کیسے کیا جاتا ہے، لیکن ان سب میں ایک جیسے تھے۔ ان کی زندگی کے دور میں ابتدائی مسائل۔
ماخذ: www.habr.com