ڇا نگراني مري ويو آهي؟ - ڊگهي زندگي جي نگراني

2008 کان وٺي، اسان جي ڪمپني بنيادي طور تي انفراسٽرڪچر مينيجمينٽ ۾ مصروف آهي ۽ ويب پروجيڪٽ لاءِ ڪلاڪ ٽيڪنيڪل سپورٽ: اسان وٽ 400 کان وڌيڪ ڪلائنٽ آهن، جيڪي روسي اي ڪامرس جو 15 سيڪڙو آهن. انهي جي مطابق، هڪ تمام متنوع فن تعمير جي حمايت ڪئي وئي آهي. جيڪڏهن ڪجهه ٿئي ٿو، اسان ان کي 15 منٽن اندر درست ڪرڻ جي پابند آهيون. پر اهو سمجهڻ لاء ته هڪ حادثو ٿي چڪو آهي، توهان کي منصوبي جي نگراني ڪرڻ ۽ واقعن جو جواب ڏيڻ جي ضرورت آهي. اهو ڪيئن ڪجي؟

مان سمجهان ٿو ته مناسب نگراني واري نظام کي منظم ڪرڻ ۾ مسئلو آهي. جيڪڏهن ڪا تڪليف نه هجي ها ته پوءِ منهنجي تقرير هڪ مقالي تي مشتمل هجي ها: ”مهرباني ڪري انسٽال ڪريو Prometheus + Grafana ۽ plugins 1, 2, 3. بدقسمتي سان، اهو هاڻي انهي طريقي سان ڪم نٿو ڪري. ۽ بنيادي مسئلو اهو آهي ته هرڪو انهي تي يقين رکي ٿو جيڪو 2008 ۾ موجود هو، سافٽ ويئر اجزاء جي لحاظ کان.

مانيٽرنگ سسٽم جي تنظيم جي حوالي سان، مان اهو چوڻ چاهيندس ته... قابل نگراني جا منصوبا موجود نه آهن. ۽ صورتحال ايتري خراب آهي ته جيڪڏهن ڪا شيءِ پوي ٿي، اتي هڪ خطرو آهي ته اهو ڪنهن جو به ڌيان نه ڏنو ويندو - آخرڪار، هر ڪنهن کي پڪ آهي ته "هر شي جي نگراني ڪئي وئي آهي."
شايد هر شي جي نگراني ڪئي پئي وڃي. پر ڪيئن؟

اسان سڀني کي هيٺ ڏنل ڪهاڻي سان منهن ڏنو آهي: هڪ خاص ڊيوپس، هڪ خاص منتظم ڪم ڪري رهيو آهي، هڪ ترقياتي ٽيم وٽن اچي ٿي ۽ چوي ٿو - "اسان کي آزاد ڪيو ويو آهي، هاڻي مانيٽر." ڇا جي نگراني؟ اهو ڪيئن ڪم ڪري ٿو؟

ٺيڪ. اسان پراڻي طريقي جي نگراني ڪندا آهيون. ۽ اهو اڳ ۾ ئي تبديل ٿي رهيو آهي، ۽ اهو ظاهر ٿئي ٿو ته توهان سروس A مانيٽر ڪيو، جيڪا خدمت B بڻجي وئي، جيڪا خدمت C سان رابطو ڪري ٿي. پر ترقياتي ٽيم توهان کي ٻڌائي ٿي: "سافٽ ويئر انسٽال ڪريو، اهو هر شيء جي نگراني ڪرڻ گهرجي!"

پوء ڇا تبديلي آئي آهي؟ - هر شئي تبديل ٿيل آهي!

2008 سڀ ڪجهه ٺيڪ آهي

اتي ڪجھ ڊولپرز آھن، ھڪڙو سرور، ھڪڙو ڊيٽابيس سرور. اهو سڀ هتان کان هلي ٿو. اسان وٽ ڪجھ معلومات آھي، اسان زبڪس، ناگيوس، ڪيڪٽي کي انسٽال ڪريون ٿا. ۽ پوءِ اسان سي پي يو تي، ڊسڪ آپريشن تي، ۽ ڊسڪ اسپيس تي واضح الرٽ قائم ڪريون ٿا. اسان ڪجھ دستي چيڪ پڻ ڪريون ٿا انهي کي يقيني بڻائڻ لاءِ ته سائيٽ جواب ڏئي ٿي ۽ آرڊر ڊيٽابيس ۾ اچي رهيا آهن. ۽ اهو ئي آهي - اسان وڌيڪ يا گهٽ محفوظ آهيون.

جيڪڏهن اسان ڪم جي مقدار جو مقابلو ڪريون ٿا ته منتظم ان وقت مانيٽرنگ مهيا ڪرڻ لاءِ ڪيو، پوءِ ان جو 98٪ خودڪار هو: جيڪو شخص مانيٽرنگ ڪري ٿو اهو سمجهڻ گهرجي ته Zabbix کي ڪيئن انسٽال ڪجي، ان کي ڪيئن ترتيب ڪجي ۽ الارٽس کي ترتيب ڏيو. ۽ 2٪ - ٻاهرين چيڪن لاءِ: ته سائيٽ جواب ڏئي ٿي ۽ ڊيٽابيس کي درخواست ڏئي ٿي، ته نوان آرڊر اچي ويا آهن.

2010 لوڊ وڌي رهيو آهي

اسان ويب کي ماپڻ شروع ڪري رهيا آهيون، هڪ سرچ انجڻ شامل ڪندي. اسان پڪ ڪرڻ چاهيون ٿا ته پراڊڪٽ جي فهرست سڀني شين تي مشتمل آهي. ۽ اهو پراڊڪٽ ڳولا ڪم ڪري ٿو. اهو ڊيٽابيس ڪم ڪري رهيو آهي، آرڊر ڪيا پيا وڃن، ته سائيٽ ٻاهرئين طور تي جواب ڏئي ٿي ۽ ٻن سرورن کان جواب ڏئي ٿي ۽ صارف کي سائيٽ کان ٻاهر نه ڪڍيو ويو آهي جڏهن ته اهو ٻئي سرور ڏانهن متوازن آهي، وغيره. وڌيڪ ادارا آهن.

ان کان علاوه، انفراسٹرڪچر سان لاڳاپيل ادارو اڃا تائين مينيجر جي سر ۾ سڀ کان وڏو رهي ٿو. اڃا تائين منهنجي ذهن ۾ هڪ خيال آهي ته مانيٽرنگ ڪرڻ وارو شخص اهو آهي جيڪو زبڪس انسٽال ڪندو ۽ ان کي ترتيب ڏيڻ جي قابل هوندو.

