ٻيو نگراني نظام

16 موڊيمس، 4 سيلولر آپريٽر = ٻاھر وڃڻ جي رفتار 933.45 Mbit/s

تعارف

سلام! هي آرٽيڪل انهي بابت آهي ته اسان پنهنجي لاءِ هڪ نئون مانيٽرنگ سسٽم ڪيئن لکيو. اهو موجوده ماڻهن کان مختلف آهي ان جي اعلي تعدد هم وقت سازي ميٽرڪس ۽ تمام گهٽ وسيلن جي واپرائڻ جي صلاحيت ۾. پولنگ جي شرح 0.1 نانو سيڪنڊن جي ميٽرڪس جي وچ ۾ هم وقت سازي جي درستگي سان 10 مليسيڪنڊ تائين پهچي سگھي ٿي. سڀ بائنري فائلون 6 ميگا بائيٽ تي قبضو ڪن ٿيون.

منصوبي بابت

اسان وٽ ھڪڙو خاص پراڊڪٽ آھي. اسان ڊيٽا ٽرانسميشن چينلز جي ذريعي ۽ غلطي رواداري کي اختصار ڪرڻ لاءِ هڪ جامع حل پيدا ڪندا آهيون. هي آهي جڏهن ڪيترائي چينل آهن، اچو ته چئو Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ ٻيو ڪجهه (5 Mbit/s)، نتيجو هڪ مستحڪم ۽ تيز چينل آهي، جنهن جي رفتار ڪجهه اهڙي هوندي. هي: (40+30+5)x0.92=75×0.92=69 Mbit/s.

اهڙا حل طلب ۾ آهن جتي ڪنهن هڪ چينل جي گنجائش ڪافي نه آهي. مثال طور، ٽرانسپورٽ، ويڊيو نگراني سسٽم ۽ حقيقي وقت جي وڊيو اسٽريمنگ، لائيو ٽيليويزن ۽ ريڊيو جي نشريات جي نشريات، ڪنهن به مضافاتي سهولتون جتي ٽيليڪ آپريٽرز جي وچ ۾ صرف بگ فور جا نمائندا آهن ۽ هڪ موڊيم / چينل تي رفتار ڪافي ناهي. .
انهن علائقن مان هر هڪ لاء، اسان ڊوائيسز جي هڪ الڳ لائين ٺاهيندا آهيون، پر انهن جو سافٽ ويئر حصو تقريبا ساڳيو آهي ۽ هڪ اعلي معيار جي نگراني سسٽم ان جي مکيه ماڊل مان هڪ آهي، جنهن جي صحيح عمل ڪرڻ کان سواء پيداوار ممڪن نه هوندي.

ڪيترن سالن جي دوران، اسان هڪ گھڻ-سطح، تيز، ڪراس پليٽ فارم ۽ هلڪو وزن مانيٽرنگ سسٽم ٺاهڻ ۾ ڪامياب ٿي ويا آهيون. اھو اھو آھي جيڪو اسان پنھنجي معزز ڪميونٽي سان حصيداري ڪرڻ چاھيو ٿا.

مسئلو جي ترتيب

مانيٽرنگ سسٽم ٻن بنيادي طور تي مختلف طبقن جا ميٽرڪ مهيا ڪري ٿو: حقيقي وقت جي ميٽرڪ ۽ ٻيا سڀ. مانيٽرنگ سسٽم کي صرف هيٺين گهرج هئي:

