مانيٽرنگ هڪ خدمت جي طور تي: مائڪرو سروس آرڪيٽيڪچر لاءِ هڪ ماڊلر سسٽم

اڄ، monolithic ڪوڊ جي اضافي ۾، اسان جي پروجيڪٽ ۾ درجن جي microservices شامل آهن. انهن مان هر هڪ جي نگراني ڪرڻ جي ضرورت آهي. DevOps انجنيئرن کي استعمال ڪندي اهڙي پيماني تي ڪرڻ مشڪل آهي. اسان هڪ مانيٽرنگ سسٽم ٺاهيو آهي جيڪو ڊولپرز لاءِ خدمت طور ڪم ڪري ٿو. اهي آزاديءَ سان مانيٽرنگ سسٽم ۾ ميٽرڪس لکي سگهن ٿا، انهن کي استعمال ڪري سگهن ٿا، انهن جي بنياد تي ڊيش بورڊ ٺاهي سگهن ٿا، ۽ انهن سان الارٽ ڳنڍي سگهن ٿا جيڪي تڏهن شروع ڪيا ويندا جڏهن حد جي قيمتن تي پهچي ويندا. DevOps انجنيئرن لاءِ، صرف انفراسٽرڪچر ۽ دستاويز.

هي پوسٽ اسان جي تقرير جو هڪ نقل آهي سيڪشن RIT++ تي. ڪيترن ئي ماڻهن اسان کي اتان رپورٽن جا ٽيڪسٽ ورجن ٺاهڻ لاءِ چيو. جيڪڏهن توهان ڪانفرنس ۾ هئا يا وڊيو ڏٺو، توهان کي ڪا نئين شيء نه ملندي. ۽ ٻيا سڀ - ٻلي ۾ ڀليڪار. مان توهان کي ٻڌايان ٿو ته اسان اهڙي سسٽم ۾ ڪيئن آيا، اهو ڪيئن ڪم ڪري ٿو ۽ اسان ان کي ڪيئن اپڊيٽ ڪرڻ جو منصوبو ٺاهيو.

ماضي: اسڪيمون ۽ منصوبا

اسان موجوده مانيٽرنگ سسٽم تي ڪيئن پهتاسين؟ هن سوال جو جواب ڏيڻ لاء، توهان کي 2015 ڏانهن وڃڻ جي ضرورت آهي. اھو اھو آھي جيڪو پوء نظر آيو:

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

اسان وٽ هڪ ميٽرڪ اسٽوريج آهي: اهي گرافائٽ آهن، جيڪي تيز ايس ايس ڊي ڊرائيو تي ٻڌل هونديون، اهي ميٽرڪس لاء ڪجهه مجموعي آهن. اڳيون - ڊيش بورڊ ڏيکارڻ لاءِ گرافانا ۽ خبردار ڪرڻ لاءِ مورا. اسان پڻ هڪ سسٽم کي ترقي ڪرڻ چاهيون ٿا جيڪو غير معمولي ڳولڻ لاء.

معياري: مانيٽرنگ 2.0

اھو اھو آھي جيڪو منصوبو 2015 ۾ نظر آيو. پر اسان کي نه رڳو بنيادي ڍانچي ۽ سروس پاڻ تيار ڪرڻي ھئي، پر ان لاءِ دستاويز پڻ. اسان پنهنجي لاءِ هڪ ڪارپوريٽ معيار تيار ڪيو آهي، جنهن کي اسين مانيٽرنگ 2.0 چوندا آهيون. سسٽم جون گهرجون ڪهڙيون هيون؟

• مسلسل دستيابي؛
• ميٽرڪ اسٽوريج وقفو = 10 سيڪنڊ؛
• ميٽرڪ ۽ ڊيش بورڊ جي منظم اسٽوريج؛
• SLA > 99,99٪
• UDP (!) ذريعي واقعن جي ماپن جو مجموعو.

اسان کي UDP جي ضرورت هئي ڇو ته اسان وٽ ٽرئفڪ ۽ واقعن جو هڪ وڏو وهڪرو آهي جيڪو ميٽرڪ ٺاهي ٿو. جيڪڏهن توهان انهن سڀني کي هڪ ڀيرو گرافائٽ ۾ لکندا آهيو، اسٽوريج ختم ٿي ويندي. اسان سڀني ميٽرڪس لاءِ پھرين سطح جا اڳوڻا پڻ چونڊيا آھن.

