لاگز سسٽم جو هڪ اهم حصو آهن، توهان کي سمجهڻ جي اجازت ڏئي ٿي ته اهو ڪم ڪري ٿو (يا ڪم نٿو ڪري) جيئن توقع ڪئي وئي آهي. microservice فن تعمير جي حالتن هيٺ، لاگن سان ڪم ڪرڻ خاص اولمپياڊ جو هڪ الڳ نظم بڻجي ويندو آهي. اتي ڪيترائي مسئلا آھن جن کي حل ڪرڻ جي ضرورت آھي:
- ايپليڪيشن مان لاگس ڪيئن لکجي؛
- ڪٿي لاگ لکڻ لاء؛
- اسٽوريج ۽ پروسيسنگ لاءِ لاگ ڪيئن پهچائڻ؛
- لاگن کي ڪيئن پروسيس ۽ اسٽور ڪجي.
هن وقت مشهور ڪنٽينرائيزيشن ٽيڪنالاجيز جو استعمال مسئلو حل ڪرڻ جي اختيارن جي ميدان ۾ ريڪ جي چوٽي تي ريل شامل ڪري ٿو.
بس هن بابت يوري بشميليف جي رپورٽ جو نقل آهي "لاگ گڏ ڪرڻ ۽ پهچائڻ جي ميدان ۾ هڪ ريڪ جو نقشو"
ڪير پرواهه، مهرباني ڪري ٻلي جي هيٺان.
منهنجو نالو Yuri Bushmelev آهي. مان Lazada لاء ڪم ڪريان ٿو. اڄ مان ڳالهه ڪندس ته اسان پنهنجا لاگ ڪيئن ٺاهيا، اسان انهن کي ڪيئن گڏ ڪيو، ۽ اسان اتي ڇا لکون.
اسان ڪٿان جا آهيون؟ اسين ڪير آهيون؟ Lazada ڏکڻ اوڀر ايشيا جي ڇهن ملڪن ۾ #1 آن لائن پرچون ڪندڙ آهي. اهي سڀئي ملڪ ڊيٽا سينٽرن ۾ ورهايل آهن. ھاڻي ڪل 4 ڊيٽا سينٽر آھن. اھو ڇو ضروري آھي؟ ڇو ته ڪي فيصلا ان ڪري به ٿيا جو مرڪز جي وچ ۾ انتهائي ڪمزور رابطا آهن. اسان وٽ هڪ microservice فن تعمير آهي. مون کي حيرت ٿي ته اسان وٽ اڳ ۾ ئي 80 مائڪرو سروسز آهن. جڏهن مون لاگز سان ڪم شروع ڪيو، انهن مان صرف 20 هئا، ان سان گڏ، پي ايڇ پي جي ورثي جو هڪ تمام وڏو ٽڪرو آهي، جنهن سان مون کي پڻ رهڻو پوندو ۽ ان سان گڏ رکڻو پوندو. هي سڀ اسان لاءِ هن وقت 6 ملين پيغامن کان وڌيڪ في منٽ سسٽم لاءِ ٺاهي ٿو. وڌيڪ مان ڏيکاريندس ته اسان هن سان ڪيئن رهڻ جي ڪوشش ڪري رهيا آهيون، ۽ اهو ڇو آهي.
توهان کي انهن 6 ملين پيغامن سان گڏ رهڻو پوندو. اسان کي انهن سان ڇا ڪرڻ گهرجي؟ 6 ملين پيغامن جي ضرورت آهي:
- ايپ مان موڪليو
- پهچائڻ لاء قبول
- تجزيو ۽ اسٽوريج لاء پهچائڻ.
- تجزيو ڪرڻ
- ڪنهن به طرح اسٽور.
جڏهن ٽي لک نياپا هئا، مون کي به ساڳيو نظر آيو هو. ڇو ته اسان ڪجهه پئسن سان شروع ڪيو. اهو واضح آهي ته ايپليڪيشن لاگس اتي لکيل آهن. مثال طور، ڊيٽابيس سان ڳنڍي نه سگھيو، ڊيٽابيس سان ڳنڍي سگھيو، پر ڪجھ پڙھي نه سگھيو. پر ان کان علاوه، اسان جي microservices مان هر هڪ رسائي لاگ پڻ لکي ٿو. هر درخواست جيڪا مائڪرو سروس تي پهچي ٿي لاگ ۾ اچي ٿي. اسان ائين ڇو ڪري رهيا آهيون؟ ڊولپرز سراغ ڪرڻ جي قابل ٿيڻ چاهيندا آهن. هر رسائي لاگ ۾ ٽريس فيلڊ شامل آهي، جنهن جي مطابق هڪ خاص انٽرفيس پوء سڄي زنجير کي ختم ڪري ٿو ۽ خوبصورت طور تي نشان ڏيکاري ٿو. سراغ ڏيکاري ٿو ته درخواست ڪيئن ٿي وئي، ۽ اهو اسان جي ڊولپرز کي ڪنهن به اڻڄاتل گندگي سان تيزيء سان ڊيل ڪرڻ ۾ مدد ڪري ٿو.
ان سان ڪيئن رهجي؟ هاڻي آئون مختصر طور تي بيان ڪندس اختيارن جي فيلڊ - ڪيئن اهو مسئلو عام طور تي حل ڪيو ويندو آهي. لاگن کي گڏ ڪرڻ، منتقل ڪرڻ ۽ محفوظ ڪرڻ جو مسئلو ڪيئن حل ڪجي.
ايپليڪيشن مان ڪيئن لکجي؟ اهو واضح آهي ته اتي مختلف طريقا آهن. خاص طور تي، بهترين عمل آهي، جيئن فيشن وارا ڪامريڊ اسان کي ٻڌايو. پراڻي اسڪول جا ٻه قسم آهن، جيئن دادا چيو. ٻيا طريقا آهن.
لاگن جي گڏ ڪرڻ سان، صورتحال تقريبن ساڳي آهي. هن خاص حصي کي حل ڪرڻ لاء ڪيترائي اختيار نه آهن. انهن مان وڌيڪ آهن، پر اڃا تائين تمام گهڻا نه آهن.
پر ترسيل ۽ بعد ۾ تجزيي سان، مختلف قسمن جو تعداد ڌماڪو ٿيڻ شروع ٿئي ٿو. مان هر اختيار کي هاڻي بيان نه ڪندس. منهنجو خيال آهي ته مکيه اختيارن هر ڪنهن کي چڱي طرح ڄاڻن ٿا جيڪو موضوع ۾ دلچسپي رکندو هو.
مان توهان کي ڏيکاريندس ته اسان اهو ڪيئن ڪيو Lazada ۾ ۽ اهو سڀ ڪيئن شروع ٿيو.
هڪ سال اڳ، مون کي Lazada آيو ۽ لاگ ان منصوبي ڏانهن موڪليو ويو. اتي ائين ئي هو. اپليڪيشن مان لاگ stdout ۽ stderr ڏانهن لکيو ويو هو. هر شي کي فيشني طريقي سان ڪيو ويو. پر پوءِ ڊولپرز ان کي معياري اسٽريم مان ڪڍي ڇڏيو، ۽ پوءِ انفراسٽرڪچر جا ماهر ان کي ڪنهن به طرح معلوم ڪندا. انفراسٹرڪچر جي ماهرن ۽ ڊولپرز جي وچ ۾، اتي پڻ رليز ڪندڙ آهن جن چيو: "او ... چڱا، اچو ته صرف انهن کي شيل سان فائل ۾ لپي، ۽ اهو ئي آهي." ۽ جيئن ته اهو سڀ هڪ ڪنٽينر ۾ آهي، انهن ان کي صحيح ڪنٽينر ۾ ئي ويڙهي ڇڏيو، ڊاريڪٽري کي اندر ميپ ڪيو ۽ ان کي اتي رکيو. منهنجو خيال آهي ته اهو هر ڪنهن لاءِ واضح آهي ته ڇا ٿيو.
اچو ته ٿورو اڳتي ڏسو. اسان انهن لاگن کي ڪيئن پهچايو. ڪنهن چونڊيو td-ايجنٽ، جيڪو اصل ۾ رواني آهي پر بلڪل رواني ناهي. مان اڃا تائين انهن ٻن منصوبن جو تعلق نه سمجهي سگهيو آهيان، پر اهي ساڳيا شيء جي باري ۾ نظر اچن ٿا. ۽ هي رواني، روبي ۾ لکيل، لاگ فائلن کي پڙهو، انهن کي JSON ۾ پارس ڪيو ڪجهه باقاعده اظهار استعمال ڪندي. پوءِ انهن کي ڪافڪا ڏانهن موڪليو ويو. ان کان علاوه، ڪافڪا ۾، اسان وٽ هر API لاء 4 الڳ موضوع هئا. ڇو 4؟ ڇاڪاڻ ته اتي لائيو آهي، اتي اسٽيجنگ آهي، ۽ ڇاڪاڻ ته اتي stdout ۽ stderr آهي. ڊولپرز انهن کي پيدا ڪن ٿا، ۽ انفراسٽرڪچر ڪارڪنن کي انهن کي ڪافڪا ۾ پيدا ڪرڻ گهرجي. ان کان سواء، ڪافڪا کي هڪ ٻئي کاتي طرفان سنڀاليو ويو. ان ڪري، هڪ ٽڪيٽ ٺاهڻ ضروري هو ته جيئن انهن هر ايپ لاءِ اتي 4 عنوان ٺاهيا. هرڪو ان جي باري ۾ وساري ويو. عام طور تي، اهو ڪچرو ۽ فضول هو.
اسان ان سان اڳتي ڇا ڪيو؟ اسان ان کي ڪافڪا ڏانهن موڪليو. ڪافڪا کان اڳتي، لاگز جو اڌ حصو Logstash ڏانهن ويو. لاگن جو ٻيو اڌ حصو ورهايو ويو. ڪي هڪ گريلاگ ڏانهن ويا، ڪي ٻئي گريلوگ ڏانهن. نتيجي طور، هي سڀ هڪ Elasticsearch ڪلستر ۾ ڀڄي ويو. اهو آهي، اهو سڀ گندا اتي ئي ختم ٿي ويو. توهان کي اهو ڪرڻ جي ضرورت ناهي!
جڏهن مٿي کان ڏٺو وڃي ته اهو ئي ڏسڻ ۾ اچي ٿو. توهان کي اهو ڪرڻ جي ضرورت ناهي! هتي، مسئلا علائقن کي فوري طور تي نمبرن سان نشان لڳل آهن. اصل ۾ انهن مان وڌيڪ آهن، پر 6 واقعي مسئلا آهن، جن سان ڪجهه ڪرڻ جي ضرورت آهي. مان هاڻي انهن جي باري ۾ الڳ الڳ ٻڌائيندس.
هتي (1,2,3) اسان فائلون لکون ٿا ۽، مطابق، هتي هڪ ئي وقت ٽي ريڪ آهن.
پهريون (1) اهو آهي ته اسان کي انهن کي ڪٿي لکڻ جي ضرورت آهي. اهو هميشه گهربل ناهي ته هڪ API کي سڌو سنئون فائل تي لکڻ جي صلاحيت ڏيو. اهو ضروري آهي ته API کي هڪ ڪنٽينر ۾ الڳ ڪيو وڃي، ۽ اڃا به بهتر، ته اهو صرف پڙهڻ لاء هجي. مان هڪ سسٽم ايڊمنسٽريٽر آهيان، تنهنڪري مون وٽ انهن شين جو ٿورو متبادل نظريو آهي.
ٻيو نقطو (2,3) اهو آهي ته اسان وٽ تمام گهڻيون درخواستون آهن API ڏانهن. API هڪ فائل ڏانهن تمام گهڻو ڊيٽا لکي ٿو. فائلون وڌي رهيون آهن. اسان کي ان کي ڦيرائڻ جي ضرورت آهي. ڇو ته ٻي صورت ۾ توهان اتي ڪا به ڊسڪ محفوظ ڪرڻ جي قابل نه هوندا. انھن کي گھمڻ خراب آھي ڇو ته اھي شيل ذريعي ڊائريڪٽري ڏانھن موڪليا ويا آھن. ڪو به طريقو ناهي ته اسان ان کي ڦيرايو. توھان ائپليڪيشن کي ھٿن کي ٻيهر کولڻ لاءِ نٿا چئي سگھو. ڇو ته ڊولپرز توهان کي بيوقوف وانگر ڏسندا: ”ڪهڙو بيان ڪندڙ؟ اسان عام طور تي stdout ڏانهن لکندا آهيون. فريم ورڪ ڪاپي ٽرنڪيٽ کي لاگروٽ ۾ ٺاهيو، جيڪو صرف فائل جي ڪاپي ٺاهي ٿو ۽ اصل کي ٽرڪن ڪري ٿو. ان جي مطابق، انهن نقل ڪرڻ جي عملن جي وچ ۾، ڊسڪ اسپيس عام طور تي هلندو آهي.
(4) اسان وٽ مختلف APIs ۾ مختلف فارميٽ هئا. اهي ٿورا مختلف هئا، پر regexp کي مختلف طرح سان لکڻو پوندو هو. جيئن ته اهو سڀ ڪجهه پپٽ جي طرفان منظم ڪيو ويو هو، اتي طبقن جو هڪ وڏو گروپ هو، پنهنجن پنهنجن ڪڪڙين سان. ان سان گڏ، ٽي ڊي ايجنٽ گهڻو ڪري ياداشت کائي سگهي ٿو، بيوقوف ٿي سگهي ٿو، هو صرف اهو ظاهر ڪري سگهي ٿو ته هو ڪم ڪري رهيو آهي ۽ ڪجهه به ناهي. ٻاهران، اهو سمجهڻ ناممڪن هو ته هو ڪجهه به نه ڪري رهيو هو. بهترين طور تي، هو ڪري ڇڏيندو، ۽ ڪو ماڻهو کيس بعد ۾ کڻندو. وڌيڪ واضح طور تي، هڪ خبرداري ۾ اڏامي ويندي، ۽ ڪو ماڻهو ويندو ۽ ان کي پنهنجن هٿن سان بلند ڪندو.
(6) ۽ سڀ کان وڌيڪ ڪچرو ۽ فضول - اهو elasticsearch هو. ڇاڪاڻ ته اهو هڪ پراڻو نسخو هو. ڇو ته ان وقت اسان وٽ وقف ماستر نه هئا. اسان وٽ متضاد لاگ هئا جن جا شعبا اوورليپ ٿي سگهن ٿا. مختلف ايپليڪيشنن جا مختلف لاگ ساڳيا فيلڊ نالن سان لکي سگهجن ٿا، پر ساڳئي وقت اندر مختلف ڊيٽا ٿي سگهي ٿي. اهو آهي، هڪ لاگ انٽيجر سان گڏ اچي ٿو فيلڊ ۾، مثال طور، سطح. ٻيو لاگ ليول فيلڊ ۾ اسٽرنگ سان گڏ اچي ٿو. جامد نقشي جي غير موجودگيءَ ۾، اهڙي عجيب شيءِ نڪرندي آهي. جيڪڏھن، انڊيڪس گھمڻ کان پوء، ھڪڙو پيغام ھڪڙي تار سان گڏ پهريون ڀيرو ايلسٽڪ سرچ ۾ پھتو، پوء اسان عام طور تي رھندا آھيون. ۽ جيڪڏھن پھريون ھڪڙو Integer سان آيو آھي، ته پوءِ ايندڙ سڀ پيغام جيڪي String سان آيا آھن، انھن کي رد ڪيو وڃي ٿو. ڇاڪاڻ ته فيلڊ جو قسم نه ملندو آهي.
اسان اهي سوال پڇڻ لڳاسين. اسان فيصلو ڪيو ته ڏوهن جي ڳولا نه ڪنداسين.
پر ڪجهه ڪرڻ جي ضرورت آهي! واضح ڳالهه اها آهي ته اسان کي معيار قائم ڪرڻ گهرجن. اسان وٽ اڳ ۾ ئي ڪجهه معيار هئا. ڪجهه اسان ٿوري دير بعد کڻي آياسين. خوشقسمتيء سان، سڀني APIs لاء هڪ واحد لاگ فارميٽ اڳ ۾ ئي ان وقت منظور ڪيو ويو هو. اهو سڌو سنئون خدمت جي رابطي جي معيار ۾ لکيل آهي. ان جي مطابق، جيڪي لاگ حاصل ڪرڻ چاهيندا آهن انهن کي هن فارميٽ ۾ لکڻ گهرجي. جيڪڏهن ڪو ماڻهو هن فارميٽ ۾ لاگ ان نه ٿو لکي، ته پوءِ اسان ڪجهه به ضمانت نه ٿا ڏيون.
وڌيڪ، مان چاهيندس ته رڪارڊنگ، پهچائڻ ۽ گڏ ڪرڻ جي طريقن لاءِ هڪ واحد معيار. دراصل، انھن کي ڪٿي لکڻ، ۽ انھن کي ڪيئن پهچائڻ. مثالي صورتحال آهي جڏهن منصوبا ساڳي لائبريري استعمال ڪندا آهن. گو لاءِ الڳ لاگنگ لائبريري آهي، پي ايڇ پي لاءِ الڳ لائبريري آهي. هرڪو اسان وٽ آهي، هر ڪنهن کي انهن کي استعمال ڪرڻ گهرجي. هن وقت مان چوندس ته اسان 80 سيڪڙو ڪامياب ٿي رهيا آهيون. پر ڪي ڪيڪٽي کائڻ جاري رکندا آهن.
۽ اتي (سلائيڊ تي) ”لاگ ترسيل لاءِ SLA“ مشڪل سان ظاهر ٿيڻ شروع ٿي چڪو آهي. اهو اڃا تائين موجود ناهي، پر اسان ان تي ڪم ڪري رهيا آهيون. ڇاڪاڻ ته اهو تمام آسان آهي جڏهن انفرا چوي ٿو ته جيڪڏهن توهان اهڙي ۽ اهڙي فارميٽ ۾ فلاڻي جڳهه تي لکندا ۽ في سيڪنڊ N پيغامن کان وڌيڪ نه هوندا، ته اسان گهڻو ڪري ان کي اتي پهچائينداسين. اهو تمام گهڻو سر درد دور ڪري ٿو. جيڪڏهن هڪ SLA آهي، پوء اهو صرف عظيم آهي!
اسان ڪيئن مسئلو حل ڪرڻ شروع ڪيو؟ مکيه ريڪ td-agent سان هو. اهو واضح نه هو ته اسان جا لاگ ڪٿي ويندا. ڇا اهي پهچائي رهيا آهن؟ ڇا اهي وڃي رهيا آهن؟ اهي بهرحال ڪٿي آهن؟ تنهن ڪري، ان کي تبديل ڪرڻ جو فيصلو ڪيو ويو td-ايجنٽ پهرين شيء سان. ان کي تبديل ڪرڻ جا اختيار، مون مختصر طور تي هتي بيان ڪيو آهي.
رواني. پهرين، مون هن سان ملاقات ڪئي، هڪ پوئين نوڪري تي، ۽ هو پڻ وقتي طور تي اتي اچي ويو. ٻيو، اهو ساڳيو آهي، صرف پروفائل ۾.
فائل بيٽ. اهو اسان لاء ڪيئن سٺو هو؟ حقيقت اها آهي ته هو گو ۾ آهي، ۽ اسان وٽ گو ۾ وڏي ماهر آهي. ان جي مطابق، جيڪڏهن ڪجھ به، اسان ڪنهن به طرح ان کي پاڻ ۾ شامل ڪري سگهون ٿا. ان ڪري اسان نه ورتو. ته جيئن وري پنهنجي لاءِ لکڻ شروع ڪرڻ ۾ به ڪو لالچ نه ٿئي.
sysadmin لاء واضح حل هن مقدار ۾ syslogs جي سڀني قسمن جي آهي (syslog-ng/rsyslog/nxlog).
يا پنهنجو ڪجهه لکو، پر اسان ان کي رد ڪري ڇڏيو، انهي سان گڏ فائل بيٽ. جيڪڏهن توهان ڪجهه لکندا آهيو، ته اهو بهتر آهي ته ڪجهه لکڻ لاء ڪاروبار لاء مفيد آهي. لاگن کي پهچائڻ لاء، اهو بهتر آهي ته ڪجهه تيار ڪيل شيون وٺو.
تنهن ڪري، پسند اصل ۾ syslog-ng ۽ rsyslog جي وچ ۾ هڪ انتخاب تي آيو. مون rsyslog ڏانهن رخ ڪيو صرف ان ڪري جو اسان وٽ اڳ ۾ ئي Puppet ۾ rsyslog لاءِ ڪلاس هئا، ۽ مون کي انهن جي وچ ۾ واضح فرق نه مليو. syslog ڇا آهي، syslog ڇا آهي. ها، ڪجهه دستاويز خراب آهن، ڪجهه بهتر. هو هن طريقي سان ڄاڻي ٿو، ۽ هو اهو مختلف طريقي سان ڪندو آهي.
۽ rsyslog بابت ٿورڙو. پهريون، اهو ٿڌو آهي ڇو ته ان ۾ ڪيترائي ماڊل آهن. ان ۾ انساني پڙهڻ جي قابل RainerScript (جديد ترتيب واري ٻولي) آهي. هڪ بهترين بونس اهو آهي ته اسان td-ايجنٽ جي رويي کي ان جي معياري اوزار سان نقل ڪري سگهون ٿا، ۽ ايپليڪيشنن لاء ڪجھ به تبديل نه ڪيو آهي. اهو آهي، اسان td-agent کي rsyslog ۾ تبديل ڪريون ٿا، ۽ اڃا تائين هر شيءِ کي هٿ نه لڳايو. ۽ فوري طور تي اسان هڪ ڪم ڪندڙ ترسيل حاصل ڪندا آهيون. اڳيون، mmnormalize rsyslog بابت سٺي شيء آهي. اهو توهان کي لاگز پارس ڪرڻ جي اجازت ڏئي ٿو، پر Grok ۽ regexp سان نه. اهو هڪ خلاصو نحو جو وڻ ٺاهي ٿو. اهو لاگز کي گهڻو ڪري ساڳيو طريقي سان پارس ڪري ٿو جيئن هڪ مرتب ڪندڙ سورس ڪوڊ کي پارس ڪري ٿو. هي توهان کي تمام تيز ڪم ڪرڻ جي اجازت ڏئي ٿو، ٿورو سي پي يو کائو، ۽، عام طور تي، اهو صرف هڪ تمام سٺي شيء آهي. اتي ٻين bonuses جي هڪ bunch آهن. مان انهن تي نه رهندس.
rsyslog تمام گهڻو وڌيڪ نقصان آهي. اهي بونس وانگر آهن. بنيادي مسئلا اهي آهن ته توهان کي ان کي پچائڻ جي ضرورت آهي، ۽ توهان کي هڪ نسخو چونڊڻ جي ضرورت آهي.
اسان فيصلو ڪيو ته يونڪس ساکٽ ۾ لاگ لکنداسين. ۽ نه /dev/log ۾، ڇاڪاڻ ته اتي اسان وٽ سسٽم لاگن جي گندگي آهي، اتي هن پائپ لائن ۾ جرنل آهي. تنهن ڪري اچو ته هڪ ڪسٽم ساکٽ ڏانهن لکون. اسان ان کي الڳ الڳ قاعدن سان ڳنڍينداسين. اچو ته ڪنهن به شيء ۾ مداخلت نه ڪريون. سڀڪنھن شيء کي شفاف ۽ سمجهي ويندي. تنهنڪري اسان اصل ۾ ڪيو. ڊاريڪٽري انهن ساکٽس سان معياري ڪئي وئي آهي ۽ سڀني ڪنٽينرز ڏانهن موڪلي وئي آهي. ڪنٽينر ڏسي سگھن ٿا ساکٽ انهن کي گهربل آهي، کوليو ۽ ان تي لکو.
فائل ڇو نه؟ ڇاڪاڻ ته هرڪو پڙهي چڪو آهي ، جنهن فائل کي ڊاکر ڏانهن اڳتي وڌڻ جي ڪوشش ڪئي، ۽ ڏٺائين ته rsyslog کي ٻيهر شروع ڪرڻ کان پوء، فائل بيان ڪندڙ تبديل ٿي، ۽ ڊڪر هن فائل کي وڃائي ٿو. هو ڪجهه ٻيو کولي ٿو، پر اهو ساڳيو ساکٽ ناهي جتي اهي لکندا آهن. اسان فيصلو ڪيو ته اسان هن مسئلي کي نظرانداز ڪنداسين، ۽ ساڳئي وقت، بلاڪ ڪرڻ واري مسئلي کي نظرانداز ڪنداسين.
Rsyslog سلائيڊ تي ظاهر ڪيل عملن کي انجام ڏئي ٿو ۽ يا ته ريل يا ڪافڪا ڏانهن لاگ موڪلي ٿو. ڪافڪا پراڻي طريقي جي پيروي ڪري ٿو. Rayleigh - مون لاگز پهچائڻ لاء خالص rsyslog استعمال ڪرڻ جي ڪوشش ڪئي. پيغام جي قطار کان سواء، معياري rsyslog اوزار استعمال ڪندي. بنيادي طور تي، اهو ڪم ڪري ٿو.
پر ان سان گڏ nuances آهن ته انهن کي بعد ۾ هن حصي ۾ ڪيئن مواد (Logstash/Graylog/ES). هي حصو (rsyslog-rsyslog) ڊيٽا سينٽرن جي وچ ۾ استعمال ٿيندو آهي. هتي هڪ کمپريس ٿيل tcp لنڪ آهي، جيڪو توهان کي بينڊوڊٿ بچائڻ جي اجازت ڏئي ٿو ۽، مطابق، ڪنهن نه ڪنهن طريقي سان اهو امڪان وڌائي ٿو ته چينل مڪمل ٿيڻ تي اسان کي ڪنهن ٻئي ڊيٽا سينٽر مان ڪجهه لاگس حاصل ڪنداسين. ڇو ته اسان وٽ انڊونيشيا آهي، جتي سڀ ڪجهه خراب آهي. اهو آهي جتي مسلسل مسئلو ڪوڙ آهي.
اسان سوچيو ته اسان اصل ۾ ڪيئن مانيٽر ڪريون ٿا، ڪهڙي امڪان سان اهي لاگز جيڪي اسان اپليڪيشن مان رڪارڊ ڪيا آهن اهي آخر تائين پهچن ٿا؟ اسان ميٽرڪ شروع ڪرڻ جو فيصلو ڪيو. Rsyslog وٽ پنهنجو شماريات گڏ ڪرڻ وارو ماڊل آهي، جنهن ۾ ڪجهه قسم جا شمار ڪندڙ آهن. مثال طور، اهو توهان کي قطار جي ماپ ڏيکاري سگهي ٿو، يا اهڙي عمل لاء ڪيترا پيغام آيا آهن. توھان اڳ ۾ ئي انھن مان ڪجھ وٺي سگھو ٿا. ان سان گڏ، ان ۾ ڪسٽم ڪائونٽر آهن جيڪي توهان ترتيب ڏئي سگهو ٿا، ۽ اهو توهان کي ڏيکاريندو، مثال طور، پيغامن جو تعداد جيڪو ڪجهه API رڪارڊ ڪيو آهي. اڳيون، مون Python ۾ rsyslog_exporter لکيو، ۽ اسان اهو سڀ ڪجهه Prometheus ڏانهن موڪليو ۽ پلاٽ ڪيو. اسان واقعي چاهيون ٿا گريلوگ ميٽرڪس، پر اڃا تائين اسان وٽ انهن کي ترتيب ڏيڻ جو وقت نه آهي.
مسئلا ڪهڙا آهن؟ مسئلو ان حقيقت سان پيدا ٿيو ته اسان کي معلوم ٿيو (اوچتو!) ته اسان جا Live APIs 50k پيغام في سيڪنڊ لکن ٿا. هي صرف لائيو API آهي بغير اسٽيجنگ. ۽ گريلوگ اسان کي صرف 12 هزار پيغام في سيڪنڊ ڏيکاري ٿو. ۽ هڪ معقول سوال پيدا ٿيو، باقي بچيل ڪٿي آهن؟ جنهن مان اسان اهو نتيجو ڪڍيو آهي ته گريلوگ صرف منهن نه ٿو ڪري سگهي. اسان ڏٺو، ۽، حقيقت ۾، Elasticsearch سان Graylog هن وهڪري کي ماهر نه ڪيو.
اڳيون، ٻيون دريافتون اسان رستي ۾ ڪيون آهن.
ساکٽ ڏانهن لکڻ بند ٿيل آهن. اهو ڪيئن ٿيو؟ جڏهن مون ترسيل لاءِ rsyslog استعمال ڪيو، ڪجهه نقطي تي اسان ڊيٽا سينٽرن جي وچ ۾ چينل کي ٽوڙيو. ترسيل هڪ جاءِ تي ٿي، ٻي جاءِ تي پهچائڻ. ھي سڀ ھيٺ آيو آھي ھڪڙي مشين تي APIs سان جيڪو لکندو آھي rsyslog ساکٽ تي. هڪ قطار هئي. پوءِ يونڪس ساکٽ تي لکڻ لاءِ قطار ڀرجي وئي، جيڪا ڊفالٽ طور 128 پيڪٽس آهي. ۽ ايندڙ لکو () ايپليڪيشن بلاڪ ۾. جڏهن اسان لئبرريءَ تي نظر وجهون ٿا جيڪا اسان گو ايپليڪيشنز ۾ استعمال ڪريون ٿا، اتي لکيل هو ته ساکٽ ۾ لکڻ غير بلاڪنگ موڊ ۾ ٿئي ٿو. اسان کي پڪ هئي ته ڪجھ به بند نه ڪيو ويو آهي. ڇاڪاڻ ته اسان پڙهيو آهي جنهن ان بابت لکيو. پر اتي هڪ لمحو آهي. هن ڪال جي چوڌاري هڪ لامحدود لوپ پڻ هو، جنهن ۾ هڪ پيغام کي ساکٽ ۾ ڌڪڻ جي مسلسل ڪوشش ڪئي وئي هئي. اسان هن کي نوٽيس نه ڪيو. مون کي لائبريري ٻيهر لکڻو پيو. ان کان پوء، اهو ڪيترائي ڀيرا تبديل ٿي چڪو آهي، پر هاڻي اسان سڀني سب سسٽم ۾ تالا کان نجات حاصل ڪئي آهي. تنهن ڪري، توهان روڪي سگهو ٿا rsyslog ۽ ڪجھ به نه ٿيندو.
اهو ضروري آهي ته قطار جي سائيز جي نگراني ڪرڻ، جيڪا هن ريڪ تي قدم نه رکڻ ۾ مدد ڪري ٿي. پهريون، اسان مانيٽر ڪري سگهون ٿا جڏهن اسان پيغام وڃائڻ شروع ڪيو. ٻيو، اسان مانيٽر ڪري سگهون ٿا ته اسان وٽ بنيادي طور تي پهچائڻ سان مسئلا آهن.
۽ هڪ ٻيو ناپسنديده لمحو - 10 ڀيرا هڪ microservice فن تعمير ۾ وڌائڻ تمام آسان آهي. اسان وٽ ڪيتريون ئي اچڻ واريون درخواستون نه آهن، پر گراف جي ڪري جنهن سان اهي پيغام اڳتي وڌن ٿا، رسائي لاگز جي ڪري، اسان اصل ۾ لاگز تي لڳ ڀڳ ڏهه ڀيرا وڌندا آهيون. بدقسمتي سان، مون وٽ صحيح انگن اکرن کي ڳڻڻ جو وقت نه هو، پر microservices اهي آهن جيڪي اهي آهن. اهو ذهن ۾ رکڻ گهرجي. اهو ظاهر ٿئي ٿو ته هن وقت لاگ گڏ ڪرڻ جو سبسسٽم سڀ کان وڌيڪ لوڊ ٿيل آهي Lazada ۾.
لچڪدار ڳولا جو مسئلو ڪيئن حل ڪجي؟ جيڪڏهن توهان کي جلدي هڪ جاءِ تي لاگز حاصل ڪرڻ جي ضرورت آهي، ته جيئن سڀني مشينن تي نه هلڻ ۽ انهن کي اتي گڏ ڪرڻ، فائل اسٽوريج استعمال ڪريو. اهو ڪم ڪرڻ جي ضمانت آهي. اهو ڪنهن به سرور کان ڪيو ويندو آهي. توهان کي صرف اتي ڊسڪ اسٽيڪ ڪرڻ ۽ syslog رکڻ جي ضرورت آهي. ان کان پوء، توهان کي ضمانت ڏني وئي آهي ته سڀئي لاگ هڪ جڳهه تي آهن. ان کان پوء اهو ممڪن ٿيندو ته سست رفتار سان ترتيب ڏيڻ لاء elasticsearch، graylog، يا ٻيو ڪجهه. پر توھان وٽ اڳ ۾ ئي سڀ لاگ آھن، ۽ ان کان سواء، توھان انھن کي ذخيرو ڪري سگھو ٿا، جيستائين ڪافي ڊسڪ صفون آھن.
منهنجي رپورٽ جي وقت، اسڪيم هن طرح ڏسڻ شروع ڪيو. اسان عملي طور تي فائل ڏانهن لکڻ بند ڪيو. هاڻي، گهڻو ڪري، اسان باقيات کي بند ڪنداسين. API هلائيندڙ مقامي مشينن تي، اسان فائلن تي لکڻ بند ڪنداسين. پهرين، اتي فائل اسٽوريج آهي، جيڪو تمام سٺو ڪم ڪري ٿو. ٻيو، اهي مشينون مسلسل خلا کان ٻاهر هلائي رهيا آهن، توهان کي مسلسل ان جي نگراني ڪرڻ جي ضرورت آهي.
Logstash ۽ Graylog سان هي حصو، اهو واقعي تيز ٿي ويو آهي. تنهن ڪري، توهان کي ان کان نجات حاصل ڪرڻ جي ضرورت آهي. توھان کي ھڪڙو چونڊڻو آھي.
اسان Logstash ۽ Kibana ڇڏڻ جو فيصلو ڪيو. ڇو ته اسان وٽ سيڪيورٽي ڊپارٽمينٽ آهي. ڪنيڪشن ڇا آهي؟ ڪنيڪشن اهو آهي ته ڪبانا بغير X-Pack ۽ بغير شيلڊ توهان کي لاگ ان تائين رسائي جي حقن ۾ فرق ڪرڻ جي اجازت ناهي. تنهن ڪري، اهي Graylog ورتو. اهو سڀ ڪجهه آهي. مون کي اهو پسند ناهي، پر اهو ڪم ڪري ٿو. اسان نئون هارڊويئر خريد ڪيو، اتي نئون گريلاگ انسٽال ڪيو، ۽ سڀني لاگن کي سخت فارميٽ سان الڳ گريلاگ ڏانھن منتقل ڪيو. اسان تنظيمي طور تي ساڳئي شعبن جي مختلف قسمن سان مسئلو حل ڪيو آهي.
ڇا واقعي نئين گريلوگ ۾ شامل آهي. اسان صرف ڊڪر ۾ سڀ ڪجهه لکيو. اسان سرورز جو هڪ گروپ ورتو، ٽي ڪافڪا مثال، 7 گريلوگ سرور ورزن 2.3 (ڇاڪاڻ ته مون کي Elasticsearch ورجن 5 چاهيو). هي سڀ ڪجهه ايڇ ڊي ڊي جي حملن تي اٿاريو ويو. اسان ڏٺو ته انڊيڪسنگ جي شرح 100 هزار پيغامن تائين في سيڪنڊ تائين. اسان ڏٺو ته انگ اکر 140 terabytes ڊيٽا في هفتي.
۽ ٻيهر هڪ ريڪ! اسان وٽ ٻه وڪرو اچي رهيا آهن. اسان 6 ملين پوسٽن کان اڳتي وڌي چڪا آهيون. اسان گريلوگ کي چبائڻ جو وقت ناهي. ڪنهن به طرح توهان کي ٻيهر زنده رهڻو پوندو.
اهڙيءَ طرح اسان بچي وياسين. شامل ڪيا ويا ڪجھ وڌيڪ سرور ۽ SSDs. هن وقت اسان اهڙي زندگي گذاري رهيا آهيون. هاڻي اسان پهريان ئي 160k پيغام في سيڪنڊ کي چيري رهيا آهيون. اسان اڃا تائين حد تائين نه پهتا آهيون، تنهنڪري اهو واضح ناهي ته اسان حقيقي طور تي ان مان ڪيترو حاصل ڪري سگهون ٿا.
اهي مستقبل لاء اسان جا منصوبا آهن. انهن مان، واقعي، سڀ کان اهم شايد اعلي دستيابي آهي. اسان وٽ اڃا تائين ناهي. ڪيتريون ئي ڪارون ساڳيون سيٽون آهن، پر هن وقت تائين سڀ ڪجهه هڪ ڪار ذريعي ٿي رهيو آهي. انهن جي وچ ۾ هڪ ناڪامي قائم ڪرڻ لاء وقت گذارڻ ضروري آهي.
Graylog مان ميٽرڪ گڏ ڪريو.
شرح جي حد ٺاهيو ته جيئن اسان وٽ ھڪڙو چريو API آھي جيڪو اسان کي بينڊوڊٿ ۽ ٻيو سڀ ڪجھ نٿو ماري.
۽ آخرڪار، ڊولپرز سان ڪنهن قسم جي SLA تي دستخط ڪريو ته جيئن اسان تمام گهڻي خدمت ڪري سگهون. وڌيڪ لکندا ته معاف ڪجو.
۽ دستاويز لکو.
مختصر طور تي، هر شيء جو نتيجو جيڪو اسان تجربو ڪيو آهي. پهريون، معيار. ٻيو، syslog ڪيڪ آهي. ٽيون، rsyslog بلڪل ڪم ڪري ٿو جيئن اهو سلائڊ تي لکيل آهي. ۽ اچو ته سوالن ڏانهن وڃو.
توهان جا سوال.
سوال: هنن نه وٺڻ جو فيصلو ڇو ڪيو... (فائل بيٽ؟)
جواب ڏيو: فائل ۾ لکڻ جي ضرورت آهي. مون واقعي نه چاهيو. جڏهن توهان جو API هزارين پيغام في سيڪنڊ لکي ٿو، جيتوڻيڪ جيڪڏهن توهان هڪ ڪلاڪ ۾ هڪ ڀيرو گھمايو، اهو اڃا تائين اختيار ناهي. توهان پائپ تي لکي سگهو ٿا. جنهن لاءِ ڊولپرز مون کان پڇيو: ”جيڪڏهن اهو عمل جنهن ۾ اسان لکون ٿا، ڇا ٿيندو“؟ مون کي نه مليو ته کين ڪهڙو جواب ڏيان، ۽ چيائين: ”چڱو، ٺيڪ آهي، اچو ته ائين نه ڪريون.
سوال: توهان صرف HDFS ڏانهن لاگس ڇو نٿا لکو؟
جواب ڏيوج: هي ايندڙ قدم آهي. اسان شروعات ۾ ان بابت سوچيو، پر جيئن ته هن وقت ان سان معاملو ڪرڻ لاءِ ڪي وسيلا نه آهن، اهو اسان جي ڊگهي مدي واري حل ۾ لٽڪيل آهي.
سوال: هڪ ڪالم فارميٽ وڌيڪ موزون هوندو.
جواب ڏيو: مان سمجهان ٿو. اسان ٻنهي هٿن سان "لاء" آهيون.
سوال: توهان rsyslog ڏانهن لکو. ٻئي TCP ۽ UDP اتي موجود آهن. پر جيڪڏهن UDP، ته پوء توهان پهچائڻ جي ضمانت ڪيئن ڏيو ٿا؟
جواب ڏيوج: ٻه نقطا آهن. پهرين، مان فوري طور تي سڀني کي ٻڌايان ٿو ته اسان لاگ ان جي ترسيل جي ضمانت نٿا ڏين. ڇو ته جڏهن ڊولپرز اچن ٿا ۽ چون ٿا: ”اچو اتي مالي ڊيٽا لکڻ شروع ڪريو، ۽ توهان ان کي اسان جي لاءِ ڪنهن جاءِ تي رکنداسين جيڪڏهن ڪجهه ٿئي ٿو،“ اسان انهن کي جواب ڏيون ٿا، ”زبردست! اچو ته بلاڪ ڪرڻ شروع ڪريون ساکٽ تي لکڻ تي، ۽ ان کي ٽرانزيڪشن ۾ ڪريو، ته جيئن توهان ان کي اسان جي ساکٽ ۾ رکڻ جي ضمانت ڏني وڃي ۽ پڪ ڪريو ته اسان ان کي ٻئي پاسي کان وصول ڪيو آهي. ۽ هن وقت، هرڪو فوري طور تي غير ضروري آهي. ۽ جيڪڏهن نه ته پوءِ اسان وٽ ڪهڙا سوال آهن؟ جيڪڏهن توهان ساکٽ تي لکڻ جي ضمانت نٿا چاهيو، ته پوءِ اسان ترسيل جي ضمانت ڇو ڏينداسين؟ اسان بهترين ڪوشش ڪري رهيا آهيون. اسان واقعي ڪوشش ڪندا آهيون ته جيترو ٿي سگهي ۽ جيترو ممڪن ٿي سگهي بهترين، پر اسان 100٪ گارنٽي نٿا ڏيون. تنهن ڪري، توهان کي اتي مالي ڊيٽا لکڻ جي ضرورت ناهي. ھن لاءِ ٽرانزيڪشنل ڊيٽابيس آھن.
سوال: جڏهن API لاگ ۾ ڪجهه پيغام ٺاهي ٿو ۽ ڪنٽرول کي microservices ڏانهن منتقل ڪري ٿو، ڇا توهان ان مسئلي کي منهن ڏنو آهي ته مختلف مائڪرو سروسز کان پيغام غلط ترتيب ۾ اچن ٿا؟ ان ڪري مونجهارو پيدا ٿئي ٿو.
جواب ڏيونواب خير بخش مري: اهو عام آهي ته اهي مختلف ترتيب ۾ اچن ٿيون. توھان کي ھن لاءِ تيار رھڻو پوندو. ڇو ته ڪنهن به نيٽ ورڪ جي ترسيل توهان کي آرڊر جي ضمانت نه آهي، يا توهان کي ان تي خاص وسيلا خرچ ڪرڻ جي ضرورت آهي. جيڪڏهن اسان فائل اسٽوريج وٺون ٿا، پوء هر API لاگ ان کي پنهنجي فائل ۾ محفوظ ڪري ٿو. بلڪه، rsyslog انهن کي ڊاريڪٽري ۾ ٺاهي ٿو. هر API جا پنهنجا لاگ آهن، جتي توهان وڃي سگهو ٿا ۽ ڏسي سگهو ٿا، ۽ پوءِ توهان هن لاگ ۾ ٽائم اسٽيمپ استعمال ڪندي انهن جو مقابلو ڪري سگهو ٿا. جيڪڏهن اهي گريلوگ ۾ ڏسڻ لاءِ وڃن، ته پوءِ اتي انهن کي ٽائم اسٽيمپ سان ترتيب ڏنو ويندو. اتي سڀ ڪجھ ٺيڪ ٿي ويندو.
سوال: ٽائيم اسٽيمپ مليس سيڪنڊن جي لحاظ کان مختلف ٿي سگھي ٿو.
جواب ڏيو: ٽائم اسٽيمپ خود API پاران ٺاهيل آهي. هي، حقيقت ۾، سڄو نقطو آهي. اسان وٽ NTP آهي. API اڳ ۾ ئي پيغام ۾ هڪ ٽائم اسٽيمپ ٺاهي ٿو. اهو rsyslog پاران شامل نه ڪيو ويو آهي.
سوال: ڊيٽا سينٽرن جي وچ ۾ رابطي بلڪل واضح ناهي. ڊيٽا سينٽر جي فريم ورڪ اندر، اهو واضح آهي ته ڪيئن لاگ ان کي گڏ ڪيو ويو ۽ پروسيس ڪيو ويو. ڊيٽا سينٽرن جي وچ ۾ رابطي ڪيئن آهي؟ يا ڇا هر ڊيٽا سينٽر پنهنجي زندگي گذاريندو آهي؟
جواب ڏيو: لڳ ڀڳ. اسان وٽ هر ملڪ هڪ ڊيٽا سينٽر ۾ واقع آهي. اسان وٽ في الحال پکيڙ نه آهي، تنهنڪري هڪ ملڪ مختلف ڊيٽا سينٽرن ۾ رکيل آهي. تنهن ڪري، انهن کي گڏ ڪرڻ جي ڪا ضرورت ناهي. هر مرڪز جي اندر هڪ لاگ رلي آهي. هي هڪ Rsyslog سرور آهي. حقيقت ۾، ٻه انتظام مشينون. اهي ساڳيا ترتيب ڏنل آهن. پر هينئر تائين، ٽرئفڪ صرف انهن مان هڪ ذريعي وڃي ٿي. هوءَ هر شيءِ کي گڏ ڪري ٿي. اهو صرف صورت ۾ هڪ ڊسڪ قطار آهي. هوءَ لاگز کي دٻائي ٿي ۽ انهن کي مرڪزي ڊيٽا سينٽر (سنگاپور) ڏانهن موڪلي ٿي، جتي اڳتي هلي اهي اڳ ۾ ئي گريلوگ ۾ زهر ٿي ويا آهن. ۽ هر ڊيٽا سينٽر کي پنهنجي فائل اسٽوريج آهي. صورت ۾ اسان جو ڪنيڪشن گم ٿي ويو، اسان وٽ سڀ لاگ موجود آهن. اهي اتي ئي رهندا. اهي اتي محفوظ ڪيا ويندا.
سوال: ڇا توهان غير معمولي حالتن دوران اتان کان لاگ حاصل ڪندا آهيو؟
جواب ڏيو: توھان اتي وڃو (فائل اسٽوريج ڏانھن) ۽ ڏسو.
سوال: توهان ڪيئن نگراني ڪندا آهيو ته توهان لاگس نه وڃايو؟
جواب ڏيو: اسان اصل ۾ انهن کي وڃائي رهيا آهيون، ۽ اسان ان جي نگراني ڪري رهيا آهيون. مانيٽرنگ هڪ مهينو اڳ شروع ٿي. لائبريري جيڪا Go APIs استعمال ڪندي آهي ميٽرڪس آهي. هوءَ ڳڻائي سگهي ٿي ته ڪيترا ڀيرا هوءَ ساکٽ تي لکڻ ۾ ناڪام ٿي. هن وقت اتي هڪ tricky heuristic آهي. اتي هڪ بفر آهي. اهو ڪوشش ڪري ٿو ته ان مان هڪ پيغام ساکٽ ڏانهن. جيڪڏهن بفر اوور فلو ٿئي ٿو، اهو انهن کي ڇڏڻ شروع ڪري ٿو. ۽ هو شمار ڪري ٿو ته هن انهن کي ڪيترا ئي ڇڏيا. جيڪڏهن ڳڻپيوڪر اتي اوور فلو ٿيڻ شروع ڪندا ته اسان کي ان جي خبر پوندي. اهي هاڻي به اچي رهيا آهن prometheus، ۽ توهان ڏسي سگهو ٿا گرافنا ۾ گراف. توهان انتباہ قائم ڪري سگهو ٿا. پر اهو اڃا واضح ناهي ته انهن کي ڪنهن ڏانهن موڪليو وڃي.
سوال: لچڪدار ڳولها ۾، توهان فالتو لاگن سان گڏ ذخيرو ڪريو ٿا. توهان وٽ ڪيترا replicas آهن؟
جواب ڏيو: هڪ نقل.
سوال: ڇا اهو صرف هڪ لڪير آهي؟
جواب ڏيو: هي ماسٽر ۽ نقل آهي. ڊيٽا نقل ۾ محفوظ ڪئي وئي آهي.
سوال: ڇا توهان ڪنهن طرح rsyslog بفر جي سائيز کي ٽوڪ ڪيو؟
جواب ڏيو: اسان هڪ ڪسٽم يونڪس ساکٽ تي ڊيٽاگرام لکندا آهيون. اهو فوري طور تي اسان تي 128 ڪلوبائٽس جي حد لاڳو ڪري ٿو. اسان ان تي وڌيڪ نه ٿا لکي سگهون. اسان اهو معيار ۾ لکيو آهي. جيڪو اسٽوريج ۾ حاصل ڪرڻ چاهي ٿو، اهي 128 ڪلوبائٽس لکندا آهن. لائبريريون، ان کان سواء، ڪٽايو، ۽ هڪ جھنڊو لڳايو ته پيغام ڪٽجي ويو. اسان وٽ پيغام جي معيار ۾ هڪ خاص ميدان آهي، جيڪو ڏيکاري ٿو ته اهو رڪارڊنگ دوران ڪٽيو ويو يا نه. تنهنڪري اسان وٽ هن لمحي کي ٽريڪ ڪرڻ جو موقعو آهي.
سوال: ڇا توهان ٽٽل JSON لکندا آهيو؟
جواب ڏيو: ٽوڙيو JSON يا ته رلي دوران رد ڪيو ويندو ڇاڪاڻ ته پيڪيٽ تمام وڏو آهي. يا گريلوگ کي ڇڏي ڏنو ويندو، ڇاڪاڻ ته اهو JSON کي پارس ڪرڻ جي قابل نه هوندو. پر هتي اهڙا nuances آهن جن کي درست ڪرڻ جي ضرورت آهي، ۽ اهي گهڻو ڪري rsyslog سان ڳنڍيل آهن. مون اڳ ۾ ئي ڪجھه مسئلو ڀريو آهي، جن تي اڃا ڪم ڪرڻ جي ضرورت آهي.
سوال: ڇو ڪافڪا؟ ڇا توهان RabbitMQ جي ڪوشش ڪئي؟ Graylog اهڙي لوڊ هيٺ شامل نه آهي؟
جواب ڏيو: اهو Graylog سان ڪم نٿو ڪري. ۽ Graylog شڪل وٺي رهيو آهي. اهو هن لاء واقعي مسئلو آهي. هو هڪ قسم جي شيء آهي. ۽، حقيقت ۾، ان جي ضرورت نه آهي. مان بجاءِ لکندس rsyslog کان سڌو سنئون elasticsearch ڏانهن ۽ پوءِ ڏسو ڪبانا. پر اسان کي سيڪيورٽي گارڊن سان مسئلو حل ڪرڻو پوندو. اهو اسان جي ترقي جو هڪ ممڪن قسم آهي جڏهن اسان گريلوگ کي اڇلائي ۽ ڪبانا استعمال ڪندا آهيون. Logstash مطلب نه ٿيندو. ڇو ته مان ائين ڪري سگهان ٿو rsyslog سان. ۽ ان ۾ هڪ ماڊل آهي لکڻ لاءِ elasticsearch. گريلوگ سان گڏ اسان ڪنهن به طرح رهڻ جي ڪوشش ڪري رهيا آهيون. اسان ان کي به ٿورو وڌايو. پر اڃا به بهتري جي گنجائش آهي.
ڪافڪا جي باري ۾. تاريخي طور تي ائين ئي ٿيو آهي. جڏهن آئون پهتو، اهو اڳ ۾ ئي موجود هو، ۽ لاگ ان کي اڳ ۾ ئي لکيو ويو هو. اسان صرف اسان جي ڪلستر کي وڌايو ۽ لاگ ان ۾ منتقل ڪيو. اسان هن کي منظم ڪريون ٿا، اسان ڄاڻون ٿا ته هو ڪيئن محسوس ڪندو آهي. جيئن ته RabbitMQ لاءِ... اسان کي RabbitMQ سان مشڪل آهي. ۽ RabbitMQ اسان لاءِ ترقي ڪري رهيو آهي. اسان وٽ اهو پيداوار ۾ آهي، ۽ ان سان گڏ مسئلا هئا. هاڻي، وڪڻڻ کان اڳ، هن کي شرمسار ڪيو ويندو، ۽ هو عام طور تي ڪم ڪرڻ شروع ڪندو. پر ان کان اڳ، مان ان کي پيداوار ۾ ڇڏڻ لاء تيار نه هو. ھڪڙو وڌيڪ نقطو آھي. Graylog AMQP 0.9 ورجن پڙهي سگهي ٿو ۽ rsyslog AMQP 1.0 ورجن لکي سگهي ٿو. ۽ اتي ھڪڙو حل نه آھي جيڪو وچ ۾ ٻئي ڪري سگھي. اتي هڪ يا ٻيو آهي. سو في الحال فقط ڪافڪا. پر اتي پڻ nuances آهن. ڇاڪاڻ ته rsyslog جي ورجن جو omkafka جيڪو اسان استعمال ڪريون ٿا اهو سڄو پيغام بفر وڃائي سگهي ٿو جيڪو اهو rsyslog مان ڪڍيو ويو آهي. جيستائين اسان ان سان گڏ رکون ٿا.
سوال: ڇا توهان ڪافڪا استعمال ڪري رهيا آهيو ڇو ته توهان وٽ آهي؟ ڪنهن ٻئي مقصد لاء استعمال نه ڪيو وڃي؟
جواب ڏيو: ڪافڪا، جيڪو ڊيٽا سائنس ٽيم پاران استعمال ڪيو ويو. هي هڪ مڪمل طور تي الڳ منصوبو آهي، جنهن بابت مان، بدقسمتي سان، ڪجهه به نٿو چئي سگهان. مون کي ناهي خبر. هوء ڊيٽا سائنس ٽيم پاران هلائي وئي هئي. جڏهن لاگ شروع ٿيا، انهن ان کي استعمال ڪرڻ جو فيصلو ڪيو، جيئن ته پنهنجو پاڻ کي نه رکڻ لاء. ھاڻي اسان گريلوگ کي اپڊيٽ ڪيو آھي، ۽ اسان مطابقت وڃائي چڪا آھيون، ڇاڪاڻ ته ڪافڪا جو ھڪڙو پراڻو ورزن آھي. اسان کي پنهنجو پاڻ ٺاهڻو هو. ساڳئي وقت، اسان هر API لاء انهن چار عنوانن کان نجات حاصل ڪئي. اسان سڀني لائيو لاءِ هڪ وائڊ ٽاپ ٺاهيو، سڀني اسٽيجنگ لاءِ هڪ وائڊ وائڊ ٽاپ ۽ اسان اتي ئي هر شي کي شوٽ ڪيو. گريلوگ اهو سڀ ڪجهه متوازي ۾ ڪڍي ٿو.
سوال: ڇو اسان کي ساکٽ سان هن shamanism جي ضرورت آهي؟ ڇا توھان استعمال ڪرڻ جي ڪوشش ڪئي آھي syslog لاگ ڊرائيور ڪنٽينرز لاءِ.
جواب ڏيو: جنهن وقت اسان اهو سوال پڇيو، ان وقت اسان جا ڊاکر سان لاڳاپا خراب هئا. اهو ڊڪر 1.0 يا 0.9 هو. ڊاڪر پاڻ به عجيب هو. ٻيو، جيڪڏهن توهان لاگ ان کي پڻ ڇڪايو ... مون کي هڪ غير تصديق ٿيل شڪ آهي ته اهو سڀ لاگز پاڻ ذريعي، ڊاکر ڊيمن ذريعي گذري ٿو. جيڪڏهن اسان وٽ هڪ API چريو آهي، ته پوءِ باقي APIs ان حقيقت ۾ هليا ويندا ته اهي stdout ۽ stderr موڪلي نٿا سگهن. مون کي خبر ناهي ته اهو رستو ڪٿي ٿيندو. مون کي احساس جي سطح تي هڪ شڪ آهي ته اهو ضروري ناهي ته هن جڳهه تي ڊاکر سيسلاگ ڊرائيور استعمال ڪيو وڃي. اسان جي فنڪشنل ٽيسٽنگ ڊپارٽمينٽ وٽ لاگز سان گڏ پنهنجو گريلاگ ڪلستر آهي. اهي ڊاکر لاگ ڊرائيور استعمال ڪندا آهن ۽ اتي هر شي ٺيڪ ٿي لڳي. پر اهي فوري طور تي GELF ڏانهن Graylog لکندا آهن. ان وقت جڏهن اسان اهو سڀ ڪجهه شروع ڪيو، اسان کي صرف ڪم ڪرڻ جي ضرورت هئي. شايد بعد ۾، جڏهن ڪو اچي ۽ چوي ته اهو سؤ سالن کان ڪم ڪري رهيو آهي، اسان ڪوشش ڪنداسين.
سوال: توهان rsyslog استعمال ڪندي ڊيٽا سينٽرن جي وچ ۾ پهچايو. ڪافڪا تي ڇو نه؟
جواب ڏيو: اسان اهو ڪندا آهيون، ۽ اهو ڪيئن آهي حقيقت ۾. ٻن سببن جي ڪري. جيڪڏهن چينل مڪمل طور تي مري ويو آهي، ته پوء اسان جا سڀئي لاگ، جيتوڻيڪ هڪ ٺهيل فارم ۾، ان جي ذريعي نه چڙهندا. ۽ ڪافڪا انهن کي صرف عمل ۾ وڃائڻ جي اجازت ڏئي ٿو. هن طريقي سان، اسان انهن لاگن جي چپڙي کان نجات حاصل ڪندا آهيون. اسان صرف استعمال ڪري رهيا آهيون Kafka هن معاملي ۾ سڌو سنئون. جيڪڏهن اسان وٽ هڪ سٺو چينل آهي ۽ ان کي آزاد ڪرڻ چاهيون ٿا، ته پوء اسان انهن جي rsyslog استعمال ڪندا آهيون. پر حقيقت ۾، توهان ان کي سيٽ ڪري سگهو ٿا ته جيئن اهو ڦٽو ڪري ٿو جيڪو اهو حاصل نه ڪيو ويو آهي. هن وقت اسان استعمال ڪري رهيا آهيون rsyslog ترسيل سڌو سنئون ڪٿي، ڪٿي ڪافڪا.
جو ذريعو: www.habr.com