1. حقيقي وقت جي ميٽرڪس جي اعلي تعدد هم وقت سازي حاصل ڪرڻ ۽ انهن جي منتقلي کي ڪميونيڪيشن مينيجمينٽ سسٽم کان بغير دير جي.
   مختلف ميٽرڪ جي اعلي تعدد ۽ هم وقت سازي صرف اهم ناهي، اهو ڊيٽا ٽرانسميشن چينلز جي اينٽراپي جي تجزيو لاء ضروري آهي. جيڪڏهن هڪ ڊيٽا ٽرانسميشن چينل ۾ سراسري دير 30 مليسيڪنڊ آهي، ته پوءِ صرف هڪ مليسيڪنڊ جي باقي ميٽرڪ جي وچ ۾ هم وقت سازي ۾ هڪ غلطي نتيجي واري چينل جي رفتار کي تقريباً 5 سيڪڙو گهٽائي ڇڏيندو. جيڪڏهن اسان 1 چينلن ۾ 4 مليسيڪنڊ جي وقت کي غلط ڪريون ٿا، رفتار جي تباهي آساني سان 30٪ تائين گهٽجي سگهي ٿي. ان کان علاوه، چينلن ۾ اينٽراپي تمام جلدي تبديل ٿي ويندي آهي، تنهنڪري جيڪڏهن اسان ان کي هر 0.5 ملي سيڪنڊن ۾ هڪ ڀيرو کان گهٽ ماپ ڪريون ٿا، تيز چينلن تي ٿوري دير سان اسان کي تيز رفتار جي خرابي حاصل ٿيندي. يقينا، اهڙي درستگي جي ضرورت ناهي سڀني ميٽرڪ لاء ۽ نه سڀني حالتن ۾. جڏهن چينل ۾ دير 500 مليسيڪنڊ آهي، ۽ اسان ان سان گڏ ڪم ڪريون ٿا، پوء 1 مليسيڪنڊ جي غلطي تقريبن قابل ذڪر نه هوندي. انهي سان گڏ، لائف سپورٽ سسٽم ميٽرڪس لاءِ، اسان وٽ ڪافي پولنگ ۽ هم وقت سازي جي شرح 2 سيڪنڊن جي آهي، پر مانيٽرنگ سسٽم پاڻ کي الٽرا هاءِ پولنگ جي شرحن ۽ ميٽرڪس جي الٽرا پرائيز سنڪرونائيزيشن سان ڪم ڪرڻ جي قابل هوندو.
2. گھٽ ۾ گھٽ وسيلن جو استعمال ۽ ھڪڙو اسٽيڪ.
   آخري ڊوائيس يا ته هڪ طاقتور آن بورڊ ڪمپليڪس ٿي سگهي ٿو جيڪو روڊ تي صورتحال جو تجزيو ڪري سگهي ٿو يا ماڻهن جي بائيو ميٽرڪ رڪارڊنگ ڪري سگهي ٿو، يا هڪ کجيءَ جي سائيز جو سنگل بورڊ ڪمپيوٽر جنهن کي اسپيشل فورسز جو سپاهي پنهنجي جسم جي آرمر هيٺان پائيندو آهي وڊيو منتقل ڪرڻ لاءِ. غريب مواصلاتي حالتن ۾ حقيقي وقت. اهڙي قسم جي فن تعمير ۽ ڪمپيوٽنگ پاور جي باوجود، اسان چاهيون ٿا ته هڪ ئي سافٽ ويئر اسٽيڪ هجي.
3. ڇت وارو فن تعمير
   ميٽرڪس کي گڏ ڪيو وڃي ۽ آخري ڊوائيس تي گڏ ڪيو وڃي، مقامي طور تي ذخيرو ٿيل، ۽ حقيقي وقت ۽ ماضي ۾ ڏسڻ ۾ اچي. جيڪڏهن ڪو ڪنيڪشن آهي، ڊيٽا کي مرڪزي مانيٽرنگ سسٽم ڏانهن منتقل ڪريو. جڏهن ڪو ڪنيڪشن نه آهي، موڪلڻ واري قطار کي گڏ ڪرڻ گهرجي ۽ رام استعمال نه ڪرڻ گهرجي.
4. صارف جي نگراني واري نظام ۾ انضمام لاءِ API، ڇاڪاڻ ته ڪنهن کي به گهڻن مانيٽرنگ سسٽم جي ضرورت ناهي. ڪسٽمر کي ڪنهن به ڊوائيس ۽ نيٽ ورڪ مان ڊيٽا گڏ ڪرڻ گهرجي هڪ واحد نگراني ۾.

