SRE (Site Reliability Engineering) ويب پروجيڪٽس جي دستيابي کي يقيني بڻائڻ جو هڪ طريقو آهي. اهو سمجهيو ويندو آهي هڪ فريم ورڪ لاءِ DevOps ۽ ڳالهائيندو آهي ته ڪيئن DevOps عملن کي لاڳو ڪرڻ ۾ ڪاميابي حاصل ڪجي. هن مضمون ۾ ترجمو ڪتاب گوگل کان. مون ھي ترجمو پاڻ تيار ڪيو ۽ مانيٽرنگ جي عمل کي سمجھڻ ۾ پنھنجي تجربي تي ڀروسو ڪيو. ٽيليگرام چينل ۾ и مون خدمت جي سطح جي مقصدن بابت ساڳئي ڪتاب جي باب 4 جي ترجمي جي لنڪ پڻ شايع ڪئي.
ٻلي پاران ترجمو. پڙهڻ جو مزو وٺو!
گوگل جي SRE ٽيمن وٽ بنيادي اصول ۽ بهترين طريقا آھن ڪامياب مانيٽرنگ ۽ نوٽيفڪيشن سسٽم ٺاهڻ لاءِ. ھي باب ھدايت ڏئي ٿو ته ڪھڙا مسئلا ھڪ ويب پيج جو دورو ڪندڙ کي پيش اچي سگھي ٿو ۽ انھن مسئلن کي ڪيئن حل ڪجي جيڪي ويب پيجز کي ڊسپلي ڪرڻ ۾ ڏکيائي ڪن ٿا.
Definitions
مانيٽرنگ سان لاڳاپيل موضوعن تي بحث ڪرڻ لاءِ ڪو به لفظ استعمال نه ڪيو ويو آهي. جيتوڻيڪ گوگل تي، هيٺ ڏنل اصطلاحن کي عام طور تي استعمال نه ڪيو ويو آهي، پر اسين سڀ کان وڌيڪ عام تعبيرن کي لسٽ ڪنداسين.
مانيٽرنگ
گڏ ڪرڻ، پروسيسنگ، گڏ ڪرڻ ۽ مقدار جي ڊيٽا کي حقيقي وقت ۾ ڊسپلي سسٽم بابت: درخواستن جو تعداد ۽ درخواستن جو تعداد، غلطين جو تعداد ۽ غلطين جو تعداد، درخواست جي پروسيسنگ وقت ۽ سرور اپ ٽائم.
وائٹ باڪس جي نگراني
اندروني سسٽم جي اجزاء پاران ڏيکاريل ميٽرڪ جي بنياد تي نگراني، بشمول لاگز، جاوا ورچوئل مشين پروفائلنگ ميٽرڪس، يا HTTP هينڊلر ميٽرڪس جيڪي اندروني انگ اکر ٺاهي رهيا آهن.
بليڪ باڪس جي نگراني
صارف جي نقطي نظر کان ايپليڪيشن جي رويي کي جانچڻ.
ڊيش بورڊ
هڪ انٽرفيس (عام طور تي ويب) جيڪو خدمتن جي اهم صحت جي اشارن جو هڪ جائزو مهيا ڪري ٿو. ڊيش بورڊ ۾ فلٽر هوندا، ڏيکاريل اشارن کي چونڊڻ جي صلاحيت، وغيره. انٽرفيس انهن اشارن کي سڃاڻڻ لاءِ ٺاهيو ويو آهي جيڪي صارفين لاءِ تمام اهم آهن. ڊيش بورڊ ٽيڪنيڪل سپورٽ اسٽاف لاءِ معلومات پڻ ڏيکاري سگھي ٿو: درخواستن جي هڪ قطار، اعليٰ ترجيحي غلطين جي هڪ فهرست، ۽ ذميواري جي ڏنل علائقي لاءِ مقرر ڪيل انجنيئر.
خبرداري (اطلاع)
اطلاعن جو ارادو هڪ شخص طرفان اي ميل يا ٻين ذريعن ذريعي حاصل ڪيو وڃي، جيڪو ٿي سگهي ٿو غلطين جي ڪري يا درخواست جي قطار ۾ اضافو. نوٽيفڪيشن جي درجه بندي ڪئي وئي آهي: ٽڪيٽون، اي ميل الرٽ ۽ فوري ميسينجر پيغام.
بنيادي سبب
هڪ سافٽ ويئر جي خرابي يا انساني غلطي جيڪا، هڪ ڀيرو درست ڪئي وئي، ٻيهر نه ٿيڻ گهرجي. مسئلو جا ڪيترائي مکيه سبب ٿي سگھن ٿا: ناکافي پروسيس آٽوميشن، سافٽ ويئر جي خرابي، ايپليڪيشن منطق جي ناکافي وضاحت. انهن مان هر هڪ عنصر بنيادي سبب ٿي سگهي ٿو، ۽ انهن مان هر هڪ کي ختم ڪيو وڃي.
نوڊ ۽ مشين (نوڊ ۽ مشين)
تبديل ٿيندڙ اصطلاحن کي فزيڪل سرور، ورچوئل مشين، يا ڪنٽينر تي هلندڙ ايپليڪيشن جي هڪ واحد مثال جي حوالي ڪرڻ لاءِ. ھڪڙي مشين ڪيترن ئي خدمتن جي ميزباني ڪري سگھي ٿي. خدمتون ٿي سگهن ٿيون:
- هڪ ٻئي سان ڳنڍيل: مثال طور، هڪ ڪيشنگ سرور ۽ هڪ ويب سرور؛
- هارڊويئر جي هڪ ٽڪڙي تي غير لاڳاپيل خدمتون: مثال طور، ڪوڊ ريپوزٽري ۽ هڪ وزرڊ هڪ ڪنفيگريشن سسٽم لاءِ، جهڙوڪ يا .
پڪو
سافٽ ويئر جي جوڙجڪ ۾ ڪا به تبديلي.
ڇو نگراني جي ضرورت آهي؟
اتي ڪيترائي سبب آهن ڇو ته ايپليڪيشنن جي نگراني ڪرڻ جي ضرورت آهي:
ڊگھي مدت جي رجحانات جو تجزيو
ڊيٽابيس ڪيترو وڏو آهي ۽ ڪيترو تيزيءَ سان وڌي رهيو آهي؟ روزاني استعمال ڪندڙن جو تعداد ڪيئن بدلجي ٿو؟
ڪارڪردگي جو مقابلو
ڇا Ajax DB 2.72 جي مقابلي ۾ Bytes 3.14 جي Acme Bucket تي درخواستون تيز آھن؟ هڪ اضافي نوڊ جي ظاهر ٿيڻ کان پوءِ ڪيش ڪيل درخواستون ڪيترو بهتر آهن؟ ڇا سائيٽ گذريل هفتي جي مقابلي ۾ سست هلندي آهي؟
خبرداري (اطلاع)
ڪجھ ڀڄي ويو آهي ۽ ڪنهن کي ان کي درست ڪرڻ جي ضرورت آهي. يا ڪجهه جلدي ڀڄي ويندو ۽ ڪنهن کي جلد ئي ان کي جانچڻ جي ضرورت آهي.
ڊيش بورڊ ٺاهڻ
ڊيش بورڊز کي بنيادي سوالن جا جواب ڏيڻ گهرجن ۽ ڪجھ شامل ڪرڻ گھرجي - دير (تاخير)، ٽرئفڪ (ٽريفڪ)، غلطيون (غلطيون) ۽ لوڊ سائيز (سنترپشن).
تجزياتي تجزيي کي منظم ڪرڻ (ڊيبگنگ)
درخواست جي پروسيسنگ جي دير وڌي وئي آهي، پر ساڳئي وقت ۾ ٻيو ڇا ٿيو؟
مانيٽرنگ سسٽم ڪارآمد آهن ڪاروباري انٽيليجنس سسٽم لاءِ ڊيٽا جو ذريعو ۽ سيڪيورٽي واقعن جي تجزيي کي آسان ڪرڻ لاءِ. ڇاڪاڻ ته هي ڪتاب انجنيئرنگ جي علائقن تي ڌيان ڏئي ٿو جن ۾ SREs کي مهارت حاصل آهي، اسان هتي نگراني جي ٽيڪنالاجي تي بحث نه ڪنداسين.
مانيٽرنگ ۽ انتباہ سسٽم توهان کي ٻڌائڻ جي اجازت ڏين ٿا جڏهن اهو ڀڄي ويو آهي يا ٽوڙڻ بابت آهي. جڏهن ڪو سسٽم پاڻمرادو مرمت نٿو ڪري سگهي، اسان چاهيون ٿا ته هڪ انسان خبرداري جو تجزيو ڪري، اهو طئي ڪري ته ڇا مسئلو اڃا به سرگرم آهي، ان کي حل ڪري، ۽ بنيادي سبب جو تعين ڪري. جيڪڏهن توهان سسٽم جي اجزاء جو آڊٽ نه ڪندا آهيو، توهان ڪڏهن به هڪ الرٽ حاصل نه ڪندا، ڇاڪاڻ ته "ڪجهه ٿورو عجيب لڳي ٿو."
نوٽيفڪيشن سان هڪ شخص تي بوجھ هڪ ملازم جي وقت جو هڪ انتهائي قيمتي استعمال آهي. جيڪڏهن ملازم ڪم ڪري رهيو آهي، خبرداري ڪم جي عمل ۾ مداخلت ڪري ٿي. جيڪڏهن ملازم گهر ۾ آهي، خبرداري ذاتي وقت ۽ ممڪن طور تي ننڊ ۾ مداخلت ڪري ٿي. جڏهن خبرداري تمام گهڻو ٿئي ٿي، ملازم انهن جي ذريعي اسڪيم، انهن کي بند ڪري، يا ايندڙ الرٽ کي نظر انداز ڪن ٿا. وقت بوقت اهي حقيقي خبرداري کي نظر انداز ڪن ٿا، جيڪو شور جي واقعن سان ڍڪيل آهي. خدمت جي رڪاوٽون ڊگهي عرصي تائين ختم ٿي سگهن ٿيون جيئن شور واقعا مسئلي کي جلدي تشخيص ۽ درست ٿيڻ کان روڪيندا آهن. مؤثر ڊيڄاريندڙ سسٽم وٽ سٺو سگنل کان شور جو تناسب آهي.
مانيٽرنگ سسٽم لاءِ مناسب اميدون قائم ڪرڻ
هڪ پيچيده ايپليڪيشن لاءِ نگراني قائم ڪرڻ پاڻ ۾ هڪ پيچيده انجنيئرنگ ڪم آهي. ايستائين جو گڏ ڪرڻ، ڊسپلي ڪرڻ، ۽ خبردار ڪرڻ واري اوزار جي هڪ اهم انفراسٽرڪچر سان گڏ، 10-12 ميمبرن جي هڪ Google SRE ٽيم ۾ عام طور تي هڪ يا ٻه ماڻهو شامل آهن جن جو بنيادي مقصد مانيٽرنگ سسٽم ٺاهڻ ۽ برقرار رکڻ آهي. اهو انگ وقت سان گڏ گهٽجي ويو آهي جيئن اسان مانيٽرنگ انفراسٽرڪچر کي مضبوط ۽ مرڪزي بڻايون ٿا، پر هر SRE ٽيم وٽ عام طور تي گهٽ ۾ گهٽ هڪ شخص هوندو آهي جيڪو صرف نگراني لاءِ وقف ڪيو ويندو آهي. اسان کي اهو چوڻو پوندو ته جڏهن نگراني سسٽم ڊيش بورڊ ڏسڻ ۾ ڪافي دلچسپ آهن، SRE ٽيمون احتياط سان انهن حالتن کان پاسو ڪن ٿيون جيڪي ڪنهن کي مسئلن جي نگراني ڪرڻ لاء اسڪرين کي ڏسڻ جي ضرورت آهي.
مجموعي طور تي، گوگل منتقل ڪيو ويو آهي سادي ۽ تيز مانيٽرنگ سسٽم کان پوءِ حقيقت جي تجزياتي اوزارن سان. اسان "جادو" سسٽم کان پاسو ڪندا آهيون جيڪي حد جي اڳڪٿي ڪرڻ جي ڪوشش ڪندا آهن يا خود بخود بنيادي سبب کي ڳوليندا آهن. سينسرز جيڪي اڻڄاتل مواد کي آخري استعمال ڪندڙ جي درخواستن ۾ ڳوليندا آهن اهي واحد مثال آهن؛ جيستائين اهي سينسر سادو رهندا، اهي جلدي ڳجهي نموني جي سببن کي ڳولي سگهندا. مانيٽرنگ ڊيٽا استعمال ڪرڻ لاءِ ٻيا فارميٽ، جھڙوڪ ظرفيت جي منصوبابندي يا ٽرئفڪ جي اڳڪٿي ڪرڻ، وڌيڪ پيچيده آھن. گھٽ نموني جي شرح (ڪلاڪن يا ڏينهن) تي تمام گهڻي عرصي (مهينن يا سالن) تي مشاهدو هڪ ڊگهي مدت جي رجحان کي ظاهر ڪندو.
گوگل ايس آر اي ٽيم کي مليل ڪاميابي ملي آهي پيچيده انحصار وارين ترتيبن سان. اسان گهٽ ۾ گهٽ ضابطا استعمال ڪندا آهيون جهڙوڪ "جيڪڏهن مون کي معلوم ٿئي ٿو ته ڊيٽابيس سست آهي، مون کي هڪ خبرداري ملي ٿي ته ڊيٽابيس سست آهي، ٻي صورت ۾ مون کي الرٽ ملي ٿو ته سائيٽ سست آهي." انحصار تي مبني ضابطا عام طور تي اسان جي سسٽم جي ناقابل تبديل حصن ڏانهن اشارو ڪن ٿا، جهڙوڪ ڊيٽا سينٽر ڏانهن صارف ٽرئفڪ کي فلٽر ڪرڻ لاء سسٽم. مثال طور، "جيڪڏهن ڊيٽا سينٽر ڏانهن ٽرئفڪ جي فلٽرنگ ترتيب ڏني وئي آهي، مون کي خبردار نه ڪريو دير جي باري ۾ پروسيسنگ صارف جي درخواستن ۾" ڊيٽا سينٽر کان خبردارين لاء هڪ عام اصول آهي. گوگل تي ڪجھ ٽيمون پيچيده انحصار واري درجي جي حمايت ڪن ٿيون ڇاڪاڻ ته اسان جي انفراسٽرڪچر ۾ مسلسل ريفڪٽرنگ جي مسلسل شرح آهي.
هن باب ۾ بيان ڪيل ڪجهه خيال اڃا به لاڳاپيل آهن: اتي هميشه هڪ موقعو آهي ته علامتي سببن جي بنيادي سبب ڏانهن، خاص طور تي مسلسل تبديل ٿيندڙ سسٽم ۾. تنهن ڪري، جڏهن ته هي باب مانيٽرنگ سسٽم لاءِ ڪجهه مقصد بيان ڪري ٿو ۽ انهن مقصدن کي ڪيئن حاصل ڪجي، اهو ضروري آهي ته مانيٽرنگ سسٽم سادو هجي ۽ ٽيم جي هر ڪنهن لاءِ سمجھ ۾ اچي.
ساڳئي طرح، شور جي سطح کي گهٽ رکڻ ۽ سگنل جي سطح بلند ڪرڻ لاء، خبردار ڪيل اثاثن جي نگراني ڪرڻ لاء طريقا تمام سادو ۽ قابل اعتماد هجڻ گهرجن. ضابطا جيڪي ماڻهن لاء ڊيڄاريندڙ پيدا ڪن ٿا انهن کي سمجهڻ ۽ واضح مسئلو پيش ڪرڻ آسان هجڻ گهرجي.
سببن جي مقابلي ۾ علامات
توهان جي نگراني واري نظام کي ٻن سوالن جو جواب ڏيڻ گهرجي: "ڇا ڀڃي" ۽ "ڇو ڀڄي ويو."
"ڇا ڀڃي" علامت بابت ڳالهائيندو آهي، ۽ "ڇو اهو ڀڄي ويو" سبب بابت ڳالهائيندو آهي. هيٺ ڏنل جدول ڏيکاري ٿو اهڙن ڪنيڪشن جا مثال.
علامتي
سبب
HTTP غلطي 500 يا 404 حاصل ڪرڻ
ڊيٽابيس سرور ڪنيڪشن کي رد ڪن ٿا
سست سرور جا جواب
اعلي سي پي يو استعمال يا خراب ٿيل Ethernet ڪيبل
انٽارڪيڪا ۾ استعمال ڪندڙ ٻلي جي GIFs وصول نه ڪري رهيا آهن
توھان جو CDN سائنسدانن ۽ ٻلين کان نفرت ڪري ٿو، تنھنڪري ڪجھ IP پتي کي بليڪ لسٽ ڪيو پيو وڃي
خانگي مواد هر جڳهه کان دستياب ٿي چڪو آهي
نئين سافٽ ويئر رليز جي رول آئوٽ فائر وال کي سڀني ACLs کي وساري ڇڏيو ۽ سڀني کي اندر وڃڻ ڏيو
”ڇا“ ۽ ”ڇو“ سڀ کان وڌيڪ اهم بلڊنگ بلاڪ آهن هڪ سٺو مانيٽرنگ سسٽم ٺاهڻ لاءِ وڌ ۾ وڌ سگنل ۽ گهٽ ۾ گهٽ شور سان.
ڪارو باڪس بمقابله وائيٽ باڪس
اسان وسيع وائيٽ-باڪس مانيٽرنگ کي گڏ ڪريون ٿا معمولي بليڪ باڪس مانيٽرنگ سان گڏ نازڪ ميٽرڪس لاءِ. بليڪ باڪس کي وائيٽ باڪس سان ڀيٽڻ جو آسان طريقو اهو آهي ته بليڪ باڪس علامتي مرڪز آهي ۽ فعال نگراني جي بجاءِ رد عمل وارو آهي: ”سسٽم هن وقت صحيح ڪم نه ڪري رهيو آهي. وائيٽ باڪس سسٽم جي اندروني تصديق جي صلاحيتن تي منحصر آهي: ايونٽ لاگز يا ويب سرور. اهڙيء طرح، وائيٽ باڪس توهان کي اڳتي وڌڻ جي مسئلن کي ڳولڻ جي اجازت ڏئي ٿو، غلطيون جيڪي ظاهر ٿيندا آهن هڪ درخواست جي ٻيهر منتقلي، وغيره.
ياد رهي ته هڪ گھڻ-پرت سسٽم ۾، هڪ انجنيئر جي ذميواري واري علائقي ۾ هڪ علامتي ذميواري جي ٻئي انجنيئر جي علائقي ۾ هڪ علامت آهي. مثال طور، ڊيٽابيس جي ڪارڪردگي گهٽجي وئي آهي. سست ڊيٽابيس پڙھندا آھن ڊيٽابيس SRE جو ھڪڙو نشانو جيڪو انھن کي ڳولي ٿو. جڏهن ته، هڪ سامهون-آخر SRE لاء هڪ سست ويب سائيٽ جو مشاهدو، ساڳئي سست ڊيٽابيس پڙهڻ جو سبب هڪ سست ڊيٽابيس آهي. تنهن ڪري، سفيد باڪس مانيٽرنگ ڪڏهن ڪڏهن علامتي-مرڪز آهي ۽ ڪڏهن ڪڏهن سبب-مرڪوز، ان تي منحصر آهي ته اهو ڪيترو وسيع آهي.
جڏهن ڊيبگنگ لاءِ ٽيليميٽري گڏ ڪرڻ، وائيٽ باڪس مانيٽرنگ گهربل آهي. جيڪڏهن ويب سرور ڊيٽابيس سوالن جا جواب ڏيڻ ۾ سست هوندا آهن، توهان کي ڄاڻڻ جي ضرورت آهي ته ويب سرور ڪيئن جلدي ڊيٽابيس سان رابطو ڪري ٿو ۽ ڪيترو جلدي جواب ڏئي ٿو. ٻي صورت ۾، توهان سست ڊيٽابيس سرور ۽ ويب سرور ۽ ڊيٽابيس جي وچ ۾ نيٽ ورڪ جي مسئلي جي وچ ۾ فرق ڪرڻ جي قابل نه هوندا.
بليڪ باڪس مانيٽرنگ هڪ اهم فائدو آهي جڏهن الرٽ موڪلڻ وقت: توهان وصول ڪندڙ ڏانهن نوٽيفڪيشن کي ٽاريندا آهيو جڏهن مسئلو اڳ ۾ ئي حقيقي علامتن جي نتيجي ۾ ٿي چڪو آهي. ٻئي طرف، بليڪ باڪس جي مسئلي لاءِ مانيٽرنگ بيڪار آهي جيڪو اڃا پيدا نه ٿيو آهي پر جلد ئي آهي.
چار سونهري نشانيون
چار گولڊن مانيٽرنگ سگنل ويڪرائي، ٽرئفڪ، غلطيون، ۽ سنترپشن آهن. جيڪڏهن توهان صرف چار صارف سسٽم ميٽرڪ کي ماپ ڪري سگهو ٿا، انهن چار تي ڌيان ڏيو.
دير
درخواست تي عمل ڪرڻ لاء گهربل وقت. اهو ضروري آهي ته ڪامياب ۽ ناڪام درخواستن جي دير جي وچ ۾ فرق ڪرڻ. مثال طور، هڪ HTTP 500 غلطي هڪ ڊيٽابيس يا ٻين پس منظر جي ڪنيڪشن جي نقصان جي ڪري تمام جلدي تشخيص ٿي سگهي ٿو، جڏهن ته، هڪ HTTP 500 غلطي هڪ ناڪام درخواست ظاهر ڪري سگهي ٿي. مجموعي ويڪرائي تي 500 غلطي جي اثر جو اندازو لڳائڻ شايد غلط نتيجن جي ڪري سگھي ٿو. ٻئي طرف، هڪ سست غلطي به هڪ تيز غلطي آهي! تنهن ڪري، اهو ضروري آهي ته غلطي جي دير جي نگراني ڪرڻ بجاء صرف غلطين کي فلٽر ڪرڻ جي بدران.
ٽريفڪ
توهان جي سسٽم جي درخواستن جو تعداد اعلي سطحي سسٽم ميٽرڪس ۾ ماپيو ويندو آهي. ويب سروس لاءِ، هي ماپ عام طور تي HTTP درخواستن جو تعداد في سيڪنڊ جي نمائندگي ڪري ٿو، درخواستن جي نوعيت سان ورهايل آهي (مثال طور، جامد يا متحرڪ مواد). هڪ آڊيو اسٽريمنگ سسٽم لاءِ، هي ماپ نيٽ ورڪ I/O جي رفتار يا هڪ ئي وقت جي سيشن جي تعداد تي ڌيان ڏئي سگهي ٿي. ھڪ اھم قدر اسٽوريج سسٽم لاءِ، ھي ماپ ٿي سگھي ٿو ٽرانزيڪشن يا ڳولا جا نتيجا في سيڪنڊ.
غلطيون
هي ناڪام درخواستن جي شرح آهي جيڪي واضح آهن (مثال طور HTTP 500)، ضمني (مثال طور HTTP 200 پر غلط مواد سان گڏ ٿيل) يا پاليسي (مثال طور "جيڪڏهن توهان هڪ سيڪنڊ ۾ جواب حاصل ڪيو، ته هڪ سيڪنڊ غلطي آهي"). جيڪڏهن HTTP جوابي ڪوڊ تمام ناڪامي حالتن کي ظاهر ڪرڻ لاء ڪافي نه آهن، ثانوي (اندروني) پروٽوڪول جي ضرورت پوندي جزوي ناڪامي کي ڳولڻ لاء. اهڙين سڀني ناڪام درخواستن جي نگراني شايد معلوماتي نه هجي، جڏهن ته آخر کان آخر تائين سسٽم جا تجربا اهو معلوم ڪرڻ ۾ مدد ڪندا ته توهان غلط مواد تي عمل ڪري رهيا آهيو.
سنترپت
ميٽرڪ ڏيکاري ٿو ته توهان جي خدمت ڪيتري شدت سان استعمال ڪئي وئي آهي. هي هڪ سسٽم مانيٽرنگ ماپ آهي جيڪو انهن وسيلن جي سڃاڻپ ڪري ٿو جيڪي تمام گهڻا محدود آهن (مثال طور، ياداشت جي محدود نظام تي، ياداشت ڏيکاري ٿو، I/O-مقرر ٿيل سسٽم تي، I/Os جو تعداد ڏيکاري ٿو). نوٽ ڪريو ته ڪيترائي سسٽم ڪارڪردگي کي خراب ڪن ٿا ان کان اڳ جو اھي 100٪ استعمال تائين پھچن، تنھنڪري استعمال جو مقصد حاصل ڪرڻ ضروري آھي.
پيچيده سسٽم ۾، سنترپشن کي اعلي سطحي لوڊ جي ماپن سان پورو ڪري سگهجي ٿو: ڇا توهان جي خدمت صحيح طريقي سان ڊبل ٽرئفڪ کي سنڀاليندي، صرف 10٪ وڌيڪ ٽرئفڪ کي سنڀاليندي، يا ان کان به گهٽ ٽرئفڪ کي هن وقت تائين سنڀاليندي؟ سادي خدمتن لاءِ جن وٽ پيٽرول نه آهن جيڪي درخواست جي پيچيدگي کي تبديل ڪن ٿا (مثال طور، "مون کي ڪجهه به نه ڏيو" يا "مون کي هڪ منفرد واحد مونوٽونڪ انٽيجر جي ضرورت آهي")، جيڪي گهٽ ۾ گهٽ ڪنفيگريشن کي تبديل ڪن ٿا، هڪ جامد لوڊ ٽيسٽ ويل ڪافي ٿي سگهي ٿي. بهرحال، جيئن پوئين پيراگراف ۾ بحث ڪيو ويو آهي، اڪثر خدمتون لازمي طور تي اڻ سڌي طرح سگنل استعمال ڪن ٿيون جهڙوڪ CPU استعمال يا نيٽ ورڪ بينڊوڊٿ، جن کي ڄاڻايل اپر بائونڊ آهي. ويڪرائي وڌائڻ اڪثر ڪري سنترپتي جو هڪ اهم اشارو آهي. هڪ ننڍڙي ونڊو ۾ 99 سيڪڙو جوابي وقت کي ماپڻ (مثال طور، هڪ منٽ) سنترپتي جو تمام ابتدائي سگنل مهيا ڪري سگهي ٿو.
آخر ۾، سنترپشن به اڳڪٿين سان جڙيل آهي اڳتي هلي سنترپتي بابت، مثال طور: "اهو لڳي ٿو ته توهان جو ڊيٽابيس توهان جي هارڊ ڊرائيو کي 4 ڪلاڪن ۾ ڀريندو."
جيڪڏهن توهان سڀني چئن سوني سگنلن کي ماپيندا آهيو ۽ جڏهن ڪنهن هڪ ميٽرڪ سان مسئلو آهي (يا، سنترپت جي صورت ۾، هڪ ويجهي مسئلو)، توهان هڪ شخص کي خبردار ڪيو ٿا، توهان جي خدمت مانيٽرنگ ذريعي گهٽ يا وڌيڪ ڍڪيل هوندي.
"دم" بابت پريشان (يا اوزار ۽ ڪارڪردگي)
جڏهن شروع کان مانيٽرنگ سسٽم ٺاهي رهيا آهن، اتي هڪ آزمائش آهي هڪ سسٽم کي ترقي ڪرڻ لاء اوسط قدرن جي بنياد تي: اوسط ويڪرائي، اوسط CPU استعمال نوڊس، يا اوسط ڊيٽابيس جي مڪمليت. آخري ٻن مثالن جو خطرو واضح آهي: پروسيسرز ۽ ڊيٽابيسس کي ختم ڪيو ويو آهي بلڪل غير متوقع انداز ۾. ساڳئي دير تي لاڳو ٿئي ٿو. جيڪڏهن توهان هڪ ويب سروس هلائيندا آهيو 100ms جي اوسط ويڪرائي سان 1000 درخواستن في سيڪنڊ سان، درخواستن جو 1٪ 5 سيڪنڊ وٺي سگھي ٿو. جيڪڏهن صارفين ڪيترن ئي اهڙين ويب خدمتن تي ڀاڙين ٿا، هڪ پس منظر جو 99th سيڪڙو آساني سان فرنٽ اينڊ جو وچين جوابي وقت بڻجي سگهي ٿو.
سست اوسط ۽ درخواستن جي تمام سست دم جي وچ ۾ فرق ڪرڻ جو آسان طريقو اهو آهي ته انگن اکرن ۾ بيان ڪيل درخواستن جي ماپن کي گڏ ڪيو وڃي (هسٽوگرام ڏيکارڻ لاءِ هڪ سٺو اوزار آهي) اصل دير جي بجاءِ: خدمت ڪيترين ئي درخواستن جي خدمت ڪئي جيڪا 0 ms جي وچ ۾ ورتي ۽ 10 ms، 10 ms ۽ 30 ms جي وچ ۾، 30 ms ۽ 100 ms جي وچ ۾، 100 ms ۽ 300 ms جي وچ ۾، وغيره. هسٽوگرام جي حدن کي تقريباً تيزيءَ سان وڌائڻ (تقريبن 3 جي فيڪٽر ذريعي) اڪثر ورهائڻ جو هڪ آسان طريقو آهي. درخواستن جي.
ماپ لاء تفصيل جي مناسب سطح چونڊيو
سسٽم جي مختلف عناصر کي تفصيل جي مختلف سطحن تي ماپ ڪيو وڃي. مثال طور:
- سي پي يو جي استعمال جي نگراني وقت جي هڪ عرصي دوران ڊگھي مدي واري اسپائڪس کي نه ڏيکاريندي جيڪا اعلي دير جي ڪري ٿي.
- ٻئي طرف، ويب سروس لاءِ هر سال 9 ڪلاڪن کان وڌيڪ ڊائون ٽائم (99,9٪ سالياني اپ ٽائم) کي نشانو بڻائڻ لاءِ، HTTP 200 جواب جي چڪاس هڪ منٽ ۾ هڪ يا ٻه ڀيرا کان وڌيڪ غير ضروري طور تي بار بار ٿيڻ جو امڪان آهي.
- ساڳئي طرح، 99,9٪ دستيابي لاء هارڊ ڊرائيو جي جاء چيڪ ڪرڻ لاء هر 1-2 منٽن کان وڌيڪ هڪ ڀيرو شايد ضروري ناهي.
خيال رکو ته توهان پنهنجي ماپن جي گرينولرٽي کي ڪيئن ترتيب ڏيو ٿا. في سيڪنڊ ۾ هڪ ڀيرو سي پي يو لوڊ گڏ ڪرڻ دلچسپ ڊيٽا مهيا ڪري سگهي ٿو، پر اهڙيون بار بار ماپون گڏ ڪرڻ، ذخيرو ڪرڻ ۽ تجزيو ڪرڻ تمام مهانگو ٿي سگهي ٿو. جيڪڏهن توهان جي نگراني جي مقصد کي اعلي گرينولرٽي جي ضرورت آهي ۽ اعلي ردعمل جي ضرورت ناهي، توهان انهن قيمتن کي گھٽائي سگهو ٿا سرور تي ميٽرڪ گڏ ڪرڻ ۽ پوء انهن ميٽرڪ کي گڏ ڪرڻ ۽ گڏ ڪرڻ لاء هڪ خارجي سسٽم قائم ڪندي. ڇا توهان ڪري سگهو ٿا:
- سي پي يو لوڊ هر سيڪنڊ کي ماپ ڪريو.
- تفصيل کي گھٽايو 5٪ تائين.
- مجموعي ميٽرڪ هر منٽ.
هي حڪمت عملي توهان کي اجازت ڏيندو ته ڊيٽا گڏ ڪرڻ جي اعلي گرينولرٽي تي بغير اعلي تجزيي ۽ اسٽوريج جي مٿان.
جيترو ٿي سگهي سادو، پر سادو نه
هڪ ٻئي جي مٿان مختلف ضرورتن جي اوورلي جي نتيجي ۾ هڪ تمام پيچيده نگراني نظام ٿي سگهي ٿو. مثال طور، توهان جي سسٽم ۾ هيٺيان پيچيده عنصر هوندا.
- الرٽ مختلف حدن جي مطابق درخواست جي پروسيسنگ جي دير لاءِ، مختلف فيصد ۾، سڀني قسمن جي مختلف اشارن لاءِ.
- ممڪن سببن کي ڳولڻ ۽ سڃاڻڻ لاء اضافي ڪوڊ لکڻ.
- مسئلن جي هر ممڪن سببن لاءِ لاڳاپيل ڊيش بورڊ ٺاهيو.
امڪاني پيچيدگي جا ذريعا ڪڏهن به ختم نه ٿيندا آهن. سڀني سافٽ ويئر سسٽم وانگر، مانيٽرنگ ايترو پيچيده ٿي سگهي ٿو ته اهو نازڪ ۽ تبديل ڪرڻ ۽ برقرار رکڻ ڏکيو ٿي سگهي ٿو.
تنهن ڪري، توهان جي مانيٽرنگ سسٽم کي ڊزائين ڪرڻ لاء ان کي ممڪن حد تائين آسان بڻائي. جڏهن چونڊيو ته ڇا ٽريڪ ڪرڻ لاء، هيٺ ڏنل ذهن ۾ رکو:
- ضابطا جيڪي اڪثر ڪري حقيقي واقعن کي پڪڙيندا آهن سادو، پيش گوئي ۽ قابل اعتماد هجڻ گهرجي.
- ڊيٽا گڏ ڪرڻ، گڏ ڪرڻ، ۽ خبردار ڪرڻ لاءِ ڪنفيگريشن جيڪا غير معمولي طور تي ڪئي ويندي آهي (مثال طور، ڪجهه SRE ٽيمن لاءِ ٽه ماهي کان به گهٽ) ختم ڪيو وڃي.
- ميٽرڪ جيڪي گڏ ڪيا ويا آهن پر ڪنهن به ڏيک ڊيش بورڊ ۾ نه ڏيکاريا ويا آهن يا ڪنهن به الرٽ طرفان استعمال ٿيل آهن حذف ڪرڻ جا اميدوار.
گوگل تي، بنيادي ميٽرڪس گڏ ڪرڻ ۽ گڏ ڪرڻ، الارٽس ۽ ڊيش بورڊن سان گڏ، هڪ نسبتا اسٽينڊ اڪيلو سسٽم طور ڪم ڪري ٿو (گوگل جو مانيٽرنگ سسٽم اصل ۾ ڪيترن ئي سب سسٽم ۾ ورهايل آهي، پر ماڻهو عام طور تي انهن سب سسٽم جي سڀني حصن کان واقف آهن). اهو ٿي سگهي ٿو مانيٽرنگ کي گڏ ڪرڻ لاءِ ٻين ٽيڪنالاجين سان گڏ پيچيده سسٽم جي جاچ ڪرڻ لاءِ: تفصيلي سسٽم جي پروفائيلنگ، پروسيس ڊيبگنگ، ٽريڪنگ تفصيلات استثنا يا ناڪامين بابت، لوڊ ٽيسٽنگ، لاگ گڏ ڪرڻ ۽ تجزيو، يا ٽرئفڪ جو معائنو. جڏهن ته انهن شين مان اڪثريت بنيادي نگراني سان هڪجهڙائي رکي ٿي، انهن کي ملائڻ سان تمام گهڻا نتيجا نڪرندا ۽ هڪ پيچيده ۽ نازڪ نظام پيدا ٿيندو. جيئن ته سافٽ ويئر ڊولپمينٽ جي ٻين ڪيترن ئي پهلوئن سان، مختلف سسٽم کي سپورٽ ڪرڻ واضح، سادو، نرمي سان جوڙيل انٽيگريشن پوائنٽس سان گڏ بهترين حڪمت عملي آهي (مثال طور، ويب API استعمال ڪندي مجموعي ڊيٽا کي حاصل ڪرڻ لاءِ فارميٽ ۾ جيڪا ڊگهي عرصي تائين مسلسل رهي سگهي ٿي. ).
اصولن کي گڏ ڪرڻ
ھن باب ۾ بحث ڪيل اصولن کي ھڪڙي نگراني ۽ خبردار ڪرڻ واري فلسفي ۾ گڏ ڪري سگھجي ٿو جيڪو گوگل ايس آر اي ٽيمن جي تصديق ۽ پيروي ڪري ٿو. هن مانيٽرنگ فلسفي تي عمل ڪرڻ لازمي آهي، توهان جي خبرداري جي طريقيڪار کي ٺاهڻ يا ان تي نظرثاني ڪرڻ لاءِ هڪ سٺو شروعاتي نقطو آهي، ۽ توهان جي تنظيم جي سائيز يا خدمت يا سسٽم جي پيچيدگي کان سواءِ، توهان جي آپريشن جي فنڪشن بابت صحيح سوال پڇڻ ۾ مدد ڪري سگهي ٿي.
جڏهن مانيٽرنگ ۽ خبرداري جا قاعدا ٺاهي رهيا آهن، هيٺ ڏنل سوال پڇڻ توهان جي مدد ڪري سگهي ٿي غلط مثبت ۽ غير ضروري خبردارين کان بچڻ ۾:
- ڇا هي قاعدو سسٽم جي ٻي صورت ۾ اڻ ڄاتل حالت کي ڳولي ٿو جيڪو تڪڙو آهي، عمل کي ڪال ڪري ٿو، ۽ لازمي طور تي صارف کي متاثر ڪري ٿو؟
- ڇا مان هن ڊيڄاريندڙ کي نظر انداز ڪري سگهان ٿو، ڄاڻو ته اهو غير معمولي آهي؟ مان هن ڊيڄاريندڙ کي ڪڏهن ۽ ڇو نظرانداز ڪري سگهان ٿو ۽ آئون هن منظر کان ڪيئن بچي سگهان ٿو؟
- ڇا هي خبرداري جو مطلب آهي ته صارفين کي منفي طور تي متاثر ڪيو پيو وڃي؟ ڇا اهڙيون حالتون آهن جتي صارفين تي منفي اثر نه هوندا آهن، جهڙوڪ ٽرئفڪ فلٽرنگ ذريعي يا جڏهن ٽيسٽ سسٽم استعمال ڪندي جنهن لاءِ الرٽ فلٽر ڪيو وڃي؟
- ڇا مان هن خبرداري جي جواب ۾ قدم کڻي سگهان ٿو؟ ڇا اهي قدم تڪڙو آهن يا اهي صبح تائين انتظار ڪري سگهن ٿا؟ ڇا هڪ عمل محفوظ طور تي خودڪار ٿي سگهي ٿو؟ ڇا اهو عمل هڪ ڊگهي مدي وارو حل هوندو يا مختصر مدت جو حل؟
- ڪجھ ماڻھو ھن مسئلي لاءِ گھڻن الارٽ حاصل ڪري رھيا آھن، پوءِ ڇا ڪو طريقو آھي الارٽ جو تعداد گھٽائڻ جو؟
اهي سوال انتباہ ۽ ڊيڄاريندڙ سسٽم تي بنيادي فلسفي کي ظاهر ڪن ٿا:
- هر دفعي هڪ خبرداري اچي ٿي، مون کي فوري طور تي رد عمل ڪرڻو پوندو. مان ٿڪجي وڃڻ کان اڳ ڏينهن ۾ ڪيترائي ڀيرا تڪڙو رد عمل ڪري سگهان ٿو.
- هر خبرداري سان لاڳاپيل هجڻ گهرجي.
- خبرداري جي هر جواب کي انساني مداخلت جي ضرورت آهي. جيڪڏهن نوٽيفڪيشن خودڪار طريقي سان عمل ڪري سگهجي ٿي، اهو نه اچڻ گهرجي.
- انتباہ هڪ نئين مسئلي يا واقعي بابت هجڻ گهرجي جيڪو اڳ موجود نه هو.
اهو طريقو ڪجهه فرقن کي ڌوئي ٿو: جيڪڏهن خبرداري اڳئين چار شرطن کي پورو ڪري ٿي، ان سان ڪو فرق نٿو پوي ته الرٽ وائيٽ باڪس يا بليڪ باڪس مانيٽرنگ سسٽم مان موڪليو ويو آهي. اهو طريقو ڪجهه اختلافن کي پڻ مضبوط ڪري ٿو: اهو بهتر آهي ته علامتن جي نشاندهي ڪرڻ جي سببن جي ڀيٽ ۾ وڌيڪ ڪوششون خرچ ڪرڻ؛ جڏهن اهو سببن تي اچي ٿو، توهان کي صرف ناگزير سببن بابت پريشان ٿيڻ جي ضرورت آهي.
ڊگهي مدت جي نگراني
اڄ جي پيداوار واري ماحول ۾، مانيٽرنگ سسٽم هڪ هميشه ترقي ڪندڙ پيداوار سسٽم جي نگراني ڪن ٿا سافٽ ويئر فن تعمير، ڪم لوڊ جي خاصيتن، ۽ ڪارڪردگي جي هدفن کي تبديل ڪرڻ سان. خبردار جيڪي هن وقت پاڻمرادو ڪرڻ مشڪل آهن عام ٿي سگهن ٿيون، شايد ان جي قابل پڻ. هن موقعي تي، ڪنهن کي ڳولڻ گهرجي ۽ مسئلي جي بنيادي سببن کي ختم ڪرڻ؛ جيڪڏهن اهڙي ريزوليوشن ممڪن نه آهي، خبرداري جو جواب مڪمل آٽوميشن جي ضرورت آهي.
اهو ضروري آهي ته نگراني جا فيصلا ذهن ۾ ڊگهي مدي وارن مقصدن سان ڪيا وڃن. هر خبرداري جيڪو اڄ هلندو آهي، هڪ شخص کي سڀاڻي سسٽم کي بهتر ڪرڻ کان پريشان ڪري ٿو، تنهنڪري اڪثر وقت ۾ ڊگهي مدت ۾ نگراني جي نظام کي بهتر ڪرڻ لاء گهربل وقت لاء پيداوار واري نظام جي دستيابي يا ڪارڪردگي ۾ گهٽتائي هوندي آهي. اچو ته هن رجحان کي واضح ڪرڻ لاء ٻه مثال ڏسو.
بگ ٽيبل ايس آر اي: هڪ ڪهاڻي اوور-الرٽ
گوگل جو اندروني انفراسٽرڪچر عام طور تي مهيا ڪيل آهي ۽ ماپي ويندي آهي خدمت جي سطح (SLO) جي خلاف. ڪيترائي سال اڳ، Bigtable جي خدمت SLO هڪ مصنوعي ٽرانزيڪشن جي اوسط ڪارڪردگي تي ٻڌل هئي جيڪا هڪ لائيو ڪلائنٽ ٺاهي ٿي. بگٽبل ۾ مسئلن جي ڪري ۽ اسٽوريج اسٽيڪ جي هيٺين سطحن جي ڪري، اوسط ڪارڪردگي "وڏي" دم جي ذريعي هلائي وئي هئي: بدترين 5٪ سوالن جي ڀيٽ ۾ گهڻو ڪري تمام گهڻو سست هئا.
اي ميل نوٽيفڪيشن موڪليا ويا جيئن SLO جي حد تائين پهچي وئي، ۽ ميسينجر الرٽ موڪليا ويا جڏهن SLO حد کان وڌي وئي. انتباہ جا ٻئي قسم گهڻو ڪري موڪليا ويا هئا، انجنيئرنگ وقت جي ناقابل قبول مقدار کي استعمال ڪندي: ٽيم انهن چند کي ڳولڻ لاءِ الارٽس ذريعي ترتيب ڏيڻ ۾ هڪ اهم وقت گذاريو جيڪي اصل ۾ لاڳاپيل هئا. اسان اڪثر هڪ مسئلو وڃايو آهي جيڪو اصل ۾ متاثر ڪندڙ صارفين کي ڇو ته صرف ڪجهه خبرداري ان مخصوص مسئلي لاءِ هئا. بنيادي ڍانچي ۾ سمجھڻ واري مسئلن جي ڪري ڪيتريون ئي خبرداريون تڪڙي نه ھيون ۽ معياري طريقي سان پروسيس ڪيون ويون، يا انھن تي عمل نه ڪيو ويو.
صورتحال کي حل ڪرڻ لاءِ، ٽيم ٽن رخي طريقه ڪار اختيار ڪئي: بگٽيبل جي ڪارڪردگي کي بهتر بڻائڻ لاءِ سخت محنت ڪندي، اسان عارضي طور تي اسان جو SLO مقصد مقرر ڪيو آهي 75 سيڪڙو سوالن جي جواب ۾ دير ٿيڻ لاءِ. اسان اي ميل الرٽس کي به بند ڪيو ڇو ته انهن مان تمام گهڻا هئا ته انهن جي تشخيص ۾ وقت گذارڻ ناممڪن هو.
هن حڪمت عملي اسان کي سانس وٺڻ واري ڪمري جي اجازت ڏني ته بگٽبل ۽ اسٽوريج اسٽيڪ جي هيٺين سطحن ۾ ڊگهي مدي وارا مسئلا حل ڪرڻ شروع ڪن، بجاءِ تاکتياتي مسئلن کي مسلسل حل ڪرڻ جي. انجنيئرن کي هر وقت خبردارين سان بمباري ڪرڻ کان سواءِ ڪم ٿي سگهي ٿو. آخرڪار، عارضي طور تي الارٽ پروسيسنگ کي ملتوي ڪرڻ اسان کي اسان جي خدمت جي معيار کي بهتر ڪرڻ جي اجازت ڏني.
جي ميل: اڳڪٿي لائق، الگورتھم انساني جواب
ان جي شروعات تي، Gmail هڪ تبديل ٿيل Workqueue پروسيس مئنيجمينٽ سسٽم تي ٺاهيو ويو هو جيڪو هڪ سرچ انڊيڪس جي پروسيس حصن کي بيچ ڪرڻ لاءِ ٺاهيو ويو هو. ڪم جي قطار کي ڊگھي زندگي جي عملن سان ٺهڪندڙ ڪيو ويو ۽ بعد ۾ Gmail تي لاڳو ڪيو ويو، پر اوپيڪ شيڊولر ڪوڊ ۾ ڪي ڪي بگ درست ڪرڻ تمام ڏکيو ثابت ٿيا.
ان وقت، جي ميل مانيٽرنگ ترتيب ڏني وئي هئي ته جيئن انتباہات شروع ڪيا ويندا جڏهن انفرادي ڪمن کي Workqueue استعمال ڪندي منسوخ ڪيو ويو. اهو طريقو مثالي نه هو، ڇاڪاڻ ته ان وقت به، Gmail ڪيترن ئي هزارين ڪمن کي انجام ڏنو، جن مان هر هڪ اسان جي استعمال ڪندڙن جي هڪ سيڪڙو جي هڪ حصي کي مهيا ڪيو ويو. اسان Gmail جي صارفين کي سٺو استعمال ڪندڙ تجربو مهيا ڪرڻ جي باري ۾ تمام گهڻو فڪرمند هئاسين، پر ڪيترن ئي الرٽ کي هٿي ڏيڻ پهچ کان ٻاهر هو.
ھن مسئلي کي حل ڪرڻ لاءِ، Gmail SRE ھڪڙو اوزار ٺاھيو آھي جيڪو شيڊولر کي ڊيبگ ڪرڻ ۾ مدد لاءِ جيترو ممڪن ٿي سگھي صارفين تي اثر گھٽائڻ لاءِ. ٽيم ڪجهه بحث ڪيو ته ڇا صرف سموري چڪر کي خودڪار ڪرڻ لاءِ مسئلي جي دريافت کان وٺي ريميڊيئشن ذريعي جيستائين هڪ ڊگهي مدي وارو حل نه مليو ، پر ڪجهه انديشو هئا ته اهڙو حل اصل ۾ مسئلو حل ڪرڻ ۾ دير ڪندو.
هي تڪرار ٽيم ۾ عام هو ۽ اڪثر ڪري خود نظم و ضبط تي اعتماد جي کوٽ کي ظاهر ڪري ٿو: جڏهن ته ڪجهه ٽيم ميمبر صحيح حل لاء وقت جي اجازت ڏيڻ چاهيندا آهن، ٻين کي پريشان آهي ته حتمي حل وساريو ويندو ۽ عارضي حل هميشه لاء وٺندو. اهو مسئلو ڌيان طلب آهي ڇو ته صورتحال کي مستقل ڪرڻ بدران عارضي طور تي حل ڪرڻ تمام آسان آهي. مئنيجر ۽ ٽيڪنيڪل اسٽاف ڊگھي مدت جي اصلاحن کي لاڳو ڪرڻ ۾ اھم ڪردار ادا ڪن ٿا، ابتدائي ”درد“ ختم ٿيڻ کان پوءِ به امڪاني طور تي ڊگھي مدي وارين سڌارن جي حمايت ۽ ترجيح ڏين ٿا.
باقاعدي، ورجائيندڙ الرٽ ۽ الگورٿمڪ جوابن کي ڳاڙهي پرچم هجڻ گهرجي. توهان جي ٽيم جي انهن خبردارين کي پاڻمرادو ڪرڻ جي لچڪ جو مطلب آهي ته ٽيم کي اعتماد نه آهي ته اهي الگورتھم تي ڀروسو ڪري سگهن ٿا. هي هڪ سنگين مسئلو آهي جنهن کي حل ڪرڻ جي ضرورت آهي.
وڏو عرصو
ھڪڙو عام موضوع بگ ٽيبل ۽ Gmail مثالن سان ڳنڍيندو آھي: مختصر مدت ۽ ڊگھي مدت جي دستيابي جي وچ ۾ مقابلو. گهڻو ڪري، هڪ مضبوط ڪوشش هڪ نازڪ نظام کي اعلي دستيابي حاصل ڪرڻ ۾ مدد ڪري سگهي ٿي، پر اهو رستو اڪثر ڪري ٿورڙي زندگي آهي، ٽيم جي ڀڃڪڙي سان ڀريل آهي ۽ ساڳئي هيروڪ ٽيم جي ميمبرن جي ننڍڙي تعداد تي انحصار.
ڪنٽرول، دستيابي ۾ مختصر مدت جي گهٽتائي اڪثر دردناڪ آهي، پر سسٽم جي ڊگهي مدت جي استحڪام لاء حڪمت عملي طور تي اهم آهي. اهو ضروري آهي ته هر خبرداري کي اڪيلائي ۾ نه ڏسجي، پر اهو غور ڪرڻ گهرجي ته ڇا الرٽ حجم جي مجموعي سطح هڪ صحت مند، مناسب طريقي سان پهچ واري نظام جي ڪري هڪ قابل عمل ٽيم ۽ هڪ سازگار اڳڪٿي ڪري ٿي. اسان انتظاميا کي ٽه ماهي رپورٽن ۾ الرٽ فريڪوئنسي جي انگن اکرن جو تجزيو ڪيو (عام طور تي واقعن في شفٽ جي طور تي ظاهر ڪيو ويو آهي، جتي هڪ واقعو ڪيترن ئي لاڳاپيل واقعن تي مشتمل ٿي سگهي ٿو) انتظاميا کي ٽه ماهي رپورٽن ۾، فيصلي سازن کي الرٽ سسٽم جي لوڊ ۽ مجموعي ٽيم جي صحت جي جاري نظر رکڻ جي اجازت ڏئي ٿي.
ٿڪل
صحتمند نگراني ۽ خبردار ڪرڻ جو رستو سادو ۽ صاف آهي. اهو مسئلو جي علامن تي ڌيان ڏئي ٿو جيڪي الرٽ کي متحرڪ ڪن ٿا، ۽ سببن جي نگراني مسئلن کي ڊيبنگ ڪرڻ ۾ مدد جي طور تي ڪم ڪري ٿو. علامتن جي نگراني ڪرڻ آسان آهي اوترو اوترو وڌيڪ توهان ان اسٽيڪ ۾ آهيو جنهن تي توهان ڪنٽرول ڪندا آهيو، جيتوڻيڪ مانيٽرنگ لوڊ ۽ ڊيٽابيس جي ڪارڪردگي سڌو سنئون ڊيٽابيس تي ٿيڻ گهرجي. اي ميل نوٽيفڪيشن تمام محدود افاديت آهي ۽ آساني سان شور بڻجي ويندا آهن؛ ان جي بدران، توهان کي هڪ ڊيش بورڊ استعمال ڪرڻ گهرجي جيڪو سڀني موجوده مسئلن کي مانيٽر ڪري ٿو جيڪو اي ميل الرٽ کي متحرڪ ڪري ٿو. ڊيش بورڊ کي تاريخي لاڳاپن جو تجزيو ڪرڻ لاءِ ايونٽ لاگ سان پڻ جوڙي سگھجي ٿو.
ڊگھي مدت ۾، ضروري آھي ته علامتن ۽ ايندڙ حقيقي مسئلن بابت خبردارين جي ڪامياب گھمڻ حاصل ڪرڻ، مقصدن کي ترتيب ڏيڻ کي يقيني بڻائڻ لاءِ ته نگراني تيز تشخيص جي مدد ڪري ٿي.
آخر تائين ترجمو پڙهڻ لاءِ مهرباني. مانيٽرنگ بابت منهنجي ٽيليگرام چينل جي رڪنيت حاصل ڪريو и .
جو ذريعو: www.habr.com