ایک اور نگرانی کا نظام

16 موڈیم، 4 سیلولر آپریٹرز = آؤٹ گوئنگ سپیڈ 933.45 Mbit/s

تعارف

ہیلو! یہ مضمون اس بارے میں ہے کہ ہم نے اپنے لیے ایک نیا مانیٹرنگ سسٹم کیسے لکھا۔ یہ اعلی تعدد مطابقت پذیر میٹرکس اور بہت کم وسائل کی کھپت حاصل کرنے کی صلاحیت میں موجودہ سے مختلف ہے۔ پولنگ کی شرح 0.1 نینو سیکنڈز کے میٹرکس کے درمیان مطابقت پذیری کی درستگی کے ساتھ 10 ملی سیکنڈ تک پہنچ سکتی ہے۔ تمام بائنری فائلیں 6 میگا بائٹس پر قابض ہیں۔

منصوبے کے بارے میں

ہمارے پاس ایک خاص پروڈکٹ ہے۔ ہم ڈیٹا ٹرانسمیشن چینلز کے تھرو پٹ اور فالٹ ٹولرنس کا خلاصہ کرنے کے لیے ایک جامع حل تیار کرتے ہیں۔ یہ اس وقت ہوتا ہے جب کئی چینلز ہوتے ہیں، آئیے کہتے ہیں آپریٹر1 (40Mbit/s) + Operator2 (30Mbit/s)+ کچھ اور (5 Mbit/s)، نتیجہ ایک مستحکم اور تیز چینل ہے، جس کی رفتار کچھ اس طرح ہوگی۔ یہ: (40+30+5)x0.92=75×0.92=69 Mbit/s۔

ایسے حل طلب ہیں جہاں کسی ایک چینل کی صلاحیت ناکافی ہو۔ مثال کے طور پر، ٹرانسپورٹ، ویڈیو سرویلنس سسٹم اور ریئل ٹائم ویڈیو اسٹریمنگ، لائیو ٹیلی ویژن اور ریڈیو نشریات کی نشریات، کوئی بھی مضافاتی سہولیات جہاں ٹیلی کام آپریٹرز کے درمیان صرف بگ فور کے نمائندے ہوں اور ایک موڈیم/چینل پر رفتار کافی نہیں ہے۔ .
ان میں سے ہر ایک شعبے کے لیے، ہم آلات کی ایک الگ لائن تیار کرتے ہیں، لیکن ان کا سافٹ ویئر حصہ تقریباً ایک جیسا ہے اور ایک اعلیٰ معیار کا مانیٹرنگ سسٹم اس کے اہم ماڈیولز میں سے ایک ہے، جس کے درست نفاذ کے بغیر پروڈکٹ کی تیاری ممکن نہیں ہوگی۔

کئی سالوں کے دوران، ہم ایک کثیر سطحی، تیز، کراس پلیٹ فارم اور ہلکے وزن کی نگرانی کا نظام بنانے میں کامیاب ہو گئے۔ یہ وہی ہے جو ہم اپنے معزز کمیونٹی کے ساتھ اشتراک کرنا چاہتے ہیں.

مسئلہ کی تشکیل

نگرانی کا نظام بنیادی طور پر دو مختلف کلاسوں کے میٹرکس فراہم کرتا ہے: ریئل ٹائم میٹرکس اور دیگر تمام۔ نگرانی کے نظام میں صرف درج ذیل تقاضے تھے:

1. ریئل ٹائم میٹرکس کا اعلی تعدد مطابقت پذیر حصول اور بغیر کسی تاخیر کے کمیونیکیشن مینجمنٹ سسٹم میں ان کی منتقلی۔
   مختلف میٹرکس کی اعلی تعدد اور ہم آہنگی صرف اہم نہیں ہے، یہ ڈیٹا ٹرانسمیشن چینلز کی اینٹروپی کا تجزیہ کرنے کے لیے ضروری ہے۔ اگر ایک ڈیٹا ٹرانسمیشن چینل میں اوسط تاخیر 30 ملی سیکنڈ ہے، تو صرف ایک ملی سیکنڈ کے بقیہ میٹرکس کے درمیان ہم آہنگی میں خرابی نتیجے میں آنے والے چینل کی رفتار کو تقریباً 5% تک گرا دے گی۔ اگر ہم 1 چینلز میں ٹائمنگ کو 4 ملی سیکنڈ سے غلط کرتے ہیں، تو رفتار میں کمی آسانی سے 30% تک گر سکتی ہے۔ اس کے علاوہ، چینلز میں اینٹروپی بہت تیزی سے تبدیل ہوتی ہے، اس لیے اگر ہم اسے ہر 0.5 ملی سیکنڈ میں ایک بار سے کم پیمائش کرتے ہیں، تو تھوڑی تاخیر کے ساتھ تیز رفتار چینلز پر ہمیں تیز رفتار انحطاط حاصل ہوگا۔ بلاشبہ، تمام میٹرکس کے لیے ایسی درستگی کی ضرورت نہیں ہے اور نہ ہی تمام حالات میں۔ جب چینل میں تاخیر 500 ملی سیکنڈ ہے، اور ہم اس کے ساتھ کام کرتے ہیں، تو 1 ملی سیکنڈ کی غلطی تقریباً قابل توجہ نہیں ہوگی۔ اس کے علاوہ، لائف سپورٹ سسٹم میٹرکس کے لیے، ہمارے پاس پولنگ اور سنکرونائزیشن کی شرح 2 سیکنڈز کی کافی ہے، لیکن نگرانی کے نظام کو خود پولنگ کی انتہائی اعلی شرحوں اور میٹرکس کی انتہائی درست مطابقت پذیری کے ساتھ کام کرنے کے قابل ہونا چاہیے۔