پر ساڳئي وقت، ڪم ​​ظاهر ٿئي ٿو ٻاهرين چيڪن کي هلائڻ تي، سرچ انڊيڪسر سوال اسڪرپٽ جو هڪ سيٽ ٺاهڻ تي، لکت جو هڪ سيٽ چيڪ ڪرڻ لاءِ ته ڳولا انڊيڪسنگ جي عمل دوران تبديل ٿي وڃي ٿي، لکت جو هڪ سيٽ جيڪو چيڪ ڪري ٿو ته سامان منتقل ڪيو ويو آهي. پهچائڻ جي خدمت، وغيره. ۽ ايئن.

نوٽ: مون 3 ڀيرا ”اسڪرپٽس جو هڪ سيٽ“ لکيو. اهو آهي، مانيٽرنگ جو ذميوار شخص هاڻي اهو ناهي جيڪو صرف زبڪس انسٽال ڪري ٿو. هي هڪ ماڻهو آهي جيڪو ڪوڊنگ شروع ڪري ٿو. پر ٽيم جي ذهنن ۾ اڃا تائين ڪجھ به تبديل نه ٿيو آهي.

پر دنيا بدلجي رهي آهي، وڌيڪ پيچيده ٿي رهي آهي. هڪ ورچوئلائيزيشن پرت ۽ ڪيترائي نوان سسٽم شامل ڪيا ويا آهن. اهي هڪ ٻئي سان ڳالهائڻ شروع ڪن ٿا. ڪنهن چيو ته "مائڪرو سروسز وانگر بوء؟" پر هر خدمت اڃا تائين انفرادي طور تي ويب سائيٽ وانگر نظر اچي ٿي. اسان ان ڏانهن رخ ڪري سگهون ٿا ۽ سمجهي سگهون ٿا ته اهو ضروري معلومات مهيا ڪري ٿو ۽ پنهنجو پاڻ تي ڪم ڪري ٿو. ۽ جيڪڏھن توھان منتظم آھيو مسلسل ھڪڙي منصوبي ۾ شامل آھي جيڪو 5-7-10 سالن کان ترقي ڪري رھيو آھي، اھو علم گڏ ڪري ٿو: ھڪڙي نئين سطح ظاهر ٿئي ٿي - توھان ان کي محسوس ڪيو، ٻيو سطح ظاهر ٿئي ٿو - توھان ان کي محسوس ڪيو ...

پر گهٽ ۾ گهٽ ڪو ماڻهو 10 سالن تائين هڪ منصوبي سان گڏ هوندو آهي.

مانيٽرنگ جي شروعات

فرض ڪريو توهان هڪ نئين اسٽارٽ اپ تي آيا آهيو جنهن فوري طور تي 20 ڊولپرز کي ملازمت ڏني، 15 مائڪرو سروسز لکيو، ۽ توهان هڪ منتظم آهيو جنهن کي چيو ويو آهي: "سي آءِ/سي ڊي ٺاهيو. مهرباني ڪري." توھان CI/CD ٺاھيو آھي ۽ اوچتو توھان ٻڌو: ”اسان لاءِ ”ڪيوب“ ۾ پيداوار سان ڪم ڪرڻ مشڪل آھي، سمجھڻ کان سواءِ ته ايپليڪيشن ان ۾ ڪيئن ڪم ڪندي. اسان کي ساڳي "ڪيوب" ۾ هڪ سينڊ باڪس ٺاهيو.
توهان هن ڪعب ۾ هڪ sandbox ٺاهيو. اهي فوري طور تي توهان کي ٻڌائين ٿا: "اسان هڪ اسٽيج ڊيٽابيس چاهيون ٿا جيڪو هر روز پيداوار کان اپڊيٽ ڪيو وڃي، انهي ڪري اسان سمجهون ٿا ته اهو ڊيٽابيس تي ڪم ڪري ٿو، پر ساڳئي وقت پيداوار جي ڊيٽابيس کي خراب نه ڪريو."

توهان هن سڀني ۾ رهندا آهيو. رليز ٿيڻ کان پهريان 2 هفتا بچيا آهن، اهي توهان کي ٻڌائين ٿا: ”هاڻي اچو ته هي سڀ مانيٽر ڪريون...“ اهو آهي. ڪلسٽر انفراسٽرڪچر جي نگراني ڪريو، مائڪرو سروس آرڪيٽيڪچر جي نگراني ڪريو، ٻاهرين خدمتن سان ڪم جي نگراني ڪريو...

۽ منهنجا ساٿي معمول جي اسڪيم کي پنهنجن سرن مان ڪڍن ٿا ۽ چون ٿا: ”خير، هتي سڀ ڪجهه واضح آهي! هڪ پروگرام انسٽال ڪريو جيڪو هن سڀني جي نگراني ڪندو. ها، ها: Prometheus + Grafana + پلگ ان.
۽ اهي شامل ڪندا آهن: ”توهان وٽ ٻه هفتا آهن ، پڪ ڪريو ته سڀ ڪجهه محفوظ آهي.

ڪيترن ئي منصوبن ۾ جيڪي اسان ڏسون ٿا، هڪ شخص کي نگراني لاء مختص ڪيو ويو آهي. تصور ڪريو ته اسان ھڪڙي شخص کي 2 ھفتن لاءِ مانيٽرنگ ڪرڻ لاءِ ڀرتي ڪرڻ چاھيون ٿا، ۽ اسان ان لاءِ ريزيومي لکون ٿا. هن شخص کي ڪهڙيون صلاحيتون هجڻ گهرجن، اهو سڀ ڪجهه ڏنو جيڪو اسان هن وقت تائين چيو آهي؟

• هن کي لوهه جي انفراسٽرڪچر جي آپريشن جي نگراني ۽ خاصيتن کي سمجهڻ گهرجي.
• هن کي ڪبرنيٽس جي نگراني جي خاصيتن کي سمجهڻ گهرجي (۽ هرڪو "ڪيوب" ڏانهن وڃڻ چاهي ٿو، ڇو ته توهان هر شيء کان خلاصو ڪري سگهو ٿا، لڪائي سگهو ٿا، ڇو ته منتظم باقي سان معاملو ڪندو) - پاڻ، ان جي انفراسٽرڪچر، ۽ سمجھو ته ايپليڪيشنن جي نگراني ڪيئن ڪجي. اندر.
• هن کي اهو سمجهڻ گهرجي ته خدمتون هڪ ٻئي سان خاص طريقن سان رابطو ڪن ٿيون، ۽ ڄاڻو ته ڪيئن خدمتون هڪ ٻئي سان لهه وچڙ ۾ آهن. اهو هڪ پروجيڪٽ ڏسڻ لاء ڪافي ممڪن آهي جتي ڪجهه خدمتون هم وقت سازي سان گفتگو ڪن ٿيون، ڇاڪاڻ ته ٻيو ڪو طريقو ناهي. مثال طور، پس منظر REST ذريعي وڃي ٿو، gRPC ذريعي ڪيٽلاگ سروس ڏانهن، حاصل ڪري ٿو پراڊڪٽس جي لسٽ ۽ ان کي واپس. توهان هتي انتظار نٿا ڪري سگهو. ۽ ٻين خدمتن سان گڏ اهو ڪم ڪري ٿو هم وقت سازي. آرڊر کي ترسيل سروس ڏانهن منتقل ڪريو، خط موڪليو، وغيره.
  توهان شايد اڳ ۾ ئي هن سڀني کان ترڻ ڪيو آهي؟ ۽ منتظم، جنهن کي هن جي نگراني ڪرڻ جي ضرورت آهي، اڃا به وڌيڪ پريشان ٿي وئي.
