سافٹ ویئر سسٹمز کی صنعتی ترقی کے لیے حتمی مصنوع کی غلطی کو برداشت کرنے کے ساتھ ساتھ ناکامیوں اور ناکامیوں پر تیزی سے ردعمل کی ضرورت ہوتی ہے۔ مانیٹرنگ، بلاشبہ، ناکامیوں اور ناکامیوں کا زیادہ موثر اور تیزی سے جواب دینے میں مدد کرتی ہے، لیکن کافی نہیں۔ سب سے پہلے، سرورز کی ایک بڑی تعداد پر نظر رکھنا بہت مشکل ہے - لوگوں کی ایک بڑی تعداد کی ضرورت ہے۔ دوم، آپ کو اچھی طرح سے سمجھنے کی ضرورت ہے کہ درخواست کس طرح کام کرتی ہے تاکہ اس کی حالت کا اندازہ لگایا جا سکے۔ لہذا، ہمیں بہت سارے لوگوں کی ضرورت ہے جو ہم جو نظام تیار کر رہے ہیں، ان کی کارکردگی اور خصوصیات کے بارے میں اچھی طرح سمجھ رکھتے ہوں۔ آئیے فرض کریں کہ اگر آپ کو کافی لوگ ایسا کرنے پر آمادہ پاتے ہیں، تب بھی انہیں تربیت دینے میں کافی وقت لگتا ہے۔
کیا کرنا ہے؟ یہ وہ جگہ ہے جہاں مصنوعی ذہانت ہماری مدد کو آتی ہے۔ مضمون میں بات کی جائے گی۔ (پیش گوئی کی دیکھ بھال). یہ نقطہ نظر فعال طور پر مقبولیت حاصل کر رہا ہے. بڑی تعداد میں مضامین لکھے گئے ہیں، بشمول Habré پر۔ بڑی کمپنیاں اپنے سرورز کی کارکردگی کو برقرار رکھنے کے لیے اس طریقہ کار کا بھرپور استعمال کرتی ہیں۔ مضامین کی ایک بڑی تعداد کا مطالعہ کرنے کے بعد، ہم نے اس نقطہ نظر کو آزمانے کا فیصلہ کیا۔ اس سے کیا نکلا؟
تعارف
ترقی یافتہ سافٹ ویئر سسٹم جلد یا بدیر کام میں چلا جاتا ہے۔ صارف کے لیے یہ ضروری ہے کہ نظام ناکامی کے بغیر کام کرے۔ اگر کوئی ہنگامی صورت حال پیش آتی ہے، تو اسے کم سے کم تاخیر سے حل کیا جانا چاہیے۔
سافٹ ویئر سسٹم کی تکنیکی معاونت کو آسان بنانے کے لیے، خاص طور پر اگر بہت سارے سرورز ہوں تو، مانیٹرنگ پروگرام عام طور پر استعمال کیے جاتے ہیں جو چلتے ہوئے سافٹ ویئر سسٹم سے میٹرکس لیتے ہیں، اس کی حالت کی تشخیص ممکن بناتے ہیں اور اس بات کا تعین کرنے میں مدد کرتے ہیں کہ ناکامی کی اصل وجہ کیا ہے۔ اس عمل کو سافٹ ویئر سسٹم مانیٹرنگ کہا جاتا ہے۔
تصویر 1. گرافانا مانیٹرنگ انٹرفیس
میٹرکس سافٹ ویئر سسٹم کے مختلف اشارے ہیں، اس کے نفاذ کے ماحول، یا فزیکل کمپیوٹر جس کے تحت سسٹم اس لمحے کے ٹائم اسٹیمپ کے ساتھ چل رہا ہے جب میٹرکس موصول ہوئے تھے۔ جامد تجزیہ میں، ان میٹرکس کو ٹائم سیریز کہا جاتا ہے۔ سافٹ ویئر سسٹم کی حالت کو مانیٹر کرنے کے لیے، میٹرکس کو گراف کی شکل میں دکھایا جاتا ہے: وقت X محور پر ہے، اور قدریں Y محور کے ساتھ ہیں (شکل 1)۔ چلنے والے سافٹ ویئر سسٹم (ہر نوڈ سے) سے کئی ہزار میٹرکس لیے جا سکتے ہیں۔ وہ میٹرکس (کثیر جہتی ٹائم سیریز) کی جگہ بناتے ہیں۔
چونکہ پیچیدہ سافٹ ویئر سسٹمز کے لیے میٹرکس کی ایک بڑی تعداد جمع کی جاتی ہے، اس لیے دستی نگرانی ایک مشکل کام بن جاتا ہے۔ منتظم کی طرف سے تجزیہ کردہ ڈیٹا کی مقدار کو کم کرنے کے لیے، نگرانی کے ٹولز میں ممکنہ مسائل کی خود بخود شناخت کرنے کے لیے ٹولز ہوتے ہیں۔ مثال کے طور پر، جب آپ مفت ڈسک کی جگہ ایک مخصوص حد سے نیچے آجاتی ہے تو آپ فائر کرنے کے لیے ایک ٹرگر تشکیل دے سکتے ہیں۔ آپ خود بخود سرور کے بند ہونے یا سروس کی رفتار میں ایک اہم سست روی کی تشخیص بھی کر سکتے ہیں۔ عملی طور پر، مانیٹرنگ ٹولز ان ناکامیوں کا پتہ لگانے یا مستقبل میں ہونے والی ناکامیوں کی سادہ علامات کی نشاندہی کرنے کا ایک اچھا کام کرتے ہیں، لیکن عام طور پر، ممکنہ ناکامی کی پیش گوئی کرنا ان کے لیے ایک مشکل کام ہے۔ میٹرکس کے دستی تجزیہ کے ذریعے پیشین گوئی کے لیے اہل ماہرین کی شمولیت کی ضرورت ہوتی ہے۔ یہ کم پیداوری ہے۔ زیادہ تر ممکنہ ناکامیوں کا دھیان نہیں دیا جا سکتا ہے۔
حال ہی میں، سافٹ ویئر سسٹمز کی نام نہاد پیشن گوئی کی دیکھ بھال بڑی آئی ٹی سافٹ ویئر ڈویلپمنٹ کمپنیوں میں تیزی سے مقبول ہوئی ہے۔ اس نقطہ نظر کا نچوڑ یہ ہے کہ مصنوعی ذہانت کا استعمال کرتے ہوئے ابتدائی مراحل میں سسٹم کی خرابی کا باعث بننے والے مسائل کو تلاش کیا جائے۔ یہ نقطہ نظر سسٹم کی دستی نگرانی کو مکمل طور پر خارج نہیں کرتا ہے۔ یہ مجموعی طور پر نگرانی کے عمل کے لیے معاون ہے۔
پیشن گوئی کی دیکھ بھال کو لاگو کرنے کے لئے اہم ٹول ٹائم سیریز میں بے ضابطگیوں کو تلاش کرنا ہے، کیونکہ جب بے ضابطگی ہوتی ہے۔ اعداد و شمار میں ایک اعلی امکان ہے کہ کچھ وقت کے بعد ناکامی یا ناکامی ہوگی. ایک بے ضابطگی سافٹ ویئر سسٹم کی کارکردگی میں ایک خاص انحراف ہے، جیسے کہ ایک قسم کی درخواست پر عمل درآمد کی رفتار میں انحطاط کی نشاندہی کرنا یا کلائنٹ کے سیشنوں کی مستقل سطح پر خدمت کی درخواستوں کی اوسط تعداد میں کمی۔
سافٹ ویئر سسٹمز کے لیے بے ضابطگیوں کو تلاش کرنے کے کام کی اپنی خصوصیات ہیں۔ اصولی طور پر، ہر سافٹ ویئر سسٹم کے لیے موجودہ طریقوں کو تیار کرنا یا ان کو بہتر کرنا ضروری ہے، کیونکہ بے ضابطگیوں کی تلاش کا انحصار اس ڈیٹا پر ہوتا ہے جس میں اسے انجام دیا جاتا ہے، اور سافٹ ویئر سسٹم کا ڈیٹا سسٹم کو لاگو کرنے کے ٹولز کے لحاظ سے بہت زیادہ مختلف ہوتا ہے۔ یہ کس کمپیوٹر پر چل رہا ہے۔
سافٹ ویئر سسٹم کی ناکامیوں کی پیش گوئی کرتے وقت بے ضابطگیوں کو تلاش کرنے کے طریقے
سب سے پہلے، یہ کہنے کے قابل ہے کہ ناکامیوں کی پیشن گوئی کا خیال مضمون سے متاثر ہوا تھا۔ . بے ضابطگیوں کے لیے خودکار تلاش کے ساتھ نقطہ نظر کی تاثیر کو جانچنے کے لیے، Web-consolidation سافٹ ویئر سسٹم کا انتخاب کیا گیا، جو NPO کرسٹا کمپنی کے منصوبوں میں سے ایک ہے۔ اس سے پہلے، حاصل شدہ میٹرکس کی بنیاد پر اس کے لیے دستی نگرانی کی جاتی تھی۔ چونکہ یہ نظام کافی پیچیدہ ہے، اس لیے اس کے لیے بڑی تعداد میں میٹرکس لیے گئے ہیں: JVM اشارے (کوڑا اٹھانے والا بوجھ)، OS کے اشارے جس کے تحت کوڈ کو عمل میں لایا جاتا ہے (ورچوئل میموری، % OS CPU لوڈ)، نیٹ ورک انڈیکیٹرز (نیٹ ورک لوڈ) )، خود سرور (CPU لوڈ، میموری)، وائلڈ فلائی میٹرکس اور تمام اہم سب سسٹمز کے لیے ایپلی کیشن کے اپنے میٹرکس۔
تمام میٹرکس گریفائٹ کا استعمال کرتے ہوئے سسٹم سے لیے گئے ہیں۔ ابتدائی طور پر، وسپر ڈیٹا بیس کو گرافانا کے لیے ایک معیاری حل کے طور پر استعمال کیا جاتا تھا، لیکن جیسے جیسے کلائنٹ کی بنیاد بڑھی، ڈی سی ڈسک سب سسٹم کی صلاحیت ختم ہونے کے بعد، گریفائٹ مزید مقابلہ نہیں کر سکتا تھا۔ اس کے بعد اس کا مزید موثر حل تلاش کرنے کا فیصلہ کیا گیا۔ انتخاب حق میں کیا گیا۔ جس سے ڈسک کے سب سسٹم پر بوجھ کو طول و عرض کے حکم سے کم کرنا اور زیر قبضہ ڈسک کی جگہ کو پانچ سے چھ گنا کم کرنا ممکن ہوا۔ نیچے گریفائٹ + کلک ہاؤس (شکل 2) کا استعمال کرتے ہوئے میٹرکس جمع کرنے کے طریقہ کار کا خاکہ ہے۔
شکل 2۔ میٹرکس جمع کرنے کی اسکیم
خاکہ اندرونی دستاویزات سے لیا گیا ہے۔ یہ گرافانا (مانیٹرنگ UI جسے ہم استعمال کرتے ہیں) اور گریفائٹ کے درمیان مواصلات کو ظاہر کرتا ہے۔ کسی ایپلیکیشن سے میٹرکس کو ہٹانا الگ سافٹ ویئر کے ذریعے کیا جاتا ہے۔ . وہ انہیں گریفائٹ میں ڈالتا ہے۔
ویب کنسولیڈیشن سسٹم میں متعدد خصوصیات ہیں جو ناکامیوں کی پیشین گوئی کے لیے مسائل پیدا کرتی ہیں:
- رجحان اکثر بدل جاتا ہے۔ اس سافٹ ویئر سسٹم کے مختلف ورژن دستیاب ہیں۔ ان میں سے ہر ایک سسٹم کے سافٹ ویئر حصے میں تبدیلی لاتا ہے۔ اس کے مطابق، اس طرح سے، ڈویلپرز براہ راست ایک دیئے گئے نظام کے میٹرکس پر اثر انداز ہوتے ہیں اور رجحان میں تبدیلی کا سبب بن سکتے ہیں۔
- نفاذ کی خصوصیت، نیز وہ مقاصد جن کے لیے کلائنٹ اس نظام کو استعمال کرتے ہیں، اکثر پچھلے تنزلی کے بغیر بے ضابطگیوں کا سبب بنتے ہیں۔
- پورے ڈیٹا سیٹ کے مقابلے میں بے ضابطگیوں کا فیصد چھوٹا ہے (<5%)؛
- سسٹم سے اشارے وصول کرنے میں خلاء ہو سکتا ہے۔ کچھ مختصر عرصے میں، نگرانی کا نظام میٹرکس حاصل کرنے میں ناکام رہتا ہے۔ مثال کے طور پر، اگر سرور اوورلوڈ ہے۔ یہ اعصابی نیٹ ورک کی تربیت کے لیے اہم ہے۔ خلا کو مصنوعی طریقے سے پر کرنے کی ضرورت ہے۔
- بے ضابطگیوں والے معاملات اکثر صرف ایک مخصوص تاریخ/مہینہ/وقت (موسمی) کے لیے متعلقہ ہوتے ہیں۔ اس سسٹم میں صارفین کے استعمال کے لیے واضح ضابطے ہیں۔ اس کے مطابق، میٹرکس صرف ایک مخصوص وقت کے لیے متعلقہ ہیں۔ سسٹم کو مسلسل استعمال نہیں کیا جا سکتا، لیکن صرف چند مہینوں میں: منتخب طور پر سال کے لحاظ سے۔ حالات اس وقت پیدا ہوتے ہیں جب ایک معاملے میں میٹرکس کا ایک ہی طرز عمل سافٹ ویئر سسٹم کی ناکامی کا باعث بن سکتا ہے، لیکن دوسرے میں نہیں۔
شروع کرنے کے لیے، سافٹ ویئر سسٹمز کے ڈیٹا کی نگرانی میں بے ضابطگیوں کا پتہ لگانے کے طریقوں کا تجزیہ کیا گیا۔ اس موضوع پر مضامین میں، جب باقی ڈیٹا سیٹ کے مقابلے میں بے ضابطگیوں کا فیصد چھوٹا ہوتا ہے، تو اکثر یہ تجویز کیا جاتا ہے کہ عصبی نیٹ ورک استعمال کریں۔
نیورل نیٹ ورک ڈیٹا کا استعمال کرتے ہوئے بے ضابطگیوں کو تلاش کرنے کے لیے بنیادی منطق تصویر 3 میں دکھائی گئی ہے:
تصویر 3. نیورل نیٹ ورک کا استعمال کرتے ہوئے بے ضابطگیوں کی تلاش
میٹرکس کے موجودہ بہاؤ کی ونڈو کی پیشن گوئی یا بحالی کے نتیجے کی بنیاد پر، چلنے والے سافٹ ویئر سسٹم سے موصول ہونے والے انحراف کا حساب لگایا جاتا ہے۔ اگر سافٹ ویئر سسٹم اور نیورل نیٹ ورک سے حاصل کردہ میٹرکس کے درمیان بڑا فرق ہے، تو ہم یہ نتیجہ اخذ کر سکتے ہیں کہ موجودہ ڈیٹا سیگمنٹ غیر متزلزل ہے۔ اعصابی نیٹ ورکس کے استعمال کے لیے درج ذیل مسائل پیدا ہوتے ہیں۔
- سٹریمنگ موڈ میں صحیح طریقے سے کام کرنے کے لیے، نیورل نیٹ ورک ماڈلز کی تربیت کے لیے ڈیٹا میں صرف "عام" ڈیٹا شامل ہونا چاہیے۔
- درست پتہ لگانے کے لیے ایک جدید ماڈل کا ہونا ضروری ہے۔ میٹرکس میں رجحانات اور موسمی تبدیلیاں ماڈل میں بڑی تعداد میں غلط مثبتات کا سبب بن سکتی ہیں۔ اسے اپ ڈیٹ کرنے کے لیے، یہ واضح طور پر اس وقت کا تعین کرنا ضروری ہے جب ماڈل پرانا ہے۔ اگر آپ بعد میں یا اس سے پہلے ماڈل کو اپ ڈیٹ کرتے ہیں، تو، زیادہ تر امکان ہے، غلط مثبت کی ایک بڑی تعداد کی پیروی کریں گے.
ہمیں جھوٹے مثبتات کی تلاش اور اسے روکنے کے بارے میں بھی نہیں بھولنا چاہیے۔ یہ فرض کیا جاتا ہے کہ وہ اکثر ہنگامی حالات میں واقع ہوں گے۔ تاہم، وہ ناکافی تربیت کی وجہ سے اعصابی نیٹ ورک کی خرابی کا نتیجہ بھی ہو سکتے ہیں۔ ماڈل کے غلط مثبت کی تعداد کو کم سے کم کرنا ضروری ہے۔ بصورت دیگر، غلط پیشین گوئیاں نظام کو چیک کرنے کے لیے منتظم کا کافی وقت ضائع کر دے گی۔ جلد یا بدیر ایڈمنسٹریٹر صرف "پیروانائڈ" مانیٹرنگ سسٹم کا جواب دینا بند کر دے گا۔
بار بار اعصابی نیٹ ورک
ٹائم سیریز میں بے ضابطگیوں کا پتہ لگانے کے لیے، آپ استعمال کر سکتے ہیں۔ LSTM میموری کے ساتھ۔ صرف ایک مسئلہ یہ ہے کہ یہ صرف پیشن گوئی شدہ ٹائم سیریز کے لیے استعمال کیا جا سکتا ہے۔ ہمارے معاملے میں، تمام میٹرکس قابل قیاس نہیں ہیں۔ RNN LSTM کو ٹائم سیریز میں لاگو کرنے کی کوشش تصویر 4 میں دکھائی گئی ہے۔
شکل 4. LSTM میموری سیلز کے ساتھ بار بار چلنے والے نیورل نیٹ ورک کی مثال
جیسا کہ شکل 4 سے دیکھا جا سکتا ہے، RNN LSTM اس وقت کی مدت میں بے ضابطگیوں کی تلاش سے نمٹنے کے قابل تھا۔ جہاں نتیجہ میں اعلیٰ پیشین گوئی کی خرابی (یعنی غلطی) ہے، اشارے میں ایک بے ضابطگی واقع ہوئی ہے۔ ایک واحد RNN LSTM کا استعمال واضح طور پر کافی نہیں ہوگا، کیونکہ یہ بہت کم میٹرکس پر لاگو ہوتا ہے۔ بے ضابطگیوں کی تلاش کے لیے ایک معاون طریقہ کے طور پر استعمال کیا جا سکتا ہے۔
ناکامی کی پیشن گوئی کے لیے آٹو اینکوڈر
- بنیادی طور پر ایک مصنوعی اعصابی نیٹ ورک۔ ان پٹ پرت انکوڈر ہے، آؤٹ پٹ لیئر ڈیکوڈر ہے۔ اس قسم کے تمام عصبی نیٹ ورکس کا نقصان یہ ہے کہ وہ بے ضابطگیوں کو اچھی طرح سے مقامی نہیں بناتے ہیں۔ ایک مطابقت پذیر آٹو اینکوڈر فن تعمیر کا انتخاب کیا گیا تھا۔
شکل 5. آٹو اینکوڈر آپریشن کی مثال
آٹو اینکوڈرز کو نارمل ڈیٹا پر تربیت دی جاتی ہے اور پھر ماڈل کو دیے گئے ڈیٹا میں کچھ غیر متزلزل پایا جاتا ہے۔ بس آپ کو اس کام کے لیے کیا ضرورت ہے۔ اس کام کے لیے کون سا آٹو اینکوڈر موزوں ہے اس کا انتخاب کرنا باقی ہے۔ آرکیٹیکچرل طور پر ایک آٹو اینکوڈر کی سب سے آسان شکل ایک فارورڈ، نان ریٹرننگ نیورل نیٹ ورک ہے، جو اس سے بہت ملتا جلتا ہے۔ (ملٹی لیئر پرسیپٹرون، ایم ایل پی)، ایک ان پٹ پرت کے ساتھ، ایک آؤٹ پٹ پرت، اور ایک یا زیادہ پوشیدہ پرتیں جو ان کو جوڑتی ہیں۔
تاہم، آٹو اینکوڈرز اور ایم ایل پی کے درمیان فرق یہ ہے کہ آٹو اینکوڈر میں، آؤٹ پٹ پرت میں نوڈس کی تعداد اتنی ہی ہوتی ہے جتنی ان پٹ لیئر، اور یہ کہ ان پٹ X کے ذریعے دی گئی ٹارگٹ ویلیو Y کی پیش گوئی کرنے کے لیے تربیت یافتہ ہونے کے بجائے، آٹو اینکوڈر کو تربیت دی جاتی ہے۔ اس کے اپنے Xs کو دوبارہ تشکیل دینے کے لیے۔ اس لیے، Autoencoders غیر زیر نگرانی سیکھنے کے ماڈل ہیں۔
آٹو اینکوڈر کا کام ان پٹ ویکٹر X میں غیر معمولی عناصر کے مطابق ٹائم انڈیکس r0 ... rn تلاش کرنا ہے۔ یہ اثر مربع کی غلطی کو تلاش کرنے سے حاصل ہوتا ہے۔
تصویر 6. ہم وقت ساز آٹو اینکوڈر
آٹو اینکوڈر کے لیے منتخب کیا گیا تھا۔ . اس کے فوائد: سٹریمنگ پروسیسنگ موڈ استعمال کرنے کی صلاحیت اور دیگر فن تعمیر کے مقابلے میں نسبتاً کم تعداد میں نیورل نیٹ ورک پیرامیٹرز۔
غلط مثبت کو کم کرنے کا طریقہ کار
اس حقیقت کی وجہ سے کہ مختلف غیر معمولی حالات پیدا ہوتے ہیں، نیز اعصابی نیٹ ورک کی ناکافی تربیت کی ممکنہ صورت حال کی وجہ سے، بے ضابطگی کا پتہ لگانے کے ماڈل کے لیے، یہ فیصلہ کیا گیا کہ غلط مثبت کو کم کرنے کے لیے ایک طریقہ کار تیار کرنا ضروری ہے۔ یہ طریقہ کار ایک ٹیمپلیٹ بیس پر مبنی ہے جسے منتظم کے ذریعہ درجہ بندی کیا گیا ہے۔
(ڈی ٹی ڈبلیو الگورتھم، انگریزی ڈائنامک ٹائم وارپنگ سے) آپ کو وقت کی ترتیب کے درمیان بہترین خط و کتابت تلاش کرنے کی اجازت دیتا ہے۔ سب سے پہلے اسپیچ ریکگنیشن میں استعمال کیا جاتا ہے: اس بات کا تعین کرنے کے لیے استعمال کیا جاتا ہے کہ دو اسپیچ سگنلز ایک ہی اصل بولے جانے والے فقرے کی نمائندگی کیسے کرتے ہیں۔ اس کے بعد دیگر علاقوں میں اس کے لیے درخواستیں ملیں۔
غلط مثبت کو کم کرنے کا بنیادی اصول ایک آپریٹر کی مدد سے معیارات کا ڈیٹا بیس اکٹھا کرنا ہے جو نیورل نیٹ ورکس کے استعمال سے پائے جانے والے مشکوک کیسز کی درجہ بندی کرتا ہے۔ اس کے بعد، درجہ بند معیار کا موازنہ اس کیس سے کیا جاتا ہے جس کا سسٹم نے پتہ لگایا تھا، اور اس بارے میں ایک نتیجہ اخذ کیا جاتا ہے کہ آیا کیس غلط ہے یا ناکامی کا باعث ہے۔ DTW الگورتھم دو وقت کی سیریز کا موازنہ کرنے کے لیے بالکل ٹھیک استعمال کیا جاتا ہے۔ اہم کم سے کم ٹول اب بھی درجہ بندی ہے۔ امید کی جاتی ہے کہ بڑی تعداد میں ریفرنس کیسز جمع کرنے کے بعد، سسٹم آپریٹر سے زیادہ تر کیسز کی مماثلت اور ایک جیسے ہونے کی وجہ سے کم پوچھنا شروع کر دے گا۔
نتیجتاً، اوپر بیان کیے گئے نیورل نیٹ ورک کے طریقوں کی بنیاد پر، "ویب کنسولیڈیشن" سسٹم کی ناکامیوں کی پیشین گوئی کرنے کے لیے ایک تجرباتی پروگرام بنایا گیا تھا۔ اس پروگرام کا ہدف، ہمارے سافٹ ویئر سسٹمز کے لیے اس نقطہ نظر کی اہلیت کا جائزہ لینا، مانیٹرنگ ڈیٹا اور پچھلی ناکامیوں کے بارے میں معلومات کے موجودہ آرکائیو کا استعمال کرنا تھا۔ پروگرام کی اسکیم ذیل میں شکل 7 میں پیش کی گئی ہے۔
پیکر 7۔ میٹرک اسپیس تجزیہ پر مبنی ناکامی کی پیشن گوئی اسکیم
خاکہ میں، دو اہم بلاکس کی تمیز کی جا سکتی ہے: مانیٹرنگ ڈیٹا سٹریم (میٹرکس) میں وقت کے بے قاعدہ وقفوں کی تلاش اور غلط مثبت کو کم کرنے کا طریقہ کار۔ نوٹ: تجرباتی مقاصد کے لیے ڈیٹا بیس سے JDBC کنکشن کے ذریعے حاصل کیا جاتا ہے جس میں گریفائٹ اسے محفوظ کرے گا۔
ترقی کے نتیجے میں حاصل کردہ نگرانی کے نظام کا انٹرفیس درج ذیل ہے (شکل 8)۔
چترا 8۔ تجرباتی نگرانی کے نظام کا انٹرفیس
انٹرفیس موصولہ میٹرکس کی بنیاد پر بے ضابطگی کا فیصد دکھاتا ہے۔ ہمارے معاملے میں، رسید نقلی ہے۔ ہمارے پاس پہلے سے ہی کئی ہفتوں کا تمام ڈیٹا موجود ہے اور ہم اسے بتدریج لوڈ کر رہے ہیں تاکہ کسی بے ضابطگی کی وجہ سے ناکامی کی صورت میں جانچ پڑتال کی جا سکے۔ نچلا اسٹیٹس بار ایک مقررہ وقت پر ڈیٹا کی بے ضابطگی کا مجموعی فیصد دکھاتا ہے، جس کا تعین آٹو اینکوڈر کے ذریعے کیا جاتا ہے۔ اس کے علاوہ، پیش گوئی کی گئی میٹرکس کے لیے ایک الگ فیصد ظاہر کیا جاتا ہے، جس کا حساب RNN LSTM کرتا ہے۔
RNN LSTM نیورل نیٹ ورک (شکل 9) کا استعمال کرتے ہوئے CPU کی کارکردگی پر مبنی بے ضابطگی کا پتہ لگانے کی ایک مثال۔
شکل 9. RNN LSTM دریافت
ایک کافی آسان کیس، بنیادی طور پر ایک عام آؤٹ لیئر، لیکن سسٹم کی ناکامی کا باعث، RNN LSTM کا استعمال کرتے ہوئے کامیابی کے ساتھ شمار کیا گیا۔ اس مدت میں بے ضابطگی کا اشارے 85-95% ہے؛ 80% سے اوپر کی ہر چیز (حد تجرباتی طور پر طے کی گئی تھی) کو ایک بے ضابطگی سمجھا جاتا ہے۔
بے ضابطگی کا پتہ لگانے کی ایک مثال جب سسٹم اپ ڈیٹ کے بعد بوٹ کرنے سے قاصر تھا۔ اس صورتحال کا پتہ آٹو اینکوڈر (شکل 10) سے ہوتا ہے۔
شکل 10۔ آٹو اینکوڈر کا پتہ لگانے کی مثال
جیسا کہ آپ اعداد و شمار سے دیکھ سکتے ہیں، PermGen ایک سطح پر پھنس گیا ہے۔ آٹو اینکوڈر کو یہ عجیب لگا کیونکہ اس نے پہلے کبھی ایسا کچھ نہیں دیکھا تھا۔ یہاں بے ضابطگی 100% رہتی ہے جب تک کہ نظام کام کرنے والی حالت میں واپس نہ آجائے۔ تمام میٹرکس کے لیے ایک بے ضابطگی ظاہر ہوتی ہے۔ جیسا کہ پہلے ذکر کیا گیا ہے، آٹو اینکوڈر بے ضابطگیوں کو مقامی نہیں بنا سکتا۔ آپریٹر کو ان حالات میں اس فنکشن کو انجام دینے کے لیے کہا جاتا ہے۔
حاصل يہ ہوا
PC "Web-consolidation" کئی سالوں سے ترقی میں ہے۔ نظام کافی مستحکم حالت میں ہے، اور ریکارڈ شدہ واقعات کی تعداد کم ہے۔ تاہم، ناکامی کے واقع ہونے سے 5 - 10 منٹ پہلے ناکامی کا باعث بننے والی بے ضابطگیوں کو تلاش کرنا ممکن تھا۔ بعض صورتوں میں، پیشگی ناکامی کی اطلاع سے طے شدہ وقت کو بچانے میں مدد ملے گی جو "مرمت" کے کام کو انجام دینے کے لیے مختص کیا گیا ہے۔
کئے گئے تجربات کی بنیاد پر، حتمی نتائج اخذ کرنا بہت جلد ہے۔ اب تک کے نتائج متضاد ہیں۔ ایک طرف، یہ واضح ہے کہ نیورل نیٹ ورکس پر مبنی الگورتھم "مفید" بے ضابطگیوں کو تلاش کرنے کے قابل ہیں۔ دوسری طرف، جھوٹے مثبتات کی ایک بڑی فیصد باقی ہے، اور عصبی نیٹ ورک میں کسی مستند ماہر کی طرف سے پائی جانے والی تمام بے ضابطگیوں کا پتہ نہیں لگایا جا سکتا۔ نقصانات میں یہ حقیقت شامل ہے کہ اب اعصابی نیٹ ورک کو معمول کے آپریشن کے لیے استاد کے ساتھ تربیت کی ضرورت ہوتی ہے۔
ناکامی کی پیشین گوئی کے نظام کو مزید ترقی دینے اور اسے تسلی بخش حالت میں لانے کے لیے، کئی طریقوں کا تصور کیا جا سکتا ہے۔ یہ بے ضابطگیوں والے معاملات کا ایک مزید تفصیلی تجزیہ ہے جو ناکامی کا باعث بنتے ہیں، اس کی وجہ اہم میٹرکس کی فہرست میں اضافہ ہے جو نظام کی حالت پر بہت زیادہ اثر انداز ہوتے ہیں، اور غیر ضروری چیزوں کو ترک کرنا جو اس پر اثر انداز نہیں ہوتے ہیں۔ اس کے علاوہ، اگر ہم اس سمت میں آگے بڑھتے ہیں، تو ہم خاص طور پر اپنے معاملات کے لیے الگورتھم کو خصوصی بنانے کی کوششیں کر سکتے ہیں جن کی وجہ سے ناکامی ہوتی ہے۔ ایک اور طریقہ ہے۔ یہ نیورل نیٹ ورک کے فن تعمیر میں بہتری ہے اور اس طرح تربیت کے وقت میں کمی کے ساتھ پتہ لگانے کی درستگی میں اضافہ ہوتا ہے۔
میں اپنے ساتھیوں کا شکریہ ادا کرتا ہوں جنہوں نے اس مضمون کو لکھنے اور اس کی مطابقت کو برقرار رکھنے میں میری مدد کی: اور سرگئی فنوجینوف۔
ماخذ: www.habr.com