هر هڪ اڳياڙيءَ ۾ ڪجهه ملڪيت هوندي آهي. هتي سرورز، نيٽ ورڪ، ڪنٽينرز، وسيلن، ايپليڪيشنن، وغيره لاء ميٽرڪ آهن. صاف، سخت، ٽائيپ ٿيل فلٽرنگ لاڳو ڪئي وئي آهي، جتي اسان پهرين سطح جي ميٽرڪس کي قبول ڪندا آهيون ۽ باقي ڇڏي ڏيو. اسان 2015 ۾ هن سسٽم کي ڪيئن رٿيو. موجوده ۾ ڇا آهي؟

موجوده: مانيٽرنگ اجزاء جي رابطي جو خاڪو

سڀ کان پهريان، اسان ايپليڪيشنن جي نگراني ڪندا آهيون: اسان جو PHP ڪوڊ، ايپليڪيشنون ۽ مائڪرو سروسز - مختصر ۾، سڀ ڪجهه جيڪي اسان جا ڊولپر لکن ٿا. سڀئي ايپليڪيشنون ميٽرڪس UDP ذريعي Brubeck ايگريگيٽر ڏانهن موڪلين ٿيون (statsd، C ۾ ٻيهر لکيل). اهو مصنوعي تجربن ۾ تيز ترين ثابت ٿيو. ۽ اهو اڳ ۾ ئي گڏ ڪيل ميٽرڪس موڪلي ٿو Graphite ڏانهن TCP ذريعي.

ان ۾ ھڪڙي قسم جي ميٽرڪ آھي جنھن کي ٽائمر سڏيو ويندو آھي. هي هڪ تمام آسان شيء آهي. مثال طور، هر صارف جي خدمت جي ڪنيڪشن لاءِ، توهان Brubeck ڏانهن جوابي وقت سان گڏ هڪ ميٽرڪ موڪليو. هڪ ملين جواب آيا، پر جمع ڪندڙ صرف 10 ميٽرڪ واپس آيو. توھان وٽ ماڻھن جو تعداد آھي جيڪي آيا، وڌ ۾ وڌ، گھٽ ۾ گھٽ ۽ اوسط جوابي وقت، وچين ۽ 4 سيڪڙو. ان کان پوء ڊيٽا کي منتقل ڪيو ويو آهي Graphite ۽ اسان ڏسون ٿا اهو سڀ زندهه.

اسان وٽ هارڊويئر، سافٽ ويئر، سسٽم ميٽرڪس ۽ اسان جي پراڻي منين مانيٽرنگ سسٽم تي ميٽرڪس لاءِ مجموعو پڻ آهي (اهو 2015 تائين اسان لاءِ ڪم ڪيو). اسان هي سڀ سي جي ڪليڪٽ ڊي ڊيمن ذريعي گڏ ڪريون ٿا (ان ۾ مختلف پلگ ان ٺهيل آهن، اهو هوسٽ سسٽم جي سڀني وسيلن کي پول ڪري سگهي ٿو جنهن تي اهو نصب ٿيل آهي، صرف ترتيب ۾ بيان ڪريو جتي ڊيٽا کي لکڻو آهي) ۽ ان جي ذريعي Graphite ڏانهن ڊيٽا لکو. اهو پڻ پٿون پلگ ان ۽ شيل اسڪرپٽ کي سپورٽ ڪري ٿو، تنهنڪري توهان پنهنجو ذاتي حل لکي سگهو ٿا: CollectD هن ڊيٽا کي مقامي يا ريموٽ ميزبان (فرض ڪري Curl) کان گڏ ڪندو ۽ ان کي Graphite ڏانهن موڪليندو.