• هن کي لازمي طور تي منصوبابندي ڪرڻ ۽ صحيح طور تي پلان ڪرڻ جي قابل هوندو - جيئن ڪم وڌيڪ ۽ وڌيڪ ٿيندو.
• تنهن ڪري هن کي لازمي طور تي ٺاهيل سروس مان هڪ حڪمت عملي ٺاهڻ گهرجي انهي کي سمجهڻ لاءِ ته خاص طور تي ان جي نگراني ڪيئن ڪجي. هن کي پروجيڪٽ جي فن تعمير ۽ ان جي ترقي کي سمجهڻ جي ضرورت آهي + ترقي ۾ استعمال ٿيندڙ ٽيڪنالاجي جي سمجھ.

اچو ته هڪ بلڪل عام ڪيس ياد رکون: ڪجهه خدمتون PHP ۾ آهن، ڪجهه خدمتون Go ۾ آهن، ڪجهه خدمتون JS ۾ آهن. اهي هڪ ٻئي سان گڏ ڪم ڪن ٿا. هي اهو آهي جتي اصطلاح "مائڪرو سروس" مان اچي ٿو: اتي ڪيترائي انفرادي سسٽم آهن جيڪي ڊولپرز مڪمل طور تي منصوبي کي سمجهي نٿا سگهن. ٽيم جو هڪ حصو JS ۾ خدمتون لکي ٿو جيڪي پنهنجو پاڻ تي ڪم ڪن ٿا ۽ خبر ناهي ته باقي سسٽم ڪيئن ڪم ڪري ٿو. ٻيو حصو Python ۾ خدمتون لکي ٿو ۽ مداخلت نٿو ڪري ته ٻيون خدمتون ڪيئن ڪم ڪن ٿيون؛ اهي پنهنجي علائقي ۾ الڳ ٿيل آهن. ٽيون هڪ PHP ۾ خدمتون لکڻ يا ٻيو ڪجهه آهي.
اهي سڀئي 20 ماڻهو 15 خدمتن ۾ ورهايل آهن، ۽ صرف هڪ منتظم آهي جنهن کي اهو سڀ سمجهڻ گهرجي. رکو! اسان صرف سسٽم کي 15 مائڪرو سروسز ۾ ورهايو، ڇاڪاڻ ته 20 ماڻهو سڄي سسٽم کي سمجهي نٿا سگهن.

پر ان کي ڪنهن به طرح مانيٽر ڪرڻ جي ضرورت آهي ...

نتيجو ڇا نڪتو؟ نتيجي طور، ھڪڙو ماڻھو آھي جيڪو ھر شيء سان گڏ اچي ٿو جيڪو ڊولپرز جي پوري ٽيم سمجھي نٿو سگھي، ۽ ساڳئي وقت اھو پڻ ڄاڻڻ گھرجي ۽ اھو ڪرڻ جي قابل آھي جيڪو اسان مٿي بيان ڪيو آھي - هارڊويئر انفراسٹرڪچر، ڪبرنيٽس انفراسٽرڪچر، وغيره.

مان ڇا ٿو چوان... هوسٽن، اسان کي مسئلا آهن.

هڪ جديد سافٽ ويئر پروجيڪٽ جي نگراني پاڻ ۾ هڪ سافٽ ويئر پروجيڪٽ آهي

ان غلط عقيدي کان ته مانيٽرنگ سافٽ ويئر آهي، اسان معجزن تي يقين پيدا ڪريون ٿا. پر معجزا، افسوس، نه ٿا ٿين. توهان زبڪس انسٽال نٿا ڪري سگهو ۽ هر شي ڪم ڪرڻ جي اميد رکو. Grafana انسٽال ڪرڻ ۾ ڪو به نقطو ناهي ۽ اميد آهي ته سڀ ڪجهه ٺيڪ ٿي ويندو. گهڻو وقت خرچ ڪيو ويندو خدمتن جي آپريشن جي چيڪن کي منظم ڪرڻ ۽ انهن جي هڪ ٻئي سان رابطي تي، چيڪ ڪرڻ ۾ ته ٻاهرين سسٽم ڪيئن ڪم ڪن ٿا. حقيقت ۾، وقت جو 90٪ اسڪرپٽ لکڻ تي نه، پر سافٽ ويئر کي ترقي ڪرڻ تي خرچ ڪيو ويندو. ۽ اهو هڪ ٽيم پاران هٿ ڪيو وڃي جيڪو منصوبي جي ڪم کي سمجهي.
جيڪڏهن هن صورتحال ۾ هڪ شخص کي نگراني ۾ اڇلايو وڃي ته پوء تباهي ٿيندي. جيڪو هر هنڌ ٿئي ٿو.

مثال طور، ڪيتريون ئي خدمتون آهن جيڪي هڪ ٻئي سان ڪافڪا ذريعي رابطو ڪن ٿيون. آرڊر آيو، اسان ڪافڪا کي آرڊر بابت پيغام موڪليو. هتي هڪ خدمت آهي جيڪا آرڊر بابت معلومات ٻڌي ٿي ۽ سامان موڪلي ٿي. اتي ھڪڙو خدمت آھي جيڪو آرڊر بابت معلومات ٻڌي ٿو ۽ صارف ڏانھن خط موڪلي ٿو. ۽ پوءِ هڪ گروپ وڌيڪ خدمتون ظاهر ٿيون ، ۽ اسان پريشان ٿيڻ شروع ڪيو.