2. کم سے کم وسائل کی کھپت اور ایک ہی اسٹیک۔
   اینڈ ڈیوائس یا تو ایک طاقتور آن بورڈ کمپلیکس ہو سکتا ہے جو سڑک پر حالات کا تجزیہ کر سکتا ہے یا لوگوں کی بائیو میٹرک ریکارڈنگ کر سکتا ہے، یا ہتھیلی کے سائز کا سنگل بورڈ کمپیوٹر ہو سکتا ہے جسے سپیشل فورس کا سپاہی اپنے جسم کے زرہ کے نیچے پہن کر ویڈیو منتقل کر سکتا ہے۔ خراب مواصلاتی حالات میں حقیقی وقت۔ اس طرح کے متعدد فن تعمیر اور کمپیوٹنگ طاقت کے باوجود، ہم ایک ہی سافٹ ویئر اسٹیک رکھنا چاہیں گے۔
3. چھتری کا فن تعمیر
   میٹرکس کو آخری ڈیوائس پر جمع اور اکٹھا کیا جانا چاہیے، مقامی طور پر اسٹور کیا جانا چاہیے، اور حقیقی وقت میں اور سابقہ ​​انداز میں تصور کیا جانا چاہیے۔ اگر کوئی کنکشن ہے تو، مرکزی نگرانی کے نظام کو ڈیٹا منتقل کریں۔ جب کوئی کنکشن نہ ہو تو بھیجنے والی قطار کو جمع ہونا چاہیے اور RAM کو استعمال نہیں کرنا چاہیے۔
4. کسٹمر کے مانیٹرنگ سسٹم میں انضمام کے لیے API، کیونکہ کسی کو بھی بہت سے مانیٹرنگ سسٹم کی ضرورت نہیں ہے۔ گاہک کو کسی بھی ڈیوائس اور نیٹ ورک سے ڈیٹا اکٹھا کرنا چاہیے ایک ہی نگرانی میں۔

کیا ہوا

پہلے سے ہی متاثر کن لانگریڈ پر بوجھ نہ ڈالنے کے لیے، میں تمام مانیٹرنگ سسٹم کی مثالیں اور پیمائشیں نہیں دوں گا۔ یہ ایک اور مضمون کی طرف لے جائے گا۔ میں صرف یہ کہوں گا کہ ہم ایک ایسا مانیٹرنگ سسٹم تلاش کرنے سے قاصر تھے جو 1 ملی سیکنڈ سے کم کی غلطی کے ساتھ بیک وقت دو میٹرکس لینے کے قابل ہو اور یہ 64 MB RAM کے ساتھ ARM فن تعمیر اور 86 کے ساتھ x64_32 فن تعمیر دونوں پر یکساں طور پر کام کرتا ہے۔ جی بی ریم۔ لہذا، ہم نے اپنے لکھنے کا فیصلہ کیا، جو یہ سب کر سکتا ہے. ہمیں جو ملا وہ یہاں ہے:

مختلف نیٹ ورک ٹوپولاجیز کے لیے تین چینلز کے تھرو پٹ کا خلاصہ

کچھ کلیدی میٹرکس کا تصور

فن تعمیر

ہم گولنگ کو مرکزی پروگرامنگ زبان کے طور پر استعمال کرتے ہیں، دونوں ڈیوائس پر اور ڈیٹا سینٹر میں۔ اس نے ملٹی ٹاسکنگ کے نفاذ اور ہر سروس کے لیے ایک مستحکم طور پر منسلک قابل عمل بائنری فائل حاصل کرنے کی صلاحیت کے ساتھ زندگی کو بہت آسان بنا دیا۔ نتیجے کے طور پر، ہم آلات، ڈیویلپمنٹ ٹائم اور کوڈ ڈیبگنگ کو ختم کرنے کے لیے سروس کی تعیناتی کے لیے وسائل، طریقوں اور ٹریفک میں نمایاں طور پر بچت کرتے ہیں۔