ان کان پوء اسان سڀني ميٽرڪ موڪليندا آهيون جيڪي اسان گڏ ڪيا هئا ڪاربن-سي-رلي ڏانهن. ھي آھي ڪاربن رلي جو حل Graphite مان، C ۾ تبديل ڪيو ويو آھي. ھي ھڪڙو روٽر آھي جيڪو سڀني ميٽرڪ کي گڏ ڪري ٿو جيڪي اسان پنھنجي ايگريگيٽرز کان موڪليندا آھيون ۽ انھن کي نوڊس ڏانھن موڪليندا آھيون. رستي جي اسٽيج تي پڻ، اهو چيڪ ڪري ٿو ميٽرڪ جي صحيحيت. پهرين، انهن کي لازمي طور تي اڳفڪس اسڪيم سان ملندو آهي جيڪو مون اڳ ۾ ڏيکاريو آهي، ۽ ٻيو، اهي گريفائٽ لاء صحيح آهن. ٻي صورت ۾ اهي ڇڏي ويندا.

ڪاربن-سي-رلي وري ميٽرڪس کي گرافائٽ ڪلستر ڏانهن موڪلي ٿو. اسان ڪاربن ڪيش استعمال ڪريون ٿا، گو ۾ ٻيهر لکيل، ميٽرڪ جي مکيه اسٽوريج طور. گو-ڪاربن، ان جي ملٽي ٿريڊنگ جي ڪري، ڪاربن ڪيش کان تمام گهڻو پري آهي. اهو ڊيٽا وصول ڪري ٿو ۽ ان کي ڊسڪ تي لکندو آهي ويسپر پيڪيج استعمال ڪندي (معياري، پٿون ۾ لکيل). اسان جي اسٽوريج مان ڊيٽا پڙهڻ لاءِ، اسان استعمال ڪريون ٿا Graphite API. اهو معياري Graphite WEB کان گهڻو تيز آهي. ايندڙ ڊيٽا کي ڇا ٿيندو؟

اهي گرافانا ڏانهن ويندا آهن. اسان اسان جي گرافائٽ ڪلسٽرز کي ڊيٽا جي مکيه ماخذ طور استعمال ڪريون ٿا، ان سان گڏ اسان وٽ گرافانا آهي ويب انٽرفيس جي طور تي ميٽرڪس ڏيکارڻ ۽ ڊيش بورڊ ٺاهڻ لاءِ. انهن جي هر هڪ خدمتن لاءِ، ڊولپر پنهنجو پنهنجو ڊيش بورڊ ٺاهي. پوءِ اھي انھن جي بنياد تي گراف ٺاھيندا آھن، جيڪي ميٽرڪ ڏيکاريندا آھن اھي پنھنجي ايپليڪيشنن مان لکندا آھن. گرافانا کان علاوه، اسان وٽ پڻ SLAM آهي. هي هڪ پٿون شيطان آهي جيڪو گريفائٽ جي ڊيٽا جي بنياد تي SLA حساب ڪري ٿو. جيئن مون اڳ ۾ ئي چيو آهي، اسان وٽ ڪيترائي درجن مائڪرو سروسز آهن، جن مان هر هڪ جون پنهنجون گهرجون آهن. SLAM کي استعمال ڪندي، اسان دستاويزن ڏانهن وڃون ٿا ۽ ان جو مقابلو ڪريون ٿا جيڪو گرافائٽ ۾ آهي ۽ موازنہ ڪريون ٿا ته اسان جي خدمتن جي دستيابي سان ڪيتري حد تائين گهربل ضرورتون ملن ٿيون.

اچو ته اڳتي وڌو: خبردار ڪرڻ. اهو هڪ مضبوط سسٽم استعمال ڪندي منظم ڪيو ويو آهي - Moira. اهو آزاد آهي ڇو ته ان جي پنهنجي گريفائٽ آهي هود هيٺ. SKB "Kontur" جي ماڻھن پاران ٺاھيو ويو، پٿون ۽ گو ۾ لکيل آھي، مڪمل طور تي کليل ذريعو. Moira ساڳيو وهڪري حاصل ڪري ٿو جيڪو گرافائٽس ۾ وڃي ٿو. جيڪڏهن ڪنهن سبب جي ڪري توهان جي اسٽوريج مري وڃي ٿي، توهان جي خبرداري اڃا به ڪم ڪندي.

اسان ڪبرنيٽس ۾ Moira کي مقرر ڪيو؛ اهو استعمال ڪري ٿو ريڊيس سرورز جو ڪلستر بنيادي ڊيٽابيس طور. نتيجو هڪ غلطي برداشت ڪرڻ وارو نظام هو. اهو ميٽرڪ جي وهڪري کي ٽارگيٽ جي فهرست سان موازنہ ڪري ٿو: جيڪڏهن ان ۾ ڪو به ذڪر نه آهي، پوء اهو ميٽرڪ کي ڇڏي ٿو. تنهنڪري اهو گيگا بائيٽ ميٽرڪ في منٽ هضم ڪرڻ جي قابل آهي.