۽ جيڪڏهن توهان ايڊمن ۽ ڊولپرز کي ان اسٽيج تي به ڏيو ٿا جڏهن رليز ٿيڻ کان ٿورو وقت بچيو آهي ته ان شخص کي اهو سڄو پروٽوڪول سمجهڻو پوندو. اهي. هن پيماني جو هڪ منصوبو وقت جو هڪ اهم مقدار وٺندو آهي، ۽ هن کي سسٽم جي ترقي ۾ فڪر ڪيو وڃي.
پر گهڻو ڪري، خاص طور تي شروعاتي ۾، اسان ڏسون ٿا ته ڪيئن نگراني ملتوي ڪئي وئي آهي دير تائين. ”هاڻي اسان تصور جو ثبوت ڏينداسين، اسان ان سان لانچ ڪنداسين، ان کي گرڻ ڏيو- اسان قرباني ڏيڻ لاءِ تيار آهيون. ۽ پوءِ اسان ان جي نگراني ڪنداسين. جڏهن (يا جيڪڏهن) پروجيڪٽ پئسا ڪمائڻ شروع ڪري ٿو، ڪاروبار اڃا به وڌيڪ خاصيتون شامل ڪرڻ چاهي ٿو - ڇاڪاڻ ته اهو ڪم ڪرڻ شروع ڪيو آهي، تنهنڪري ان کي اڳتي وڌڻ جي ضرورت آهي! ۽ توهان ان نقطي تي آهيو جتي توهان کي پهرين هر شيءِ جي نگراني ڪرڻ جي ضرورت آهي پوئين، جيڪو وقت جو 1٪ نه وٺندو آهي، پر گهڻو ڪجهه. ۽ رستي ۾، ڊولپرز جي نگراني جي ضرورت پوندي، ۽ اهو آسان آهي ته انهن کي نئين خاصيتن تي ڪم ڪرڻ ڏيو. نتيجي طور، نيون خاصيتون لکيل آهن، هر شيء خراب ٿي ويندي آهي، ۽ توهان هڪ لامحدود تعطل ۾ آهيو.

پوءِ شروع کان شروع ٿيندڙ پروجيڪٽ جي مانيٽر ڪيئن ڪجي، ۽ ڇا ڪجي جيڪڏهن توهان هڪ پروجيڪٽ حاصل ڪريو جنهن جي نگراني ڪرڻ جي ضرورت آهي، پر توهان کي خبر ناهي ته ڪٿان شروع ڪجي؟

پهرين، توهان کي پلان ڪرڻ جي ضرورت آهي.

شعري تحرڪ: گهڻو ڪري اهي بنيادي ڍانچي جي نگراني سان شروع ڪندا آهن. مثال طور، اسان وٽ آهي Kubernetes. اچو ته شروع ڪريون Prometheus کي انسٽال ڪري Grafana سان، انسٽال ڪريون پلگ ان کي مانيٽر ڪرڻ لاءِ ”ڪيوب“. نه رڳو ڊولپرز، پر منتظمين کي پڻ بدقسمتي سان عمل ڪيو ويو آهي: "اسان هن پلگ ان کي انسٽال ڪنداسين، پر پلگ ان شايد ڄاڻي ٿو ته اهو ڪيئن ڪجي." ماڻهو اهم عملن جي بجاءِ سادي ۽ سڌيءَ طرح شروعات ڪرڻ پسند ڪن ٿا. ۽ انفراسٹرڪچر مانيٽرنگ آسان آهي.

پهرين، فيصلو ڪريو ته توهان ڇا ۽ ڪيئن مانيٽر ڪرڻ چاهيو ٿا، ۽ پوءِ هڪ اوزار چونڊيو، ڇاڪاڻ ته ٻيا ماڻهو توهان لاءِ سوچي نٿا سگهن. ۽ انهن کي گهرجي؟ ٻيا ماڻهو پاڻ کي، هڪ عالمگير نظام جي باري ۾ سوچيو - يا اهو سڀ ڪجهه نه سوچيو جڏهن هي پلگ ان لکيو ويو هو. ۽ صرف ان ڪري ته هن پلگ ان ۾ 5 هزار استعمال ڪندڙ آهن ان جو مطلب اهو ناهي ته اهو ڪنهن به ڪم جو آهي. ٿي سگهي ٿو ته توهان 5001 هين بڻجي ويندا صرف ڇاڪاڻ ته اتي اڳ ۾ ئي 5000 ماڻهو موجود هئا.

جيڪڏهن توهان انفراسٽرڪچر جي نگراني شروع ڪندا آهيو ۽ توهان جي ايپليڪيشن جو پسمنظر جواب ڏيڻ بند ڪري ٿو، سڀئي صارف موبائل ايپليڪيشن سان ڪنيڪشن وڃائي ويهندا. هڪ نقص ظاهر ٿيندو. اهي توهان وٽ ايندا ۽ چوندا "ايپليڪيشن ڪم نه ڪري رهي آهي، توهان هتي ڇا ڪري رهيا آهيو؟" - "اسان نگراني ڪري رهيا آهيون." - "توهان ڪيئن نگراني ڪندا جيڪڏهن توهان نه ٿا ڏسو ته ايپليڪيشن ڪم نه ڪري رهي آهي؟!"

1. مان سمجهان ٿو ته توهان کي صارف جي داخلا واري نقطي کان بلڪل نگراني شروع ڪرڻ جي ضرورت آهي. جيڪڏهن صارف اهو نه ٿو ڏسي ته ايپليڪيشن ڪم ڪري رهي آهي، اهو آهي، اهو هڪ ناڪامي آهي. ۽ مانيٽرنگ سسٽم کي پهريان ان بابت خبردار ڪرڻ گهرجي.
2. ۽ صرف پوء اسان انفراسٹرڪچر جي نگراني ڪري سگهون ٿا. يا ان کي متوازي ۾ ڪريو. اهو انفراسٽرڪچر سان آسان آهي - هتي اسان آخرڪار صرف زبڪس انسٽال ڪري سگهون ٿا.
3. ۽ ھاڻي توھان کي ايپليڪيشن جي روٽ ڏانھن وڃڻ جي ضرورت آھي سمجھڻ لاءِ جتي شيون ڪم نه ڪري رھيون آھن.

منهنجو بنيادي خيال اهو آهي ته مانيٽرنگ کي ترقي جي عمل سان متوازي ۾ وڃڻ گهرجي. جيڪڏهن توهان مانيٽرنگ ٽيم کي ٻين ڪمن (CI/CD ٺاهڻ، سينڊ باڪسنگ، انفراسٽرڪچر ري آرگنائيزيشن) لاءِ پريشان ڪريو ٿا، مانيٽرنگ دير ٿيڻ شروع ٿي ويندي ۽ توهان ڪڏهن به ترقيءَ سان پڪڙي نه سگهندا (يا جلد يا بعد ۾ توهان کي ان کي روڪڻو پوندو).

هر شي سطح تي

هي ڪيئن ڏسان ٿو مانيٽرنگ سسٽم جي تنظيم.