یہ نظام کلاسک ماڈیولر اصول کے مطابق لاگو کیا جاتا ہے اور اس میں کئی ذیلی نظام شامل ہیں:

1. میٹرکس رجسٹریشن۔
   ہر میٹرک کو اس کے اپنے تھریڈ کے ذریعے پیش کیا جاتا ہے اور تمام چینلز پر ہم آہنگ کیا جاتا ہے۔ ہم 10 نینو سیکنڈ تک مطابقت پذیری کی درستگی حاصل کرنے کے قابل تھے۔
2. میٹرکس اسٹوریج
   ہم ٹائم سیریز کے لیے اپنا ذخیرہ لکھنے یا پہلے سے دستیاب کسی چیز کو استعمال کرنے کے درمیان انتخاب کر رہے تھے۔ ڈیٹا بیس کو سابقہ ​​اعداد و شمار کے لیے درکار ہے جو بعد کے تصور سے مشروط ہے۔ یعنی اس میں ہر 0.5 ملی سیکنڈ میں چینل کی تاخیر یا ٹرانسپورٹ نیٹ ورک میں غلطی کی ریڈنگ پر ڈیٹا نہیں ہوتا ہے، لیکن ہر انٹرفیس پر ہر 500 ملی سیکنڈ میں رفتار ہوتی ہے۔ کراس پلیٹ فارم اور کم وسائل کی کھپت کے لیے اعلیٰ تقاضوں کے علاوہ، ہمارے لیے پروسیس کرنے کے قابل ہونا انتہائی ضروری ہے۔ ڈیٹا وہ جگہ ہے جہاں اسے محفوظ کیا جاتا ہے۔ اس سے کمپیوٹنگ کے بہت زیادہ وسائل کی بچت ہوتی ہے۔ ہم 2016 سے اس پروجیکٹ میں Tarantool DBMS استعمال کر رہے ہیں اور اب تک ہمیں افق پر اس کا متبادل نظر نہیں آتا ہے۔ لچکدار، زیادہ سے زیادہ وسائل کی کھپت کے ساتھ، مناسب تکنیکی مدد سے زیادہ۔ Tarantool ایک GIS ماڈیول بھی نافذ کرتا ہے۔ بلاشبہ، یہ پوسٹ جی آئی ایس کی طرح طاقتور نہیں ہے، لیکن مقام سے متعلق کچھ میٹرکس (ٹرانسپورٹ کے لیے متعلقہ) کو ذخیرہ کرنے کے ہمارے کاموں کے لیے کافی ہے۔
3. میٹرکس کا تصور
   یہاں سب کچھ نسبتاً آسان ہے۔ ہم گودام سے ڈیٹا لیتے ہیں اور اسے حقیقی وقت میں یا سابقہ ​​طور پر ڈسپلے کرتے ہیں۔
4. مرکزی نگرانی کے نظام کے ساتھ ڈیٹا کی ہم آہنگی۔
   مرکزی نگرانی کا نظام تمام آلات سے ڈیٹا وصول کرتا ہے، اسے ایک مخصوص تاریخ کے ساتھ ذخیرہ کرتا ہے اور API کے ذریعے صارف کے مانیٹرنگ سسٹم کو بھیجتا ہے۔ کلاسک مانیٹرنگ سسٹم کے برعکس، جس میں "سر" گھومتا ہے اور ڈیٹا اکٹھا کرتا ہے، ہمارے پاس اس کے برعکس سکیم ہے۔ جب کوئی کنکشن ہوتا ہے تو آلات خود ڈیٹا بھیجتے ہیں۔ یہ ایک بہت اہم نکتہ ہے، کیونکہ یہ آپ کو اس وقت کے دوران آلہ سے ڈیٹا حاصل کرنے کی اجازت دیتا ہے جس کے دوران یہ دستیاب نہیں تھا اور ڈیوائس کے دستیاب نہ ہونے پر چینلز اور وسائل کو لوڈ نہیں کرتا ہے۔ ہم انفلکس مانیٹرنگ سرور کو مرکزی نگرانی کے نظام کے طور پر استعمال کرتے ہیں۔ اس کے analogues کے برعکس، یہ سابقہ ​​اعداد و شمار کو درآمد کر سکتا ہے (یعنی میٹرکس موصول ہونے کے لمحے سے مختلف ٹائم اسٹیمپ کے ساتھ)۔ جمع شدہ میٹرکس کو گرافانا کے ذریعے تصور کیا جاتا ہے، جس میں فائل کے ساتھ ترمیم کی جاتی ہے۔ اس معیاری اسٹیک کو اس لیے بھی چنا گیا کیونکہ اس میں تقریباً کسی بھی کسٹمر مانیٹرنگ سسٹم کے ساتھ تیار API انضمام ہے۔
