ايندڙ HighLoad++ ڪانفرنس 6 ۽ 7 اپريل 2020 تي سينٽ پيٽرسبرگ ۾ ٿيندي تفصيلات ۽ ٽڪيٽون . HighLoad++ ماسڪو 2018. هال “ماسڪو”. نومبر 9, 15:00. ٿيسز ۽ .
* مانيٽرنگ - آن لائن ۽ تجزياتي.
* ZABBIX پليٽ فارم جون بنيادي حدون.
* تجزياتي اسٽوريج اسڪيلنگ لاء حل.
* ZABBIX سرور جي اصلاح.
* UI اصلاح.
* 40k NVPS کان وڌيڪ بوجھ هيٺ سسٽم کي هلائڻ جو تجربو.
* مختصر نتيجو.
ميخائل ماڪوروف (هتي - ايم ايم): - هيلو سڀ!
ميڪسم چرنيٽسوف (هاڻي - MCH): - منجهند جو سلام!
ايم ايم: - مون کي ميڪسم متعارف ڪرائڻ ڏيو. ميڪس هڪ باصلاحيت انجنيئر آهي، بهترين نيٽ ورڪر جيڪو مان ڄاڻان ٿو. ميڪسم نيٽ ورڪ ۽ خدمتن، انهن جي ترقي ۽ آپريشن ۾ ملوث آهي.
MCH: - ۽ مان توهان کي ميخائل بابت ٻڌائڻ چاهيان ٿو. ميخائل هڪ سي ڊولپر آهي. هن اسان جي ڪمپني لاءِ ڪيترائي تيز لوڊ ٽرئفڪ پروسيسنگ حل لکيا. اسان رهون ٿا ۽ ڪم ڪريون ٿا Urals ۾، سخت مردن جي شهر Chelyabinsk ۾، Intersvyaz ڪمپني ۾. اسان جي ڪمپني 16 شهرن ۾ هڪ ملين ماڻهن لاءِ انٽرنيٽ ۽ ڪيبل ٽيليويزن سروس فراهم ڪندڙ آهي.
ايم ايم: - ۽ اهو چوڻ جي قابل آهي ته Intersvyaz صرف هڪ فراهم ڪندڙ کان وڌيڪ آهي، اها هڪ آئي ٽي ڪمپني آهي. اسان جا گهڻا حل اسان جي آئي ٽي ڊپارٽمينٽ پاران ڪيا ويا آهن.
ج: سرورز کان وٺي ٽرئفڪ جي پروسيسنگ هڪ ڪال سينٽر ۽ موبائل ايپليڪيشن ڏانهن. آئي ٽي ڊپارٽمينٽ ۾ هاڻي تقريباً 80 ماڻهو آهن جن وٽ تمام گهڻيون مختلف صلاحيتون آهن.
Zabbix ۽ ان جي فن تعمير بابت
MCH: - ۽ ھاڻي مان ھڪ ذاتي رڪارڊ قائم ڪرڻ جي ڪوشش ڪندس ۽ ھڪ منٽ ۾ ٻڌايان ٿو ته زبڪس ڇا آھي (ھاڻي ان کي ”زبڪس“ چيو ويندو آھي).
زبڪس پاڻ کي هڪ انٽرنيشنل-سطح کان ٻاهر جي باڪس مانيٽرنگ سسٽم جي حيثيت ۾ رکي ٿو. ان ۾ ڪيتريون ئي خاصيتون آھن جيڪي زندگي کي آسان بڻائين ٿيون: ترقي يافته وڌائڻ وارا ضابطا، API لاءِ انضمام، گروپنگ ۽ ھوسٽ ۽ ميٽرڪس جي خودڪار سڃاڻپ. زيبڪس وٽ نام نهاد اسڪيلنگ جا اوزار آهن - پراڪس. Zabbix هڪ اوپن سورس سسٽم آهي.
فن تعمير جي باري ۾ مختصر طور. اسان اهو چئي سگهون ٿا ته اهو ٽن حصن تي مشتمل آهي:
- سرور. سي ۾ لکيل آهي. بلڪه پيچيده پروسيسنگ ۽ موضوعن جي وچ ۾ معلومات جي منتقلي سان. سڀ پروسيسنگ ان ۾ ٿيندي آهي: وصول ڪرڻ کان وٺي ڊيٽابيس کي محفوظ ڪرڻ تائين.
- سڀ ڊيٽا ڊيٽابيس ۾ ذخيرو ٿيل آهي. Zabbix MySQL، PostreSQL ۽ Oracle کي سپورٽ ڪري ٿو.
- ويب انٽرفيس PHP ۾ لکيل آهي. اڪثر سسٽم تي اهو هڪ Apache سرور سان گڏ اچي ٿو، پر nginx + php سان ميلاپ ۾ وڌيڪ موثر ڪم ڪري ٿو.
اڄ اسان Zabbix سان لاڳاپيل اسان جي ڪمپني جي زندگيء مان هڪ ڪهاڻي ٻڌائڻ چاهيندا.
Intersvyaz ڪمپني جي زندگي مان هڪ ڪهاڻي. اسان وٽ ڇا آهي ۽ اسان کي ڇا گهرجي؟
5 يا 6 مهينا اڳ. ڪم کان پوء هڪ ڏينهن ...
MCH: - ميشا، هيلو! مون کي خوشي آهي ته مون توهان کي پڪڙڻ ۾ مدد ڪئي - اتي هڪ گفتگو آهي. اسان کي ٻيهر نگراني سان مسئلا هئا. هڪ وڏي حادثي دوران، هر شيء سست هئي ۽ نيٽ ورڪ جي حالت بابت ڪا به ڄاڻ نه هئي. بدقسمتي سان، اهو پهريون ڀيرو نه ٿيو آهي. مون کي تنهنجي مدد جي ضرورت آهي. اچو ته اسان جي نگراني جو ڪم ڪنهن به حالت ۾ ڪريون!
ايم ايم: - پر اچو ته پهرين هم وقت سازي ڪريون. مون اتي ڪجهه سالن کان نه ڏٺو آهي. جيترو مون کي ياد آهي، اسان ناگيوس کي ڇڏي ڏنو ۽ تقريبا 8 سال اڳ زيبڪس ڏانهن تبديل ڪيو. ۽ ھاڻي اسان وٽ لڳي ٿو 6 طاقتور سرورز ۽ اٽڪل ھڪ درجن پراڪسي. ڇا مان ڪجھ به پريشان آهيان؟
MCH: - لڳ ڀڳ. 15 سرور، جن مان ڪجھ مجازي مشينون آھن. سڀ کان اهم شيء اها آهي ته اهو اسان کي ان وقت بچائي نٿو سگهي جڏهن اسان کي ان جي تمام گهڻي ضرورت آهي. هڪ حادثي وانگر - سرور سست ٿي ويا ۽ توهان ڪجهه به نه ڏسي سگهو ٿا. اسان ترتيب کي بهتر ڪرڻ جي ڪوشش ڪئي، پر اهو بهتر ڪارڪردگي وڌائڻ مهيا نه ڪيو.
ايم ايم: - اهو واضح آهي. ڇا توھان ڪجھھ تي نظر ڪيو، ڇا توھان اڳ ۾ ئي تشخيص مان ڪجھ کڙو ڪيو آھي؟
MCH: - پهرين شيء جيڪا توهان سان معاملو ڪرڻو آهي ڊيٽابيس آهي. MySQL مسلسل لوڊ ٿيل آهي، نون ميٽرڪس کي محفوظ ڪري ٿو، ۽ جڏهن زيبڪس واقعن جو هڪ گروپ پيدا ڪرڻ شروع ڪري ٿو، ڊيٽابيس لفظي طور تي ڪجهه ڪلاڪن لاءِ اوور ڊرائيو ۾ وڃي ٿو. مون اڳ ۾ ئي توهان کي ترتيب ڏيڻ کي بهتر ڪرڻ بابت ٻڌايو آهي، پر لفظي طور تي هن سال انهن هارڊويئر کي اپڊيٽ ڪيو: سرورز وٽ SSD RAIDs تي سؤ گيگا بائيٽ کان وڌيڪ ميموري ۽ ڊسڪ صفون آهن - ڊگهي مدت ۾ ان کي لڪير ۾ وڌائڻ جو ڪو به مطلب ناهي. اسان ڇا ڪريون؟
ايم ايم: - اهو واضح آهي. عام طور تي، MySQL هڪ LTP ڊيٽابيس آهي. ظاهري طور تي، اهو هاڻي اسان جي ماپ جي ميٽرڪ جي آرڪائيو کي محفوظ ڪرڻ لاء مناسب ناهي. اچو ته ان جو اندازو لڳايو.
MCH: - اچو ته!
هيڪٿون جي نتيجي ۾ زيبڪس ۽ ڪلڪ هائوس جو انضمام
ڪجهه وقت کان پوء اسان کي دلچسپ ڊيٽا ملي ٿي:
اسان جي ڊيٽابيس ۾ گھڻا خلا ميٽرڪس آرڪائيو تي قبضو ڪيو ويو ۽ 1٪ کان گھٽ استعمال ڪيو ويو ٺاھ جوڙ، ٽيمپليٽس ۽ سيٽنگون لاء. ان وقت تائين، اسان هڪ سال کان وڌيڪ عرصي تائين ڪلڪ هائوس تي ٻڌل بگ ڊيٽا حل کي هلائي رهيا هئاسين. تحريڪ جو رخ اسان لاءِ واضح هو. اسان جي بهار جي Hackathon تي، مون لکيو Zabbix جو انضمام Clickhouse سان سرور ۽ فرنٽ اينڊ لاءِ. ان وقت، زيبڪس اڳ ۾ ئي ElasticSearch لاءِ سپورٽ ڪئي هئي، ۽ اسان ان جو مقابلو ڪرڻ جو فيصلو ڪيو.
Clickhouse ۽ Elasticsearch جو مقابلو
ايم ايم: - مقابلي لاءِ، اسان ساڳيو لوڊ پيدا ڪيو جيئن زيبڪس سرور مهيا ڪري ٿو ۽ ڏٺو ويو ته سسٽم ڪيئن هلندا. اسان CURL استعمال ڪندي ڊيٽا کي 1000 لائينن جي بيچ ۾ لکيو. اسان اڳ ۾ ئي فرض ڪيو ته ڪلڪ هائوس لوڊ پروفائل لاءِ وڌيڪ ڪارائتو هوندو جيڪو زيبڪس ڪندو آهي. نتيجا اسان جي اميدن کان به وڌي ويا:
ساڳئي امتحان جي حالتن هيٺ، ڪلڪ هائوس ٽي ڀيرا وڌيڪ ڊيٽا لکيو. ساڳئي وقت، ٻنهي سسٽم کي تمام مؤثر انداز ۾ استعمال ڪيو ويو (ذريعو جو هڪ ننڍڙو مقدار) جڏهن ڊيٽا پڙهڻ. پر Elastics کي وڏي مقدار ۾ پروسيسر جي ضرورت آھي جڏھن رڪارڊنگ:
مجموعي طور تي، ڪلڪ هائوس پروسيسر جي استعمال ۽ رفتار جي لحاظ کان ايلسٽڪس کان گهڻو بهتر هو. ساڳئي وقت، ڊيٽا ڪمپريشن جي ڪري، ڪلڪ هاؤس هارڊ ڊرائيو تي 11 ڀيرا گهٽ استعمال ڪري ٿو ۽ تقريبن 30 ڀيرا گهٽ ڊسڪ آپريشن انجام ڏئي ٿو:
MCH: - ها، ڪلڪ هاؤس جو ڪم ڊسڪ سب سسٽم سان تمام مؤثر طريقي سان لاڳو ٿئي ٿو. توهان ڊيٽابيس لاءِ وڏي SATA ڊسڪ استعمال ڪري سگهو ٿا ۽ لکن جي رفتار حاصل ڪري سگهو ٿا هزارين سٽون في سيڪنڊ. آئوٽ آف دي باڪس سسٽم شارڊنگ، نقل، ۽ ترتيب ڏيڻ بلڪل آسان آهي. اسان سڄي سال ۾ ان جي استعمال سان مطمئن کان وڌيڪ آهيون.
وسيلن کي بهتر ڪرڻ لاءِ، توھان انسٽال ڪري سگھو ٿا ڪلڪ ھاؤس پنھنجي موجوده مکيه ڊيٽابيس جي اڳيان ۽ اھڙي طرح سي پي يو جو گھڻو وقت ۽ ڊسڪ آپريشن بچائي. اسان ميٽرڪ جي آرڪائيو کي موجوده ڪلڪ هائوس ڪلسٽرز ڏانهن منتقل ڪيو آهي:
اسان مکيه MySQL ڊيٽابيس کي ايترو ته رليف ڪيو ته اسان ان کي هڪ مشين تي Zabbix سرور سان گڏ ڪري سگهون ٿا ۽ MySQL لاءِ وقف ڪيل سرور کي ڇڏي ڏيون.
زبڪس ۾ پولنگ ڪيئن ڪم ڪري ٿي؟
4 مھينا اڳ
ايم ايم: - خير، ڇا اسان بنيادي مسئلن جي باري ۾ وساري سگهون ٿا؟
MCH: - اها پڪ آهي! ٻيو مسئلو اسان کي حل ڪرڻ جي ضرورت آهي سست ڊيٽا گڏ ڪرڻ. ھاڻي اسان جا سڀ 15 پراکسي سرورز SNMP ۽ پولنگ جي عمل سان اوور لوڊ ٿيل آھن. ۽ نئون ۽ نئون سرور نصب ڪرڻ کان سواء ٻيو ڪو رستو ناهي.
ايم ايم: - زبردست. پر پهرين، اسان کي ٻڌايو ته پولنگ زيبڪس ۾ ڪيئن ڪم ڪري ٿي؟
MCH: - مختصر ۾، 20 قسم جا ميٽرڪ ۽ درجن وارا طريقا آھن انھن کي حاصل ڪرڻ لاءِ. Zabbix ڊيٽا گڏ ڪري سگھي ٿو يا ته "درخواست-جواب" موڊ ۾، يا "ٽريپر انٽرفيس" ذريعي نئين ڊيٽا جو انتظار ڪريو.
اها ڳالهه نوٽ ڪرڻ جي قابل آهي ته اصل Zabbix ۾ هي طريقو (Trapper) تيز ترين آهي.
لوڊ ورهائڻ لاءِ پراکسي سرور آهن:
پراڪسز ساڳيا گڏ ڪرڻ وارا ڪم سرانجام ڏئي سگھن ٿيون جيئن زيبڪس سرور، ان کان ڪم حاصل ڪرڻ ۽ گڏ ڪيل ميٽرڪس کي ٽريپر انٽرفيس ذريعي موڪلڻ. هي لوڊ ورهائڻ لاء سرڪاري طور تي تجويز ڪيل طريقو آهي. NAT يا سست چينل ذريعي هلندڙ ريموٽ انفراسٽرڪچر جي نگراني لاءِ پراڪسز پڻ ڪارآمد آهن:
ايم ايم: - فن تعمير سان سڀ ڪجهه واضح آهي. اسان کي ذريعن کي ڏسڻ جي ضرورت آهي ...
ڪجهه ڏينهن کان پوءِ
ڪهاڻي ڪيئن nmap fping کٽيو
ايم ايم: "منهنجو خيال آهي ته مون ڪجهه ڳولهيو آهي."
MCH: - مون کي ٻڌاءِ!
ايم ايم: - مون دريافت ڪيو ته دستيابي جي جانچ ڪندي، زيبڪس هڪ وقت ۾ وڌ ۾ وڌ 128 ميزبان چيڪ ڪري ٿو. مون هن نمبر کي 500 تائين وڌائڻ جي ڪوشش ڪئي ۽ انهن جي پنگ (پنگ) ۾ انٽر-پيڪٽ وقفي کي هٽائڻ جي ڪوشش ڪئي - هن ڪارڪردگي کي ٻيڻو ڪيو. پر مان چاهيان ٿو وڏا انگ.
MCH: - منهنجي مشق ۾، مون کي ڪڏهن ڪڏهن هزارين ميزبانن جي دستيابي جي جانچ ڪرڻي پوندي آهي، ۽ مون ان لاءِ nmap کان وڌيڪ تيز ڪڏهن به نه ڏٺو آهي. مون کي پڪ آهي ته هي تيز ترين طريقو آهي. اچو ته ڪوشش ڪريون! اسان کي لازمي طور تي ميزبانن جو تعداد وڌائڻو پوندو.
ايم ايم: - پنج سئو کان وڌيڪ چيڪ ڪريو؟ 600؟
MCH: - گهٽ ۾ گهٽ ٻه هزار.
ايم ايم: - ٺيڪ. سڀ کان اهم شيء جيڪا مان چوڻ چاهيان ٿي ته مون ڏٺو ته زيبڪس ۾ اڪثر پولنگ هم وقت سازي سان ڪئي وئي آهي. اسان کي ضرور ان کي تبديل ڪرڻ جي ضرورت آهي asynchronous mode. پوء اسان ڊرامائي طور تي پولرز پاران گڏ ڪيل ميٽرڪ جو تعداد وڌائي سگھون ٿا، خاص طور تي جيڪڏھن اسان ميٽرڪ جو تعداد وڌائي سگھون ٿا.
MCH: - زبردست! ۽ ڪڏهن؟
ايم ايم: - هميشه وانگر، ڪالهه.
MCH: - اسان fping ۽ nmap جي ٻنهي نسخن جو مقابلو ڪيو:
ميزبانن جي وڏي تعداد تي، nmap کي پنج ڀيرا وڌيڪ اثرائتو ٿيڻ جي اميد هئي. جيئن ته nmap صرف دستيابي ۽ جوابي وقت جي جانچ ڪري ٿو، اسان نقصان جي حساب کي ٽارگيٽ ڏانهن منتقل ڪيو ۽ دستيابي جي چڪاس جي وقفن کي خاص طور تي گھٽائي ڇڏيو. اسان nmap لاءِ ميزبانن جو مناسب تعداد 4 ھزار في ورجائي لاءِ مليو. Nmap اسان کي اجازت ڏني ته دستيابي چيڪن جي سي پي يو جي قيمت کي ٽي ڀيرا گھٽائي ۽ وقفو گھٽائي 120 سيڪنڊن کان 10 تائين.
پولنگ جي اصلاح
ايم ايم: ”پوءِ اسان پولر ڪرڻ شروع ڪيو. اسان خاص طور تي SNMP ڳولڻ ۽ ايجنٽ ۾ دلچسپي وٺندا هئا. زيبڪس ۾، پولنگ هڪجهڙائي سان ڪئي وئي آهي ۽ سسٽم جي ڪارڪردگي کي وڌائڻ لاء خاص قدم کنيا ويا آهن. هم وقت سازي موڊ ۾، ميزبان جي غير موجودگيءَ سبب پولنگ جي وڏي تباهي اچي ٿي. رياستن جو هڪ مڪمل نظام آهي، اتي خاص عمل آهن - نام نهاد ناقابل رسائي پولرز، جيڪي صرف ناقابل رسائي ميزبان سان ڪم ڪن ٿا:
هي هڪ تبصرو آهي جيڪو رياستي ميٽرڪس کي ظاهر ڪري ٿو، منتقلي جي سسٽم جي تمام پيچيدگي جيڪا سسٽم کي اثرائتو رهڻ لاء گهربل آهي. ان کان سواء، هم وقت سازي پولنگ پاڻ ڪافي سست آهي:
اهو ئي سبب آهي ته هزارين پولر اسٽريمز ڪيترن ئي پراڪسز تي اسان لاءِ گهربل ڊيٽا گڏ نه ڪري سگهيا. غير مطابقت واري عمل درآمد نه رڳو مسئلن جي مسئلن کي حل ڪيو، پر غير دستياب ميزبان جي رياستي نظام کي پڻ آسان بڻائي ڇڏيو، ڇاڪاڻ ته ڪنهن به نمبر لاء هڪ پولنگ جي ورهاڱي ۾ چيڪ ڪيو ويو، وڌ ۾ وڌ انتظار جو وقت 1 وقت ختم ٿي ويو:
اضافي طور تي، اسان SNMP درخواستن لاء پولنگ سسٽم کي تبديل ۽ بهتر ڪيو. حقيقت اها آهي ته گهڻا ماڻهو هڪ ئي وقت ڪيترن ئي SNMP درخواستن جو جواب نٿا ڏئي سگهن. تنهن ڪري، اسان هڪ هائبرڊ موڊ ٺاهيو، جڏهن ساڳئي ميزبان جي SNMP پولنگ غير مطابقت سان ڪيو ويندو آهي:
اهو لشڪر جي پوري پيڪ لاء ڪيو ويندو آهي. هي موڊ آخرڪار هڪ مڪمل طور تي هم وقت سازي کان وڌيڪ سست نه آهي، ڇو ته پولنگ هڪ اڌ سو SNMP ويلز اڃا تائين 1 ٽائيم آئوٽ کان گهڻو تيز آهي.
اسان جا تجربا ڏيکاريا ويا آهن ته درخواستن جو وڌ کان وڌ تعداد هڪ ورجائي ۾ لڳ ڀڳ 8 هزار آهي SNMP پولنگ سان. مجموعي طور تي، غير مطابقت واري موڊ جي منتقلي اسان کي پولنگ ڪارڪردگي کي 200 ڀيرا تيز ڪرڻ جي اجازت ڏني، ڪيترائي سو ڀيرا.
MCH: - نتيجي ۾ پولنگ جي اصلاحن مان ظاهر ٿيو ته اسان نه رڳو سڀني پراڪسيز کان نجات حاصل ڪري سگهون ٿا، پر ڪيترن ئي چيڪن لاءِ وقفو به گهٽائي سگهون ٿا، ۽ لوڊ شيئر ڪرڻ جي طريقي جي طور تي پراڪسي جي ضرورت نه پوندي.
اٽڪل ٽي مهينا اڳ
فن تعمير کي تبديل ڪريو - لوڊ وڌايو!
ايم ايم: - چڱو، ميڪس، اهو وقت آهي پيداوار حاصل ڪرڻ جو؟ مون کي هڪ طاقتور سرور ۽ سٺو انجنيئر جي ضرورت آهي.
MCH: - ٺيڪ آهي، اچو ته ان جي رٿابندي ڪريون. 5 هزار ميٽرڪ في سيڪنڊ جي مرڻ واري نقطي کان اڳتي وڌڻ جو وقت آهي.
صبح جو اپ گريڊ کان پوء
MCH: - ميشا، اسان پاڻ کي اپڊيٽ ڪيو، پر صبح جو اسان واپس ڦري ويا ... اندازو لڳايو ته اسان ڪهڙي رفتار حاصل ڪرڻ ۾ ڪامياب ٿي ويا؟
ايم ايم: - 20 هزار وڌ ۾ وڌ.
MCH: - ها، 25! بدقسمتي سان، اسان صحيح آهيون جتي اسان شروع ڪيو.
ايم ايم: - ڇو؟ ڇا توهان ڪنهن به تشخيص کي هلائي ڇڏيو؟
MCH: - ها، يقينا! هتي، مثال طور، هڪ دلچسپ مٿي آهي:
ايم ايم: - اچو ته ڏسو. مان ڏسان ٿو ته اسان پولنگ جي سلسلي جي وڏي تعداد جي ڪوشش ڪئي آهي:
پر ساڳئي وقت اهي سسٽم کي اڌ کان به ري سائيڪل نه ڪري سگهيا:
۽ مجموعي ڪارڪردگي بلڪل ننڍڙو آهي، اٽڪل 4 هزار ميٽرڪ في سيڪنڊ:
ٻيو ڪجهه آهي؟
MCH: - ها، پولر مان هڪ جو اسٽريس:
ايم ايم: - هتي توهان واضح طور تي ڏسي سگهو ٿا ته پولنگ عمل "سيمفورس" جي انتظار ۾ آهي. اهي تالا آهن:
MCH: - اڻڄاڻ.
ايم ايم: - ڏس، هي هڪ اهڙي صورتحال سان ملندڙ جلندڙ آهي جتي موضوعن جو هڪ گروپ وسيلن سان ڪم ڪرڻ جي ڪوشش ڪري رهيا آهن جيڪي صرف هڪ وقت ۾ ڪم ڪري سگهن ٿيون. پوءِ اھي سڀ ڪجھ ڪري سگھن ٿا ھن وسيلن کي وقت سان حصيداري ڪريو:
۽ اهڙي وسيلن سان ڪم ڪرڻ جي ڪل ڪارڪردگي هڪ بنيادي جي رفتار تائين محدود آهي:
هن مسئلي کي حل ڪرڻ جا ٻه طريقا آهن.
مشين جي هارڊويئر کي اپڊيٽ ڪريو، تيز ڪور ڏانهن سوئچ ڪريو:
يا فن تعمير کي تبديل ڪريو ۽ ساڳئي وقت لوڊ تبديل ڪريو:
MCH: - رستي ۾، ٽيسٽ مشين تي اسان جنگي هڪ جي ڀيٽ ۾ گهٽ ڪور استعمال ڪنداسين، پر اهي آهن 1,5 ڀيرا تيز فريڪئنسي في ڪور ۾!
ايم ايم: - صاف؟ توھان کي ڏسڻ جي ضرورت آھي سرور ڪوڊ.
Zabbix سرور ۾ ڊيٽا جو رستو
MCH: - ان کي معلوم ڪرڻ لاء، اسان تجزيو ڪرڻ شروع ڪيو ته ڪيئن ڊيٽا Zabbix سرور جي اندر منتقل ڪئي وئي آهي:
سٺي تصوير، صحيح؟ اچو ته ان کي وڌيڪ يا گهٽ واضح ڪرڻ لاء قدم قدم ذريعي وڃو. ڊيٽا گڏ ڪرڻ جا ذميوار ٿريڊ ۽ خدمتون آهن:
اهي گڏ ڪيل ميٽرڪس کي ساکٽ ذريعي پري پروسيسر مينيجر ڏانهن منتقل ڪن ٿا، جتي اهي قطار ۾ محفوظ ڪيا ويا آهن:
"پري پروسيسر مئنيجر" ڊيٽا کي پنهنجي ڪارڪنن ڏانهن منتقل ڪري ٿو، جيڪي اڳ پروسيسنگ هدايتون تي عمل ڪن ٿا ۽ ساڳئي ساکٽ ذريعي واپس واپس آڻين ٿا.
ان کان پوء، پري پروسيسر مينيجر انهن کي تاريخ جي ڪيش ۾ محفوظ ڪري ٿو:
اتان کان اهي تاريخ جي سنڪن پاران ورتو وڃي ٿو، جيڪي ڪافي ڪم انجام ڏين ٿا: مثال طور، ڳڻپيوڪر ٽريگرز، قيمتي ڪيش ڀرڻ ۽، سڀ کان اهم، تاريخ جي اسٽوريج ۾ ميٽرڪس کي بچائڻ. عام طور تي، عمل پيچيده ۽ تمام پريشان آهي.
ايم ايم: - پهرين شيء جيڪا اسان ڏٺي اها اها هئي ته اڪثر موضوع نام نهاد "ڪانفيگريشن ڪيش" لاءِ مقابلو ڪندا آهن (ميموري ايريا جتي سڀئي سرور ترتيبون محفوظ ٿيل آهن). ڊيٽا گڏ ڪرڻ جا ذميوار موضوع خاص طور تي تمام گهڻو بلاڪ ڪندا آهن:
...جيئن ته ڪنفيگريشن اسٽور نه رڳو ميٽرڪس انهن جي پيرا ميٽرن سان، پر قطارون به جن مان پولر معلومات وٺن ٿا ته اڳتي ڇا ڪجي. جڏهن اتي ڪيترائي پولر آهن ۽ هڪ بلاڪ ٺاھ جوڙ، ٻيا درخواستن جو انتظار ڪن ٿا:
پولرز کي تڪرار نه ڪرڻ گهرجي
تنهن ڪري، پهريون ڪم جيڪو اسان ڪيو اهو قطار کي 4 حصن ۾ ورهايو ويو ۽ پولرز کي انهن قطارن کي بلاڪ ڪرڻ جي اجازت ڏني وئي، اهي حصا ساڳئي وقت، محفوظ حالتن ۾:
اهو هٽايو ويو مقابلو ترتيب جي ڪيش لاء، ۽ پولرز جي رفتار کي خاص طور تي وڌايو ويو. پر پوءِ اسان ان حقيقت سان منهن ڪيو ته پري پروسيسر مئنيجر نوڪرين جي قطار گڏ ڪرڻ شروع ڪيو:
پري پروسيسر مينيجر کي ترجيح ڏيڻ جي قابل هوندو
اهو ڪيسن ۾ ٿيو جتي هن جي ڪارڪردگي نه هئي. پوءِ اھو سڀ ڪجھ ڪري سگھيو ھو ڊيٽا گڏ ڪرڻ جي عملن کان درخواستون گڏ ڪري ۽ انھن جي بفر کي شامل ڪري جيستائين اھو سمورو ميموري استعمال ڪري ۽ حادثو ٿي ويو:
هن مسئلي کي حل ڪرڻ لاء، اسان هڪ ٻيو ساکٽ شامل ڪيو جيڪو خاص طور تي ڪارڪنن لاء وقف ڪيو ويو:
اهڙيء طرح، پري پروسيسر مينيجر کي پنهنجي ڪم کي ترجيح ڏيڻ جو موقعو مليو، ۽ جيڪڏهن بفر وڌندو آهي، اهو ڪم ختم ڪرڻ کي سست ڪرڻ آهي، ڪارڪنن کي هن بفر کي وٺڻ جو موقعو ڏئي ٿو:
پوءِ اسان دريافت ڪيو ته سستي جو هڪ سبب پاڻ مزدور هئا، ڇاڪاڻ ته اهي هڪ وسيلن لاءِ مقابلو ڪري رهيا هئا، جيڪو سندن ڪم لاءِ مڪمل طور تي غير اهم هو. اسان هن مسئلي کي بگ-فڪس جي طور تي دستاويز ڪيو، ۽ اهو اڳ ۾ ئي حل ڪيو ويو آهي Zabbix جي نئين نسخن ۾:
اسان ساکٽ جو تعداد وڌايو - اسان نتيجو حاصل ڪندا آهيون
ان کان علاوه، پري پروسيسر مينيجر پاڻ کي هڪ رڪاوٽ بڻجي ويو، ڇاڪاڻ ته اهو هڪ موضوع آهي. اهو بنيادي رفتار تي آرام ڪري ٿو، وڌ ۾ وڌ رفتار ڏئي ٿو اٽڪل 70 هزار ميٽرڪ في سيڪنڊ:
تنهن ڪري، اسان چار ٺاهيو، ساکٽ جي چار سيٽن سان، ڪارڪنن:
۽ هن اسان کي رفتار وڌائڻ جي اجازت ڏني تقريبن 130 هزار ميٽرڪ تائين:
ترقي جي غير لڪير جي حقيقت اها وضاحت ڪئي وئي آهي ته تاريخ جي ڪيش لاء مقابلو ظاهر ٿيو آهي. 4 پري پروسيسر مينيجرز ۽ تاريخ سنڪرز ان لاءِ مقابلو ڪيو. هن نقطي تي، اسان ٽيسٽ مشين تي تقريبا 130 هزار ميٽرڪ في سيڪنڊ حاصل ڪري رهيا هئاسين، پروسيسر جي تقريبا 95٪ طرفان استعمال ڪندي:
اٽڪل 2,5 مهينا اڳ
snmp-community کان انڪار NVPs وڌائي اڌ ڀيرا
ايم ايم: - ميڪس، مون کي نئين ٽيسٽ ڪار جي ضرورت آهي! اسان هاڻي موجوده ۾ مناسب نه آهيون.
MCH: - توهان وٽ هاڻي ڇا آهي؟
ايم ايم: - هاڻي - 130k NVPs ۽ هڪ شيلف تيار پروسيسر.
MCH: - واهه! عمده! انتظار ڪريو، مون وٽ ٻه سوال آهن. منهنجي حساب سان اسان جي ضرورت 15-20 هزار ميٽرڪ في سيڪنڊ جي لڳ ڀڳ آهي. اسان کي وڌيڪ ضرورت ڇو آهي؟
ايم ايم: "مان ڪم ختم ڪرڻ چاهيان ٿو." مان ڏسڻ چاهيان ٿو ته اسان هن نظام مان ڪيترو نچوض ڪري سگهون ٿا.
MCH: - پر…
ايم ايم: "پر اهو ڪاروبار لاء بيڪار آهي."
MCH: - اهو واضح آهي. ۽ ٻيو سوال: ڇا اسان مدد ڪري سگھون ٿا جيڪو اسان وٽ ھاڻي آھي پاڻ تي، ڊولپر جي مدد کانسواءِ؟
ايم ايم: - مان نه ٿو سوچان. ڪئين ترتيب ڏيڻ واري ڪيش کي تبديل ڪرڻ هڪ مسئلو آهي. اهو سڀ کان وڌيڪ موضوعن ۾ تبديلين کي متاثر ڪري ٿو ۽ برقرار رکڻ ڏاڍو ڏکيو آهي. گهڻو ڪري، ان کي برقرار رکڻ لاء تمام ڏکيو ٿيندو.
MCH: "پوء اسان کي ڪنهن قسم جي متبادل جي ضرورت آهي."
ايم ايم: - اتي هڪ اهڙي اختيار آهي. نئين لاڪنگ سسٽم کي ڇڏي ڏيڻ دوران، اسان تيز ڪور ڏانهن تبديل ڪري سگھون ٿا. اسان اڃا تائين 60-80 هزار ميٽرڪ جي ڪارڪردگي حاصل ڪنداسين. ساڳئي وقت، اسان سڀ باقي ڪوڊ ڇڏي سگهون ٿا. ڪلڪ هائوس ۽ هم وقت سازي پولنگ ڪم ڪندو. ۽ ان کي برقرار رکڻ آسان ٿيندو.
MCH: - حيرت انگيز! مان صلاح ڏيان ٿو ته اسان هتي رکو.
سرور جي پاسي کي بهتر ڪرڻ کان پوء، اسان آخرڪار نئين ڪوڊ کي پيداوار ۾ شروع ڪرڻ جي قابل ٿي ويا. اسان ڪجھ تبديلين کي ڇڏي ڏنو آھي ھڪڙي مشين تي سوئچ ڪرڻ جي حق ۾ فاسٽ ڪور سان ۽ ڪوڊ تبديلين جي تعداد کي گھٽائڻ. اسان ان ترتيب کي به آسان ڪيو آهي ۽ ڊيٽا آئٽمز ۾ ميڪرو کي ختم ڪيو آهي جتي ممڪن هجي، جيئن اهي اضافي لاڪنگ متعارف ڪرائين.
مثال طور، snmp-community macro کي ڇڏڻ، جيڪو اڪثر دستاويزن ۽ مثالن ۾ ملي ٿو، اسان جي صورت ۾ NVPs کي 1,5 ڀيرا وڌيڪ تيز ڪرڻ ممڪن بڻايو.
پيداوار ۾ ٻن ڏينهن کان پوء
هٽائڻ واري واقعي جي تاريخ پاپ اپ
MCH: - ميشا، اسان ٻن ڏينهن کان سسٽم استعمال ڪري رهيا آهيون، ۽ سڀ ڪجهه ڪم ڪري ٿو. پر صرف جڏهن سڀ ڪجهه ڪم ڪري ٿو! اسان نيٽ ورڪ جي ڪافي وڏي حصي جي منتقلي سان ڪم جي منصوبابندي ڪئي هئي، ۽ اسان ٻيهر پنهنجن هٿن سان چيڪ ڪيو ته ڇا ٿيو ۽ ڇا نه ٿيو.
ايم ايم: - نه ٿي سگهي! اسان هر شي کي 10 ڀيرا چيڪ ڪيو. سرور سنڀالي ٿو مڪمل نيٽ ورڪ جي دستيابي کي فوري طور تي.
MCH: - ها، مان سڀ ڪجھ سمجھان ٿو: سرور، ڊيٽابيس، ٽاپ، آسٽٽ، لاگز - سڀ ڪجھ تيز آھي... پر اسان ويب انٽرفيس کي ڏسون ٿا، ۽ سرور تي ھڪڙو پروسيسر آھي "شيلف ۾" ۽ ھي:
ايم ايم: - اهو واضح آهي. اچو ته ويب ڏسو. اسان ڏٺو ته هڪ اهڙي صورتحال ۾ جتي فعال واقعن جو هڪ وڏو تعداد موجود هئا، اڪثر لائيو ويجٽ تمام سست ڪم ڪرڻ شروع ڪيو:
هن جو سبب اهو هو ته واقعن جي تاريخ پاپ اپن جو نسل جيڪو فهرست ۾ هر شئي لاءِ ٺاهيا ويا آهن. تنهن ڪري، اسان انهن ونڊوز جي نسل کي ڇڏي ڏنو (ڪوڊ ۾ 5 لائينون تبصرو ڪيو)، ۽ اهو اسان جي مسئلن کي حل ڪيو.
ويجيٽس لاءِ لوڊشيڊنگ جو وقت، جيتوڻيڪ مڪمل طور تي دستياب نه هجي، ڪيترن ئي منٽن کان گھٽائي اسان لاءِ قابل قبول 10-15 سيڪنڊن تائين ڪيو ويو آهي، ۽ تاريخ اڃا به وقت تي ڪلڪ ڪري ڏسي سگهجي ٿي:
ڪم کان پوء. 2 مهينا اڳ
MCH: - Misha، تون وڃي رهيو آهين؟ اسان کي ڳالهائڻو آهي.
ايم ايم: - مون ارادو نه ڪيو. زيبڪس سان گڏ ڪجهه ٻيهر؟
MCH: - نه، آرام ڪر! مان صرف چوڻ چاهيان ٿو: سڀ ڪجهه ڪم ڪري ٿو، مهرباني! مون وٽ بيئر آهي.
زيبڪس ڪارائتو آهي
زيبڪس هڪ انتهائي آفاقي ۽ امير سسٽم ۽ فنڪشن آهي. اهو دٻي کان ٻاهر ننڍڙي تنصيب لاء استعمال ڪري سگهجي ٿو، پر جيئن ضرورت وڌندي، ان کي بهتر ڪيو وڃي. ميٽرڪ جي وڏي آرڪائيو کي ذخيرو ڪرڻ لاء، مناسب اسٽوريج استعمال ڪريو:
- توھان استعمال ڪري سگھوٿا بلٽ ان ٽولز جي صورت ۾ انضمام جي صورت ۾ Elasticsearch سان يا ٽيڪسٽ فائلن تي تاريخ کي اپلوڊ ڪرڻ (ورجن XNUMX مان دستياب)؛
- توهان اسان جي تجربي مان فائدو وٺي سگهو ٿا ۽ Clickhouse سان انضمام.
ڊرامائي طور تي ميٽرڪ گڏ ڪرڻ جي رفتار کي وڌائڻ لاءِ، ان کي گڏ ڪريو غير مطابقت رکندڙ طريقا استعمال ڪندي ۽ انھن کي ٽرپر انٽرفيس ذريعي زيبڪس سرور ڏانھن منتقل ڪريو؛ يا توهان زبڪس پولرز کي هم وقت سازي ڪرڻ لاءِ پيچ استعمال ڪري سگهو ٿا.
زيبڪس سي ۾ لکيل آهي ۽ ڪافي ڪارائتو آهي. ڪيترن ئي تعميراتي رڪاوٽن کي حل ڪرڻ توهان کي ان جي ڪارڪردگي کي وڌيڪ وڌائڻ جي اجازت ڏئي ٿي ۽، اسان جي تجربي ۾، هڪ واحد پروسيسر مشين تي 100 هزار ميٽرڪس کان وڌيڪ حاصل ڪريو.
ساڳي Zabbix پيچ
ايم ايم: - مان ڪجهه پوائنٽ شامل ڪرڻ چاهيان ٿو. سموري موجوده رپورٽ، سڀ ٽيسٽ، انگ اُھي ترتيب ڏنل آھن جيڪي اسان استعمال ڪريون ٿا. اسان هينئر ان مان لڳ ڀڳ 20 هزار ميٽرڪ في سيڪنڊ وٺي رهيا آهيون. جيڪڏهن توهان سمجهڻ جي ڪوشش ڪري رهيا آهيو ته ڇا اهو توهان لاءِ ڪم ڪندو، توهان مقابلو ڪري سگهو ٿا. اڄ ڇا بحث ڪيو ويو آهي GitHub تي پوسٽ جي صورت ۾ پوسٽ ڪيو ويو آهي:
پيچ شامل آهن:
- ڪلڪ هاؤس سان مڪمل انضمام (ٻنهي زبڪس سرور ۽ فرنٽ اينڊ)؛
- پري پروسيسر مينيجر سان مسئلا حل ڪرڻ؛
- هم وقت سازي پولنگ.
پيچ سڀني ورزن 4 سان مطابقت رکي ٿو، بشمول lts. گهڻو ڪري، گهٽ ۾ گهٽ تبديلين سان اهو ڪم ڪندو نسخو 3.4.
توهان جي ڌيان لاء توهان جي مهرباني.
توهان جا سوال
سامعين کان سوال (هتي - الف): - صبح جو سلام! مھرباني ڪري مون کي ٻڌايو، ڇا توھان وٽ زيبڪس ٽيم سان يا انھن سان گڏ توھان سان سخت رابطي جو منصوبو آھي، تنھنڪري اھو ھڪڙو پيچ نه آھي، پر Zabbix جو عام رويو آھي؟
ايم ايم: - ها، اسان ضرور ڪجهه تبديليون ڪنداسين. ڪجهه ته ٿيندو، ڪجهه ته پڳ ۾ رهندو.
ج: - شاندار رپورٽ لاء توهان جي وڏي مهرباني! مھرباني ڪري مون کي ٻڌايو، پيچ کي لاڳو ڪرڻ کان پوء، Zabbix جي حمايت رھندي ۽ ڪيئن اعلي نسخن تي تازه ڪاري جاري رکي؟ ڇا توھان جي پيچ کان پوء زيبڪس کي اپڊيٽ ڪرڻ ممڪن آھي 4.2، 5.0؟
ايم ايم: - مان سپورٽ بابت ڪجهه نٿو چئي سگهان. جيڪڏهن مان Zabbix ٽيڪنيڪل سپورٽ هجان ها، مان شايد نه چوان ها، ڇاڪاڻ ته هي ڪنهن ٻئي جو ڪوڊ آهي. جيئن ته 4.2 ڪوڊ بيس لاء، اسان جي پوزيشن آهي: "اسان وقت سان منتقل ڪنداسين، ۽ اسان پاڻ کي ايندڙ ورزن تي تازه ڪاري ڪنداسين." تنهن ڪري، ڪجهه وقت لاء اسين تازه ڪاري ورزن لاء هڪ پيچ پوسٽ ڪنداسين. مون اڳ ۾ ئي رپورٽ ۾ چيو آهي: نسخن سان تبديلين جو تعداد اڃا تائين تمام ننڍڙو آهي. منهنجو خيال آهي ته 3.4 کان 4 تائين جي منتقلي اسان کي اٽڪل 15 منٽ لڳا، اتي ڪجهه تبديل ٿيو، پر تمام ضروري ناهي.
ج: - تنهن ڪري توهان پنهنجي پيچ کي سپورٽ ڪرڻ جو منصوبو ٺاهيو ٿا ۽ توهان محفوظ طور تي ان کي پيداوار ۾ انسٽال ڪري سگهو ٿا ۽ مستقبل ۾ ڪنهن طريقي سان تازه ڪاريون حاصل ڪري سگهو ٿا؟
ايم ايم: - اسان سختي سان ان جي سفارش ڪريون ٿا. اهو اسان لاء تمام گهڻا مسئلا حل ڪري ٿو.
MCH: - هڪ ڀيرو ٻيهر، مان هن حقيقت ڏانهن ڌيان ڏيڻ چاهيان ٿو ته اهي تبديليون جيڪي فن تعمير سان تعلق نه رکندا آهن ۽ نه بلاڪ ڪرڻ يا قطار جي باري ۾ نه آهن ماڊيولر آهن، اهي الڳ ماڊل ۾ آهن. جيتوڻيڪ معمولي تبديلين سان توهان انهن کي آساني سان برقرار رکي سگهو ٿا.
ايم ايم: - جيڪڏھن توھان دلچسپي وٺندا آھيو تفصيل ۾، پوء "ڪلڪ ھاؤس" استعمال ڪري ٿو نام نهاد تاريخ لائبريري. اهو اڻڄاتل آهي - اهو ايلسٽڪس سپورٽ جي ڪاپي آهي، اهو آهي، اهو ترتيب ڏيڻ وارو آهي. پولنگ صرف پولرن کي تبديل ڪري ٿي. اسان يقين رکون ٿا ته اهو هڪ ڊگهو وقت تائين ڪم ڪندو.
ج: - تمام گهڻي مهرباني. مون کي ٻڌاءِ، ڇا تبديلين جا ڪي دستاويز آھن؟
ايم ايم: - دستاويز هڪ پيچ آهي. ظاهر آهي، ڪلڪ هاؤس جي تعارف سان، نئين قسم جي پولرز جي تعارف سان، نئين ترتيب جا اختيار پيدا ٿين ٿا. آخري سلائڊ جي لنڪ ۾ هڪ مختصر وضاحت آهي ته ان کي ڪيئن استعمال ڪجي.
nmap سان fping کي تبديل ڪرڻ بابت
ج: - توهان آخرڪار هن کي ڪيئن لاڳو ڪيو؟ ڇا توھان مخصوص مثال ڏئي سگھو ٿا: ڇا توھان وٽ اسٽريپر ۽ ٻاھرين رسم الخط آھي؟ آخر ايتري وڏي تعداد ۾ ميزبانن کي ايترو جلدي جانچڻ ڇا آهي؟ توهان انهن ميزبانن کي ڪيئن ٿا ڏسو؟ ڇا اسان کي ضرورت آھي انھن کي فيڊ ڪرڻ لاءِ ڪنھن نه ڪنھن طرح nmap ڪرڻ لاءِ، انھن کي ڪٿان آڻيون، انھن ۾ وجھون، ڪجھ ھلائي؟...
ايم ايم: - عمده. بلڪل صحيح سوال! ڳالهه هيءَ آهي. اسان ICMP چيڪن لاءِ لائبريري (ICMP پنگ، زيبڪس جو حصو) ۾ ترميم ڪئي، جيڪا پيڪٽس جو تعداد ڏيکاري ٿي - هڪ (1)، ۽ ڪوڊ nmap استعمال ڪرڻ جي ڪوشش ڪري ٿو. اهو آهي، اهو زبڪس جو اندروني ڪم آهي، جيڪو پنگر جو اندروني ڪم بڻجي چڪو آهي. ان جي مطابق، ڪا به هم وقت سازي يا ٽرپر جي استعمال جي ضرورت ناهي. اهو عمدي طور ڪيو ويو آهي سسٽم کي برقرار رکڻ لاءِ ۽ ٻن ڊيٽابيس سسٽم جي هم وقت سازي سان معاملو ڪرڻ جي ضرورت ناهي: ڇا چيڪ ڪيو وڃي، پولر ذريعي اپلوڊ ڪيو وڃي، ۽ ڇا اسان جي اپلوڊ ڀڄي وئي آهي؟.. اهو گهڻو آسان آهي.
ج: - ڇا اهو پراکسيز لاءِ به ڪم ڪري ٿو؟
ايم ايم: - ها، پر اسان چيڪ نه ڪيو. پولنگ ڪوڊ زبڪس ۽ سرور ٻنهي ۾ ساڳيو آهي. ڪم ڪرڻ گهرجي. مون کي هڪ ڀيرو ٻيهر زور ڏيڻ ڏيو: سسٽم جي ڪارڪردگي اهڙي آهي ته اسان کي پراکسي جي ضرورت ناهي.
MCH: - سوال جو صحيح جواب آهي: "توهان کي اهڙي سسٽم سان پراکسي جي ضرورت ڇو آهي؟" صرف NAT جي ڪري يا ڪنهن قسم جي سست چينل ذريعي مانيٽرنگ ...
ج: - ۽ توھان استعمال ڪريو زبڪس کي الرٽر طور، جيڪڏھن مان صحيح سمجھان. يا ڇا توهان جا گرافڪس (جتي آرڪائيو پرت آهي) ٻئي سسٽم ڏانهن منتقل ڪيا ويا آهن، جهڙوڪ گرافانا؟ يا ڇا توهان هن ڪارڪردگي کي استعمال نه ڪندا آهيو؟
ايم ايم: - مان هڪ ڀيرو ٻيهر زور ڏيندس: اسان مڪمل انضمام حاصل ڪيو آهي. اسان تاريخ کي ڪلڪ هائوس ۾ وجهي رهيا آهيون، پر ساڳئي وقت اسان php فرنٽ اينڊ کي تبديل ڪيو آهي. پي ايڇ پي فرنٽ اينڊ ڪلڪ هائوس ڏانهن وڃي ٿو ۽ اتان کان سڀئي گرافڪس ڪندو آهي. ساڳئي وقت، ايماندار هجڻ لاء، اسان وٽ هڪ حصو آهي جيڪو ٻين گرافڪ ڊسپلي سسٽم ۾ ڊيٽا ٺاهي ٿو ساڳئي ڪلڪ هاؤس کان، ساڳئي زيبڪس ڊيٽا مان.
MCH: - "Grafan" ۾ پڻ.
وسيلن جي ورهاست بابت فيصلا ڪيئن ڪيا ويا؟
ج: - پنهنجي اندروني باورچی خانه جو ٿورڙو حصيداري ڪريو. اهو فيصلو ڪيئن ڪيو ويو ته اها پيداوار جي سنجيده پروسيسنگ لاء وسيلن کي مختص ڪرڻ ضروري آهي؟ اهي آهن، عام طور تي، ڪجهه خطرا. ۽ مهرباني ڪري مون کي ٻڌايو، حقيقت جي حوالي سان ته توهان نئين نسخن جي حمايت ڪرڻ وارا آهيو: اهو فيصلو انتظامي نقطي نظر کان ڪيئن صحيح آهي؟
ايم ايم: - بظاهر، اسان تاريخ جي ڊرامي کي چڱي طرح نه ٻڌايو. اسان پاڻ کي اهڙي صورتحال ۾ مليو جتي ڪجهه ٿيڻو هو، ۽ اسان لازمي طور تي ٻه متوازي ٽيمن سان گڏ وياسون:
- هڪ مانيٽرنگ سسٽم شروع ڪري رهيو هو نئين طريقن کي استعمال ڪندي: هڪ خدمت جي طور تي نگراني، اوپن سورس حلن جو هڪ معياري سيٽ جنهن کي اسان گڏ ڪريون ٿا ۽ پوءِ نئين مانيٽرنگ سسٽم سان ڪم ڪرڻ لاءِ ڪاروباري عمل کي تبديل ڪرڻ جي ڪوشش ڪريون ٿا.
- ساڳئي وقت، اسان وٽ هڪ پرجوش پروگرامر هو جيڪو اهو ڪري رهيو هو (پنهنجي باري ۾). ائين ٿيو ته هو کٽي ويو.
ج: - ۽ ٽيم جي ماپ ڇا آهي؟
MCH: - هوء توهان جي سامهون آهي.
ج: - پوء، هميشه وانگر، توهان کي هڪ پرجوش ضرورت آهي؟
ايم ايم: - مون کي خبر ناهي ته پرجوش ڇا آهي.
ج: - هن معاملي ۾، apparently، توهان. توهان جي وڏي مهرباني، توهان شاندار آهيو.
ايم ايم: - تنهنجي مهرباني.
Zabbix لاء پيچ بابت
ج: - هڪ سسٽم لاءِ جيڪو پراڪسز استعمال ڪري ٿو (مثال طور، ڪجهه ورهايل سسٽم ۾)، ڇا اهو ممڪن آهي ته موافقت ۽ پيچ، چئو، پولرز، پراڪسز ۽ جزوي طور تي Zabbix جو اڳوڻو پروسيسر؛ ۽ انهن جو رابطو؟ ڇا اهو ممڪن آهي ته موجوده ترقيات کي بهتر ڪرڻ لاء ڪيترن ئي پراکسي سان سسٽم لاء؟
ايم ايم: - مون کي خبر آهي ته Zabbix سرور هڪ پراکسي استعمال ڪندي گڏ ڪيو ويو آهي (ڪوڊ مرتب ڪيو ويو آهي ۽ حاصل ڪيو ويو آهي). اسان هن پيداوار ۾ آزمائشي نه ڪيو آهي. مون کي ان بابت پڪ ناهي، پر مان سمجهان ٿو ته پري پروسيسر مينيجر پراکسي ۾ استعمال نه ڪيو ويو آهي. پراکسي جو ڪم زبڪس مان ميٽرڪس جو هڪ سيٽ وٺڻ آهي، انهن کي ضم ڪرڻ (اهو پڻ ترتيب ڏئي ٿو، مقامي ڊيٽابيس) ۽ ان کي واپس Zabbix سرور ڏانهن ڏيو. سرور پاڻ وري پروسيسنگ ڪندو جڏهن اهو وصول ڪندو.
پراکسي ۾ دلچسپي سمجھ ۾ اچي ٿي. اسان ان کي چيڪ ڪنداسين. هي هڪ دلچسپ موضوع آهي.
ج: - خيال هي هو: جيڪڏهن توهان پولرز کي پيچ ڪري سگهو ٿا، توهان انهن کي پراڪسي تي پيچ ڪري سگهو ٿا ۽ سرور سان رابطي کي پيچ ڪري سگهو ٿا، ۽ صرف سرور تي انهن مقصدن لاء پري پروسيسر کي ترتيب ڏيو.
ايم ايم: - مان سمجهان ٿو ته اهو اڃا به آسان آهي. توھان ڪوڊ وٺو، ھڪڙو پيچ لاڳو ڪريو، پوء ان کي ترتيب ڏيو جيئن توھان کي ضرورت آھي - پراکسي سرور گڏ ڪريو (مثال طور، ODBC سان) ۽ پيچ ٿيل ڪوڊ کي سسٽم ۾ ورهايو. جتي ضروري هجي - هڪ پراکسي گڏ ڪريو، جتي ضروري هجي - هڪ سرور.
ج: - گهڻو ڪري، توهان کي اضافي طور تي سرور ڏانهن پراکسي ٽرانسميشن کي پيچ ڪرڻو پوندو؟
MCH: - نه، اهو معياري آهي.
ايم ايم: - حقيقت ۾، خيالن مان هڪ آواز نه آيو. اسان هميشه خيالن جي ڌماڪي ۽ تبديلين جي مقدار ۽ مدد جي آسانيءَ جي وچ ۾ توازن برقرار رکيو آهي.
ڪجھ اشتهار 🙂
اسان سان گڏ رهڻ لاء توهان جي مهرباني. ڇا توهان اسان جا مضمون پسند ڪندا آهيو؟ وڌيڪ دلچسپ مواد ڏسڻ چاهيو ٿا؟ آرڊر ڏيڻ يا دوستن کي سفارش ڪندي اسان جي مدد ڪريو، , داخلا-سطح سرورز جو هڪ منفرد اينالاگ، جيڪو اسان توهان لاءِ ايجاد ڪيو هو: (RAID1 ۽ RAID10 سان دستياب آهي، 24 ڪور تائين ۽ 40GB DDR4 تائين).
ڊيل R730xd 2x سستا Equinix Tier IV ڊيٽا سينٽر ۾ Amsterdam ۾؟ صرف هتي هالينڊ ۾! ڊيل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 کان! جي باري ۾ پڙهو
جو ذريعو: www.habr.com