1) درخواست جي سطح:

• نگراني ايپليڪيشن ڪاروباري منطق؛
• خدمتن جي صحت جي ميٽرڪ جي نگراني؛
• انضمام جي نگراني.

2) انفراسٽرڪچر سطح:

• آرڪيسٽريشن جي سطح جي نگراني؛
• سسٽم سافٽ ويئر جي نگراني؛
• لوهه جي سطح جي نگراني.

3) ٻيهر ايپليڪيشن سطح - پر هڪ انجنيئرنگ پراڊڪٽ جي طور تي:

• ايپليڪيشن لاگ گڏ ڪرڻ ۽ نگراني ڪرڻ؛
• اي پي ايم؛
• نشان لڳائڻ.

4) خبردار ڪرڻ:

• ڊيڄاريندڙ نظام جي تنظيم؛
• هڪ فرض نظام جي تنظيم؛
• "علم جي بنياد" جي تنظيم ۽ واقعن جي پروسيسنگ لاء ڪم فلو.

اهم: اسان کي خبردار ٿيڻ کان پوء نه، پر فوري طور تي حاصل ڪريون! مانيٽرنگ شروع ڪرڻ جي ڪا ضرورت ناهي ۽ ”ڪجهه دير سان“ معلوم ڪيو ته ڪير الرٽ وصول ڪندو. آخرڪار، مانيٽرنگ جو ڪم ڇا آهي: اهو سمجهڻ لاء ته سسٽم ۾ ڪٿي ڪجهه غلط ڪم ڪري رهيو آهي، ۽ صحيح ماڻهن کي ان جي باري ۾ ڄاڻڻ لاء. جيڪڏهن توهان هن کي آخر تائين ڇڏي ڏيو ته پوءِ صحيح ماڻهن کي خبر پئجي ويندي ته ڪجهه غلط ٿي رهيو آهي صرف "اسان لاءِ ڪجهه به ڪم نه ڪري رهيو آهي."

ايپليڪيشن پرت - ڪاروباري منطق مانيٽرنگ

هتي اسان انهي حقيقت کي جانچڻ بابت ڳالهائي رهيا آهيون ته ايپليڪيشن صارف لاءِ ڪم ڪري ٿي.

هن سطح کي ترقي جي مرحلي دوران ڪيو وڃي. مثال طور، اسان وٽ هڪ مشروط Prometheus آهي: اهو سرور ڏانهن وڃي ٿو جيڪو چيڪ ڪري ٿو، آخري پوائنٽ کي ڇڪي ٿو، ۽ آخري پوائنٽ وڃي ٿو ۽ API کي چيڪ ڪري ٿو.

جڏهن اڪثر گهر واري صفحي کي مانيٽر ڪرڻ لاءِ چيو ويندو آهي انهي کي يقيني بڻائڻ لاءِ ته سائيٽ ڪم ڪري رهي آهي، پروگرامر هڪ هينڊل ڏيندا آهن جنهن کي هر وقت ڇڪي سگهجي ٿو انهن کي پڪ ڪرڻ جي ضرورت آهي ته API ڪم ڪري رهيو آهي. ۽ هن وقت پروگرامر اڃا تائين /api/test/helloworld وٺي ۽ لکندا آهن
پڪ ڪرڻ جو واحد طريقو هر شي ڪم ڪري ٿو؟ - نه!

• اهڙيون چيڪون ٺاهڻ بنيادي طور تي ڊولپرز جو ڪم آهي. يونٽ ٽيسٽ کي پروگرامرن طرفان لکيو وڃي ٿو جيڪي ڪوڊ لکن ٿا. ڇو ته جيڪڏهن توهان ان کي ايڊمن ڏانهن لڪي ٿا، "يار، هتي سڀني 25 افعال لاء API پروٽوڪول جي فهرست آهي، مهرباني ڪري هر شيء جي نگراني ڪريو!" - ڪجھ به ڪم نه ڪندو.
• جيڪڏهن توهان "هيلو دنيا" کي پرنٽ ڪريو ٿا، ڪنهن کي ڪڏهن به خبر ناهي ته API کي گهرجي ۽ ڪم ڪري. هر API تبديلي کي چڪاس ۾ تبديلي جي اڳواڻي ڪرڻ گهرجي.
• جيڪڏهن توهان وٽ اڳ ۾ ئي اهڙو مسئلو آهي، خاصيتن کي روڪيو ۽ ڊولپرز کي مختص ڪريو جيڪي اهي چيڪ لکندا، يا نقصان کي قبول ڪندا، قبول ڪريو ته ڪجھ به نه چيڪ ڪيو ويو آهي ۽ ناڪام ٿيندو.

ٽيڪنيڪل صلاحون:

• چيڪن کي منظم ڪرڻ لاءِ ٻاهرين سرور کي منظم ڪرڻ جي پڪ ڪريو - توهان کي پڪ ڪرڻ گهرجي ته توهان جو پروجيڪٽ ٻاهرين دنيا تائين رسائي لائق آهي.
• پوري API پروٽوڪول ۾ چيڪن کي منظم ڪريو، نه رڳو انفرادي آخري پوائنٽون.
• ٽيسٽ جي نتيجن سان گڏ هڪ پرومٿيس-آخر پوائنٽ ٺاهيو.

ايپليڪيشن پرت - صحت جي ميٽرڪ مانيٽرنگ

هاڻي اسان خدمتن جي خارجي صحت جي ماپ بابت ڳالهائي رهيا آهيون.

اسان فيصلو ڪيو ته اسان ٻاهرين چيڪن کي استعمال ڪندي ايپليڪيشن جي سڀني ”هينڊلز“ جي نگراني ڪريون ٿا، جنهن کي اسان ٻاهرين مانيٽرنگ سسٽم مان سڏين ٿا. پر اهي آهن "هينڊلز" جيڪي صارف "ڏسندا آهن". اسان پڪ ڪرڻ چاهيون ٿا ته اسان جون خدمتون پاڻ ڪم ڪن ٿيون. هتي هڪ بهتر ڪهاڻي آهي: K8s صحت جي چڪاس ڪئي آهي، انهي ڪري ته گهٽ ۾ گهٽ "ڪيوب" پاڻ کي يقين ڏياريو وڃي ته خدمت ڪم ڪري رهي آهي. پر اڌ چيڪ مون ڏٺا آهن ساڳيا پرنٽ “هيلو ورلڊ”. اهي. تنهن ڪري هو هڪ دفعو ٺهڻ کان پوءِ ڇڪي ٿو، هن جواب ڏنو ته سڀ ڪجهه ٺيڪ آهي - بس. ۽ خدمت، جيڪڏهن اها پنهنجي API مهيا ڪري ٿي، انهي ساڳئي API لاء داخلا پوائنٽن جو هڪ وڏو تعداد آهي، جنهن کي پڻ مانيٽر ڪرڻ جي ضرورت آهي، ڇاڪاڻ ته اسان ڄاڻڻ چاهيون ٿا ته اهو ڪم ڪري ٿو. ۽ اسان اڳ ۾ ئي اندر اندر ان جي نگراني ڪري رهيا آهيون.

