هيلو هرڪو، منهنجو نالو اليگزينڊر آهي، مان هڪ انجنيئر طور CIAN ۾ ڪم ڪريان ٿو ۽ سسٽم انتظاميه ۽ انفراسٽرڪچر جي عملن جي خودڪار ۾ شامل آهيان. پوئين مضمونن مان ھڪڙي جي تبصرن ۾، اسان کي ٻڌايو ويو آھي ته اسان کي روزانو 4 ٽي بي لاگ ڪٿي ملن ٿا ۽ اسان انھن سان ڇا ڪندا آھيون. ها، اسان وٽ ڪيترائي لاگ آهن، ۽ انهن کي پروسيس ڪرڻ لاءِ هڪ الڳ انفراسٽرڪچر ڪلسٽر ٺاهيو ويو آهي، جيڪو اسان کي جلدي مسئلن کي حل ڪرڻ جي اجازت ڏئي ٿو. هن آرٽيڪل ۾ آئون انهي بابت ڳالهائيندس ته اسان ان کي هڪ سال جي عرصي دوران ڊيٽا جي وڌندڙ وهڪري سان ڪم ڪرڻ لاءِ ڪيئن ٺاهيو.
اسان ڪٿان شروع ڪيو؟
گذريل ڪجھ سالن کان، cian.ru تي لوڊ تمام تيزيء سان وڌيو آھي، ۽ 2018 جي ٽئين چوٿين تائين، وسيلن جي ٽرئفڪ 11.2 ملين منفرد استعمال ڪندڙن تائين پھچي. ان وقت، نازڪ لمحن تي اسان لاگز جو 40 سيڪڙو تائين وڃائي ڇڏيو، اهو ئي سبب آهي ته اسان جلدي واقعن کي منهن نه ڏئي سگهيا ۽ انهن کي حل ڪرڻ لاء گهڻو وقت ۽ ڪوشش خرچ ڪيو. اسان اڪثر ڪري مسئلي جو سبب ڳولي نه سگهيا آهيون، ۽ اهو ڪجهه وقت کان پوء ٻيهر ٿيندو. اهو دوزخ هو ۽ ان بابت ڪجهه ڪرڻو هو.
ان وقت، اسان استعمال ڪيو 10 ڊيٽا نوڊس جو ڪلسٽر ايلسٽسٽڪ سرچ ورزن 5.5.2 سان معياري انڊيڪس سيٽنگن سان لاگز کي ذخيرو ڪرڻ لاءِ. اهو هڪ سال اڳ کان وڌيڪ مشهور ۽ سستي حل جي طور تي متعارف ڪرايو ويو هو: پوء لاگز جي وهڪري ايتري وڏي نه هئي، غير معياري ترتيبن سان گڏ اچڻ ۾ ڪو به اشارو نه هو.
ايندڙ لاگن جي پروسيسنگ Logstash پاران مهيا ڪئي وئي هئي مختلف بندرگاهن تي پنجن ElasticSearch Coordinators تي. ھڪڙي انڊيڪس، سائيز جي لحاظ کان، پنجن حصن تي مشتمل آھي. هڪ ڪلاڪ ۽ روزاني گردش منظم ڪئي وئي، نتيجي طور، ڪلستر ۾ هر ڪلاڪ تقريبا 100 نوان شارڊ ظاهر ٿيا. جڏهن ته تمام گھڻا لاگ نه هئا، ڪلستر چڱي طرح نقل ڪيو ۽ ڪو به ان جي سيٽنگن تي ڌيان نه ڏنو.
تيز رفتار ترقي جا چئلينج
ٺاهيل لاگز جو حجم تمام تيزيء سان وڌيو، جيئن ٻه عمل هڪ ٻئي کان مٿي ٿي ويا. هڪ پاسي، خدمت جي استعمال ڪندڙن جو تعداد وڌي رهيو آهي. ٻئي طرف، اسان فعال طور تي مائڪرو سروس آرڪيٽيڪچر ڏانهن سوئچ ڪرڻ شروع ڪيو، اسان جي پراڻي monoliths کي C# ۽ Python ۾ ڏٺو. ڪيترائي درجن نيون مائيڪرو سروسز جيڪي تبديل ڪيا ويا منولٿ جا حصا بنيادي طور تي انفراسٽرڪچر ڪلسٽر لاءِ وڌيڪ لاگ ٺاهيا.
اهو اسڪيلنگ هو جنهن اسان کي ان نقطي تي پهچايو جتي ڪلستر عملي طور تي غير منظم ٿي ويو. جڏهن لاگز 20 هزار ميسيج في سيڪنڊ جي رفتار سان اچڻ شروع ٿيا، بار بار بيڪار گردش شارڊز جو تعداد 6 هزار تائين وڌايو، ۽ هر نوڊ ۾ 600 کان وڌيڪ شارڊس هئا.
اهو رام جي مختص ڪرڻ سان مسئلن جو سبب بڻيو، ۽ جڏهن هڪ نوڊ خراب ٿي ويو، سڀئي شارڊ هڪ ئي وقت هلڻ شروع ڪيو، ٽرئفڪ کي ضرب ڪرڻ ۽ ٻين نوڊس کي لوڊ ڪرڻ، جنهن کي ڪلستر تي ڊيٽا لکڻ لڳ ڀڳ ناممڪن بڻائي ڇڏيو. ۽ ان عرصي دوران اسان بغير لاگن کان رهجي ويا هئاسين. ۽ جيڪڏهن سرور سان ڪو مسئلو هو، اسان بنيادي طور تي ڪلستر جو 1/10 وڃائي ڇڏيو. ننڍن انگن اکرن جو وڏو تعداد پيچيدگي شامل ڪيو.
لاگن کان سواء، اسان واقعي جي سببن کي سمجهي نه سگھندا هئاسين ۽ جلدي يا بعد ۾ ساڳئي ريڪ تي ٻيهر قدم کڻندا هئاسين، ۽ اسان جي ٽيم جي نظريي ۾ اهو ناقابل قبول هو، ڇاڪاڻ ته اسان جا سڀئي ڪم ميڪانيزم صرف ان جي سامهون ڪرڻ لاء ٺهيل آهن - ڪڏهن به نه ورجائي. ساڳيا مسئلا. ائين ڪرڻ لاءِ، اسان کي لاگز جي مڪمل مقدار جي ضرورت هئي ۽ انهن جي ترسيل تقريباً حقيقي وقت ۾، ڇو ته آن ڊيوٽي انجنيئرن جي هڪ ٽيم نه رڳو ميٽرڪس کان، پر لاگز مان پڻ خبرداري جي نگراني ڪئي. مسئلي جي پيماني کي سمجهڻ لاء، ان وقت لاگن جو ڪل مقدار تقريبا 2 ٽي بي في ڏينهن هو.
اسان لاگز جي نقصان کي مڪمل طور تي ختم ڪرڻ ۽ ELK ڪلستر تائين پهچائڻ جي وقت کي گھٽائڻ لاءِ هڪ مقصد مقرر ڪيو آهي وڌ ۾ وڌ 15 منٽن تائين فورس ميجر دوران (اسان بعد ۾ هن انگن اکرن تي انحصار ڪيو اندروني KPI).
نئين گردش ميڪانيزم ۽ گرم-گرم نوڊس
اسان 5.5.2 کان 6.4.3 تائين ElasticSearch ورجن کي اپڊيٽ ڪندي ڪلسٽر ڪنورشن شروع ڪيو. هڪ دفعو ٻيهر اسان جو نسخو 5 ڪلستر مري ويو، ۽ اسان ان کي بند ڪرڻ جو فيصلو ڪيو ۽ ان کي مڪمل طور تي اپڊيٽ ڪيو - اڃا تائين ڪوبه لاگ ان ناهي. تنهن ڪري اسان هن منتقلي کي صرف چند ڪلاڪن ۾ ڪيو.
هن اسٽيج تي سڀ کان وڏي پيماني تي تبديلي اپاچي ڪافڪا کي ٽن نوڊس تي لاڳو ڪرڻ هو جنهن ۾ ڪوآرڊينيٽر هڪ وچولي بفر طور شامل هو. پيغام بروکر اسان کي ElasticSearch جي مسئلن دوران لاگز وڃائڻ کان بچايو. ساڳئي وقت، اسان ڪلستر ۾ 2 نوڊس شامل ڪيا ۽ ڊيٽا سينٽر ۾ مختلف ريڪن ۾ واقع ٽن "گرم" نوڊس سان گرم-گرم آرڪيٽيڪچر ڏانهن تبديل ڪيو. اسان لاگز کي انهن ڏانهن منتقل ڪيو هڪ ماسڪ استعمال ڪندي جيڪو ڪنهن به حالت ۾ وڃائڻ نه گهرجي - nginx، انهي سان گڏ ايپليڪيشن ايرر لاگز. ننڍا لاگز باقي نوڊس ڏانهن موڪليا ويا - ڊيبگ، ڊيڄاريندڙ، وغيره، ۽ 24 ڪلاڪن کان پوء، "گرم" نوڊس مان "اهم" لاگز منتقل ڪيا ويا.
ننڍي انڊيڪس جي تعداد ۾ اضافو نه ڪرڻ لاء، اسان وقت جي گردش کان رول اوور ميڪانيزم کي تبديل ڪيو. فورمن تي تمام گهڻي ڄاڻ هئي ته انڊيڪس سائيز جي گردش بلڪل ناقابل اعتبار آهي، تنهنڪري اسان انڊيڪس ۾ دستاويزن جي تعداد جي ذريعي گردش استعمال ڪرڻ جو فيصلو ڪيو. اسان هر انڊيڪس جو تجزيو ڪيو ۽ دستاويزن جو تعداد رڪارڊ ڪيو جنهن کانپوءِ گردش کي ڪم ڪرڻ گهرجي. اهڙيء طرح، اسان پهچي ويا آهيون بهترين شارڊ سائيز - 50 GB کان وڌيڪ نه.
ڪلستر جي اصلاح
بهرحال، اسان مڪمل طور تي مسئلن کان نجات حاصل نه ڪئي آهي. بدقسمتيءَ سان، ننڍڙا انڊيڪس اڃا به ظاهر ٿيا: اهي مخصوص مقدار تائين نه پهتا هئا، نه گھميا ويا هئا، ۽ ٽن ڏينهن کان پراڻن انڊيڪسز جي عالمي صفائي ذريعي ختم ڪيا ويا، جتان اسان تاريخ جي حساب سان گردش کي هٽايو آهي. اهو ڊيٽا جي نقصان جو سبب بڻيو ان حقيقت جي ڪري ته ڪلسٽر مان انڊيڪس مڪمل طور تي غائب ٿي ويو، ۽ هڪ غير موجود انڊيڪس ڏانهن لکڻ جي ڪوشش ڪيوريٽر جي منطق کي ٽوڙي ڇڏيو جيڪو اسان انتظام لاء استعمال ڪيو. لکڻ لاءِ عرف انڊيڪس ۾ تبديل ٿي ويو ۽ رول اوور جي منطق کي ٽوڙيو ويو، ڪجهه انڊيڪسز جي 600 GB تائين غير ڪنٽرول ٿيل واڌ جو سبب بڻيو.
مثال طور، گردش جي ترتيب لاء:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
جيڪڏهن ڪو رول اوور عرف نه هو، هڪ غلطي ٿي وئي:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
اسان هن مسئلي جو حل ايندڙ ورهاڱي لاءِ ڇڏي ڏنو ۽ ٻيو مسئلو ورتو: اسان Logstash جي پل لاجڪ ڏانهن رخ ڪيو، جيڪو ايندڙ لاگن کي پروسيس ڪري ٿو (غير ضروري معلومات کي هٽائڻ ۽ بهتر ڪرڻ). اسان ان کي ڊاڪر ۾ رکيو، جيڪو اسان ڊاڪر-ڪمپوز ذريعي لانچ ڪيو، ۽ اسان اتي لاگ اسٽاش ايڪسپورٽر پڻ رکيا، جيڪو لاگ اسٽريم جي آپريشنل مانيٽرنگ لاءِ پروميٿيس کي ميٽرڪس موڪلي ٿو. هن طريقي سان اسان پاڻ کي اهو موقعو ڏنو ته هر قسم جي لاگ ان جي پروسيسنگ لاءِ ذميوار لاگ اسٽاش مثالن جي تعداد کي آساني سان تبديل ڪري سگهون.
جڏهن اسان ڪلسٽر کي بهتر ڪري رهيا هئاسين، cian.ru جي ٽرئفڪ هر مهيني 12,8 ملين منفرد صارفين تائين وڌي وئي. نتيجي طور، اهو ظاهر ٿيو ته اسان جي تبديلين جي پيداوار ۾ تبديلين جي پويان ٿورڙي هئي، ۽ اسان کي حقيقت سان منهن ڏيڻو پيو ته "گرم" نوڊس لوڊ سان مقابلو نه ڪري سگهيو ۽ لاگز جي پوري پهچائڻ کي سست ڪري ڇڏيو. اسان حاصل ڪيو "گرم" ڊيٽا بغير ناڪامي، پر اسان کي باقي جي ترسيل ۾ مداخلت ڪرڻو پيو ۽ انڊيڪس کي برابر طور تي ورهائڻ لاء هڪ دستي رول اوور ڪيو.
ساڳي ئي وقت، ڪلسٽر ۾ لاگ اسٽاش مثالن جي سيٽنگن کي ماپڻ ۽ تبديل ڪرڻ ان حقيقت جي ڪري پيچيده ٿي ويو هو ته اهو هڪ مقامي ڊاکر-ڪپوز هو، ۽ سڀئي عمل دستي طور تي ڪيا ويا هئا (نئين سرن کي شامل ڪرڻ لاء، اهو ضروري هو ته دستي طور تي سڀني جي ذريعي وڃڻ گهرجي. سرورز ڪريو ۽ ڊاڪر-ڪپوز اپ -d هر جڳهه ڪريو).
لاگ ٻيهر ورڇ
هن سال جي سيپٽمبر ۾، اسان اڃا تائين monolith کي ڪٽي رهيا هئاسين، ڪلستر تي لوڊ وڌندي هئي، ۽ لاگز جو وهڪرو 30 هزار پيغام في سيڪنڊ جي ويجهو اچي رهيو هو.
اسان هڪ هارڊويئر اپڊيٽ سان ايندڙ ورهاڱي شروع ڪيو. اسان پنجن ڪوآرڊينيٽرن مان مٽائي ٽن ڏانھن، ڊيٽا نوڊس کي تبديل ڪيو ۽ پئسا ۽ اسٽوريج جي جڳھ جي لحاظ کان کٽيو. نوڊس لاءِ اسان ٻه ترتيبون استعمال ڪريون ٿا:
- "گرم" نوڊس لاءِ: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 لاءِ Hot1 ۽ 3 لاءِ Hot2).
- "گرم" نوڊس لاءِ: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
هن ورهاڱي تي، اسان انڊيڪس کي مائڪرو سروسز جي رسائي لاگز سان منتقل ڪيو، جيڪو ساڳيو جاء وٺندو آهي جيئن فرنٽ لائين نينڪس لاگز، ٽن "گرم" نوڊس جي ٻئي گروپ ڏانهن. اسان ھاڻي ڊيٽا کي "گرم" نوڊس تي 20 ڪلاڪن تائين ذخيرو ڪندا آھيون، ۽ پوء انھن کي "گرم" نوڊس ڏانھن منتقل ڪريون ٿا باقي لاگز ڏانھن.
اسان انهن جي گردش کي ٻيهر ترتيب ڏيڻ سان غائب ٿيڻ واري ننڍڙي انڊيڪس جو مسئلو حل ڪيو. هاڻي انڊيڪس هر 23 ڪلاڪن ۾ گھمايو وڃي ٿو ڪنهن به صورت ۾، جيتوڻيڪ اتي ٿورڙي ڊيٽا آهي. اهو ٿورڙو شارڊز جو تعداد وڌايو (انهن مان اٽڪل 800 هئا)، پر ڪلستر جي ڪارڪردگي جي نقطي نظر کان، اهو قابل برداشت آهي.
نتيجي طور، ڪلستر ۾ ڇهه "گرم" ۽ صرف چار "گرم" نوڊس هئا. اهو ڊگهي وقت جي وقفن تي درخواستن تي ٿوري دير جو سبب آهي، پر مستقبل ۾ نوڊس جو تعداد وڌائڻ اهو مسئلو حل ڪندو.
اهو تڪرار پڻ نيم خودڪار اسڪيلنگ جي کوٽ جو مسئلو حل ڪيو. هن کي ڪرڻ لاء، اسان هڪ انفراسٽرڪچر نومڊ ڪلستر کي ترتيب ڏنو - جيڪو اسان اڳ ۾ ئي پيداوار ۾ لڳايو آهي. في الحال، Logstash جو مقدار خودڪار طور تي لوڊ جي لحاظ کان تبديل نٿو ڪري، پر اسان ان تي اچي وينداسين.
مستقبل لاء منصوبا
لاڳو ڪيل ٺاھ جوڙ مڪمل طور تي اسڪيل آھي، ۽ ھاڻي اسان 13,3 TB ڊيٽا کي ذخيرو ڪريون ٿا - سڀ لاگ 4 ڏينھن لاء، جيڪي خبردارين جي هنگامي تجزيي لاء ضروري آھن. اسان ڪجھ لاگز کي ميٽرڪس ۾ تبديل ڪندا آهيون، جن کي اسان Graphite ۾ شامل ڪندا آهيون. انجنيئرن جي ڪم کي آسان بڻائڻ لاءِ، اسان وٽ انفراسٽرڪچر ڪلسٽر لاءِ ميٽرڪس ۽ عام مسئلن جي نيم خودڪار مرمت لاءِ اسڪرپٽ آهن. ڊيٽا نوڊس جو تعداد وڌائڻ کان پوء، جيڪو ايندڙ سال لاء رٿابندي ڪئي وئي آهي، اسان 4 کان 7 ڏينهن تائين ڊيٽا اسٽوريج ڏانهن تبديل ڪنداسين. اهو آپريشنل ڪم لاءِ ڪافي هوندو، ڇاڪاڻ ته اسان هميشه ڪوشش ڪندا آهيون ته جلد کان جلد واقعن جي جاچ ڪريون، ۽ ڊگهي مدي واري تحقيق لاءِ ٽيلي ميٽري ڊيٽا موجود آهي.
آڪٽوبر 2019 ۾، cian.ru ڏانهن ٽريفڪ اڳ ۾ ئي وڌي چڪو هو 15,3 ملين منفرد صارفين هر مهيني. اهو لاگس پهچائڻ لاء تعميراتي حل جو هڪ سنگين امتحان بڻجي ويو.
ھاڻي اسان تيار ڪري رھيا آھيون ElasticSearch کي ورجن 7 ۾ اپ ڊيٽ ڪرڻ لاءِ. پر ان لاءِ اسان کي ElasticSearch ۾ ڪيترن ئي انڊيڪسز جي ميپنگ کي اپڊيٽ ڪرڻو پوندو، ڇاڪاڻ ته اھي ورجن 5.5 مان ھليا ويا آھن ۽ ورجن 6 ۾ ختم ٿيل قرار ڏنا ويا آھن (اھي رڳو ورزن ۾ موجود ناھن. 7). هن جو مطلب اهو آهي ته تازه ڪاري جي عمل دوران اتي ضرور ڪجهه قسم جي قوت جو شڪار هوندو، جيڪو اسان کي بغير لاگ ان ڪري ڇڏيندو جڏهن مسئلو حل ڪيو ويندو. نسخو 7 جو، اسان سڀ کان وڌيڪ منتظر آهيون Kibana هڪ بهتر انٽرفيس ۽ نئين فلٽر سان.
اسان پنھنجو بنيادي مقصد حاصل ڪيو: اسان لاگز کي وڃائڻ بند ڪيو ۽ انفراسٽرڪچر ڪلسٽر جي گھٽتائي کي گھٽائي ڇڏيو 2-3 حادثن في ھفتي کان ڪجھ ڪلاڪ سار سنڀال جو ڪم في مھينا. پيداوار ۾ هي سڀ ڪم لڳ ڀڳ پوشيده آهي. بهرحال، هاڻي اسان اهو طئي ڪري سگهون ٿا ته اسان جي خدمت سان ڇا ٿي رهيو آهي، اسان جلدي ڪري سگهون ٿا خاموش موڊ ۾ ۽ پريشان نه ڪريو ته لاگز گم ٿي ويندا. عام طور تي، اسان مطمئن، خوش ۽ نئين ڪارناما لاء تيار آهيون، جنهن بابت اسان بعد ۾ ڳالهائينداسين.
جو ذريعو: www.habr.com