ڇا ٿيو

ان لاءِ ته اڳ ۾ ئي متاثر ٿيندڙ لانگ ريڊ تي بار نه وجهڻ لاءِ، مان سڀني مانيٽرنگ سسٽم جا مثال ۽ ماپون نه ڏيندس. اهو هڪ ٻئي مضمون ڏانهن وٺي ويندو. مان صرف ايترو چوندس ته اسان هڪ مانيٽرنگ سسٽم ڳولڻ جي قابل نه هئاسين جيڪو 1 مليسيڪنڊ کان گهٽ جي غلطي سان گڏ ٻه ميٽرڪ گڏ ڪرڻ جي قابل آهي ۽ اهو ڪم ڪري ٿو هڪجهڙائي سان ٻنهي ARM آرڪيٽيڪچر تي 64 MB ريم سان ۽ x86_64 آرڪيٽيڪچر تي 32 سان. GB جي رام. تنهن ڪري، اسان پنهنجو پاڻ لکڻ جو فيصلو ڪيو، جيڪو اهو سڀ ڪجهه ڪري سگهي ٿو. هتي اسان کي ڇا مليو آهي:

مختلف نيٽ ورڪ ٽوپولوجيز لاءِ ٽن چينلن جي ذريعي اختصار ڪرڻ

ڪجهه اهم ميٽرڪس جي تصور

تعمير

اسان گولنگ کي مکيه پروگرامنگ ٻولي طور استعمال ڪريون ٿا، ٻئي ڊوائيس تي ۽ ڊيٽا سينٽر ۾. اهو زندگي کي تمام گهڻو آسان بڻائي ٿو ان جي عمل درآمد سان ملٽي ٽاسڪنگ ۽ هر خدمت لاءِ هڪ مستحڪم طور تي ڳنڍيل ايگزيڪيوٽو بائنري فائل حاصل ڪرڻ جي صلاحيت. نتيجي طور، اسان وسيلن، طريقن ۽ ٽرئفڪ ۾ خاص طور تي محفوظ ڪريون ٿا سروس کي ختم ڪرڻ لاءِ ڊيوائسز، ڊولپمينٽ ٽائيم ۽ ڪوڊ ڊيبگنگ لاءِ.

سسٽم کي کلاسي ماڊلر اصول جي مطابق لاڳو ڪيو ويو آهي ۽ ڪيترن ئي سب سسٽم تي مشتمل آهي:

1. ميٽرڪ رجسٽريشن.
   هر ميٽرڪ ان جي پنهنجي سلسلي سان خدمت ڪئي وئي آهي ۽ چينلن تي هم وقت سازي ڪئي وئي آهي. اسان 10 نانو سيڪنڊن تائين هم وقت سازي جي درستگي حاصل ڪرڻ جي قابل ٿي ويا.