هن کي ٽيڪنيڪل طور تي صحيح طريقي سان ڪيئن لاڳو ڪيو وڃي: هر خدمت پنهنجي موجوده ڪارڪردگي بابت هڪ آخري نقطو ظاهر ڪري ٿي، ۽ گرافانا (يا ڪنهن ٻئي ايپليڪيشن) جي گراف ۾ اسان سڀني خدمتن جي حالت ڏسون ٿا.

• هر API تبديلي کي چڪاس ۾ تبديلي جي اڳواڻي ڪرڻ گهرجي.
• صحت جي ميٽرڪس سان فوري طور تي نئين خدمت ٺاهيو.
• هڪ منتظم ڊولپرز وٽ اچي سگهي ٿو ۽ پڇي سگھي ٿو ”مون کي ڪجھ خاصيتون شامل ڪريو ته جيئن مان سڀ ڪجھ سمجھان ۽ ان بابت معلومات پنھنجي مانيٽرنگ سسٽم ۾ شامل ڪريان. پر ڊولپر عام طور تي جواب ڏيندا آهن، "اسان رليز ٿيڻ کان ٻه هفتا اڳ ڪجهه به شامل نه ڪنداسين."
  ڊولپمينٽ مينيجرز کي خبر ڏيو ته اهڙا نقصان ٿيندا، ڊولپمينٽ مينيجرز جي انتظاميا کي به خبر ڏيو. ڇاڪاڻ ته جڏهن سڀ ڪجهه ٿئي ٿو، ڪو ماڻهو اڃا به فون ڪندو ۽ "مسلسل گرڻ واري خدمت" جي نگراني ڪرڻ جو مطالبو ڪندو (c)
• رستي ۾، ڊولپرز کي مختص ڪريو گرافانا لاءِ پلگ ان لکڻ لاءِ - اهو منتظمين لاءِ سٺو مددگار ثابت ٿيندو.

ايپليڪيشن ليئر - انٽيگريشن مانيٽرنگ

انضمام جي نگراني ڪاروباري-نازڪ سسٽم جي وچ ۾ رابطي جي نگراني تي ڌيان ڏئي ٿو.

مثال طور، 15 خدمتون آهن جيڪي هڪ ٻئي سان رابطو ڪن ٿيون. اهي هاڻي الڳ سائيٽون نه آهن. اهي. اسان خدمت کي پاڻ تي نه ٿا ڪڍون، حاصل ڪريو /helloworld ۽ سمجھو ته خدمت هلي رهي آهي. ڇاڪاڻ ته آرڊر ڏيڻ واري ويب سروس کي لازمي طور تي آرڊر بابت معلومات بس ڏانهن موڪلڻ گهرجي - بس مان، گودام سروس کي لازمي طور تي هي پيغام ملي ٿو ۽ ان سان اڳتي ڪم ڪرڻ گهرجي. ۽ اي ميل ورهائڻ واري خدمت کي لازمي طور تي عمل ڪرڻ گهرجي انهي کي اڳتي وڌايو، وغيره.

ان جي مطابق، اسان سمجهي نٿا سگهون، هر هڪ فرد جي خدمت تي ڇڪايو، ته اهو سڀ ڪم ڪري ٿو. ڇاڪاڻ ته اسان وٽ هڪ خاص بس آهي جنهن جي ذريعي هر شيءِ ڳالهائي ٿي ۽ لهي ٿي.
تنهن ڪري، هن اسٽيج کي ٻين خدمتن سان رابطي لاءِ جانچ جي خدمتن جي اسٽيج کي نشانو بڻائڻ گهرجي. پيغام بروکر جي نگراني ڪندي رابطي جي نگراني کي منظم ڪرڻ ناممڪن آهي. جيڪڏهن هڪ خدمت آهي جيڪا ڊيٽا کي جاري ڪري ٿي ۽ هڪ خدمت جيڪا ان کي وصول ڪري ٿي، جڏهن بروکر جي نگراني ڪنداسين ته اسان صرف ڊيٽا کي ڏسندا سين جيڪو هڪ طرف کان ٻئي طرف اڏامي ٿو. جيتوڻيڪ اسان ڪنهن به طرح هن ڊيٽا جي اندروني رابطي جي نگراني ڪرڻ ۾ منظم ڪيو - ته هڪ خاص پروڊيوسر ڊيٽا کي پوسٽ ڪري ٿو، ڪو ان کي پڙهي ٿو، اهو وهڪرو ڪافڪا ڏانهن وڃڻ جاري آهي - اهو اڃا تائين اسان کي معلومات نه ڏيندو جيڪڏهن هڪ خدمت هڪ ورزن ۾ پيغام موڪليو. ، پر ٻي خدمت هن نسخي جي توقع نه ڪئي ۽ ان کي ڇڏي ڏنو. اسان ان جي باري ۾ نه ڄاڻندا سين، ڇو ته خدمتون اسان کي ٻڌايون ٿا ته سڀ ڪجهه ڪم ڪري رهيو آهي.

مان ڇا ڪرڻ جي صلاح ڏيان ٿو:

• هم وقت سازي رابطي لاءِ: آخري پوائنٽ لاڳاپيل خدمتن لاءِ درخواستون ڏئي ٿو. اهي. اسان هن آخري نقطي کي وٺو، خدمت جي اندر هڪ اسڪرپٽ ڇڪيو، جيڪو سڀني نقطن ڏانهن وڃي ٿو ۽ چوي ٿو "مان اتي ڇڪي سگهان ٿو، ۽ اتي ڇڪي سگهان ٿو، مان اتي ڇڪي سگهان ٿو ..."
• هم وقت سازي ڪميونيڪيشن لاءِ: ايندڙ پيغام - آخري پوائنٽ بس کي جانچي ٿو ٽيسٽ پيغامن لاءِ ۽ ڏيکاري ٿو پروسيسنگ اسٽيٽس.
• هم وقت سازي ڪميونيڪيشن لاءِ: ٻاهر وڃڻ وارا پيغام - آخري پوائنٽ بس ڏانهن ٽيسٽ پيغام موڪلي ٿو.

