آج، یک سنگی کوڈ کے علاوہ، درجنوں مائیکرو سروسز ہمارے پروجیکٹ پر کام کرتی ہیں۔ ان میں سے ہر ایک کی نگرانی کی ضرورت ہے۔ DevOps انجینئرز کے ذریعہ ایسی جلدوں میں ایسا کرنا مشکل ہے۔ ہم نے ایک مانیٹرنگ سسٹم تیار کیا ہے جو ڈویلپرز کے لیے ایک سروس کے طور پر کام کرتا ہے۔ وہ مانیٹرنگ سسٹم میں آزادانہ طور پر میٹرکس لکھ سکتے ہیں، ان کا استعمال کر سکتے ہیں، ان کی بنیاد پر ڈیش بورڈ بنا سکتے ہیں، ان کے ساتھ انتباہات منسلک کر سکتے ہیں جو حد کی قدروں تک پہنچنے پر متحرک ہو جائیں گے۔ DevOps انجینئرز کے ساتھ - صرف بنیادی ڈھانچہ اور دستاویزات۔
یہ پوسٹ ہماری طرف سے میری تقریر کی نقل ہے۔ RIT++ پر۔ بہت سے لوگوں نے ہم سے وہاں سے رپورٹس کے ٹیکسٹ ورژن بنانے کو کہا۔ اگر آپ کسی کانفرنس میں گئے ہیں یا کوئی ویڈیو دیکھی ہے تو آپ کو کوئی نئی چیز نہیں ملے گی۔ اور باقی سب کو - بلی کے نیچے خوش آمدید۔ میں آپ کو بتاؤں گا کہ ہمارے پاس ایسا نظام کیسے آیا، یہ کیسے کام کرتا ہے اور ہم اسے اپ ڈیٹ کرنے کا منصوبہ کیسے رکھتے ہیں۔
ماضی: اسکیمیں اور منصوبے
ہم موجودہ مانیٹرنگ سسٹم میں کیسے آئے؟ اس سوال کا جواب دینے کے لیے، آپ کو 2015 میں جانا ہوگا۔ یہ اس وقت کیسا لگتا تھا:
ہمارے پاس تقریباً 24 نوڈس تھے جو نگرانی کے ذمہ دار تھے۔ مختلف کرونز، اسکرپٹس، ڈیمنز کا ایک پورا گروپ ہے جو کہیں کسی چیز کی نگرانی کرتا ہے، پیغامات بھیجتا ہے، افعال انجام دیتا ہے۔ ہمارا خیال تھا کہ اس طرح کا نظام جتنا آگے بڑھے گا اتنا ہی کم قابل عمل ہوگا۔ اسے تیار کرنے کا کوئی مطلب نہیں ہے: یہ بہت بوجھل ہے۔
ہم نے نگرانی کے ان عناصر کو منتخب کرنے کا فیصلہ کیا جنہیں ہم چھوڑیں گے اور ترقی کریں گے، اور جن کو ہم ترک کر دیں گے۔ ان میں سے 19 تھے۔ صرف گریفائٹس، ایگریگیٹرز اور گرافانا بطور ڈیش بورڈ باقی رہ گئے تھے۔ لیکن نیا نظام کیسا ہوگا؟ اس طرح:
ہمارے پاس میٹرکس کا ذخیرہ ہے: یہ وہ گریفائٹس ہیں جو تیز SSD ڈرائیوز پر مبنی ہوں گے، یہ میٹرکس کے لیے کچھ خاص جمع کرنے والے ہیں۔ اگلا - ڈیش بورڈز اور مورا کو الرٹ کے طور پر ڈسپلے کرنے کے لیے گرافانا۔ ہم بے ضابطگیوں کو تلاش کرنے کے لیے ایک نظام بھی تیار کرنا چاہتے تھے۔
معیاری: مانیٹرنگ 2.0
2015 میں منصوبے ایسے ہی نظر آئے۔ لیکن ہمیں نہ صرف بنیادی ڈھانچہ اور سروس خود تیار کرنی تھی بلکہ اس کے لیے دستاویزات بھی تیار کرنی تھیں۔ ہم نے اپنے لیے ایک کارپوریٹ معیار تیار کیا ہے، جسے ہم نے مانیٹرنگ 2.0 کہا ہے۔ نظام کے تقاضے کیا تھے؟
- مسلسل دستیابی؛
- میٹرک اسٹوریج وقفہ = 10 سیکنڈ؛
- میٹرکس اور ڈیش بورڈز کا منظم ذخیرہ؛
- SLA > 99,99%
- UDP (!) کے ذریعے ایونٹ میٹرکس کا مجموعہ۔
ہمیں UDP کی ضرورت تھی کیونکہ ہمارے پاس بہت زیادہ ٹریفک اور واقعات ہیں جو میٹرکس تیار کرتے ہیں۔ اگر وہ سب ایک ساتھ گریفائٹ میں لکھے جائیں تو ذخیرہ گر جائے گا۔ ہم نے تمام میٹرکس کے لیے پہلے درجے کے سابقے بھی منتخب کیے ہیں۔
سابقے میں سے ہر ایک کی کچھ خاصیت ہوتی ہے۔ سرورز، نیٹ ورکس، کنٹینرز، وسائل، ایپلی کیشنز وغیرہ کے لیے میٹرکس موجود ہیں۔ ایک واضح، سخت، ٹائپ شدہ فلٹرنگ لاگو کی گئی ہے، جہاں ہم پہلے درجے کے میٹرکس کو قبول کرتے ہیں، اور باقی کو چھوڑ دیتے ہیں۔ اس طرح ہم نے 2015 میں اس نظام کی منصوبہ بندی کی۔ حال میں کیا ہے؟
موجودہ: نگرانی کے اجزاء کے تعامل کی اسکیم
سب سے پہلے، ہم ایپلی کیشنز کی نگرانی کرتے ہیں: ہمارا پی ایچ پی کوڈ، ایپلی کیشنز اور مائیکرو سروسز - ایک لفظ میں، ہر وہ چیز جو ہمارے ڈویلپر لکھتے ہیں۔ تمام ایپلیکیشنز میٹرکس UDP کے ذریعے بروبیک ایگریگیٹر کو بھیجتی ہیں (statsd، C میں دوبارہ لکھی گئی)۔ مصنوعی ٹیسٹ کے نتائج کے مطابق یہ سب سے تیز ثابت ہوا۔ اور یہ پہلے سے جمع شدہ میٹرکس کو ٹی سی پی کے ذریعے گریفائٹ کو بھیجتا ہے۔
اس میں ٹائمر جیسے میٹرکس ہیں۔ یہ بہت آسان چیز ہے۔ مثال کے طور پر، سروس سے ہر صارف کے کنکشن کے لیے، آپ بروبیک کو رسپانس ٹائم میٹرک بھیجتے ہیں۔ ایک ملین جوابات آئے، اور جمع کرنے والے نے صرف 10 میٹرکس دیے۔ آپ کے پاس آنے والے لوگوں کی تعداد، زیادہ سے زیادہ، کم سے کم اور اوسط جوابی اوقات، درمیانی اور 4 پرسنٹائلز ہیں۔ پھر ڈیٹا گریفائٹ میں منتقل ہوتا ہے اور ہم ان سب کو زندہ دیکھتے ہیں۔
ہمارے پاس ہارڈ ویئر، سافٹ ویئر، سسٹم میٹرکس اور ہمارے پرانے منین مانیٹرنگ سسٹم کے لیے بھی جمع ہے (یہ 2015 تک ہمارے ساتھ کام کرتا تھا)۔ ہم یہ سب کچھ C'ish daemon CollectD کے ذریعے جمع کرتے ہیں (مختلف پلگ انز کا ایک پورا گروپ اس میں سلائی ہوا ہے، یہ میزبان سسٹم کے تمام وسائل سے استفسار کر سکتا ہے جس پر یہ انسٹال ہے، صرف اس ترتیب میں واضح کریں کہ ڈیٹا کہاں لکھا جائے ) اور گریفائٹ میں اس کے ذریعے ڈیٹا لکھیں۔ یہ python پلگ انز اور شیل اسکرپٹس کو بھی سپورٹ کرتا ہے، لہذا آپ اپنی مرضی کے مطابق حل لکھ سکتے ہیں: CollectD اس ڈیٹا کو مقامی یا ریموٹ ہوسٹ (فرض کر کے کہ کرل دستیاب ہے) سے جمع کرے گا اور اسے Graphite کو بھیجے گا۔
مزید، تمام میٹرکس جو ہم نے جمع کیے ہیں کاربن-سی-ریلے کو بھیجے جاتے ہیں۔ یہ گریفائٹ کا کاربن ریلے حل ہے، جس میں C میں ترمیم کی گئی ہے۔ یہ ایک راؤٹر ہے جو تمام میٹرکس کو جمع کرتا ہے جو ہم اپنے ایگریگیٹرز سے بھیجتے ہیں اور انہیں نوڈس کے ذریعے روٹ کرتے ہیں۔ روٹنگ کے مرحلے پر بھی، یہ میٹرکس کی درستگی کو چیک کرتا ہے۔ سب سے پہلے، انہیں اس سابقہ اسکیم سے مماثل ہونا چاہیے جو میں نے پہلے دکھایا تھا اور، دوسرا، وہ گریفائٹ کے لیے درست ہونا چاہیے۔ دوسری صورت میں، وہ گر جاتے ہیں.
پھر کاربن-سی-ریلے میٹرکس کو گریفائٹ کلسٹر کو بھیجتا ہے۔ ہم میٹرکس کے لیے مرکزی اسٹوریج کے طور پر گو میں دوبارہ لکھے گئے کاربن کیشے کا استعمال کرتے ہیں۔ گو کاربن، اپنی ملٹی تھریڈنگ کی وجہ سے، کاربن کیشے سے کارکردگی میں کہیں بہتر ہے۔ یہ ڈیٹا کو اپنے اندر لیتا ہے اور وسپر پیکج (معیاری، ازگر میں لکھا ہوا) کا استعمال کرتے ہوئے اسے ڈسک پر لکھتا ہے۔ اپنے سٹوریج سے ڈیٹا پڑھنے کے لیے، ہم Graphite API استعمال کرتے ہیں۔ یہ معیاری Graphite WEB سے زیادہ تیزی سے کام کرتا ہے۔ ڈیٹا کا اگلا کیا ہوتا ہے؟
وہ گرافانا جاتے ہیں۔ ہم اپنے گریفائٹ کلسٹرز کو ڈیٹا کے مرکزی ذریعہ کے طور پر استعمال کرتے ہیں، نیز ہمارے پاس میٹرکس دکھانے، ڈیش بورڈ بنانے کے لیے ایک ویب انٹرفیس کے طور پر گرافانا ہے۔ اپنی ہر سروس کے لیے، ڈویلپر اپنا ڈیش بورڈ بناتے ہیں۔ پھر وہ ان کی بنیاد پر گراف بناتے ہیں، جو وہ میٹرکس دکھاتے ہیں جو وہ اپنی ایپلی کیشنز سے لکھتے ہیں۔ گرافانا کے علاوہ، ہمارے پاس سلیم بھی ہے۔ یہ ایک pythonic شیطان ہے جو گریفائٹ کے ڈیٹا کی بنیاد پر SLA کا حساب لگاتا ہے۔ جیسا کہ میں نے کہا، ہمارے پاس کئی درجن مائیکرو سروسز ہیں، جن میں سے ہر ایک کی اپنی ضروریات ہیں۔ SLAM کی مدد سے، ہم دستاویزات پر جاتے ہیں اور اس کا موازنہ Graphite میں موجود چیزوں سے کرتے ہیں اور موازنہ کرتے ہیں کہ ضروریات ہماری خدمات کی دستیابی سے کس طرح مطابقت رکھتی ہیں۔
آگے بڑھنا: خبردار کرنا۔ یہ ایک مضبوط نظام کے ساتھ منظم ہے - Moira. وہ خود مختار ہے کیونکہ اس کے پاس ہڈ کے نیچے اپنا گریفائٹ ہے۔ SKB Kontur کے لڑکوں کے ذریعہ تیار کیا گیا، python اور Go میں لکھا گیا، مکمل طور پر اوپن سورس۔ مائرا کو وہی بہاؤ ملتا ہے جو گریفائٹس میں جاتا ہے۔ اگر کسی وجہ سے آپ کا سٹوریج مر جاتا ہے، تو آپ کا الرٹ کام کرے گا۔
ہم نے Moira کو Kubernetes میں تعینات کیا، یہ Redis سرورز کے ایک کلسٹر کو مرکزی ڈیٹا بیس کے طور پر استعمال کرتا ہے۔ نتیجہ ایک غلطی برداشت کرنے والا نظام ہے۔ یہ محرکات کی فہرست کے ساتھ میٹرکس کے بہاؤ کا موازنہ کرتا ہے: اگر اس میں کوئی ذکر نہیں ہے، تو یہ میٹرک کو گرا دیتا ہے۔ اس لیے وہ گیگا بائٹس میٹرکس فی منٹ ہضم کرنے کے قابل ہے۔
ہم نے اس میں ایک کارپوریٹ LDAP بھی شامل کیا، جس کی مدد سے کارپوریٹ سسٹم کا ہر صارف موجودہ (یا نئے بنائے گئے) محرکات پر اپنے لیے اطلاعات بنا سکتا ہے۔ چونکہ Moira Graphite پر مشتمل ہے، یہ اس کی تمام خصوصیات کو سپورٹ کرتا ہے۔ تو آپ پہلے لائن لیں اور اسے گرافانا میں کاپی کریں۔ دیکھیں کہ چارٹ پر ڈیٹا کیسے ظاہر ہوتا ہے۔ اور پھر آپ وہی لائن لیں اور اسے Moira میں کاپی کریں۔ اسے حد کے ساتھ لٹکا دیں اور آؤٹ پٹ پر الرٹ حاصل کریں۔ یہ سب کرنے کے لیے، آپ کو کسی خاص علم کی ضرورت نہیں ہے۔ Moira ایس ایم ایس، ای میل، جیرا، سلیک کے ذریعے الرٹ کر سکتا ہے… یہ حسب ضرورت اسکرپٹس کو بھی سپورٹ کرتا ہے۔ جب اس کے پاس ٹرگر ہوتا ہے، اور اس نے کسٹم اسکرپٹ یا بائنری کو سبسکرائب کیا ہوتا ہے، تو وہ اسے لانچ کرتی ہے اور اس JSON بائنری کو stdin کو بھیجتی ہے۔ اس کے مطابق، آپ کے پروگرام کو اس کا تجزیہ کرنا چاہیے۔ آپ اس JSON کے ساتھ کیا کریں گے آپ پر منحصر ہے۔ چاہو تو ٹیلی گرام پر بھیج دو، جیرا میں کام کھولو، جو چاہو کرو۔
ہم اپنی ترقی کو الرٹ کرنے کے لیے بھی استعمال کرتے ہیں - Imagotag۔ ہم نے پینل کو اپنی ضروریات کے مطابق ڈھال لیا، جو عام طور پر اسٹورز میں الیکٹرانک پرائس ٹیگز کے لیے استعمال ہوتا ہے۔ ہم اس میں Moira سے محرکات لائے۔ یہ بتاتا ہے کہ وہ کس حالت میں ہیں، جب وہ ہوا تھا۔ ترقی کے کچھ لڑکوں نے اس پینل کے حق میں سلیک اور میل میں اطلاعات کو ترک کر دیا۔
ٹھیک ہے، چونکہ ہم ایک ترقی پسند کمپنی ہیں، ہم نے اس سسٹم میں Kubernetes کی بھی نگرانی کی۔ ہم نے اسے ہیپسٹر کا استعمال کرتے ہوئے سسٹم میں شامل کیا، جسے ہم نے کلسٹر میں انسٹال کیا، یہ ڈیٹا اکٹھا کرتا ہے اور اسے گریفائٹ کو بھیجتا ہے۔ نتیجے کے طور پر، اسکیم اس طرح نظر آتی ہے:
مانیٹرنگ اجزاء
یہاں ان اجزاء کے لنکس کی فہرست ہے جو ہم نے اس کام کے لیے استعمال کیے تھے۔ یہ سب اوپن سورس ہیں۔
گریفائٹ:
- گو کاربن:
- سرگوشی:
- گریفائٹ اے پی آئی:
کاربن سی ریلے:
بروبیک:
جمع:
مائرہ:
گرافانا:
heapster:
اعداد و شمار
اور یہاں کچھ اعداد ہیں کہ یہ نظام ہمارے لیے کیسے کام کرتا ہے۔
جمع کرنے والا (بروبیک)
میٹرکس کی تعداد: ~ 300 / سیکنڈ
گریفائٹ میٹرکس بھیجنے کا وقفہ: 30 سیکنڈ
سرور وسائل کا استعمال: ~ 6% CPU (ہم مکمل سرورز کے بارے میں بات کر رہے ہیں)؛ ~ 1 جی بی ریم؛ ~ 3 Mbps LAN
گریفائٹ (گو کاربن)
میٹرکس کی تعداد: ~ 1 / منٹ
میٹرک اپ ڈیٹ کا وقفہ: 30 سیکنڈ
میٹرکس سٹوریج سکیم: 30sec 35d، 5min 90d، 10min 365d (اس بات کی تفہیم دیتا ہے کہ طویل عرصے میں سروس کا کیا ہوتا ہے)
سرور وسائل کا استعمال: ~10% CPU؛ ~ 20 جی بی ریم؛ ~ 30 Mbps LAN
لچک۔
ایویٹو میں ہم واقعی اپنی مانیٹرنگ سروس میں لچک کی تعریف کرتے ہیں۔ وہ دراصل اس طرح کیوں نکلا؟ سب سے پہلے، اس کے اجزاء کے حصے قابل تبادلہ ہیں: دونوں اجزاء خود اور ان کے ورژن۔ دوسرا، برقرار رکھنے کی صلاحیت. چونکہ پورا پروجیکٹ اوپن سورس پر بنایا گیا ہے، اس لیے آپ خود کوڈ میں ترمیم کر سکتے ہیں، تبدیلیاں کر سکتے ہیں اور ایسے فنکشنز کو نافذ کر سکتے ہیں جو باکس کے باہر دستیاب نہیں ہیں۔ کافی عام اسٹیک استعمال کیے جاتے ہیں، بنیادی طور پر Go اور Python، اس لیے یہ بالکل سادہ کیا جاتا ہے۔
یہاں ایک حقیقی مسئلہ کی ایک مثال ہے۔ گریفائٹ میں میٹرک ایک فائل ہے۔ اس کا ایک نام ہے۔ فائل کا نام = میٹرک نام۔ اور وہاں تک پہنچنے کا ایک طریقہ ہے۔ لینکس میں فائل نام 255 حروف تک محدود ہیں۔ اور ہمارے پاس ڈیٹا بیس ڈیپارٹمنٹ سے (بطور "اندرونی صارفین") لوگ ہیں۔ وہ ہمیں بتاتے ہیں: "ہم اپنے SQL سوالات کی نگرانی کرنا چاہتے ہیں۔ اور وہ 255 حروف نہیں بلکہ 8 MB ہر ایک کے ہیں۔ ہم انہیں Grafana میں ڈسپلے کرنا چاہتے ہیں، اس درخواست کے پیرامیٹرز دیکھنا چاہتے ہیں، اور اس سے بھی بہتر، ہم ایسی درخواستوں میں سب سے اوپر دیکھنا چاہتے ہیں۔ یہ بہت اچھا ہو گا اگر اسے حقیقی وقت میں دکھایا جائے۔ اور انہیں الرٹ میں دھکیلنا واقعی اچھا ہوگا۔
ایس کیو ایل استفسار کی مثال بطور مثال لی گئی ہے۔
ہم Redis سرور اور اپنے جمع کردہ پلگ انز کو بڑھاتے ہیں جو Postgres پر جاتے ہیں اور وہاں سے تمام ڈیٹا لیتے ہیں، میٹرکس کو Graphite کو بھیجتے ہیں۔ لیکن ہم میٹرک کے نام کو ہیش سے بدل دیتے ہیں۔ وہی ہیش بیک وقت Redis کو کلید کے طور پر اور پوری SQL استفسار کو بطور قدر بھیجا جاتا ہے۔ Grafana کو Redis پر جا کر یہ معلومات لینے کے قابل بنانا ہمارے لیے باقی ہے۔ ہم Graphite API کو کھول رہے ہیں کیونکہ یہ گریفائٹ کے ساتھ نگرانی کے تمام اجزاء کے تعامل کا بنیادی انٹرفیس ہے، اور ہم وہاں ایک نیا فنکشن داخل کرتے ہیں جسے عرف بائے ہیش () کہتے ہیں - ہمیں گرافانا سے میٹرک کا نام ملتا ہے، اور اسے ریڈیس کو کلید کے طور پر استعمال کرنے کی درخواست میں استعمال کرتے ہیں۔ جواب میں ہمیں کلید کی قدر ملتی ہے، جو کہ ہماری "SQL استفسار" ہے۔ اس طرح، ہم گرافانا کے پاس ایس کیو ایل کے استفسار کا ڈسپلے لے کر آئے، جو نظریہ طور پر، اس پر اعداد و شمار کے ساتھ، وہاں ظاہر نہیں کیا جا سکتا تھا (کال، قطار، کل_وقت، ...)۔
کے نتائج
دستیابی۔ ہماری مانیٹرنگ سروس کسی بھی ایپلیکیشن اور کسی بھی کوڈ سے 24/7 دستیاب ہے۔ اگر آپ کو اسٹوریج تک رسائی حاصل ہے، تو آپ سروس کو ڈیٹا لکھ سکتے ہیں۔ زبان اہم نہیں، فیصلے اہم نہیں۔ آپ کو صرف یہ جاننے کی ضرورت ہے کہ ساکٹ کیسے کھولنا ہے، وہاں میٹرک پھینکنا ہے، اور ساکٹ کو بند کرنا ہے۔
اعتماد تمام اجزاء غلطی برداشت کرنے والے ہیں اور ہمارے کام کے بوجھ کو اچھی طرح سے ہینڈل کرتے ہیں۔
داخلے کی کم حد۔ اس سسٹم کو استعمال کرنے کے لیے آپ کو گرافانا میں پروگرامنگ کی زبانیں اور سوالات سیکھنے کی ضرورت نہیں ہے۔ بس اپنی ایپلیکیشن کھولیں، اس میں ایک ساکٹ شامل کریں جو گریفائٹ کو میٹرکس بھیجے گا، اسے بند کرے گا، گرافانا کھولے گا، وہاں ڈیش بورڈز بنائے گا اور اپنے میٹرکس کے رویے کو دیکھے گا، Moira کے ذریعے اطلاعات موصول ہوں گی۔
آزادی۔ آپ DevOps انجینئرز کی مدد کے بغیر یہ سب خود کر سکتے ہیں۔ اور یہ ایک اوور فیچر ہے، کیوں کہ آپ ابھی اپنے پروجیکٹ کی نگرانی کر سکتے ہیں، آپ کو کسی سے پوچھنے کی ضرورت نہیں ہے - نہ کام شروع کرنے کے لیے، نہ ہی تبدیلیاں کرنے کے لیے۔
ہم کس چیز کے لیے کوشش کر رہے ہیں؟
ذیل میں درج ہر چیز صرف تجریدی خیالات نہیں ہے، بلکہ ایسی چیز ہے جس کی طرف کم از کم پہلے قدم اٹھائے گئے ہیں۔
- بے ضابطگی کا پتہ لگانے والا۔ ہم ایک ایسی سروس بنانا چاہتے ہیں جو ہمارے گریفائٹ سٹوریج پر جائے اور مختلف الگورتھم کا استعمال کرتے ہوئے ہر میٹرک کو چیک کرے۔ پہلے سے ہی الگورتھم موجود ہیں جنہیں ہم دیکھنا چاہتے ہیں، ڈیٹا موجود ہے، ہم جانتے ہیں کہ اس کے ساتھ کیسے کام کرنا ہے۔
- میٹا ڈیٹا ہمارے پاس بہت سی خدمات ہیں، وہ وقت کے ساتھ ساتھ بدلتی رہتی ہیں، ساتھ ہی ان کے ساتھ کام کرنے والے لوگ بھی۔ ریکارڈز کو دستی طور پر رکھنا کوئی آپشن نہیں ہے۔ لہذا، میٹا ڈیٹا اب ہماری مائیکرو سروسز میں سرایت کر گیا ہے۔ اس میں بتایا گیا ہے کہ اسے کس نے تیار کیا، وہ کن زبانوں کے ساتھ تعامل کرتا ہے، SLA کی ضروریات، کہاں اور کس کو اطلاعات بھیجنی ہیں۔ کسی سروس کو تعینات کرتے وقت، تمام ہستی کا ڈیٹا آزادانہ طور پر بنایا جاتا ہے۔ نتیجے کے طور پر، آپ کو دو لنکس ملتے ہیں - ایک ٹرگرز کے لیے، دوسرا Grafana میں ڈیش بورڈز کے لیے۔
- ہر گھر میں نگرانی۔ ہمارا ماننا ہے کہ تمام ڈویلپرز کو ایسا نظام استعمال کرنا چاہیے۔ اس صورت میں، آپ ہمیشہ سمجھتے ہیں کہ آپ کی ٹریفک کہاں ہے، اس کا کیا ہوتا ہے، یہ کہاں گرتا ہے، کہاں اس کے کمزور پوائنٹس ہیں۔ اگر، مثال کے طور پر، کوئی چیز آتی ہے اور آپ کی سروس کو کریش کر دیتی ہے، تو آپ کو اس کے بارے میں مینیجر کی کال کے دوران نہیں، بلکہ ایک الرٹ سے پتہ چلے گا، اور آپ فوری طور پر تازہ لاگز کھول کر دیکھ سکتے ہیں کہ وہاں کیا ہوا ہے۔
- اعلی کارکردگی. ہمارا پروجیکٹ مسلسل بڑھ رہا ہے، اور آج یہ تقریباً 2 میٹرک ویلیو فی منٹ پر کارروائی کرتا ہے۔ ایک سال پہلے، یہ تعداد 000 تھی۔ اور ترقی جاری ہے، اور اس کا مطلب ہے کہ کچھ عرصے بعد گریفائٹ (سرگوشی) ڈسک کے سب سسٹم کو بہت زیادہ لوڈ کرنا شروع کر دے گا۔ جیسا کہ میں نے کہا، یہ نگرانی کا نظام اجزاء کی تبدیلی کی وجہ سے کافی ورسٹائل ہے۔ کوئی خاص طور پر گریفائٹ کے لیے اپنے بنیادی ڈھانچے کو برقرار رکھتا ہے اور اسے مسلسل بڑھاتا ہے، لیکن ہم نے دوسرے راستے پر جانے کا فیصلہ کیا: استعمال ہمارے میٹرکس کے ذخیرے کے طور پر۔ یہ منتقلی تقریباً مکمل ہو چکی ہے، اور بہت جلد میں آپ کو مزید تفصیل سے بتاؤں گا کہ یہ کیسے ہوا: مشکلات کیا تھیں اور ان پر کیسے قابو پایا گیا، منتقلی کا عمل کیسے چلا، میں بائنڈنگ کے طور پر منتخب کردہ اجزاء اور ان کی تشکیلات کو بیان کروں گا۔
آپکی توجہ کا شکریہ! موضوع پر اپنے سوالات پوچھیں، میں یہاں یا درج ذیل پوسٹس میں جواب دینے کی کوشش کروں گا۔ شاید کسی کو ایسا ہی مانیٹرنگ سسٹم بنانے یا اسی طرح کی صورتحال میں Clickhouse پر سوئچ کرنے کا تجربہ ہو - اسے تبصروں میں شیئر کریں۔
ماخذ: www.habr.com