منهنجو نالو Anton Baderin آهي. مان هاءِ ٽيڪنالاجي سينٽر تي ڪم ڪريان ٿو ۽ سسٽم ايڊمنسٽريشن ڪريان ٿو. هڪ مهينو اڳ، اسان جي ڪارپوريٽ ڪانفرنس ختم ٿي، جتي اسان پنهنجي شهر جي آئي ٽي ڪميونٽي سان گڏ ڪيل تجربو شيئر ڪيو. مون ويب ايپليڪيشنن جي نگراني بابت ڳالهايو. مواد جونيئر يا وچين سطح جي لاء ارادو ڪيو ويو، جن هن عمل کي شروع کان تعمير نه ڪيو.
ڪنهن به مانيٽرنگ سسٽم جو بنيادي بنياد ڪاروباري مسئلن کي حل ڪري رهيو آهي. مانيٽرنگ لاءِ ڪم ڪرڻ ڪنهن جي به فائدي جي ڳالهه ناهي. ڪاروبار ڇا ٿو چاهي؟ انهي ڪري ته هر شي جلدي ۽ بغير ڪنهن غلطي جي ڪم ڪري ٿي. ڪاروبار چاھيو ٿا چاھيون چاھيون، ته جيئن اسان پاڻ خدمت ۾ مسئلن جي نشاندهي ڪريون ۽ انھن کي جلد کان جلد حل ڪريون. اهي، حقيقت ۾، اهي مسئلا آهن جيڪي مون گذريل سال اسان جي هڪ گراهڪ جي منصوبي تي حل ڪيا آهن.
منصوبي بابت
پروجيڪٽ ملڪ ۾ سڀ کان وڏي وفاداري پروگرامن مان هڪ آهي. اسان پرچون زنجيرن جي مدد ڪندا آهيون سيلز جي تعدد کي وڌائڻ ۾ مختلف مارڪيٽنگ ٽولز جهڙوڪ بونس ڪارڊ. مجموعي طور تي، منصوبي ۾ 14 ايپليڪيشنون شامل آهن جيڪي ڏهن سرورن تي هلن ٿيون.
انٽرويو جي عمل دوران، مون بار بار محسوس ڪيو ته منتظمين هميشه ويب ايپليڪيشنن جي نگراني جي صحيح طريقي سان نه ايندا آهن: ڪيترائي اڃا تائين آپريٽنگ سسٽم ميٽرڪس تي ڌيان ڏين ٿا ۽ ڪڏهن ڪڏهن خدمتن جي نگراني ڪن ٿا.
منهنجي صورت ۾، ڪسٽمر جي نگراني نظام اڳ ۾ Icinga تي ٻڌل هئي. اهو مٿين مسئلن کي ڪنهن به طريقي سان حل نه ڪيو. گهڻو ڪري ڪلائنٽ پاڻ اسان کي مسئلن جي باري ۾ ٻڌايو، ۽ گهڻو ڪري نه، اسان وٽ صرف ايترو ڊيٽا نه هو جو سبب جي تري ۾ حاصل ڪري سگهجي.
ان کان علاوه، ان جي اڳتي وڌڻ جي فضيلت جي واضح ڄاڻ هئي. منهنجو خيال آهي ته جيڪي Icinga کان واقف آهن اهي مون کي سمجهي سگهندا. تنهن ڪري، اسان منصوبي لاءِ ويب ايپليڪيشن مانيٽرنگ سسٽم کي مڪمل طور تي نئين سر ترتيب ڏيڻ جو فيصلو ڪيو.
Prometheus
اسان ٽن مکيه اشارن جي بنياد تي Prometheus چونڊيو:
- دستياب ميٽرڪ جو وڏو تعداد. اسان جي صورت ۾ انهن مان 60 هزار آهن. يقينا، اهو قابل ذڪر آهي ته اسان انهن جي وڏي اڪثريت استعمال نٿا ڪريون (شايد 95٪ بابت). ٻئي طرف، اهي سڀ نسبتا سستا آهن. اسان لاءِ، اڳ ۾ استعمال ٿيل Icinga جي مقابلي ۾ هي ٻيو انتها آهي. ان ۾، ميٽرڪس شامل ڪرڻ هڪ خاص درد هو: موجوده جيڪي قيمتي هئا (صرف ڪنهن به پلگ ان جو سورس ڪوڊ ڏسو). ڪو به پلگ ان بش يا پٿون ۾ هڪ اسڪرپٽ هوندو هو، جنهن جو لانچ استعمال ٿيل وسيلن جي لحاظ کان قيمتي آهي.
- هي سسٽم وسيلن جي هڪ نسبتا ننڍڙي رقم استعمال ڪري ٿو. 600 MB RAM، 15% ھڪڙي ڪور ۽ ٻه درجن IOPS اسان جي سڀني ميٽرڪ لاء ڪافي آھن. يقينا، توهان کي ميٽرڪس برآمد ڪندڙن کي هلائڻو پوندو، پر اهي سڀئي گو ۾ لکيل آهن ۽ پڻ تمام گهڻو طاقت بکيو نه آهن. مان نه ٿو سمجهان ته جديد حقيقتن ۾ اهو هڪ مسئلو آهي.
- Kubernetes ڏانهن لڏپلاڻ ڪرڻ جي صلاحيت فراهم ڪري ٿي. ڪسٽمر جي منصوبن تي غور ڪندي، چونڊ واضح آهي.
ايل
اڳي، اسان لاگ گڏ نه ڪيو يا عمل نه ڪيو. نقص هر ڪنهن لاءِ واضح آهن. اسان چونڊيو ELK ڇاڪاڻ ته اسان وٽ اڳ ۾ ئي هن سسٽم سان تجربو هو. اسان اتي صرف ايپليڪيشن لاگ محفوظ ڪندا آهيون. مکيه چونڊ معيار مڪمل متن جي ڳولا ۽ ان جي رفتار هئا.
ڪليڪ هائوس
شروعات ۾، انتخاب InfluxDB تي ٿي ويو. اسان Nginx لاگز گڏ ڪرڻ جي ضرورت محسوس ڪئي، pg_stat_statements مان انگ اکر، ۽ Prometheus تاريخي ڊيٽا کي ذخيرو ڪريو. اسان انفلڪس کي پسند نه ڪيو ڇاڪاڻ ته اهو وقتي طور تي وڏي مقدار ۾ ياداشت کي استعمال ڪرڻ شروع ڪيو ۽ تباهه ٿي ويو. ان کان علاوه، مون remote_addr ذريعي گروپ سوالن کي ترتيب ڏيڻ چاهيو، پر هن ڊي بي ايم ايس ۾ گروپ صرف ٽيگ ذريعي آهي. ٽيگ قيمتي آهن (ياداشت)، انهن جو تعداد مشروط طور تي محدود آهي.
اسان وري پنهنجي ڳولا شروع ڪئي. ڇا جي ضرورت هئي هڪ تجزياتي ڊيٽابيس هئي گهٽ ۾ گهٽ وسيلن جي استعمال سان، ترجيح طور تي ڊسڪ تي ڊيٽا ڪمپريشن سان.
ڪلڪ هائوس انهن سڀني معيارن کي پورو ڪري ٿو، ۽ اسان ڪڏهن به پنهنجي پسند تي افسوس نه ڪيو آهي. اسان ان ۾ ڊيٽا جي ڪا به غير معمولي مقدار نه لکندا آهيون (داخلن جو تعداد صرف پنج هزار في منٽ آهي).
نئون ريليڪ
NewRelic تاريخي طور تي اسان سان گڏ آهي ڇو ته اها ڪسٽمر جي پسند هئي. اسان ان کي APM طور استعمال ڪندا آهيون.
زيبڪس
اسان Zabbix استعمال ڪندا آهيون خاص طور تي مختلف APIs جي بليڪ باڪس جي نگراني ڪرڻ لاءِ.
هڪ مانيٽرنگ انداز جي وضاحت
اسان ڪم کي ختم ڪرڻ چاهيون ٿا ۽ انهي جي نگراني جي طريقي کي منظم ڪرڻ.
هن کي ڪرڻ لاء، مون اسان جي سسٽم کي هيٺين سطحن ۾ ورهايو:
- هارڊويئر ۽ VMS؛
- آپريٽنگ سسٽم؛
- سسٽم خدمتون، سافٽ ويئر اسٽيڪ؛
- درخواست؛
- ڪاروباري منطق.
ڇو ته هي طريقو آسان آهي:
- اسان ڄاڻون ٿا ته هر سطح جي ڪم جو ذميوار ڪير آهي ۽، ان جي بنياد تي، اسان الرٽ موڪلي سگهون ٿا؛
- اسان ڍانچي کي استعمال ڪري سگھون ٿا جڏھن خبرداري کي دٻايو وڃي - اھو عجيب ھوندو ته ڊيٽابيس جي غير موجودگيءَ بابت خبرداري موڪلڻ جڏھن ورچوئل مشين مجموعي طور تي دستياب ناھي.
جيئن ته اسان جو ڪم سسٽم جي آپريشن ۾ خلاف ورزين جي نشاندهي ڪرڻ آهي، اسان کي هر سطح تي هڪ خاص سيٽ ميٽرڪس کي اجاگر ڪرڻ گهرجي جيڪي خبرداري جي ضابطن کي لکڻ وقت ڌيان ڏيڻ جي قابل آهن. اڳيون، اچو ته "VMS"، "آپريٽنگ سسٽم" ۽ "سسٽم خدمتون، سافٽ ويئر اسٽيڪ" جي سطحن ذريعي وڃو.
مجازي مشينون
هوسٽنگ اسان کي هڪ پروسيسر، ڊسڪ، ميموري ۽ نيٽورڪ مختص ڪري ٿو. ۽ اسان کي پهرين ٻن سان مسئلا هئا. تنهن ڪري، ميٽرڪ:
CPU چوري جو وقت - جڏهن توهان Amazon (t2.micro، مثال طور) تي هڪ ورچوئل مشين خريد ڪندا آهيو، توهان کي سمجهڻ گهرجي ته توهان کي مڪمل پروسيسر ڪور مختص نه ڪيو ويو آهي، پر صرف ان جي وقت جو ڪوٽا. ۽ جڏهن توهان ان کي ختم ڪيو، پروسيسر توهان کان پري ورتو ويندو.
هي ميٽرڪ توهان کي اهڙن لمحن کي ٽريڪ ڪرڻ ۽ فيصلا ڪرڻ جي اجازت ڏئي ٿو. مثال طور، ڇا اهو ضروري آهي ته ٿلهي ٽريف وٺڻ يا پس منظر جي ڪمن جي پروسيسنگ کي ورهائڻ ۽ مختلف سرورن تي API درخواستون؟
IOPS + CPU iowait وقت - ڪجهه سببن لاء، ڪافي IOPS مهيا نه ڪرڻ سان ڪيترائي بادل ميزباني گناهه. ان کان علاوه، گهٽ IOPS سان شيڊول انهن لاء هڪ دليل نه آهي. تنهن ڪري، اهو CPU iowait گڏ ڪرڻ جي قابل آهي. گراف جي ھن جوڙي سان - گھٽ IOPS ۽ اعلي I/O انتظار سان - توھان اڳ ۾ ئي ھوسٽنگ سان ڳالھائي سگھوٿا ۽ مسئلو حل ڪري سگھو ٿا.
آپريٽنگ سسٽم
آپريٽنگ سسٽم جي ماپ:
- % ۾ موجود ياداشت جي مقدار؛
- ادل بدلي استعمال جي سرگرمي: vmstat swapin، swapout؛
- موجود انوڊس جو تعداد ۽ فائل سسٽم تي خالي جاءِ٪ ۾
- سراسري لوڊ؛
- ٻن رياستن ۾ ڪنيڪشن جو تعداد؛
- contrack ٽيبل جي پوريء طرح؛
- نيٽ ورڪ جي معيار کي استعمال ڪندي مانيٽر ڪري سگهجي ٿو ايس ايس يوٽيليٽي، iproute2 پيڪيج - ان جي آئوٽ مان RTT ڪنيڪشن جو هڪ اشارو حاصل ڪريو ۽ ان کي ڊيسٽ پورٽ ذريعي گروپ ڪريو.
پڻ آپريٽنگ سسٽم جي سطح تي اسان وٽ عمل جي طور تي هڪ ادارو آهي. اهو ضروري آهي ته سسٽم ۾ پروسيس جي هڪ سيٽ کي سڃاڻڻ لاء جيڪو ان جي آپريشن ۾ اهم ڪردار ادا ڪري ٿو. جيڪڏهن، مثال طور، توهان وٽ ڪيترائي pgpool آهن، پوء توهان کي انهن مان هر هڪ لاء معلومات گڏ ڪرڻ جي ضرورت آهي.
ميٽرڪ جو سيٽ هن ريت آهي:
- سي پي يو ؛
- ياداشت بنيادي طور تي رهائشي آهي؛
- IO - ترجيحي طور تي IOPS ۾؛
- FileFd - کليل ۽ حد؛
- اهم صفحو ناڪاميون - هن طريقي سان توهان سمجهي سگهو ٿا ته ڪهڙي عمل کي تبديل ڪيو پيو وڃي.
اسان Docker ۾ سڀني نگراني کي ترتيب ڏيو ٿا، ۽ اسان ميٽرڪ ڊيٽا گڏ ڪرڻ لاء صلاحڪار استعمال ڪندا آهيون. ٻين مشينن تي اسان پروسيس-ايڪسپورٽر استعمال ڪندا آهيون.
سسٽم خدمتون، سافٽ ويئر اسٽيڪ
هر ايپليڪيشن کي پنهنجون خاصيتون هونديون آهن، ۽ اهو مشڪل آهي ته ميٽرڪس جي مخصوص سيٽ کي اڪيلو ڪرڻ.
آفاقي سيٽ آهي:
- درخواست جي شرح؛
- غلطين جو تعداد؛
- دير
- saturation
هن سطح تي نگراني جا اسان جا سڀ کان وڌيڪ مثال آهن Nginx ۽ PostgreSQL.
اسان جي سسٽم ۾ سڀ کان وڌيڪ لوڊ ٿيل خدمت ڊيٽابيس آهي. ماضي ۾، اسان کي اڪثر اهو سمجهڻ ۾ مشڪل هئي ته ڊيٽابيس ڇا ڪري رهيو هو.
اسان ڊسڪ تي هڪ وڏو لوڊ ڏٺو، پر سست لاگز حقيقت ۾ ڪجھ به نه ڏيکاريا. اسان هن مسئلي کي pg_stat_statements استعمال ڪندي حل ڪيو، هڪ نظارو جيڪو سوالن جا انگ اکر گڏ ڪري ٿو.
اهو سڀ ڪجهه منتظم جي ضرورت آهي.
اسان درخواستون پڙهڻ ۽ لکڻ جي سرگرمي جا گراف ٺاهيندا آهيون:
هر شي سادي ۽ صاف آهي، هر درخواست جو پنهنجو رنگ آهي.
هڪ جيتري نموني مثال آهي نينگڪس لاگز. اها تعجب جي ڳالهه ناهي ته ٿورا ماڻهو انهن کي پارس ڪن ٿا يا انهن جو ذڪر لازمي فهرست ۾ ڪن ٿا. معياري شڪل تمام معلوماتي نه آهي ۽ وڌائڻ جي ضرورت آهي.
ذاتي طور تي، مون شامل ڪيو request_time, upstream_response_time, body_bytes_sent, request_length, request_id. اسان جوابي وقت ۽ غلطين جو تعداد پلاٽ ڪريون ٿا:
اسان جوابي وقت ۽ غلطين جي تعداد جا گراف ٺاهيندا آهيون. ياد اٿئي؟ ڇا مون ڪاروباري مقصدن بابت ڳالهايو؟ جلدي ۽ بغير غلطين لاء؟ اسان پهريان ئي انهن مسئلن کي ٻن چارٽ سان ڍڪي چڪا آهيون. ۽ توھان انھن کي استعمال ڪندي اڳ ۾ ئي منتظمين کي ڊيوٽي تي سڏي سگھو ٿا.
پر هڪ وڌيڪ مسئلو رهي ٿو - واقعي جي سببن جي تيزيء سان خاتمي کي يقيني بڻائڻ لاء.
حادثو حل
سڃاڻپ کان وٺي مسئلو حل ڪرڻ جي پوري عمل کي ڪيترن ئي مرحلن ۾ ورهائي سگهجي ٿو:
- مسئلي جي سڃاڻپ؛
- ڊيوٽي ايڊمنسٽريٽر کي اطلاع؛
- واقعي جو جواب؛
- سببن جي خاتمي.
اهو ضروري آهي ته اسان کي اهو ڪرڻ گهرجي جيترو جلدي ٿي سگهي. ۽ جيڪڏهن ڪنهن مسئلي جي نشاندهي ڪرڻ ۽ نوٽيفڪيشن موڪلڻ جي مرحلن تي اسان گهڻو وقت نه ٿا حاصل ڪري سگهون - انهن تي ٻه منٽ ڪنهن به صورت ۾ خرچ ڪيا ويندا، پوءِ ايندڙن کي صرف بهتر ڪرڻ لاءِ خالي ميدان آهي.
سوچيم ته ڊيوٽي آفيسر جو فون آيو. هو ڇا ڪندو؟ سوالن جا جواب ڳوليو - ڇا ڀڄي ويو، ڪٿي ڀڄي ويو، ڪيئن رد عمل ڪجي؟ هتي اسان انهن سوالن جا جواب ڪيئن ڏيون ٿا:
اسان صرف اها سموري معلومات نوٽيفڪيشن جي متن ۾ شامل ڪريون ٿا، ان کي وڪي پيج جو لنڪ ڏيو جيڪو بيان ڪري ٿو ته هن مسئلي کي ڪيئن جواب ڏنو وڃي، ان کي ڪيئن حل ڪجي ۽ ان کي اڳتي وڌايو وڃي.
مون اڃا تائين ايپليڪيشن پرت ۽ ڪاروباري منطق بابت ڪجهه نه چيو آهي. بدقسمتي سان، اسان جون ايپليڪيشنون اڃا تائين ميٽرڪ گڏ ڪرڻ تي عمل نه ٿيون ڪن. انهن سطحن مان ڪنهن به معلومات جو واحد ذريعو لاگس آهي.
ڪجهه نقطا.
پهريون، ترتيب ڏنل لاگ لکو. پيغام جي متن ۾ حوالن کي شامل ڪرڻ جي ڪا ضرورت ناهي. اهو انهن کي گروپ ۽ تجزيو ڪرڻ ڏکيو بڻائي ٿو. Logstash اهو سڀ ڪجهه عام ڪرڻ ۾ گهڻو وقت وٺندو آهي.
ٻيو، شدت جي سطح کي صحيح طور تي استعمال ڪريو. هر ٻوليءَ جو پنهنجو معيار آهي. ذاتي طور تي، مان چار سطحن ۾ فرق ڪريان ٿو:
- ڪابه غلطي؛
- ڪلائنٽ پاسي جي غلطي؛
- غلطي اسان جي پاسي آهي، اسان پئسا نه وڃايو، اسان خطرو برداشت نه ڪندا آهيون؛
- غلطي اسان جي پاسي آهي، اسان پئسا وڃائي ڇڏيو.
مون کي اختصار ڪرڻ ڏيو. توهان کي ڪوشش ڪرڻ جي ضرورت آهي مانيٽرنگ جي بنياد تي ڪاروباري منطق جي بنياد تي. ڪوشش ڪريو ايپليڪيشن کي پاڻ مانيٽر ڪريو ۽ اهڙين ميٽرڪس سان هلائڻ جي ڪوشش ڪريو جيئن سيلز جو تعداد، نون استعمال ڪندڙن جي رجسٽريشن جو تعداد، في الحال فعال استعمال ڪندڙن جو تعداد، وغيره.
جيڪڏهن توهان جو سڄو ڪاروبار برائوزر ۾ هڪ بٽڻ آهي، توهان کي نگراني ڪرڻ جي ضرورت آهي ته ڇا اهو ڪلڪ ڪري ٿو ۽ صحيح ڪم ڪري ٿو. باقي سڀ ڪا ڳالهه ناهي.
جيڪڏهن توهان وٽ اهو ناهي، توهان ڪوشش ڪري سگهو ٿا ان سان گڏ ايپليڪيشن لاگز، نينڪس لاگز، ۽ انهي تي، جيئن اسان ڪيو. توهان کي ممڪن طور تي ايپليڪيشن جي ويجهو هجڻ گهرجي.
آپريٽنگ سسٽم ميٽرڪ ضرور اهم آهن، پر ڪاروبار انهن ۾ دلچسپي نه آهي، اسان انهن لاء ادا نه ڪيو ويو آهي.
جو ذريعو: www.habr.com