2. ميٽرڪ اسٽوريج
   اسان وقت جي سيريز لاءِ اسان جي پنهنجي اسٽوريج لکڻ جي وچ ۾ چونڊ ڪري رهيا هئاسين يا ڪجهه استعمال ڪندي جيڪو اڳ ۾ ئي موجود هو. ڊيٽابيس جي ضرورت آهي ماضيءَ واري ڊيٽا لاءِ جيڪو بعد ۾ ڏسڻ سان مشروط آهي. يعني ان ۾ چينل جي دير هر 0.5 ملي سيڪنڊن تي ڊيٽا شامل نه آهي يا ٽرانسپورٽ نيٽ ورڪ ۾ غلطي پڙهڻ تي، پر هر انٽرفيس تي هر 500 ملي سيڪنڊن جي رفتار هوندي آهي. ڪراس پليٽ فارم ۽ گهٽ وسيلن جي واپرائڻ جي اعلي ضرورتن کان علاوه، اسان لاء پروسيس ڪرڻ جي قابل ٿيڻ تمام ضروري آهي. ڊيٽا جتي ذخيرو ٿيل آهي. هي وڏي ڪمپيوٽنگ وسيلن کي بچائيندو آهي. اسان 2016 کان وٺي هن پروجيڪٽ ۾ Tarantool DBMS استعمال ڪري رهيا آهيون ۽ اڃا تائين اسان کي افق تي ان لاءِ متبادل نظر نٿو اچي. لچڪدار، بهترين وسيلن جي استعمال سان، مناسب ٽيڪنيڪل سپورٽ کان وڌيڪ. Tarantool هڪ GIS ماڊل پڻ لاڳو ڪري ٿو. يقينن، اهو ايترو طاقتور ناهي جيترو پوسٽ جي آءِ ايس، پر اهو ڪافي آهي اسان جي ڪمن لاءِ ڪجهه هنڌن سان لاڳاپيل ميٽرڪس (ٽرانسپورٽ لاءِ لاڳاپيل).
3. ميٽرڪ جي تصور
   هتي هر شي نسبتا سادو آهي. اسان گودام مان ڊيٽا وٺون ٿا ۽ ان کي ڏيکاريون ٿا يا ته حقيقي وقت ۾ يا اڳڀرائي سان.
4. مرڪزي نگراني نظام سان ڊيٽا جي هم وقت سازي.
   مرڪزي مانيٽرنگ سسٽم سڀني ڊوائيسن مان ڊيٽا وصول ڪري ٿو، ان کي مخصوص تاريخ سان محفوظ ڪري ٿو ۽ ان کي API ذريعي ڪسٽمر جي نگراني واري نظام ڏانهن موڪلي ٿو. کلاسک مانيٽرنگ سسٽم جي برعڪس، جنهن ۾ "سر" گھمندو آهي ۽ ڊيٽا گڏ ڪري ٿو، اسان وٽ سامهون اسڪيم آهي. ڊوائيس پاڻ ڊيٽا موڪليندا آهن جڏهن ڪو ڪنيڪشن هوندو آهي. هي هڪ تمام اهم نقطو آهي، ڇاڪاڻ ته اهو توهان کي ڊوائيس مان ڊيٽا حاصل ڪرڻ جي اجازت ڏئي ٿو انهن وقتن جي دوران جنهن دوران اهو دستياب نه هو ۽ چينل ۽ وسيلن کي لوڊ نه ڪيو جڏهن ڊوائيس دستياب ناهي. اسان استعمال ڪندا آهيون Influx مانيٽرنگ سرور هڪ مرڪزي مانيٽرنگ سسٽم طور. ان جي analogues جي برعڪس، اهو ريٽروسپيڪٽو ڊيٽا درآمد ڪري سگهي ٿو (يعني هڪ ٽائم اسٽمپ سان مختلف لمحن جي ڀيٽ ۾ ميٽرڪس وصول ڪيو ويو آهي) گڏ ڪيل ميٽرڪس گرافانا طرفان تصور ڪيا ويا آهن، فائل سان تبديل ٿيل. هي معياري اسٽيڪ پڻ چونڊيو ويو آهي ڇاڪاڻ ته ان ۾ تيار ڪيل API انضمام آهي تقريبن ڪنهن به گراهڪ مانيٽرنگ سسٽم سان.