اسان ان سان هڪ ڪارپوريٽ LDAP پڻ ڳنڍيو آهي، جنهن جي مدد سان ڪارپوريٽ سسٽم جو هر استعمال ڪندڙ موجوده (يا نئين ٺاهيل) ٽرگرن جي بنياد تي پاڻ لاءِ نوٽيفڪيشن ٺاهي سگهي ٿو. جيئن ته Moira Graphite تي مشتمل آهي، اهو ان جي سڀني خاصيتن کي سپورٽ ڪري ٿو. تنهن ڪري توهان پهرين لائن وٺو ۽ ان کي گرافانا ۾ نقل ڪريو. ڏسو ته ڊيٽا ڪيئن ڏيکاريل آهي گرافس تي. ۽ پوء توهان ساڳي لائن وٺو ۽ ان کي نقل ڪريو Moira ۾. توھان ان کي حدن سان پھانسو ۽ ٻاھرين تي خبرداري حاصل ڪريو. هي سڀ ڪرڻ لاء، توهان کي ڪنهن خاص علم جي ضرورت ناهي. Moira ايس ايم ايس، اي ميل، جيرا، سست ذريعي خبردار ڪري سگهي ٿو ... اهو پڻ ڪسٽم اسڪرپٽ جي عمل جي حمايت ڪري ٿو. جڏهن هڪ ٽرگر هن سان ٿئي ٿو، ۽ هوء هڪ ڪسٽم اسڪرپٽ يا بائنري جي رڪنيت حاصل ڪئي وئي آهي، هوء ان کي هلائي ٿي ۽ JSON موڪلي ٿي stdin ڏانهن هن بائنري لاء. انهي جي مطابق، توهان جو پروگرام ان کي پارس ڪرڻ گهرجي. توهان هن JSON سان ڇا ڪندا آهيو توهان تي منحصر آهي. جيڪڏھن توھان چاھيو، ان کي ٽيليگرام ڏانھن موڪليو، جيڪڏھن توھان چاھيو، جيرا ۾ ڪم کوليو، جيڪو ڪجھ ڪريو.

اسان پڻ اسان جي پنهنجي ترقي کي خبردار ڪرڻ لاء استعمال ڪندا آهيون - Imagotag. اسان پينل کي ترتيب ڏنو، جيڪو عام طور تي اسٽورن ۾ اليڪٽرانڪ قيمت ٽيگ لاءِ استعمال ڪيو ويندو آهي، اسان جي ضرورتن مطابق. اسان ان لاءِ موئرا مان ٽريگرز کڻي آيا آهيون. اهو ظاهر ڪري ٿو ته اهي ڪهڙي حالت ۾ آهن ۽ جڏهن اهي واقع ٿيا. ڪجهه ترقي پسند ماڻهن هن پينل جي حق ۾ Slack ۽ اي ميل ۾ اطلاعن کي ڇڏي ڏنو.

خير، جيئن ته اسان هڪ ترقي پسند ڪمپني آهيون، اسان پڻ هن سسٽم ۾ ڪبرنيٽس جي نگراني ڪئي. اسان ان کي سسٽم ۾ Heapster استعمال ڪندي شامل ڪيو، جيڪو اسان ڪلستر ۾ نصب ڪيو، اهو ڊيٽا گڏ ڪري ٿو ۽ ان کي Graphite ڏانهن موڪلي ٿو. نتيجي طور، خاڪو هن طرح نظر اچي ٿو:

مانيٽرنگ اجزاء

هتي انهن حصن جي لنڪ جي هڪ فهرست آهي جيڪي اسان هن ڪم لاءِ استعمال ڪيا آهن. اهي سڀئي کليل ذريعو آهن.

گرافائٽ:

• ڪاربان: github.com/lomik/go-carbon
• سرگوشي: github.com/graphite-project/whisper
• graphite-api: github.com/brutasse/graphite-api

ڪاربن-سي-رلي:

github.com/grobian/carbon-c-relay