جيئن عام طور تي ٿئي ٿو: اسان وٽ هڪ خدمت آهي جيڪا ڊيٽا کي بس ۾ اڇلائي ٿي. اسان هن خدمت تي آيا آهيون ۽ توهان کان پڇو ته اسان کي ان جي انضمام جي صحت بابت ٻڌايو. ۽ جيڪڏهن خدمت جي ضرورت آهي ته هڪ پيغام پيدا ڪرڻ جي ضرورت آهي ڪنهن به جاء تي (WebApp)، پوء اهو اهو امتحان پيغام پيدا ڪندو. ۽ جيڪڏهن اسان OrderProcessing پاسي تي هڪ خدمت هلائيندا آهيون، اهو پهريان پوسٽ ڪري ٿو ته اهو ڇا پوسٽ ڪري سگهي ٿو آزاد، ۽ جيڪڏهن ڪجهه منحصر شيون آهن، پوء اهو بس مان ٽيسٽ پيغامن جو هڪ سيٽ پڙهي ٿو، سمجهي ٿو ته اهو انهن کي پروسيس ڪري سگهي ٿو، ان کي رپورٽ ڪري سگهي ٿو ۽ ، جيڪڏھن ضروري ھجي، انھن کي اڳتي وڌايو، ۽ ان بابت ھو چوي ٿو - سڀ ڪجھ ٺيڪ آھي، مان جيئرو آھيان.

گهڻو ڪري اسان اهو سوال ٻڌندا آهيون ته "اسان هن کي جنگي ڊيٽا تي ڪيئن آزمائي سگهون ٿا؟" مثال طور، اسان ساڳئي آرڊرنگ سروس بابت ڳالهائي رهيا آهيون. آرڊر گودام ڏانهن پيغام موڪلي ٿو جتي سامان بند ٿيل آهن: اسان هن کي جنگي ڊيٽا تي آزمائي نٿا سگهون، ڇاڪاڻ ته "منهنجو سامان بند ڪيو ويندو!" حل: هن سڄي ٽيسٽ کي شروعات ۾ رٿيو. توهان وٽ پڻ يونٽ ٽيسٽ آهن جيڪي ٺٺوليون ٺاهيندا آهن. تنهن ڪري، اهو هڪ اونهي سطح تي ڪريو جتي توهان وٽ هڪ مواصلاتي چينل آهي جيڪو ڪاروبار جي آپريشن کي نقصان نه پهچائيندو آهي.

انفراسٽرڪچر جي سطح

انفراسٹرڪچر مانيٽرنگ اهو آهي جيڪو گهڻو وقت پاڻ کي مانيٽرنگ سمجهي رهيو آهي.

• انفراسٹرڪچر مانيٽرنگ هڪ الڳ عمل جي طور تي شروع ڪري سگهجي ٿو ۽ ٿيڻ گهرجي.
• توهان کي هلندڙ منصوبي تي انفراسٽرڪچر مانيٽرنگ سان شروع نه ڪرڻ گهرجي، جيتوڻيڪ توهان واقعي چاهيو ٿا. اهو درد سڀني ديوانن لاءِ آهي. "پهرين مان ڪلستر جي نگراني ڪندس، مان انفراسٹرڪچر جي نگراني ڪندس" - يعني پهرين، اهو مانيٽر ڪندو جيڪو هيٺ آهي، پر ايپليڪيشن ۾ نه ويندو. ڇو ته ايپليڪيشن ڊيوپس لاء هڪ ناقابل فهم شيء آهي. اهو هن ڏانهن لڪي ويو، ۽ هو سمجهي نه ٿو ته اهو ڪيئن ڪم ڪري ٿو. ۽ هو انفراسٹرڪچر کي سمجهي ٿو ۽ ان سان شروع ٿئي ٿو. پر نه - توهان کي هميشه پهرين ايپليڪيشن جي نگراني ڪرڻ جي ضرورت آهي.
• خبردارين جي تعداد سان گڏ نه وڃو. جديد سسٽم جي پيچيدگي تي غور ڪندي، الرٽ مسلسل پرواز ڪري رهيا آهن، ۽ توهان کي ڪنهن به طرح جي خبردارين جي هن گروپ سان گڏ رهڻو پوندو. ۽ ڪال ڪندڙ شخص، ايندڙ سؤ وارن وارن کي ڏسندي، فيصلو ڪندو ”مان ان بابت سوچڻ نٿو چاهيان“. خبردارين کي صرف نازڪ شين بابت اطلاع ڏيڻ گهرجي.

ڪاروباري يونٽ جي طور تي ايپليڪيشن جي سطح

اهم نقطا

• ايل ڪي. هي صنعت جو معيار آهي. جيڪڏهن ڪجهه سببن لاءِ توهان لاگز کي گڏ نه ڪري رهيا آهيو، فوري طور تي ائين ڪرڻ شروع ڪريو.
• اي پي ايم. خارجي APMs هڪ طريقي جي طور تي ايپليڪيشن مانيٽرنگ کي جلدي بند ڪرڻ لاءِ (NewRelic, BlackFire, Datadog). توهان هن شيءَ کي عارضي طور تي انسٽال ڪري سگهو ٿا گهٽ ۾ گهٽ ڪنهن نه ڪنهن طرح اهو سمجهڻ لاءِ ته توهان سان ڇا ٿي رهيو آهي.
• ٽريڪنگ. ڪيترن ئي مائڪرو سروسز ۾، توهان کي هر شي کي ڳولڻو پوندو، ڇو ته درخواست هاڻي پنهنجي پاڻ تي نه رهي آهي. اهو بعد ۾ شامل ڪرڻ تمام ڏکيو آهي، تنهنڪري اهو بهتر آهي ته فوري طور تي ترقي ۾ ٽريڪنگ شيڊول - اهو ڪم ۽ افاديت ڊولپرز جو آهي. جيڪڏهن توهان اڃا تائين ان تي عمل نه ڪيو آهي، ان کي لاڳو ڪريو! ڏسو Jaeger/Zipkin

خبردار ڪرڻ

