بايوينو - ورهايل، اسپيبلبل ميٽرڪ ايگريگيٽر

تنهنڪري توهان ميٽرڪ گڏ ڪيو. جيئن اسان آهيون. اسان پڻ ميٽرڪ گڏ ڪندا آهيون. يقينا، ڪاروبار لاء ضروري آهي. اڄ اسان اسان جي مانيٽرنگ سسٽم جي پهرين ڪڙي بابت ڳالهائينداسين - هڪ statsd-مطابقت وارو مجموعي سرور بايوينو، اسان اهو ڇو لکيو ۽ ڇو اسان بربڪ کي ڇڏي ڏنو.

اسان جي پوئين مضمونن مان (1, 2) توهان اهو ڳولي سگهو ٿا ته ڪجهه وقت تائين اسان استعمال ڪندي نشان گڏ ڪيا بربڪ. اهو سي ۾ لکيل آهي. ڪوڊ جي نقطي نظر کان، اهو هڪ پلگ جيترو سادو آهي (اهو ضروري آهي جڏهن توهان حصو ڏيڻ چاهيو ٿا) ۽، سڀ کان اهم، اهو اسان جي مقدار کي 2 ملين ميٽرڪس في سيڪنڊ (MPS) جي چوٽي تي سنڀاليندو آهي. بغير ڪنهن پريشاني جي. دستاويز بيان ڪري ٿو 4 ملين ايم پي ايس لاءِ اسٽريڪ سان. ان جو مطلب اهو آهي ته توهان بيان ڪيل انگ اکر حاصل ڪندا جيڪڏهن توهان نيٽ ورڪ کي لينڪس تي صحيح طور تي ترتيب ڏيو. (اسان کي خبر ناهي ته توهان ڪيترا ايم پي ايس حاصل ڪري سگهو ٿا جيڪڏهن توهان نيٽ ورڪ کي ڇڏي ڏيو). انهن فائدن جي باوجود، اسان کي بربڪ بابت ڪيتريون ئي سنگين شڪايتون هيون.

دعويٰ 1. Github، منصوبي جي ڊولپر، ان کي سپورٽ ڪرڻ بند ڪيو: پيچ ۽ فيڪس شايع ڪرڻ، اسان کي قبول ڪرڻ ۽ (صرف اسان جي) پي آر. گذريل ڪجهه مهينن ۾ (ڪٿي ڪٿي فيبروري-مارچ 2018 کان)، سرگرميون ٻيهر شروع ٿي ويون آهن، پر ان کان اڳ تقريبا 2 سال مڪمل پرامن هئا. ان کان علاوه، منصوبي کي ترقي ڪري رهيو آهي اندروني Gihub جي ضرورتن لاء، جيڪو نئين خاصيتن جي تعارف لاءِ سنگين رڪاوٽ بڻجي سگهي ٿو.

دعويٰ 2. حساب جي درستگي. Brubeck مجموعي لاء مجموعي طور تي 65536 قدر گڏ ڪري ٿو. اسان جي حالت ۾، ڪجهه ميٽرڪس لاء، مجموعي مدت (30 سيڪنڊن) دوران، تمام گهڻو قدر اچي سگھي ٿو (چوٽي تي 1). ھن نموني جي نتيجي ۾، وڌ ۾ وڌ ۽ گھٽ ۾ گھٽ قدر بيڪار نظر اچن ٿا. مثال طور، هن طرح:

جيئن هو

ڪيئن ٿيڻ گهرجي ها

ساڳئي سبب لاء، رقم عام طور تي غلط حساب سان ڳڻيا ويا آهن. هتي 32-bit فلوٽ اوور فلو سان هڪ بگ شامل ڪريو، جيڪو عام طور تي سرور کي سيگفالٽ ڏانهن موڪلي ٿو جڏهن بظاهر معصوم ميٽرڪ حاصل ڪري ٿي، ۽ سڀ ڪجهه عظيم ٿي وڃي ٿو. بگ، رستي ۾، مقرر نه ڪيو ويو آهي.