5. مرکزی ڈیوائس مینجمنٹ سسٹم کے ساتھ ڈیٹا کی ہم آہنگی۔
   ڈیوائس مینجمنٹ سسٹم زیرو ٹچ پروویژننگ (فرم ویئر، کنفیگریشن وغیرہ کو اپ ڈیٹ کرنا) کو نافذ کرتا ہے اور مانیٹرنگ سسٹم کے برعکس، فی ڈیوائس پر صرف مسائل موصول ہوتے ہیں۔ یہ آن بورڈ ہارڈویئر واچ ڈاگ سروسز اور لائف سپورٹ سسٹم کے تمام میٹرکس کے آپریشن کے لیے محرکات ہیں: CPU اور SSD درجہ حرارت، CPU لوڈ، خالی جگہ اور ڈسکوں پر اسمارٹ ہیلتھ۔ سب سسٹم سٹوریج بھی Tarantool پر بنایا گیا ہے۔ یہ ہمیں ہزاروں آلات میں ٹائم سیریز کو جمع کرنے میں اہم رفتار فراہم کرتا ہے، اور ان آلات کے ساتھ ڈیٹا کی مطابقت پذیری کے مسئلے کو بھی مکمل طور پر حل کرتا ہے۔ Tarantool میں ایک بہترین قطار اور ضمانتی ترسیل کا نظام ہے۔ ہمیں یہ اہم خصوصیت باکس سے باہر مل گئی، بہت اچھا!

نیٹ ورک مینجمنٹ سسٹم

آگے کیا ہے

اب تک ہماری سب سے کمزور کڑی مرکزی نگرانی کا نظام ہے۔ یہ معیاری اسٹیک پر 99.9 فیصد لاگو ہوتا ہے اور اس کے بہت سے نقصانات ہیں:

1. بجلی ختم ہونے پر InfluxDB ڈیٹا کھو دیتا ہے۔ ایک اصول کے طور پر، گاہک فوری طور پر ہر وہ چیز جمع کرتا ہے جو آلات سے آتی ہے اور ڈیٹا بیس میں ہی 5 منٹ سے زیادہ پرانا ڈیٹا نہیں ہوتا، لیکن مستقبل میں یہ تکلیف کا باعث بن سکتا ہے۔
2. گرافانا کو ڈیٹا اکٹھا کرنے اور اس کے ڈسپلے کی مطابقت پذیری کے ساتھ بہت سے مسائل ہیں۔ سب سے عام مسئلہ اس وقت ہوتا ہے جب ڈیٹا بیس میں ٹائم سیریز ہوتی ہے جس کا وقفہ 2 سیکنڈ کا ہوتا ہے، 00:00:00 سے شروع ہوتا ہے، اور گرافانا +1 سیکنڈ سے ڈیٹا کو جمع کرنا شروع کر دیتا ہے۔ نتیجے کے طور پر، صارف کو رقص کا گراف نظر آتا ہے۔
3. تھرڈ پارٹی مانیٹرنگ سسٹم کے ساتھ API انضمام کے لیے کوڈ کی ضرورت سے زیادہ مقدار۔ اسے بہت زیادہ کمپیکٹ بنایا جا سکتا ہے اور یقیناً گو میں دوبارہ لکھا جا سکتا ہے)

میرے خیال میں آپ سب نے بالکل دیکھا ہوگا کہ گرافانا کیسا لگتا ہے اور میرے بغیر اس کے مسائل کو جانتے ہیں، اس لیے میں تصویروں کے ساتھ پوسٹ کو زیادہ نہیں کروں گا۔

حاصل يہ ہوا

میں نے جان بوجھ کر تکنیکی تفصیلات بیان نہیں کیں بلکہ اس سسٹم کے بنیادی ڈیزائن کو ہی بیان کیا۔ سب سے پہلے، تکنیکی طور پر نظام کو مکمل طور پر بیان کرنے کے لیے، ایک اور مضمون کی ضرورت ہوگی۔ دوسری بات یہ کہ ہر کوئی اس میں دلچسپی نہیں لے گا۔ کمنٹس میں لکھیں کہ آپ کون سی تکنیکی تفصیلات جاننا چاہیں گے۔

اگر کسی کے پاس اس مضمون کے دائرہ کار سے باہر سوالات ہیں، تو آپ مجھے [email protected] پر لکھ سکتے ہیں۔

ماخذ: www.habr.com