بربڪ:

github.com/github/brubeck

گڏ ڪيل:

collected.org

ميرا:

github.com/moira-alert

گرافانا:

grafana.com

هيپسٽر:

github.com/kubernetes/heapster

انگ

۽ هتي ڪجهه انگ آهن ته ڪيئن سسٽم اسان لاء ڪم ڪري ٿو.

جمع ڪندڙ (بربڪ)

ميٽرڪ جو تعداد: ~300/sec
Graphite ڏانهن ميٽرڪ موڪلڻ لاء وقفو: 30 سيڪنڊ
سرور وسيلن جو استعمال: ~ 6٪ سي پي يو (اسان مڪمل سرور بابت ڳالهائي رهيا آهيون)؛ ~ 1 جي بي ريم؛ ~3 Mbps LAN

گريفائٽ (گو ڪاربان)

ميٽرڪ جو تعداد: ~ 1 / منٽ
ميٽرڪ اپڊيٽ جو وقفو: 30 سيڪنڊ
ميٽرڪ اسٽوريج اسڪيم: 30sec 35d، 5min 90d، 10min 365d (توهان کي اها سمجھ ڏئي ٿي ته خدمت جي ڊگهي عرصي دوران ڇا ٿئي ٿو)
سرور وسيلن جو استعمال: ~ 10٪ CPU؛ ~ 20 جي بي ريم؛ ~30 Mbps LAN

سکيائي

اسان Avito تي واقعي اسان جي مانيٽرنگ سروس ۾ لچڪ جو قدر ڪريون ٿا. هو اصل ۾ ائين ڇو نڪتو؟ پهرين، ان جا حصا مٽائي سگهجن ٿا: ٻئي اجزاء پاڻ ۽ انهن جا نسخا. ٻيو، حمايت. جيئن ته سڄو پروجيڪٽ اوپن سورس آهي، ان ڪري توهان ڪوڊ پاڻ ايڊٽ ڪري سگهو ٿا، تبديليون ڪري سگهو ٿا، ۽ انهن ڪمن کي لاڳو ڪري سگهو ٿا جيڪي دٻي کان ٻاهر موجود نه آهن. ڪافي عام اسٽيڪ استعمال ڪيا ويا آهن، خاص طور تي Go ۽ Python، تنهنڪري اهو بلڪل سادو ڪيو ويندو آهي.

هتي هڪ حقيقي مسئلو جو هڪ مثال آهي. گرافائٽ ۾ هڪ ميٽرڪ هڪ فائل آهي. ان جو نالو آهي. فائل جو نالو = ميٽرڪ نالو. ۽ اتي حاصل ڪرڻ جو هڪ طريقو آهي. لينڪس ۾ فائل جا نالا 255 اکرن تائين محدود آهن. ۽ اسان وٽ آهي (جيئن ”اندروني گراهڪ“) ماڻهو ڊيٽابيس ڊپارٽمينٽ مان. اهي اسان کي ٻڌائين ٿا: "اسان چاهيون ٿا اسان جي SQL سوالن جي نگراني ڪرڻ. ۽ اهي 255 اکر نه آهن، پر 8 MB هر هڪ. اسان انهن کي گرافانا ۾ ڏيکارڻ چاهيون ٿا، هن درخواست لاءِ پيرا ميٽرز ڏسو، ۽ اڃا به بهتر، اسان چاهيون ٿا ته اهڙين درخواستن جي مٿئين حصي کي. اهو عظيم ٿيندو جيڪڏهن اهو حقيقي وقت ۾ ڏيکاريل آهي. انهن کي خبرداريءَ ۾ رکڻ واقعي تمام سٺو هوندو.

SQL سوال جو مثال مثال طور ورتو ويو آھي مان سائيٽ postgrespro.ru