۽ نيٺ دعوي ايڪس. لکڻ جي وقت تي، اسان ان کي پيش ڪرڻ لاء تيار آهيون سڀني 14 وڌيڪ يا گهٽ ڪم ڪندڙ statsd لاڳو ڪندڙ جيڪي اسان ڳولڻ جي قابل هئا. اچو ته تصور ڪريون ته ڪجهه سنگل انفراسٽرڪچر ايتري ترقي ڪئي آهي جو 4 ملين ايم پي ايس کي قبول ڪرڻ ڪافي ناهي. يا اڃا ته اهو اڃا نه وڌيو آهي، پر ميٽرڪس توهان لاءِ اڳ ۾ ئي اهم آهن ته چارٽ ۾ 2-3 منٽ جي گهٽتائي به اڳ ۾ ئي نازڪ ٿي سگهي ٿي ۽ مينيجرز جي وچ ۾ ناقابل برداشت ڊپريشن جو سبب بڻجي سگهي ٿي. جيئن ته ڊپريشن جو علاج هڪ شڪرگذار ڪم آهي، ٽيڪنيڪل حل جي ضرورت آهي.

پهرين، غلطي رواداري، انهي ڪري ته سرور تي اوچتو مسئلو آفيس ۾ هڪ نفسياتي زومبي apocalypse جو سبب ناهي. ٻيو، 4 ملين ايم پي ايس کان وڌيڪ قبول ڪرڻ جي قابل ٿيڻ لاءِ اسڪيلنگ، لينڪس نيٽ ورڪ اسٽيڪ ۾ گہرا کوٽڻ کان سواءِ ۽ آرام سان ”موڙ ۾“ وڌندي گهربل سائيز تائين.

جيئن ته اسان وٽ اسڪيلنگ لاءِ ڪمرو هو، اسان غلطي رواداري سان شروع ڪرڻ جو فيصلو ڪيو. ”اٽڪل! عيب رواداري! اهو سادو آهي، اسان اهو ڪري سگهون ٿا،“ اسان سوچيو ۽ 2 سرور شروع ڪيا، هر هڪ تي بربڪ جي ڪاپي وڌائيندي. هن کي ڪرڻ لاءِ، اسان کي نقل ڪرڻو پوندو ميٽرڪس سان گڏ ٻنهي سرورن تي ۽ ان لاءِ به لکڻو پوندو ننڍي افاديت. اسان هن سان غلطي رواداري جو مسئلو حل ڪيو، پر ... تمام سٺو ناهي. پهرين ۾ سڀ ڪجهه سٺو لڳي رهيو هو: هر بربڪ گڏ ڪرڻ جو پنهنجو نسخو گڏ ڪري ٿو، هر 30 سيڪنڊن ۾ هڪ ڀيرو گرافائٽ ڏانهن ڊيٽا لکي ٿو، پراڻي وقفي کي اوور رائٽنگ ڪري ٿو (اهو گريفائٽ پاسي تي ڪيو ويندو آهي). جيڪڏهن هڪ سرور اوچتو ناڪام ٿئي ٿو، اسان وٽ هميشه هڪ ٻيو هوندو آهي ان جي پنهنجي مجموعي ڊيٽا جي ڪاپي سان. پر هتي مسئلو آهي: جيڪڏهن سرور ناڪام ٿئي ٿو، هڪ "ڏٺو" گرافس تي ظاهر ٿئي ٿو. اهو هن حقيقت جي ڪري آهي ته بربڪ جي 30 سيڪنڊن جي وچ ۾ هم وقت سازي نه ڪئي وئي آهي، ۽ حادثي جي وقت انهن مان هڪ کي ختم نه ڪيو ويو آهي. جڏهن ٻيو سرور شروع ٿئي ٿو، ساڳي شيء ٿئي ٿي. ڪافي قابل برداشت، پر مان بهتر چاهيان ٿو! اسڪاليبلٽي جو مسئلو پڻ دور نه ٿيو آهي. سڀئي ميٽرڪ اڃا تائين "پرواز" هڪ واحد سرور ڏانهن، ۽ تنهنڪري اسان نيٽ ورڪ جي سطح تي منحصر ڪري، ساڳئي 2-4 ملين ايم پي ايس تائين محدود آهيون.