5. مرڪزي ڊوائيس مينيجمينٽ سسٽم سان ڊيٽا هم وقت سازي.
   ڊيوائس مئنيجمينٽ سسٽم لاڳو ڪري ٿو زيرو ٽچ پروويزننگ (اپڊيٽ ڪرڻ فرم ویئر، ڪنفيگريشن، وغيره) ۽، مانيٽرنگ سسٽم جي برعڪس، في ڊيوائس صرف مسئلا وصول ڪري ٿي. اهي محرڪ آهن آن بورڊ هارڊويئر واچ ڊاگ سروسز جي آپريشن ۽ لائف سپورٽ سسٽم جي سڀني ميٽرڪس: سي پي يو ۽ ايس ايس ڊي جي درجه حرارت، سي پي يو لوڊ، خالي جاءِ ۽ ڊسڪ تي سمارٽ صحت. ذيلي سسٽم اسٽوريج پڻ Tarantool تي ٺهيل آهي. ھي اسان کي ھزارين ڊوائيسز تي وقت جي سيريز کي گڏ ڪرڻ ۾ اھم رفتار ڏئي ٿو، ۽ انھن ڊوائيسز سان ڊيٽا کي هم وقت سازي ڪرڻ جي مسئلي کي مڪمل طور تي حل ڪري ٿو. Tarantool ۾ هڪ بهترين قطار ۽ ضمانت واري ترسيل نظام آهي. اسان هن اهم خصوصيت کي دٻي مان ڪڍي ڇڏيو، عظيم!

نيٽ ورڪ مينيجمينٽ سسٽم

ايندڙ ڇا آهي

هينئر تائين، اسان جي ڪمزور ڪڙي مرڪزي نگراني نظام آهي. اهو لاڳو ڪيو ويو آهي 99.9٪ هڪ معياري اسٽيڪ تي ۽ ان ۾ ڪيترائي نقصان آهن:

1. InfluxDB ڊيٽا وڃائي ٿو جڏهن پاور گم ٿي وڃي ٿي. ضابطي جي طور تي، ڪسٽمر فوري طور تي هر شيء کي گڏ ڪري ٿو جيڪو ڊوائيس مان اچي ٿو ۽ ڊيٽابيس پاڻ ۾ 5 منٽن کان پراڻي ڊيٽا تي مشتمل ناهي، پر مستقبل ۾ اهو درد بڻجي سگهي ٿو.
2. گرافانا کي ڊيٽا گڏ ڪرڻ ۽ ان جي ڊسپلي جي هم وقت سازي سان ڪيترائي مسئلا آهن. سڀ کان عام مسئلو اهو آهي جڏهن ڊيٽابيس ۾ 2 سيڪنڊن جي وقفي سان هڪ ٽائيم سيريز شامل آهي، چئو، 00:00:00 کان شروع ٿئي ٿو، ۽ گرافانا +1 سيڪنڊ کان مجموعي طور تي ڊيٽا ڏيکارڻ شروع ڪري ٿو. نتيجي طور، صارف هڪ ناچ گراف ڏسي ٿو.
3. ٽئين پارٽي مانيٽرنگ سسٽم سان API جي انضمام لاءِ ڪوڊ جي گھڻي مقدار. اهو تمام گهڻو ڪمپيڪٽ ٿي سگهي ٿو ۽ يقيناً گو ۾ ٻيهر لکي سگهجي ٿو)

مان سمجهان ٿو ته توهان سڀني چڱي طرح ڏٺو آهي ته گرافانا ڇا ڏسڻ ۾ اچي ٿو ۽ ان جي مسئلن کي مون کان سواء ڄاڻو، تنهنڪري آئون تصويرن سان پوسٽ اوورلوڊ نه ڪندس.

ٿڪل

مون عمدي طور تي ٽيڪنيڪل تفصيلن کي بيان نه ڪيو، پر صرف هن سسٽم جي بنيادي ڊيزائن کي بيان ڪيو. پهرين، ٽيڪنيڪل طور تي سسٽم کي مڪمل طور تي بيان ڪرڻ لاء، هڪ ٻيو مضمون گهربل هوندو. ٻيو، هرڪو هن ۾ دلچسپي نه رکندو. تبصرن ۾ لکو ڪھڙي ٽيڪنيڪل تفصيل توھان ڄاڻڻ چاھيو ٿا.

جيڪڏهن ڪنهن وٽ هن مضمون جي دائري کان ٻاهر سوال آهن، توهان مون ڏانهن لکي سگهو ٿا [email protected]

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