وکٹوریہ میٹرکس ٹائم سیریز کی شکل میں ڈیٹا کو ذخیرہ کرنے اور اس پر کارروائی کرنے کے لیے ایک تیز رفتار اور توسیع پذیر DBMS ہے (ایک ریکارڈ وقت اور اس وقت کے مطابق اقدار کے سیٹ پر مشتمل ہوتا ہے، مثال کے طور پر، سینسر کی حیثیت کی متواتر پولنگ کے ذریعے حاصل کیا جاتا ہے یا میٹرکس کا مجموعہ)۔
میرا نام کولوبایف پاول ہے۔ DevOps, SRE, LeroyMerlin، سب کچھ کوڈ کی طرح ہے - یہ سب ہمارے بارے میں ہے: میرے بارے میں اور LeroyMerlin کے دیگر ملازمین کے بارے میں۔
اوپن اسٹیک پر مبنی ایک کلاؤڈ ہے۔ ٹیکنیکل ریڈار کا ایک چھوٹا سا لنک ہے۔
یہ Kubernetes ہارڈ ویئر کے ساتھ ساتھ OpenStack اور لاگنگ کے لیے تمام متعلقہ خدمات پر بنایا گیا ہے۔
یہ وہ اسکیم ہے جو ہم نے ترقی میں رکھی تھی۔ جب ہم یہ سب تیار کر رہے تھے، ہمارے پاس ایک Prometheus آپریٹر تھا جو K8s کلسٹر کے اندر ہی ڈیٹا محفوظ کرتا تھا۔ وہ خود بخود ڈھونڈ لیتا ہے جس چیز کو صاف کرنے کی ضرورت ہے اور اسے اپنے پیروں کے نیچے رکھ دیتا ہے
ہمیں تمام ڈیٹا کوبرنیٹس کلسٹر سے باہر منتقل کرنے کی ضرورت ہوگی، کیونکہ اگر کچھ ہوتا ہے، تو ہمیں یہ سمجھنے کی ضرورت ہے کہ کیا اور کہاں۔
پہلا حل یہ ہے کہ ہم فیڈریشن کا استعمال اس وقت کریں جب ہمارے پاس تھرڈ پارٹی پرومیتھیس ہو، جب ہم فیڈریشن میکانزم کے ذریعے کبرنیٹس کلسٹر میں جائیں۔
لیکن یہاں کچھ چھوٹے مسائل ہیں۔ ہمارے معاملے میں، مسائل اس وقت شروع ہوئے جب ہمارے پاس 250 میٹرکس تھے، اور جب 000 میٹرکس تھے، ہمیں احساس ہوا کہ ہم اس طرح کام نہیں کر سکتے۔ ہم نے scrape_timeout کو 400 سیکنڈ تک بڑھا دیا۔
ہمیں ایسا کیوں کرنا پڑا؟ پرومیتھیس باڑ کے آغاز سے ٹائم آؤٹ گننا شروع کرتا ہے۔ اس سے کوئی فرق نہیں پڑتا کہ ڈیٹا اب بھی بہہ رہا ہے۔ اگر اس مخصوص مدت کے دوران ڈیٹا کو ضم نہیں کیا جاتا ہے اور سیشن کو HTTP کے ذریعے بند نہیں کیا جاتا ہے، تو سیشن کو ناکام سمجھا جاتا ہے اور ڈیٹا خود پرومیتھیس میں نہیں آتا ہے۔
ہر کوئی ان گرافس سے واقف ہے جو ہمیں کچھ ڈیٹا غائب ہونے پر حاصل ہوتے ہیں۔ شیڈول پھٹا ہوا ہے اور ہم اس سے خوش نہیں ہیں۔
اگلا آپشن ایک ہی فیڈریشن میکانزم کے ذریعے دو مختلف Prometheus پر مبنی شارڈنگ ہے۔
مثال کے طور پر، صرف انہیں لے لو اور نام کے ساتھ ان کا حصہ ڈالو. یہ بھی استعمال کیا جا سکتا ہے، لیکن ہم نے آگے بڑھنے کا فیصلہ کیا۔
اب ہمیں ان شارڈز کو کسی نہ کسی طرح پروسیس کرنا پڑے گا۔ آپ پرامکسی لے سکتے ہیں، جو شارڈ ایریا میں جاتا ہے اور ڈیٹا کو ضرب دیتا ہے۔ یہ ایک ہی انٹری پوائنٹ کے طور پر دو شارڈز کے ساتھ کام کرتا ہے۔ اسے پرامکسی کے ذریعے لاگو کیا جا سکتا ہے، لیکن یہ اب بھی بہت مشکل ہے۔
پہلا آپشن یہ ہے کہ ہم فیڈریشن کے طریقہ کار کو ترک کرنا چاہتے ہیں کیونکہ یہ بہت سست ہے۔
Prometheus کے ڈویلپرز واضح طور پر کہہ رہے ہیں، "دوستوں، ایک مختلف TimescaleDB استعمال کریں کیونکہ ہم میٹرکس کے طویل مدتی اسٹوریج کی حمایت نہیں کریں گے۔" یہ ان کا کام نہیں ہے۔
ہم کاغذ کے ایک ٹکڑے پر لکھتے ہیں کہ ہمیں ابھی بھی باہر سے اتارنے کی ضرورت ہے، تاکہ ہر چیز کو ایک جگہ پر ذخیرہ نہ کیا جائے۔
دوسری خرابی میموری کی کھپت ہے۔ ہاں، میں سمجھتا ہوں کہ بہت سے لوگ کہیں گے کہ 2020 میں کچھ گیگا بائٹس میموری کی قیمت ایک پیسہ ہے، لیکن پھر بھی۔
اب ہمارے پاس دیو اور پروڈ ماحول ہے۔ دیو میں یہ 9 میٹرکس کے لیے تقریباً 350 گیگا بائٹس ہے۔ پیداوار میں یہ 000 گیگا بائٹس اور 14 میٹرکس سے کچھ زیادہ ہے۔ ایک ہی وقت میں، ہمارا برقرار رکھنے کا وقت صرف 780 منٹ ہے۔ یہ برا ہے. اور اب میں اس کی وجہ بتاؤں گا۔
ہم ایک حساب لگاتے ہیں، یعنی ڈیڑھ ملین میٹرکس کے ساتھ، اور ہم پہلے ہی ان کے قریب ہیں، ڈیزائن کے مرحلے پر ہمیں 35-37 گیگا بائٹس میموری ملتی ہے۔ لیکن پہلے ہی 4 ملین میٹرکس کے لیے تقریباً 90 گیگا بائٹس میموری کی ضرورت ہوتی ہے۔ یعنی پرومیتھیس ڈویلپرز کے فراہم کردہ فارمولے کا استعمال کرتے ہوئے اس کا حساب لگایا گیا۔ ہم نے ارتباط کو دیکھا اور محسوس کیا کہ ہم صرف نگرانی کے لیے سرور کے لیے چند ملین ادا نہیں کرنا چاہتے۔
ہم نہ صرف مشینوں کی تعداد میں اضافہ کریں گے بلکہ ورچوئل مشینوں کی خود نگرانی بھی کر رہے ہیں۔ اس لیے جتنی زیادہ ورچوئل مشینیں ہوں گی، مختلف قسم کے میٹرکس وغیرہ۔ میٹرکس کے لحاظ سے ہمارے کلسٹر میں خاص اضافہ ہوگا۔
ڈسک کی جگہ کے ساتھ، یہاں سب کچھ اتنا خراب نہیں ہے، لیکن میں اسے بہتر کرنا چاہوں گا۔ ہمیں 15 دنوں میں کل 120 گیگا بائٹس موصول ہوئے، جن میں سے 100 کمپریسڈ ڈیٹا، 20 غیر کمپریسڈ ڈیٹا ہیں، لیکن ہم ہمیشہ کم چاہتے ہیں۔
اس کے مطابق، ہم ایک اور نکتہ لکھتے ہیں - یہ وسائل کی ایک بڑی کھپت ہے، جسے ہم اب بھی بچانا چاہتے ہیں، کیونکہ ہم نہیں چاہتے کہ ہمارا مانیٹرنگ کلسٹر ہمارے کلسٹر سے زیادہ وسائل استعمال کرے، جو OpenStack کا انتظام کرتا ہے۔
Prometheus کی ایک اور خرابی ہے، جس کی ہم نے خود نشاندہی کی ہے، یہ کم از کم میموری کی ایک قسم کی حد ہے۔ Prometheus کے ساتھ، یہاں سب کچھ بہت زیادہ خراب ہے، کیونکہ اس میں ایسے موڑ بالکل نہیں ہیں۔ ڈوکر میں حد کا استعمال بھی آپشن نہیں ہے۔ اگر اچانک آپ کا RAF گر گیا اور 20-30 گیگا بائٹس ہیں، تو اسے اوپر آنے میں کافی وقت لگے گا۔
یہ ایک اور وجہ ہے کہ Prometheus ہمارے لیے موزوں نہیں ہے، یعنی ہم میموری کی کھپت کو محدود نہیں کر سکتے۔
اس طرح کی ایک سکیم کے ساتھ آنا ممکن ہو گا. HA کلسٹر کو منظم کرنے کے لیے ہمیں اس اسکیم کی ضرورت ہے۔ ہم چاہتے ہیں کہ ہمارے میٹرکس ہمیشہ اور ہر جگہ دستیاب رہیں، چاہے ان میٹرکس کو اسٹور کرنے والا سرور کریش ہو جائے۔ اور اس طرح ہمیں ایسی اسکیم بنانا پڑے گی۔
یہ اسکیم کہتی ہے کہ ہمارے پاس شارڈز کی نقل ہوگی، اور اس کے مطابق، استعمال شدہ وسائل کے اخراجات کی نقل ہوگی۔ اسے تقریباً افقی طور پر پیمانہ کیا جا سکتا ہے، لیکن اس کے باوجود وسائل کی کھپت جہنمی ہو گی۔
ترتیب میں نقصانات جس میں ہم نے انہیں اپنے لیے لکھا ہے:
- بیرونی طور پر میٹرکس اپ لوڈ کرنے کی ضرورت ہے۔
- اعلی وسائل کی کھپت۔
- میموری کی کھپت کو محدود کرنے کا کوئی طریقہ نہیں ہے۔
- HA کا پیچیدہ اور وسائل سے بھرپور نفاذ۔
اپنے لیے، ہم نے فیصلہ کیا کہ ہم پرومیتھیس سے ایک اسٹوریج کی سہولت کے طور پر دور جا رہے ہیں۔
ہم نے اپنے لیے اضافی ضروریات کی نشاندہی کی ہے جن کی ہمیں ضرورت ہے۔ یہ:
- یہ promql کی حمایت ہے، کیونکہ Prometheus کے لیے بہت سی چیزیں پہلے ہی لکھی جا چکی ہیں: سوالات، انتباہات۔
- اور پھر ہمارے پاس گرافانا ہے، جو پہلے ہی بالکل اسی طرح پرومیٹیس کے لیے بیک اینڈ کے طور پر لکھا گیا ہے۔ میں ڈیش بورڈز کو دوبارہ نہیں لکھنا چاہتا۔
- ہم ایک عام HA آرکیٹیکچر بنانا چاہتے ہیں۔
- ہم کسی بھی وسائل کی کھپت کو کم کرنا چاہتے ہیں۔
- ایک اور چھوٹی سی بات ہے۔ ہم مختلف قسم کے کلاؤڈ میٹرکس کلیکشن سسٹم استعمال نہیں کر سکتے۔ ہم ابھی تک نہیں جانتے کہ ان میٹرکس میں کیا آئے گا۔ اور چونکہ وہاں کچھ بھی اڑ سکتا ہے، ہمیں خود کو مقامی جگہوں تک محدود رکھنا ہوگا۔
بہت کم انتخاب تھا۔ ہم نے وہ سب کچھ اکٹھا کیا جس کا ہمیں تجربہ تھا۔ ہم نے انضمام کے حصے میں پرومیٹیس صفحہ کو دیکھا، مضامین کا ایک گروپ پڑھا، اور دیکھا کہ وہاں کیا ہے۔ اور اپنے لیے، ہم نے VictoriaMetrics کو Prometheus کے متبادل کے طور پر منتخب کیا۔
کیوں؟ کیونکہ:
- promql جانتا ہے۔
- ایک ماڈیولر فن تعمیر ہے۔
- گرافانا میں تبدیلیوں کی ضرورت نہیں ہے۔
- اور سب سے اہم بات یہ ہے کہ ہم اپنی کمپنی کے اندر میٹرکس اسٹوریج کو بطور سروس فراہم کریں گے، اس لیے ہم مختلف قسم کی پابندیوں کی طرف پیشگی تلاش کر رہے ہیں تاکہ صارفین کلسٹر کے تمام وسائل کو کسی حد تک محدود طریقے سے استعمال کر سکیں، کیونکہ ایک موقع موجود ہے۔ کہ یہ کثیر کرایہ داری کرے گا.
آئیے پہلا موازنہ کرتے ہیں۔ ہم اسی پرومیتھیس کو کلسٹر کے اندر لے جاتے ہیں، بیرونی پرومیتھیس اس کی طرف جاتا ہے۔ remoteWrite VictoriaMetrics کے ذریعے شامل کریں۔
میں فوری طور پر ایک ریزرویشن کروں گا کہ یہاں ہم نے VictoriaMetrics سے CPU کی کھپت میں معمولی اضافہ دیکھا ہے۔ VictoriaMetrics ویکی آپ کو بتاتا ہے کہ کون سے پیرامیٹرز بہترین ہیں۔ ہم نے انہیں چیک کیا۔ انہوں نے CPU کی کھپت کو بہت اچھی طرح سے کم کیا ہے۔
ہمارے معاملے میں، Prometheus کی یادداشت کی کھپت، جو Kubernetes کلسٹر میں واقع ہے، نمایاں طور پر نہیں بڑھی۔
ہم ایک ہی ڈیٹا کے دو ڈیٹا ذرائع کا موازنہ کرتے ہیں۔ Prometheus میں ہم وہی گمشدہ ڈیٹا دیکھتے ہیں۔ وکٹوریہ میٹرکس میں سب کچھ ٹھیک ہے۔
ڈسک اسپیس ٹیسٹ کے نتائج۔ پرومیتھیس میں ہمیں مجموعی طور پر 120 گیگا بائٹس موصول ہوئے۔ VictoriaMetrics میں ہم پہلے ہی 4 گیگا بائٹس فی دن وصول کرتے ہیں۔ پرومیتھیس میں جو ہم دیکھنے کے عادی ہیں اس سے تھوڑا مختلف طریقہ کار ہے۔ یعنی، ڈیٹا پہلے ہی ایک دن میں، آدھے گھنٹے میں کافی اچھی طرح سے کمپریس ہو جاتا ہے۔ وہ پہلے ہی ایک دن میں اچھی طرح سے کاٹ چکے ہیں، آدھے گھنٹے میں، اس حقیقت کے باوجود کہ ڈیٹا اب بھی بعد میں ضائع ہو جائے گا۔ نتیجے کے طور پر، ہم نے ڈسک کی جگہ پر بچت کی۔
ہم میموری وسائل کی کھپت پر بھی بچت کرتے ہیں۔ جانچ کے وقت، ہم نے پرومیتھیس کو ایک ورچوئل مشین - 8 کور، 24 گیگا بائٹس پر تعینات کیا تھا۔ پرومیتھیس تقریباً سب کچھ کھاتا ہے۔ وہ OOM قاتل پر گر پڑا۔ ایک ہی وقت میں، اس میں صرف 900 فعال میٹرکس ڈالے گئے تھے۔ یہ تقریباً 000-25 میٹرکس فی سیکنڈ ہے۔
ہم نے VictoriaMetrics کو 8 گیگا بائٹس RAM کے ساتھ ڈوئل کور ورچوئل مشین پر چلایا۔ ہم وکٹوریہ میٹرکس کو 8 جی بی مشین پر کچھ چیزوں کے ساتھ گھوم پھر کر اچھی طرح سے کام کرنے میں کامیاب ہو گئے۔ آخر میں، ہم نے اسے 7 گیگا بائٹس تک رکھا۔ اس کے ساتھ ساتھ مواد کی ترسیل کی رفتار، یعنی میٹرکس، پرومیتھیس سے بھی زیادہ تھی۔
CPU Prometheus کے مقابلے بہت بہتر ہو گیا ہے۔ یہاں Prometheus 2,5 cores استعمال کرتا ہے، اور VictoriaMetrics صرف 0,25 cores استعمال کرتا ہے۔ شروع میں - 0,5 کور۔ جیسے جیسے یہ ضم ہوتا ہے، یہ ایک کور تک پہنچ جاتا ہے، لیکن یہ انتہائی، انتہائی نایاب ہے۔
ہمارے معاملے میں، انتخاب واضح وجوہات کی بناء پر وکٹوریہ میٹرکس پر پڑا؛ ہم پیسہ بچانا چاہتے تھے اور ہم نے ایسا کیا۔
آئیے فوراً دو نکات کو عبور کرتے ہیں – میٹرکس کی اپ لوڈنگ اور وسائل کی زیادہ کھپت۔ اور ہمیں صرف دو نکات کا فیصلہ کرنا ہے جو ہم نے ابھی اپنے لیے چھوڑے ہیں۔
یہاں میں ابھی ایک ریزرویشن کروں گا، ہم وکٹوریہ میٹرکس کو میٹرکس کا ذخیرہ سمجھتے ہیں۔ لیکن چونکہ ہم غالباً VictoriaMetrics کو تمام Leroy کے لیے اسٹوریج کے طور پر فراہم کریں گے، ہمیں ان لوگوں کو محدود کرنے کی ضرورت ہے جو اس کلسٹر کو استعمال کریں گے تاکہ وہ ہمیں نہ دیں۔
ایک شاندار پیرامیٹر ہے جو آپ کو وقت کے لحاظ سے، ڈیٹا کے حجم کے لحاظ سے اور عملدرآمد کے وقت کے لحاظ سے محدود کرنے کی اجازت دیتا ہے۔
ایک بہترین آپشن بھی ہے جو ہمیں میموری کی کھپت کو محدود کرنے کی اجازت دیتا ہے، اس طرح ہم بہت توازن تلاش کر سکتے ہیں جو ہمیں عام آپریٹنگ رفتار اور وسائل کی مناسب استعمال حاصل کرنے کی اجازت دے گا۔
مائنس ایک اور پوائنٹ، یعنی کراس آؤٹ دی پوائنٹ - آپ میموری کی کھپت کو محدود نہیں کر سکتے۔
پہلی تکرار میں، ہم نے وکٹوریہ میٹرکس سنگل نوڈ کا تجربہ کیا۔ اس کے بعد ہم وکٹوریہ میٹرکس کلسٹر ورژن کی طرف بڑھتے ہیں۔
یہاں ہمارے پاس VictoriaMetrics میں مختلف خدمات کو الگ کرنے کے لیے ایک آزاد ہاتھ ہے اس پر منحصر ہے کہ وہ کس چیز پر چلیں گی اور وہ کون سے وسائل استعمال کریں گے۔ یہ ایک بہت ہی لچکدار اور آسان حل ہے۔ ہم نے اسے اپنے اوپر استعمال کیا۔
VictoriaMetrics کلسٹر ورژن کے اہم اجزاء vmstsorage ہیں۔ ان کا N نمبر ہو سکتا ہے۔ ہمارے معاملے میں اب تک ان میں سے 2 ہیں۔
اور وہاں vminsert ہے۔ یہ ایک پراکسی سرور ہے جو ہمیں اجازت دیتا ہے کہ: ان تمام سٹوریجز کے درمیان شارڈنگ کا بندوبست کریں جن کے بارے میں ہم نے اسے بتایا ہے، اور یہ ایک نقل کی بھی اجازت دیتا ہے، یعنی آپ کے پاس شارڈنگ اور ایک نقل دونوں ہوں گے۔
Vminsert Prometheus سے OpenTSDB، Graphite، InfluxDB اور remoteWrite پروٹوکول کو سپورٹ کرتا ہے۔
vmselect بھی ہے۔ اس کا بنیادی کام vmstorage پر جانا، ان سے ڈیٹا وصول کرنا، اس ڈیٹا کو ڈپلیکیٹ کرنا اور کلائنٹ کو دینا ہے۔
vmagent نامی ایک حیرت انگیز چیز ہے۔ ہم واقعی اسے پسند کرتے ہیں۔ یہ آپ کو بالکل Prometheus کی طرح ترتیب دینے اور پھر بھی Prometheus کی طرح سب کچھ کرنے کی اجازت دیتا ہے۔ یعنی، یہ مختلف اداروں اور خدمات سے میٹرکس اکٹھا کرتا ہے اور انہیں vminsert کو بھیجتا ہے۔ پھر سب کچھ آپ پر منحصر ہے۔
ایک اور زبردست سروس vmalert ہے، جو آپ کو VictoriaMetrics کو بیک اینڈ کے طور پر استعمال کرنے، vminsert سے پروسیس شدہ ڈیٹا حاصل کرنے اور اسے vmselect پر بھیجنے کی اجازت دیتی ہے۔ یہ انتباہات کے ساتھ ساتھ قواعد پر بھی کارروائی کرتا ہے۔ انتباہات کی صورت میں، ہمیں الرٹ مینیجر کے ذریعے الرٹ موصول ہوتا ہے۔
ایک wmauth جزو ہے۔ ہم کر سکتے ہیں یا نہیں (ہم نے ابھی تک اس پر فیصلہ نہیں کیا ہے) اسے کلسٹرز کے ملٹی ٹیننسی ورژن کے لیے اجازت کے نظام کے طور پر استعمال کر سکتے ہیں۔ یہ Prometheus کے لیے ریموٹ رائٹ کو سپورٹ کرتا ہے اور یو آر ایل، یا اس کے دوسرے حصے کی بنیاد پر اجازت دے سکتا ہے، جہاں آپ لکھ سکتے ہیں یا نہیں لکھ سکتے۔
vmbackup، vmrestore بھی ہے۔ یہ، جوہر میں، تمام ڈیٹا کی بحالی اور بیک اپ ہے۔ S3، GCS، فائل کر سکتے ہیں.
ہمارے کلسٹر کا پہلا تکرار قرنطینہ کے دوران کیا گیا تھا۔ اس وقت، کوئی نقل نہیں تھی، لہذا ہماری تکرار دو مختلف اور آزاد کلسٹرز پر مشتمل تھی جس میں ہمیں ریموٹ رائٹ کے ذریعے ڈیٹا موصول ہوا۔
یہاں میں ایک ریزرویشن کروں گا کہ جب ہم نے VictoriaMetrics Single Node سے VictoriaMetrics کلسٹر ورژن میں تبدیل کیا، تب بھی ہم وہی استعمال شدہ وسائل کے ساتھ رہے، یعنی سب سے اہم میموری ہے۔ تقریباً یہی ہے کہ ہمارا ڈیٹا، یعنی وسائل کی کھپت، تقسیم کی گئی۔
ایک نقل پہلے ہی یہاں شامل کی جا چکی ہے۔ ہم نے ان سب کو ایک نسبتاً بڑے کلسٹر میں جوڑ دیا۔ ہمارا تمام ڈیٹا شارڈ اور نقل کیا گیا ہے۔
پورے کلسٹر میں N انٹری پوائنٹس ہیں، یعنی Prometheus HAPROXY کے ذریعے ڈیٹا شامل کر سکتا ہے۔ یہاں ہمارے پاس یہ انٹری پوائنٹ ہے۔ اور اس انٹری پوائنٹ کے ذریعے آپ Grafana سے لاگ ان کر سکتے ہیں۔
ہمارے معاملے میں، HAPROXY واحد پورٹ ہے جو پراکسی اس کلسٹر کے اندر منتخب، داخل اور دیگر خدمات انجام دیتی ہے۔ ہمارے معاملے میں، ایک ایڈریس بنانا ناممکن تھا؛ ہمیں کئی انٹری پوائنٹس بنانے پڑے، کیونکہ ورچوئل مشینیں جن پر وکٹوریہ میٹرکس کلسٹر چلتا ہے، ایک ہی کلاؤڈ فراہم کنندہ کے مختلف زونز میں واقع ہیں، یعنی ہمارے کلاؤڈ کے اندر نہیں، بلکہ باہر۔ .
ہمارے پاس الرٹ ہے۔ ہم اسے استعمال کرتے ہیں۔ ہم Prometheus سے alertmanager استعمال کرتے ہیں۔ ہم Opsgenie اور Telegram کو الرٹ ڈیلیوری چینل کے طور پر استعمال کرتے ہیں۔ ٹیلیگرام میں وہ dev سے ڈالتے ہیں، شاید پروڈ سے کچھ، لیکن زیادہ تر کچھ شماریاتی، انجینئرز کو درکار ہوتا ہے۔ اور Opsgenie اہم ہے. یہ کالز ہیں، واقعہ کا انتظام۔
ابدی سوال: "مانیٹرنگ کی نگرانی کون کرتا ہے؟" ہمارے معاملے میں، مانیٹرنگ مانیٹر خود کی نگرانی کرتا ہے، کیونکہ ہم ہر نوڈ پر vmagent استعمال کرتے ہیں۔ اور چونکہ ہمارے نوڈس ایک ہی فراہم کنندہ کے مختلف ڈیٹا سینٹرز میں تقسیم کیے جاتے ہیں، اس لیے ہر ڈیٹا سینٹر کا اپنا چینل ہوتا ہے، وہ خود مختار ہوتے ہیں، اور یہاں تک کہ اگر ایک منقسم دماغ آجاتا ہے، تب بھی ہمیں الرٹس موصول ہوں گے۔ ہاں، ان میں سے اور بھی ہوں گے، لیکن کسی سے بھی زیادہ الرٹس وصول کرنا بہتر ہے۔
ہم اپنی فہرست کو HA کے نفاذ کے ساتھ ختم کرتے ہیں۔
اور مزید میں VictoriaMetrics کمیونٹی کے ساتھ بات چیت کے تجربے کو نوٹ کرنا چاہوں گا۔ یہ بہت مثبت نکلا۔ لڑکے جوابدہ ہیں۔ وہ پیش کیے جانے والے ہر معاملے میں کھوج لگانے کی کوشش کرتے ہیں۔
میں نے گٹ ہب پر مسائل شروع کیے ہیں۔ وہ بہت جلد حل ہو گئے۔ کچھ اور مسائل ہیں جو مکمل طور پر بند نہیں ہوئے ہیں، لیکن میں پہلے ہی کوڈ سے دیکھ سکتا ہوں کہ اس سمت میں کام جاری ہے۔
تکرار کے دوران میرے لئے بنیادی تکلیف یہ تھی کہ اگر میں ایک نوڈ کو بند کرتا ہوں تو پہلے 30 سیکنڈ تک vminsert یہ نہیں سمجھ سکتا تھا کہ کوئی بیک اینڈ نہیں ہے۔ اب یہ فیصلہ ہو چکا ہے۔ اور لفظی طور پر ایک یا دو سیکنڈ میں، ڈیٹا باقی تمام نوڈس سے لیا جاتا ہے، اور درخواست اس گمشدہ نوڈ کے انتظار میں رک جاتی ہے۔
کسی وقت ہم چاہتے تھے کہ VictoriaMetrics ایک VictoriaMetrics آپریٹر بنے۔ ہم اس کا انتظار کرتے رہے۔ اب ہم VictoriaMetrics آپریٹر کے لیے پہلے سے حساب لگانے کے تمام اصولوں وغیرہ کو لینے کے لیے ایک فریم ورک کو فعال طور پر بنا رہے ہیں۔
کلسٹر کے نفاذ کو بہتر بنانے کی تجاویز ہیں۔ میں نے انہیں اوپر بیان کیا ہے۔
اور میں واقعی نیچے نمونہ کرنا چاہتا ہوں۔ ہمارے معاملے میں، نمونے لینے کی ضرورت صرف رجحانات کو دیکھنے کے لیے ہے۔ موٹے الفاظ میں، میرے لیے دن میں ایک میٹرک کافی ہے۔ یہ رجحانات ایک سال، تین، پانچ، دس سال کے لیے درکار ہیں۔ اور ایک میٹرک قدر کافی ہے۔
- ہم درد کو جانتے ہیں، جیسا کہ ہمارے کچھ ساتھی پرومیتھیس کا استعمال کرتے وقت جانتے ہیں۔
- ہم نے اپنے لیے وکٹوریہ میٹرکس کا انتخاب کیا۔
- یہ عمودی اور افقی طور پر کافی اچھی طرح سے پیمانہ ہے۔
- ہم مختلف اجزاء کو کلسٹر میں نوڈس کی مختلف تعداد میں تقسیم کر سکتے ہیں، انہیں میموری کے ذریعے محدود کر سکتے ہیں، میموری شامل کر سکتے ہیں، وغیرہ۔
ہم گھر پر VictoriaMetrics استعمال کریں گے کیونکہ ہمیں واقعی یہ پسند آیا۔ یہ جو تھا اور جو بن گیا ہے۔
VictoriaMetrics چیٹ، میرے رابطے، LeroyMerlin ٹیکنیکل ریڈار کے لیے کچھ QR کوڈز۔
ماخذ: www.habr.com