اسان هڪ Redis سرور قائم ڪيو ۽ اسان جي گڏ ڪيل پلگ ان کي استعمال ڪيو، جيڪو پوسٽ گريس ڏانهن وڃو ۽ اتان کان سمورو ڊيٽا وٺي، ميٽرڪ کي گرافائٽ ڏانهن موڪليندا آهيون. پر اسان ميٽرڪ جو نالو هٽس سان تبديل ڪريون ٿا. اسان هڪ ئي وقت ساڳيو هيش موڪليندا آهيون ريڊس کي ڪيجي طور، ۽ پوري SQL سوال هڪ قدر جي طور تي. اسان سڀني کي اهو ڪرڻو آهي ته اهو پڪ ڪرڻ گهرجي ته گرافانا ريڊس ڏانهن وڃو ۽ هي معلومات وٺي. اسان Graphite API کولي رهيا آهيون ڇاڪاڻ ته ... هي گرافائٽ سان سڀني مانيٽرنگ اجزاء جي رابطي لاءِ بنيادي انٽرفيس آهي، ۽ اسان اتي هڪ نئون فنڪشن داخل ڪريون ٿا جنهن کي aliasByHash() سڏيو ويندو آهي - Grafana مان اسان کي ميٽرڪ جو نالو ملي ٿو، ۽ ان کي ريڊيس کي ڪيئي جي طور تي درخواست ۾ استعمال ڪريو. جواب ۾ اسان کي چيڪ جي قيمت ملي ٿي، جيڪا اسان جي "SQL سوال" آهي اهڙيء طرح، اسان گرافانا ۾ هڪ SQL سوال جو هڪ ڊسپلي ڏيکاريو، جنهن کي نظريي ۾ ظاهر ڪرڻ ناممڪن هو، ان تي انگن اکرن سان گڏ (ڪال، قطار، کل_وقت، ...).

نتيجو

دستياب اسان جي نگراني سروس موجود آهي 24/7 ڪنهن به ايپليڪيشن ۽ ڪنهن به ڪوڊ کان. جيڪڏهن توهان وٽ اسٽوريج سهولتن تائين رسائي آهي، توهان خدمت ڏانهن ڊيٽا لکي سگهو ٿا. ٻولي اهم ناهي، فيصلا اهم ناهن. توهان کي صرف ڄاڻڻ جي ضرورت آهي ته هڪ ساکٽ ڪيئن کوليو، اتي هڪ ميٽرڪ رکي ۽ ساکٽ کي بند ڪريو.

اعتبار سڀئي حصا غلطي برداشت ڪندڙ آهن ۽ اسان جي لوڊ کي چڱي طرح سنڀاليندا آهن.

داخل ٿيڻ ۾ گھٽ رڪاوٽ. ھن سسٽم کي استعمال ڪرڻ لاء، توھان کي سکڻ جي ضرورت نه آھي پروگرامنگ ٻوليون ۽ سوال Grafana ۾. بس پنهنجي اپليڪيشن کي کوليو، ان ۾ هڪ ساکٽ داخل ڪريو جيڪو ميٽرڪس کي Graphite ڏانهن موڪليندو، ان کي بند ڪري، Grafana کوليو، اتي ڊيش بورڊ ٺاهيو ۽ توهان جي ميٽرڪس جي رويي کي ڏسو، Moira ذريعي اطلاعن حاصل ڪرڻ.

آزادي. توهان اهو سڀ پاڻ ڪري سگهو ٿا، بغير DevOps انجنيئرن جي مدد کان. ۽ اهو هڪ فائدو آهي، ڇاڪاڻ ته توهان هن وقت پنهنجي پروجيڪٽ جي نگراني ڪري سگهو ٿا، توهان کي ڪنهن کان پڇڻ جي ضرورت ناهي - يا ته ڪم شروع ڪرڻ يا تبديليون ڪرڻ لاء.

اسان جو مقصد ڇا آهي؟

هيٺ ڏنل فهرستن ۾ سڀ ڪجهه نه رڳو تجريدي سوچون آهن، پر ڪجهه جنهن ڏانهن گهٽ ۾ گهٽ پهريون قدم کنيا ويا آهن.