• نوٽيفڪيشن سسٽم جي تنظيم: شين جي هڪ گروپ جي نگراني جي حالتن ۾، اطلاعن کي موڪلڻ لاء هڪ متحد نظام هجڻ گهرجي. توهان Grafana ۾ ڪري سگهو ٿا. اولهه ۾، هرڪو استعمال ڪري ٿو PagerDuty. خبرداري صاف هجڻ گهرجي (مثال طور اهي ڪٿان آيا آهن ...). ۽ اهو ڪنٽرول ڪرڻ جي صلاح ڏني وئي آهي ته اطلاعن کي وصول ڪيو وڃي
• ڊيوٽي سسٽم جي تنظيم: الرٽ هر ڪنهن کي نه موڪليو وڃي (يا ته هرڪو هڪ ميڙ ۾ رد عمل ڪندو، يا ڪو به رد عمل نه ڪندو). ڊولپرز کي پڻ آن ڪال ٿيڻ جي ضرورت آهي: ذميواري جي علائقن جي وضاحت ڪرڻ جي پڪ ڪريو، واضح هدايتون ٺاهيون ۽ ان ۾ لکو ته سومر ۽ اربع تي ڪنهن کي فون ڪرڻو آهي، ۽ ڪير اڱارو ۽ جمعه تي فون ڪري ٿو (ٻي صورت ۾ اهي ڪنهن کي به فون نه ڪندا. هڪ وڏي مسئلي جو واقعو - اهي توهان کي جاڳڻ يا پريشان ڪرڻ کان ڊڄندا: ماڻهو عام طور تي ٻين ماڻهن کي فون ڪرڻ ۽ جاڳڻ پسند نٿا ڪن، خاص طور تي رات جو). ۽ وضاحت ڪريو ته مدد لاءِ پڇڻ نااهلي جو اشارو نه آهي ("مان مدد لاءِ پڇان ٿو، ان جو مطلب آهي ته مان هڪ خراب ڪم ڪندڙ آهيان")، مدد لاءِ درخواستن جي حوصلا افزائي ڪريو.
• "علم جي بنياد" جي تنظيم ۽ واقعي جي پروسيسنگ لاء ڪم فلو: هر سنگين واقعي لاء، پوسٽ مارٽم جي منصوبابندي ڪئي وڃي، ۽ هڪ عارضي انداز جي طور تي، عمل جيڪي واقعا حل ڪندا، رڪارڊ ڪيو وڃي. ۽ ان کي هڪ مشق ٺاهيو ته بار بار خبردار ڪرڻ هڪ گناهه آهي. انهن کي ڪوڊ يا انفراسٽرڪچر جي ڪم ۾ مقرر ڪرڻ جي ضرورت آهي.

ٽيڪنالاجي اسٽيڪ

اچو ته تصور ڪريو ته اسان جو اسٽيڪ هن ريت آهي:

• ڊيٽا گڏ ڪرڻ - Prometheus + Grafana؛
• لاگ تجزيو - ELK؛
• APM يا ٽريڪنگ لاءِ - Jaeger (Zipkin).

اختيارن جو انتخاب نازڪ نه آهي. ڇو ته جيڪڏھن شروعات ۾ توھان سمجھيو ھو ته سسٽم کي مانيٽر ڪيئن ڪجي ۽ ھڪڙو منصوبو لکجي، پوءِ توھان شروع ڪيو اوزار چونڊڻ لاءِ توھان جي ضرورتن مطابق. سوال اهو آهي ته توهان پهرين جڳهه ۾ مانيٽر ڪرڻ جو انتخاب ڪيو آهي. ڇاڪاڻ ته شايد اهو اوزار جيڪو توهان شروع ۾ چونڊيو آهي اهو توهان جي گهرجن کي پورو نٿو ڪري.

ڪجھ ٽيڪنيڪل نقطا جيڪي مون کي هر جاءِ تي نظر اچن ٿا:

پروميٿيوس کي ڪبرنيٽس جي اندر ڌڪيو پيو وڃي - ڪير آيو آهي؟! جيڪڏهن توهان جو ڪلستر حادثو، توهان ڇا ڪندا؟ جيڪڏهن توهان وٽ هڪ پيچيده ڪلسٽر آهي، ته پوء اتي ڪجهه قسم جي نگراني سسٽم ڪلستر جي اندر، ۽ ڪجهه ٻاهران، جيڪو ڪلستر جي اندر کان ڊيٽا گڏ ڪندو.

ڪلستر جي اندر اسان لاگ ۽ ٻيو سڀ ڪجهه گڏ ڪندا آهيون. پر مانيٽرنگ سسٽم ٻاهران هجڻ گهرجي. گهڻو ڪري، هڪ ڪلستر ۾ جتي Promtheus اندروني طور تي نصب ٿيل آهي، اتي پڻ سسٽم آهن جيڪي سائيٽ جي آپريشن جي ٻاهرين چيڪن کي انجام ڏين ٿا. ڇا جيڪڏهن توهان جا ڪنيڪشن ٻاهرئين دنيا سان ختم ٿي ويا آهن ۽ ايپليڪيشن ڪم نه ڪندي؟ اهو ظاهر ٿئي ٿو ته هر شي اندر اندر ٺيڪ آهي، پر اهو صارفين لاء شيون آسان ناهي.

پهچڻ

• مانيٽرنگ ڊولپمينٽ يوٽيلٽيز جي تنصيب نه آهي، پر سافٽ ويئر جي پيداوار جي ترقي. اڄ جي نگراني جو 98٪ ڪوڊنگ آهي. خدمتن ۾ ڪوڊنگ، خارجي چيڪن کي ڪوڊنگ، خارجي خدمتن جي جانچ ڪرڻ، ۽ اهو سڀ ڪجهه آهي.
• پنھنجي ڊولپرز جو وقت مانيٽرنگ تي ضايع نه ڪريو: اھو انھن جي ڪم جو 30٪ تائين وٺي سگھي ٿو، پر اھو ان جي لائق آھي.
• Devops، پريشان نه ڪريو ته توهان ڪجهه مانيٽر نٿا ڪري سگهو، ڇو ته ڪجهه شيون سوچڻ جو هڪ مڪمل طور تي مختلف طريقو آهي. توهان هڪ پروگرامر نه هئا، ۽ نگراني جو ڪم بلڪل انهن جو ڪم آهي.
• جيڪڏهن پروجيڪٽ اڳ ۾ ئي هلندڙ آهي ۽ نگراني نه ڪئي وئي آهي (۽ توهان هڪ مينيجر آهيو)، نگراني لاء وسيلن کي مختص ڪريو.
• جيڪڏهن پيداوار اڳ ۾ ئي پيداوار ۾ آهي، ۽ توهان هڪ ڊيوپس آهيو جنهن کي چيو ويو هو ته "مانيٽرنگ قائم ڪريو" - انتظاميا کي وضاحت ڪرڻ جي ڪوشش ڪريو جيڪو مون اهو سڀ ڪجهه لکيو آهي.

هي سينٽ هاء لوڊ ++ ڪانفرنس ۾ رپورٽ جو وڌايل نسخو آهي.

جيڪڏهن توهان منهنجي خيالن ۽ خيالن ۾ دلچسپي وٺندا آهيو ۽ ان سان لاڳاپيل عنوانن تي، پوء هتي توهان ڪري سگهو ٿا چينل پڙهو 🙂

جو ذريعو: www.habr.com