جيڪڏهن توهان مسئلي جي باري ۾ ٿورو سوچيو ٿا ۽ ساڳئي وقت هڪ بيلٽ سان برف کي کڙو ڪريو، هيٺ ڏنل واضح خيال ذهن ۾ اچي سگهي ٿو: توهان کي هڪ statsd جي ضرورت آهي جيڪا تقسيم موڊ ۾ ڪم ڪري سگهي ٿي. اهو آهي، جيڪو وقت ۽ ميٽرڪس ۾ نوڊس جي وچ ۾ هم وقت سازي کي لاڳو ڪري ٿو. ”يقيناً، اهڙو حل شايد اڳ ۾ ئي موجود آهي،“ اسان چيو ۽ گوگل ڏانهن وياسون…. ۽ انهن کي ڪجهه به نه مليو. مختلف statsd لاءِ دستاويزن ذريعي وڃڻ کان پوءِ (https://github.com/etsy/statsd/wiki#server-implementations ڊسمبر 11.12.2017، XNUMX تائين)، اسان کي بلڪل ڪجھ به نه مليو. ظاهري طور تي، نه ئي ڊولپرز ۽ نه ئي انهن حلن جا استعمال ڪندڙ اڃا تائين SO ڪيترن ئي ميٽرڪس کي منهن ڏئي چڪا آهن، ٻي صورت ۾ اهي ضرور ضرور ڪجهه کڻي ايندا.

۽ پوءِ اسان کي ”راند“ statsd - bioyino جي باري ۾ ياد آيو، جيڪو Just for Fun hackathon تي لکيو ويو هو (پراجيڪٽ جو نالو هيڪاٿون جي شروع ٿيڻ کان اڳ اسڪرپٽ پاران ٺاهيل هو) ۽ محسوس ڪيو ته اسان کي فوري طور تي پنهنجي statsd جي ضرورت آهي. ڇا جي لاءِ؟

• ڇاڪاڻ ته دنيا ۾ تمام گهٽ statsd کلون آهن،
• ڇاڪاڻ ته اهو ممڪن آهي ته گهربل هجي يا گهربل غلطي جي رواداري ۽ اسڪاليبلٽي جي ويجهو هجي (بشمول سرور جي وچ ۾ مجموعي ميٽرڪ کي هم وقت سازي ڪرڻ ۽ تڪرار موڪلڻ جو مسئلو حل ڪرڻ)،
• ڇاڪاڻ ته اهو ممڪن آهي ته ميٽرڪ جي حساب سان بربيڪ جي ڀيٽ ۾ وڌيڪ صحيح،
• ڇاڪاڻ ته توهان پاڻ وڌيڪ تفصيلي انگ اکر گڏ ڪري سگهو ٿا، جيڪي بربڪ عملي طور اسان کي مهيا نه ڪيا آهن،
• ڇاڪاڻ ته مون کي پنهنجي پنهنجي هائپرپرفارمنس ورهايل اسڪيل ليب ايپليڪيشن کي پروگرام ڪرڻ جو موقعو مليو، جيڪو مڪمل طور تي ٻي ساڳئي هائپر جي فن تعمير کي نه ورجائيندو... خير، اهو ئي آهي.

ڇا تي لکجي؟ يقينا، Rust ۾. ڇو؟

• ڇاڪاڻ ته اتي اڳ ۾ ئي هڪ پروٽوٽائپ حل هو،
• ڇاڪاڻ ته آرٽيڪل جو ليکڪ ان وقت اڳ ۾ ئي زنگ کي ڄاڻندو هو ۽ ان کي اوپن سورس ۾ رکڻ جي موقعي سان پيداوار لاءِ ان ۾ ڪجهه لکڻ جو خواهشمند هو.
• ڇاڪاڻ ته GC سان ٻوليون اسان لاءِ موزون نه آهن ڇاڪاڻ ته موصول ٿيندڙ ٽريفڪ جي نوعيت جي ڪري (تقريبا حقيقي وقت) ۽ GC روڪ عملي طور تي ناقابل قبول آهن،
• ڇاڪاڻ ته توهان کي C جي مقابلي ۾ وڌ کان وڌ ڪارڪردگي جي ضرورت آهي
• ڇاڪاڻ ته مورچا اسان کي بي خوف مطابقت فراهم ڪري ٿو، ۽ جيڪڏهن اسان ان کي C/C++ ۾ لکڻ شروع ڪريون ها، ته اسان کي بروبڪ کان به وڌيڪ ڪمزورين، بفر اوور فلوز، نسل جي حالتن ۽ ٻين خوفناڪ لفظن ۾ شامل ڪيو وڃي ها.

راس جي خلاف به هڪ دليل هو. ڪمپنيء کي رسٽ ۾ پروجيڪٽ ٺاهڻ جو ڪو به تجربو نه هو، ۽ هاڻي اسان ان کي مکيه منصوبي ۾ استعمال ڪرڻ جو منصوبو ناهي. تنهن ڪري، سخت خوف هئا ته ڪجهه به ڪم نه ڪندو، پر اسان هڪ موقعو وٺڻ جو فيصلو ڪيو ۽ ڪوشش ڪئي.

وقت گذري ويو...

آخرڪار، ڪيترن ئي ناڪام ڪوششن کان پوء، پهريون ڪم ڪندڙ نسخو تيار ڪيو ويو. ڇا ٿيو؟ ائين ئي ٿيو.

هر نوڊ حاصل ڪري ٿو پنهنجي ميٽرڪس جو پنهنجو سيٽ ۽ انهن کي گڏ ڪري ٿو، ۽ انهن قسمن جي ميٽرڪس کي مجموعي نه ڪندو آهي جتي انهن جي مڪمل سيٽ کي حتمي مجموعي لاء گهربل هجي. نوڊس ھڪ ٻئي سان ڳنڍيل آھن ھڪڙي قسم جي ورهايل تالا پروٽوڪول سان، جيڪو توھان کي انھن مان صرف ھڪڙو چونڊڻ جي اجازت ڏئي ٿو (هتي اسان روئي رھيا آھيو) جيڪو عظيم ھڪڙي ڏانھن ميٽرڪ موڪلڻ جي لائق آھي. اهو مسئلو هن وقت حل ڪيو پيو وڃي قونصل، پر مستقبل ۾ ليکڪ جي عزائم کي وڌايو پنهنجو عمل درآمد رافٽ، جتي سڀ کان وڌيڪ لائق هڪ هوندو، يقينا، متفقه اڳواڻ نوڊ هوندو. اتفاق راءِ کان علاوه، نوڊس اڪثر ڪري (هڪ ڀيرو في سيڪنڊ ڊفالٽ) پنهنجن پاڙيسرين ڏانهن موڪليندا آهن اهي اڳڪٿي ٿيل ميٽرڪ جا حصا جيڪي انهن انهي سيڪنڊ ۾ گڏ ڪرڻ ۾ منظم ڪيا. اهو ظاهر ٿئي ٿو ته اسڪيلنگ ۽ غلطي رواداري محفوظ آهن - هر نوڊ اڃا تائين ميٽرڪس جو پورو سيٽ رکي ٿو، پر ميٽرڪس اڳ ۾ ئي موڪليا ويا آهن، TCP ذريعي ۽ هڪ بائنري پروٽوڪول ۾ انڪوڊ ٿيل آهن، تنهنڪري نقل جي قيمتون UDP جي مقابلي ۾ گهٽجي وينديون آهن. اچڻ واري ميٽرڪس جي وڏي تعداد جي باوجود، گڏ ڪرڻ لاء تمام گهٽ ياداشت جي ضرورت آهي ۽ اڃا به گهٽ سي پي يو. اسان جي انتهائي compressible mertics لاء، هي ڊيٽا جي صرف چند ڏهن ميگا بائيٽ آهي. اضافي بونس جي طور تي، اسان Graphite ۾ غير ضروري ڊيٽا ٻيهر لکندا آهيون، جيئن بربڪ سان معاملو هو.

ميٽرڪس سان يو ڊي پي پيڪٽ هڪ سادي گول رابن ذريعي نيٽ ورڪ سامان تي نوڊس جي وچ ۾ غير متوازن آهن. يقينن، نيٽ ورڪ هارڊويئر پيڪٽس جي مواد کي پارس نٿو ڪري ۽ تنهن ڪري 4M پيڪٽس في سيڪنڊ کان وڌيڪ کڄي سگهي ٿو، ميٽرڪ جو ذڪر نه ڪرڻ جنهن بابت اهو ڪجهه به نه ٿو ڄاڻي. جيڪڏهن اسان اهو خيال رکون ٿا ته ميٽرڪ هڪ وقت ۾ هر پيٽ ۾ نه ايندا آهن، پوء اسان هن جڳهه ۾ ڪارڪردگي جي ڪنهن به مسئلي جي اڳڪٿي نه ڪندا آهيون. جيڪڏهن سرور حادثو ٿئي ٿو، نيٽ ورڪ ڊوائيس جلدي (1-2 سيڪنڊن جي اندر) هن حقيقت کي ڳولي ٿو ۽ خراب ٿيل سرور کي گردش کان هٽائي ٿو. انهي جي نتيجي ۾، غير فعال (يعني، غير ليڊر) نوڊس کي بند ڪري سگھجي ٿو ۽ عملي طور تي چارٽ تي گهٽتائي کي نوٽيس ڪرڻ کان سواء. وڌ ۾ وڌ جيڪو اسان وڃائي ڇڏيو آهي اهو ميٽرڪس جو حصو آهي جيڪو آخري سيڪنڊ ۾ آيو. ليڊر جو اوچتو نقصان/شٽ ڊائون/سوئچ اڃا به هڪ معمولي انتشار پيدا ڪندو (30 سيڪنڊ جو وقفو اڃا به هم وقت سازي کان ٻاهر آهي)، پر جيڪڏهن نوڊس جي وچ ۾ رابطي ۾ آهي، انهن مسئلن کي گهٽائي سگهجي ٿو، مثال طور، هم وقت سازي پيڪيٽس موڪلڻ سان. .

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

ڳڻپ (مجموعي لاءِ ذميوار) حصو ڪافي بورنگ آهي. نيٽ ورڪ جي وهڪري سان ڀريل بفر ڳڻپ جي وهڪري جي وچ ۾ ورهايا ويندا آهن، جتي انهن کي بعد ۾ پارس ڪيو ويندو آهي ۽ گڏ ڪيو ويندو آهي. درخواست تي، ميٽرڪ ٻين نوڊس ڏانهن موڪلڻ لاء ڏنل آهن. اهو سڀ ڪجهه، بشمول نوڊس جي وچ ۾ ڊيٽا موڪلڻ ۽ قونصل سان ڪم ڪرڻ، فريم ورڪ تي هلندڙ، غير مطابقت سان ڪيو ويندو آهي. tokio.

ترقي جي دوران وڌيڪ مسئلا نيٽ ورڪ جو حصو ميٽرڪ حاصل ڪرڻ لاء ذميوار هئا. نيٽ ورڪ جي وهڪري کي الڳ الڳ ادارن ۾ ڌار ڪرڻ جو بنيادي مقصد ان وقت کي گهٽائڻ جي خواهش هئي جيڪا وهڪري خرچ ڪري ٿي. نه ساکٽ مان ڊيٽا پڙهڻ لاء. غير مطابقت رکندڙ UDP استعمال ڪرڻ جا اختيار ۽ باقاعده recvmsg جلدي غائب ٿي ويا: پهريون استعمال ڪندڙ تمام گهڻو استعمال ڪندڙ-اسپيس سي پي يو ايونٽ پروسيسنگ لاءِ، ٻئي کي تمام گهڻن حوالن جي سوئچز جي ضرورت آهي. تنهن ڪري اهو هاڻي استعمال ڪيو ويندو آهي recvmmsg وڏن بفرن سان (۽ بفر، حضرات آفيسر، توهان لاء ڪجھ به نه آهن!). باقاعده UDP لاءِ سپورٽ ھلڪي ڪيسن لاءِ رکيل آھي جتي recvmmsg جي ضرورت ناھي. ملٽي ميسيج موڊ ۾، اهو ممڪن آهي ته بنيادي شيءِ حاصل ڪرڻ: وقت جي وڏي اڪثريت، نيٽ ورڪ ٿريڊ او ايس جي قطار کي ريڪ ڪري ٿو - ساکٽ مان ڊيٽا پڙهي ٿو ۽ ان کي يوزر اسپيس بفر ڏانهن منتقل ڪري ٿو، صرف ڪڏهن ڪڏهن مٽائڻ لاءِ ڀريو بفر ڏيڻ لاءِ. جمع ڪندڙ. ساکٽ ۾ قطار عملي طور تي جمع نه ٿيندي آهي، گراهڪ پيڪٽس جو تعداد عملي طور تي نه وڌندو آهي.

ويچاري

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

آخرڪار، چارٽ عاشق لاء ڪجهه چارٽ.

هر سرور لاءِ ايندڙ ميٽرڪ جي تعداد تي انگ اکر: 2 ملين ايم پي ايس کان وڌيڪ.

ھڪڙي نوڊس کي غير فعال ڪرڻ ۽ ايندڙ ميٽرڪ کي ٻيهر ورهائڻ.

انگ اکر نڪرندڙ ميٽرڪ تي: صرف هڪ نوڊ هميشه موڪلي ٿو - ريڊ باس.

هر نوڊ جي آپريشن جا انگ اکر، مختلف سسٽم ماڊلز ۾ اڪائونٽ جي غلطين کي کڻڻ.

ايندڙ ميٽرڪ جي تفصيل (ميٽرڪ نالا لڪيل آهن).

اسان هن سڀني سان اڳتي وڌڻ جي ڪهڙي رٿابندي ڪري رهيا آهيون؟ يقينا، ڪوڊ لکو، لعنت...! پروجيڪٽ اصل ۾ منصوبابندي ڪئي وئي هئي اوپن سورس ۽ ائين ئي رهندو سڄي زندگي. اسان جي فوري منصوبن ۾ اسان جي رافٽ جي ورزن کي تبديل ڪرڻ، پير پروٽوڪول کي وڌيڪ پورٽبل ۾ تبديل ڪرڻ، اضافي اندروني انگ اکر متعارف ڪرائڻ، نئين قسم جا ميٽرڪس، بگ فيڪس ۽ ٻيون سڌارا شامل آهن.

يقينن، منصوبي جي ترقي ۾ مدد ڪرڻ لاء هرڪو خوش آمديد آهي: پي آر ٺاهيو، مسئلا، جيڪڏهن ممڪن هجي ته اسان جواب ڏينداسين، بهتر، وغيره.

ان سان گڏ چيو پيو وڃي ته، اهو سڀ ماڻهو، اسان جا هاٿي خريد ڪريو!

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