1. انمولي ڊيڪٽر. اسان هڪ خدمت ٺاهڻ چاهيون ٿا جيڪو اسان جي گرافائٽ اسٽوريج ڏانهن وڃو ۽ هر ميٽرڪ کي مختلف الگورتھم استعمال ڪندي چيڪ ڪريو. اتي اڳ ۾ ئي الگورتھم آھن جيڪي اسان ڏسڻ چاھيون ٿا، ڊيٽا آھي، اسان ڄاڻون ٿا ته ان سان ڪيئن ڪم ڪجي.
2. ميٽاداٽا. اسان وٽ ڪيتريون ئي خدمتون آهن، اهي وقت سان گڏ تبديل ٿيندا آهن، جيئن اهي ماڻهو جيڪي انهن سان گڏ ڪم ڪن ٿا. دستي طور تي دستاويز کي مسلسل برقرار رکڻ هڪ اختيار ناهي. ان ڪري اسان ھاڻي ميٽاڊيٽا کي پنھنجي مائڪرو سروسز ۾ شامل ڪري رھيا آھيون. اهو ٻڌائي ٿو ته ڪنهن ان کي ترقي ڪئي، ٻوليون جيڪي ان سان رابطو ڪن ٿيون، SLA گهرجون، ڪٿي ۽ جن کي اطلاع موڪليا وڃن. جڏهن خدمت کي ترتيب ڏيڻ، سڀ ادارو ڊيٽا آزاد طور تي ٺاهي وئي آهي. نتيجي طور، توھان کي ٻه لنڪ ملن ٿا - ھڪڙو ٽريگرز ڏانھن، ٻيو Grafana ۾ ڊيش بورڊ ڏانھن.
3. هر گهر ۾ نگراني. اسان يقين رکون ٿا ته سڀني ڊولپرز کي اهڙي سسٽم کي استعمال ڪرڻ گهرجي. انهي حالت ۾، توهان هميشه سمجهي رهيا آهيو ته توهان جي ٽرئفڪ ڪٿي آهي، ان کي ڇا ٿئي ٿو، اهو ڪٿي پوي ٿو، جتي هن جون ڪمزوريون آهن. جيڪڏهن، مثال طور، ڪا شيء اچي ٿي ۽ توهان جي خدمت کي تباهه ڪري، پوء توهان ان جي باري ۾ سکندا سين نه مئنيجر جي ڪال دوران، پر هڪ خبرداري کان، ۽ توهان فوري طور تي تازو لاگز کوليو ۽ ڏسو ته اتي ڇا ٿيو.
4. اعليٰ ڪارڪردگي. اسان جو منصوبو مسلسل وڌي رهيو آهي، ۽ اڄ اهو پروسيس ڪري ٿو اٽڪل 2 ميٽرڪ ويلز في منٽ. هڪ سال اڳ، اهو انگ 000 هو. ۽ واڌارو جاري آهي، ۽ ان جو مطلب اهو آهي ته ڪجهه وقت کان پوء گرافائٽ (وسوس) ڊسڪ جي سب سسٽم کي تمام گهڻو لوڊ ڪرڻ شروع ڪندو. جيئن ته مون اڳ ۾ ئي چيو آهي، هي مانيٽرنگ سسٽم ڪافي آفاقي آهي ڇاڪاڻ ته اجزاء جي مٽاسٽا جي ڪري. ڪو ماڻهو برقرار رکي ٿو ۽ مسلسل پنهنجي انفراسٽرڪچر کي خاص طور تي Graphite لاءِ وڌائي ٿو، پر اسان فيصلو ڪيو ته مختلف رستو اختيار ڪيو وڃي: استعمال ڪلڪ ڪريو هائوس اسان جي ميٽرڪ لاء هڪ مخزن جي طور تي. هي منتقلي تقريبن مڪمل ٿي چڪي آهي، ۽ تمام جلد آئون توهان کي وڌيڪ تفصيل سان ٻڌايان ٿو ته اهو ڪيئن ڪيو ويو: اتي ڪهڙيون مشڪلاتون هيون ۽ انهن کي ڪيئن قابو ڪيو ويو، لڏپلاڻ وارو عمل ڪيئن ٿيو، آئون انهن حصن کي بيان ڪندس جن کي بائنڊنگ طور چونڊيو ويو آهي ۽ انهن جي ترتيب.

توهان جي توجه لاء مهرباني! موضوع تي پنهنجا سوال پڇو، آئون هتي يا هيٺين پوسٽن ۾ جواب ڏيڻ جي ڪوشش ڪندس. ٿي سگهي ٿو ڪنهن کي تجربو آهي هڪ جهڙو مانيٽرنگ سسٽم تعمير ڪرڻ يا ساڳئي صورتحال ۾ ڪلڪ هاؤس ڏانهن سوئچ ڪرڻ - ان کي تبصرن ۾ حصيداري ڪريو.

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