اهو 2019 آهي، ۽ اسان وٽ اڃا تائين ڪوبرنيٽس ۾ لاگ مجموعي لاءِ معياري حل ناهي. هن آرٽيڪل ۾، اسان چاهيون ٿا، حقيقي مشق مان مثالن کي استعمال ڪندي، اسان جي ڳولها، مسئلن ۽ انهن جي حل کي حصيداري ڪرڻ لاء.
بهرحال، پهرين، مان هڪ رزرويشن ڪندس ته مختلف گراهڪ لاگ گڏ ڪرڻ سان تمام مختلف شيون سمجهندا آهن:
- ڪو ماڻهو سيڪيورٽي ۽ آڊٽ لاگ ڏسڻ چاهي ٿو؛
- ڪو - سڄي انفراسٽرڪچر جي مرڪزي لاگنگ؛
- ۽ ڪجهه لاء، اهو صرف ايپليڪيشن لاگ گڏ ڪرڻ لاء ڪافي آهي، سواء، مثال طور، بيلنسرز.
هيٺ ڏنل ڪٽ هيٺ ڏنل آهي ته اسان ڪيئن مختلف "خواهش جي فهرستن" تي عمل ڪيو ۽ اسان کي ڪهڙيون مشڪلاتون پيش آيون.
نظريو: لاگنگ اوزار بابت
لاگنگ سسٽم جي اجزاء تي پس منظر
لاگنگ هڪ ڊگهو رستو اچي چڪو آهي، جنهن جي نتيجي ۾ لاگس گڏ ڪرڻ ۽ تجزيو ڪرڻ جا طريقا ٺاهيا ويا آهن، جيڪو اسان اڄ استعمال ڪندا آهيون. 1950 جي ڏهاڪي ۾، فورٽران معياري ان پٽ/آئوٽ پٽ اسٽريمز جو هڪ اينالاگ متعارف ڪرايو، جنهن پروگرامر کي پنهنجي پروگرام کي ڊيب ڪرڻ ۾ مدد ڏني. اهي پهريان ڪمپيوٽر لاگ هئا جن انهن وقتن جي پروگرامرن لاءِ زندگي آسان بڻائي ڇڏي. اڄ اسان ڏسون ٿا انهن ۾ لاگنگ سسٽم جو پهريون حصو - لاگن جو ذريعو يا ”پيداوار“.
ڪمپيوٽر سائنس اڃا بيٺي نه رهي: ڪمپيوٽر جا نيٽ ورڪ ظاهر ٿيا، پهريون ڪلستر... ڪمپليڪس سسٽم جنهن ۾ ڪيترن ئي ڪمپيوٽرن تي مشتمل آهي ڪم ڪرڻ شروع ڪيو. هاڻي سسٽم جي منتظمين کي مجبور ڪيو ويو ته ڪيترن ئي مشينن مان لاگز گڏ ڪرڻ لاء، ۽ خاص ڪيسن ۾ اهي او ايس ڪنيل پيغام شامل ڪري سگھن ٿا جيڪڏهن انهن کي سسٽم جي ناڪامي جي تحقيق ڪرڻ جي ضرورت آهي. مرڪزي لاگ گڏ ڪرڻ واري نظام کي بيان ڪرڻ لاء، شروعاتي 2000s ۾ شايع ڪيو ويو ، جنهن کي معياري بڻايو ويو remote_syslog. هي ڪيئن هڪ ٻيو اهم حصو ظاهر ٿيو: لاگ جمع ڪندڙ ۽ انهن جو ذخيرو.
لاگز جي مقدار ۾ اضافو ۽ ويب ٽيڪنالاجيز جي وسيع تعارف سان، سوال پيدا ٿيو ته ڪھڙي لاگز کي استعمال ڪندڙن کي آساني سان ڏيکاريو وڃي. سادو ڪنسول ٽولز (awk/sed/grep) کي تبديل ڪيو ويو آهي وڌيڪ جديد اوزارن سان لاگ ڏسندڙ - ٽيون حصو.
لاگن جي مقدار ۾ واڌ جي ڪري، ٻيو ڪجهه واضح ٿي ويو: لاگز جي ضرورت آهي، پر انهن مان سڀئي نه. ۽ مختلف لاگن کي تحفظ جي مختلف سطحن جي ضرورت آهي: ڪجهه هڪ ڏينهن ۾ گم ٿي سگهن ٿا، جڏهن ته ٻين کي 5 سالن تائين ذخيرو ڪرڻ جي ضرورت آهي. تنهن ڪري، ڊيٽا جي وهڪري کي فلٽر ڪرڻ ۽ روٽ ڪرڻ لاء هڪ جزو شامل ڪيو ويو لاگنگ سسٽم ۾ - اچو ته ان کي سڏين فلٽر.
اسٽوريج پڻ هڪ وڏي ڇنڊڇاڻ ڪئي آهي: باقاعده فائلن کان لاڳاپا ڊيٽابيس تائين، ۽ پوء دستاويزن تي مبني اسٽوريج تائين (مثال طور، ايلسٽسٽيسرچ). تنهن ڪري ذخيري کي ڪليڪٽر کان الڳ ڪيو ويو.
آخرڪار، لاگ جي بلڪل تصور کي وڌايو ويو آهي هڪ قسم جي تجريدي وهڪرو واقعن جو جيڪو اسان تاريخ لاء محفوظ ڪرڻ چاهيون ٿا. يا بلڪه، صورت ۾ توهان کي هڪ تحقيق ڪرڻ يا هڪ تجزياتي رپورٽ تيار ڪرڻ جي ضرورت آهي ...
نتيجي طور، وقت جي نسبتا مختصر عرصي ۾، لاگ گڏ ڪرڻ هڪ اهم سبسسٽم ۾ ترقي ڪئي آهي، جنهن کي صحيح طور تي بگ ڊيٽا جي سبسڪشن مان هڪ سڏيو وڃي ٿو.
جيڪڏهن هڪ ڀيرو عام پرنٽ "لاگنگ سسٽم" لاء ڪافي ٿي سگهي ٿي، هاڻي صورتحال تمام گهڻو تبديل ٿي چڪو آهي.
ڪبرنيٽس ۽ لاگس
جڏهن ڪبرنيٽس انفراسٽرڪچر تي آيا، لاگ گڏ ڪرڻ جو اڳ ۾ ئي موجود مسئلو ان کي نظرانداز نه ڪيو. ڪجهه طريقن سان، اهو اڃا به وڌيڪ دردناڪ ٿي ويو آهي: انفراسٽرڪچر پليٽ فارم کي منظم ڪرڻ نه رڳو آسان، پر ساڳئي وقت پيچيده پڻ. ڪيتريون ئي پراڻيون خدمتون microservices ڏانهن لڏڻ شروع ڪيون آهن. لاگز جي حوالي سان، اهو لاگ ذريعن جي وڌندڙ تعداد ۾ ظاهر ٿئي ٿو، انهن جي خاص زندگي جي چڪر، ۽ لاگز ذريعي سڀني سسٽم جي اجزاء جي رشتي کي ٽريڪ ڪرڻ جي ضرورت آهي ...
اڳتي ڏسي رهيو آهيان، مان ٻڌائي سگهان ٿو ته هاڻي، بدقسمتي سان، ڪوبرنيٽس لاءِ ڪو به معياري لاگنگ آپشن ناهي جيڪو ٻين سڀني سان بهتر نموني سان مقابلو ڪري. ڪميونٽي ۾ سڀ کان وڌيڪ مشهور منصوبا هيٺ ڏنل آهن:
- ڪو ماڻهو اسٽيڪ کي ختم ڪري ٿو اي ايف ڪي (Elasticsearch, Fluentd, Kibana);
- ڪو ماڻهو تازو جاري ڪيل ڪوشش ڪري رهيو آهي يا استعمال ڪري ٿو ;
- нас (۽ شايد نه رڳو اسان؟ ..) مان گهڻو ڪري مطمئن آهيان پنهنجي ترقيءَ سان- ...
ضابطي جي طور تي، اسان K8s ڪلستر ۾ ھيٺيون بنڊ استعمال ڪندا آھيون (خود ميزبان حل لاء):
- ;
- .
بهرحال، مان انهن جي تنصيب ۽ ترتيب جي هدايتن تي نه ويندس. ان جي بدران، آئون انهن جي گهٽتائي تي ڌيان ڏيندس ۽ عام طور تي لاگ ان سان صورتحال بابت وڌيڪ عالمي نتيجن تي.
K8s ۾ لاگن سان مشق ڪريو
”روزاني لاگ“، توهان مان ڪيترا آهن؟...
هڪ تمام وڏي انفراسٽرڪچر مان لاگز جي مرڪزي مجموعي لاءِ ڪافي وسيلن جي ضرورت هوندي آهي، جيڪي لاگز گڏ ڪرڻ، اسٽوريج ۽ پروسيسنگ ڪرڻ تي خرچ ڪيا ويندا. مختلف منصوبن جي آپريشن دوران، اسان کي مختلف ضرورتن ۽ انهن مان پيدا ٿيندڙ آپريشنل مسئلن کي منهن ڏيڻو پيو.
اچو ته ڪوشش ڪريون ClickHouse
اچو ته هڪ پروجيڪٽ تي هڪ سينٽرلائيز اسٽوريج تي نظر رکون هڪ ايپليڪيشن سان جيڪا لاگز ٺاهي ٿي فعال طور تي: 5000 کان وڌيڪ لائين في سيڪنڊ. اچو ته هن جي لاگن سان ڪم ڪرڻ شروع ڪريون، انهن کي ڪلڪ هائوس ۾ شامل ڪريون.
جيترو جلدي وڌ ۾ وڌ حقيقي وقت گهربل آهي، ڪلڪ هائوس سان 4-ڪور سرور اڳ ۾ ئي ڊسڪ سب سسٽم تي اوورلوڊ ڪيو ويندو:
هن قسم جي لوڊشيڊنگ ان حقيقت جي ڪري آهي ته اسان جلدي ممڪن طور تي ڪلڪ هائوس ۾ لکڻ جي ڪوشش ڪري رهيا آهيون. ۽ ڊيٽابيس انهي کي رد ڪري ٿو وڌائي ڊسڪ لوڊ سان، جنهن ۾ هيٺيان غلطيون ٿي سگهن ٿيون:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
نڪتو ته آهي ClickHouse ۾ (اهي لاگ ڊيٽا تي مشتمل آهن) لکڻ جي عملن دوران پنهنجون مشڪلاتون آهن. انهن ۾ داخل ڪيل ڊيٽا هڪ عارضي ورهاڱي ٺاهي ٿي، جيڪا پوء مکيه ٽيبل سان ملائي وئي آهي. نتيجي طور، رڪارڊنگ ڊسڪ تي تمام گهڻو مطالبو ڪيو ويو آهي، ۽ اهو پڻ ان حد جي تابع آهي جنهن بابت اسان مٿي ڄاڻايل نوٽيس حاصل ڪيو آهي: 1 کان وڌيڪ ذيلي تقسيم 300 سيڪنڊن ۾ ضم نه ٿي سگھن ٿيون (حقيقت ۾، اهو 300 داخل ڪيو ويو آهي. في سيڪنڊ).
هن رويي کان بچڻ لاء، جيترو ٿي سگهي وڏي ٽڪرن ۾ ۽ هر 1 سيڪنڊن ۾ 2 ڀيرا کان وڌيڪ نه. بهرحال، وڏي دفن ۾ لکڻ جو مشورو ڏئي ٿو ته اسان کي ڪلڪ هائوس ۾ گهٽ اڪثر لکڻ گهرجي. اهو، موڙ ۾، هڪ بفر اوور فلو ۽ لاگن جي نقصان جي ڪري سگھي ٿو. حل اهو آهي ته Fluentd بفر کي وڌايو وڃي، پر پوءِ ميموري جو استعمال به وڌندو.
ويچاري: ClickHouse سان اسان جي حل جو ٻيو مسئلو ان حقيقت سان لاڳاپيل هو ته اسان جي ڪيس (لاگ هائوس) ۾ ورهاڱي کي ٻاهرين جدولن سان جڙيل آهي. . اهو حقيقت ڏانهن وٺي ٿو ته جڏهن نموني وڏي وقت جي وقفن کي، تمام گهڻي RAM جي ضرورت هوندي آهي، ڇاڪاڻ ته ميٽيٽيبل سڀني ورهاڱي جي ذريعي ورجائي ٿو - جيتوڻيڪ اهي جيڪي واضح طور تي ضروري ڊيٽا تي مشتمل نه آهن. بهرحال، هاڻي اهو طريقو محفوظ طور تي ClickHouse (c ).
نتيجي طور، اهو واضح ٿئي ٿو ته هر پروجيڪٽ ڪافي وسيلا نه هوندا آهن لاگس گڏ ڪرڻ لاءِ اصل وقت ۾ ClickHouse ۾ (وڌيڪ واضح طور تي، انهن جي ورڇ مناسب نه هوندي). ان کان سواء، توهان کي استعمال ڪرڻ جي ضرورت پوندي аккумулятор، جنهن ڏانهن اسان بعد ۾ واپس ڪنداسين. مٿي بيان ڪيل ڪيس حقيقي آهي. ۽ ان وقت اسان هڪ قابل اعتماد ۽ مستحڪم حل پيش ڪرڻ کان قاصر هئاسين جيڪو گراهڪ لاءِ مناسب هجي ۽ اسان کي گهٽ ۾ گهٽ دير سان لاگ گڏ ڪرڻ جي اجازت ڏئي.
Elasticsearch بابت ڇا؟
Elasticsearch ڳري ڪم لوڊ کي سنڀالڻ لاءِ سڃاتو وڃي ٿو. اچو ته ان کي ساڳي منصوبي ۾ ڪوشش ڪريو. هاڻي لوڊ هن طرح نظر اچي ٿو:
Elasticsearch ڊيٽا جي وهڪري کي هضم ڪرڻ جي قابل هئي، جڏهن ته، اهڙيون حجم لکڻ ان کي تمام گهڻو استعمال ڪري ٿو سي پي يو. اهو هڪ ڪلستر کي منظم ڪندي فيصلو ڪيو ويو آهي. ٽيڪنيڪل طور تي، اهو ڪو مسئلو ناهي، پر اهو ظاهر ٿئي ٿو ته صرف لاگ گڏ ڪرڻ واري نظام کي هلائڻ لاء اسان اڳ ۾ ئي تقريبا 8 ڪور استعمال ڪندا آهيون ۽ سسٽم ۾ هڪ اضافي انتهائي لوڊ ٿيل جزو آهي ...
هيٺيون لڪير: هي اختيار صحيح ثابت ٿي سگهي ٿو، پر صرف ان صورت ۾ جڏهن پروجيڪٽ وڏو آهي ۽ ان جو انتظام مرڪزي لاگنگ سسٽم تي اهم وسيلن کي خرچ ڪرڻ لاء تيار آهي.
پوءِ هڪ فطري سوال پيدا ٿئي ٿو:
ڪھڙين لاگن جي واقعي ضرورت آھي؟
اچو ته پاڻ ئي طريقي کي تبديل ڪرڻ جي ڪوشش ڪريون: لاگس کي گڏوگڏ معلوماتي هجڻ گهرجي ۽ نه ڍڪڻ گهرجي هر هڪ سسٽم ۾ واقعا.
اچو ته اسان وٽ هڪ ڪامياب آن لائن اسٽور آهي. ڪهڙا لاگ اھم آھن؟ جيترو ٿي سگهي معلومات گڏ ڪرڻ، مثال طور، ادائگي جي گيٽ وي کان، هڪ بهترين خيال آهي. پر پراڊڪٽ ڪيٽلاگ ۾ تصويري سلائسنگ سروس جا سڀئي لاگ اسان لاءِ نازڪ نه آهن: صرف غلطيون ۽ جديد نگراني ڪافي آهن (مثال طور، 500 غلطين جو سيڪڙو جيڪو هي جزو ٺاهي ٿو).
تنهنڪري اسان ان نتيجي تي پهتا آهيون مرڪزي لاگنگ هميشه جائز نه آهي. گهڻو ڪري ڪلائنٽ سڀني لاگن کي هڪ جڳهه تي گڏ ڪرڻ چاهي ٿو، جيتوڻيڪ حقيقت ۾، سڄي لاگ مان، صرف هڪ مشروط 5٪ پيغام جيڪي ڪاروبار لاءِ نازڪ آهن گهربل آهن:
- ڪڏهن ڪڏهن ان کي ترتيب ڏيڻ لاء ڪافي آهي، چون ٿا، صرف ڪنٽينر لاگ جي سائيز ۽ غلطي ڪليڪٽر (مثال طور، سينٽري).
- هڪ غلطي نوٽيفڪيشن ۽ هڪ وڏو مقامي لاگ پاڻ اڪثر واقعن جي تحقيقات لاء ڪافي ٿي سگهي ٿو.
- اسان وٽ منصوبا هئا جيڪي خاص طور تي فنڪشنل ٽيسٽ ۽ غلطي گڏ ڪرڻ واري نظام سان ڪيا ويا. ڊولپر کي لاگس جي ضرورت نه هئي جيئن ته - انهن غلطي جي نشانين مان سڀ ڪجهه ڏٺو.
زندگيءَ مان عڪس
ٻي ڪهاڻي هڪ سٺو مثال طور ڪم ڪري سگهي ٿي. اسان کي اسان جي هڪ ڪلائنٽ جي سيڪيورٽي ٽيم کان هڪ درخواست ملي آهي جيڪو اڳ ۾ ئي هڪ تجارتي حل استعمال ڪري رهيو هو جيڪو ڪبرنيٽس جي تعارف کان گهڻو اڳ تيار ڪيو ويو هو.
اهو ضروري هو ته "دوست بڻائڻ" مرڪزي لاگ گڏ ڪرڻ واري نظام کي ڪارپوريٽ مسئلو ڳولڻ سينسر سان - QRadar. هي سسٽم syslog پروٽوڪول ذريعي لاگز حاصل ڪري سگهي ٿو ۽ انهن کي ايف ٽي پي مان ٻيهر حاصل ڪري سگهي ٿو. بهرحال، اهو فوري طور تي ممڪن نه هو ته ان کي fluentd لاءِ remote_syslog پلگ ان سان ضم ڪرڻ (جيئن ته اهو نڪتو، ). QRadar کي ترتيب ڏيڻ سان مسئلا ڪلائنٽ جي سيڪيورٽي ٽيم جي پاسي ۾ ٿي ويا.
نتيجي طور، ڪاروباري-نازڪ لاگز جو حصو FTP QRadar تي اپ لوڊ ڪيو ويو، ۽ ٻيو حصو ريموٽ syslog ذريعي سڌو سنئون نوڊس مان. ان لاءِ اسان به لکيو آهي - ٿي سگهي ٿو اهو ڪنهن جي مدد ڪندو هڪ جهڙو مسئلو حل ڪرڻ ۾... نتيجي واري اسڪيم جي مهرباني، ڪلائنٽ پاڻ نازڪ لاگس حاصل ڪيا ۽ تجزيو ڪيو (پنهنجي پسنديده اوزار استعمال ڪندي)، ۽ اسان لاگنگ سسٽم جي قيمت کي گهٽائڻ جي قابل ٿي ويا، صرف بچت. گذريل مھيني.
ٻيو مثال ڪافي اشارو آهي ته ڇا نه ڪجي. پروسيسنگ لاء اسان جي گراهڪن مان هڪ هر هڪ جو يوزر کان اچڻ وارا واقعا، ملٽي لائن ڪئي غير منظم پيداوار لاگ ۾ ڄاڻ. جئين توهان اندازو لڳائي سگهو ٿا، اهڙيون لاگز پڙهڻ ۽ اسٽور ٻنهي لاء انتهائي ناگزير هئا.
لاگن لاء معيار
اھڙا مثال ھن نتيجي تي پھچندا آھن ته لاگ گڏ ڪرڻ واري نظام کي چونڊڻ کان علاوه، توھان کي ضرورت آھي پڻ لاگز پاڻ کي ڊزائين! هتي ڪهڙيون گهرجون آهن؟
- لاگز مشين پڙهڻ جي قابل فارميٽ ۾ هجڻ گهرجن (مثال طور، JSON).
- لاگز کي ٺهيل هجڻ گهرجي ۽ ممڪن مسئلن کي ڊيب ڪرڻ لاء لاگنگ جي درجي کي تبديل ڪرڻ جي صلاحيت سان. ساڳئي وقت، پيداوار جي ماحول ۾ توهان کي سسٽم هلائڻ گهرجي لاگنگ جي سطح سان خبردار يا مسئلو.
- لاگز کي عام ٿيڻ گهرجي، اهو آهي، هڪ لاگ اعتراض ۾، سڀني لائينن کي ساڳيو فيلڊ قسم هجڻ گهرجي.
اڻڄاتل لاگ ان کي اسٽوريج ۾ لوڊ ڪرڻ ۽ انهن جي پروسيسنگ ۾ مڪمل اسٽاپ سان مسئلا پيدا ڪري سگھن ٿا. هڪ مثال جي طور تي، هتي هڪ مثال آهي غلطي 400 سان، جنهن ۾ ڪيترائي ضرور ضرور سامهون آيا آهن fluentd لاگز:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
غلطي جو مطلب آهي ته توهان هڪ فيلڊ موڪلي رهيا آهيو جنهن جو قسم تيار ٿيل ميپنگ سان انڊيڪس ڏانهن غير مستحڪم آهي. سادو مثال هڪ فيلڊ آهي nginx لاگ ۾ هڪ متغير سان $upstream_status. اهو يا ته هڪ نمبر يا هڪ تار تي مشتمل ٿي سگھي ٿو. مثال طور:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
لاگ ان ڏيکاري ٿو ته سرور 10.100.0.10 هڪ 404 غلطي سان جواب ڏنو ۽ درخواست موڪلي وئي ٻي مواد اسٽوريج ڏانهن. نتيجي طور، لاگن ۾ قيمت هن طرح بڻجي وئي:
"upstream_response_time": "0.001, 0.007"
اها صورتحال ايتري عام آهي ته اها به هڪ الڳ مستحق آهي .
اعتبار بابت ڇا؟
اھڙا وقت آھن جڏھن سڀ لاگ بغير استثناء جي اھم آھن. ۽ ان سان گڏ، K8s لاءِ عام لاگ گڏ ڪرڻ واري اسڪيمن ۾ تجويز ڪيل/ڳالهايل مسئلا آهن.
مثال طور، fluentd مختصر-رهندڙ ڪنٽينرز مان لاگ گڏ نه ٿو ڪري سگھي. اسان جي ھڪڙي منصوبي ۾، ڊيٽابيس لڏپلاڻ ڪنٽينر 4 سيڪنڊن کان گھٽ رھيو ۽ پوءِ ختم ڪيو ويو - لاڳاپيل تشريح جي مطابق:
"helm.sh/hook-delete-policy": hook-succeeded
انهي جي ڪري، لڏپلاڻ جي عمل جي لاگ ان اسٽوريج ۾ شامل نه هئي. سياست هن معاملي ۾ مدد ڪري سگهي ٿي. before-hook-creation.
ٻيو مثال Docker لاگ گردش آهي. اچو ته چوندا آهن ته هڪ ايپليڪيشن آهي جيڪو فعال طور تي لاگ ان کي لکي ٿو. عام حالتن ۾، اسان سڀني لاگن کي پروسيس ڪرڻ جو انتظام ڪريون ٿا، پر جيئن ئي ڪو مسئلو ظاهر ٿئي ٿو - مثال طور، جيئن مٿي بيان ڪيل غلط فارميٽ سان - پروسيسنگ روڪي ٿي، ۽ ڊڪر فائل کي گھمائي ٿو. نتيجو اهو آهي ته ڪاروباري-نازڪ لاگز گم ٿي سگهن ٿيون.
اهو ڇو ٿو لاگ اسٽريم کي الڳ ڪرڻ ضروري آهيسڀ کان وڌيڪ قيمتي شيون سڌو سنئون ايپليڪيشن ۾ موڪلڻ لاء انهن جي حفاظت کي يقيني بڻائڻ لاء. ان کان سواء، اهو ڪجهه ٺاهڻ لاء غير ضروري نه هوندو لاگن جو ”جمع ڪندڙ“، جيڪو نازڪ پيغامن کي محفوظ ڪرڻ دوران مختصر اسٽوريج جي غير موجودگيءَ کان بچي سگھي ٿو.
آخرڪار، اسان کي اهو نه وسارڻ گهرجي اهو ضروري آهي ته ڪنهن به سب سسٽم کي صحيح طور تي مانيٽر ڪرڻ لاء. ٻي صورت ۾، هڪ اهڙي صورتحال ۾ هلڻ آسان آهي جنهن ۾ فلو هڪ حالت ۾ آهي CrashLoopBackOff ۽ ڪجھ به نه موڪليندو آهي، ۽ اهو اهم معلومات جي نقصان جو واعدو ڪري ٿو.
پهچڻ
هن آرٽيڪل ۾، اسان Datadog وانگر SaaS حل نه ڏسي رهيا آهيون. هتي بيان ڪيل ڪيترائي مسئلا اڳ ۾ ئي هڪ طريقي سان حل ڪيا ويا آهن تجارتي ڪمپنيون جيڪي لاگ گڏ ڪرڻ ۾ ماهر آهن، پر هرڪو مختلف سببن جي ڪري SaaS استعمال نٿو ڪري سگهي. (مکيه آهن قيمت ۽ تعميل 152-FZ سان).
مرڪزي لاگ گڏ ڪرڻ پهريون ڀيرو هڪ سادي ڪم وانگر نظر اچي ٿو، پر اهو بلڪل ناهي. اهو ياد رکڻ ضروري آهي ته:
- صرف نازڪ حصن کي تفصيل سان لاگ ان ٿيڻ جي ضرورت آهي، جڏهن ته نگراني ۽ غلطي گڏ ڪرڻ ٻين سسٽم لاء ترتيب ڏئي سگهجي ٿو.
- پيداوار ۾ لاگ ان کي گهٽ ۾ گهٽ رکڻ گهرجي ته جيئن غير ضروري لوڊ شامل نه ٿئي.
- لاگز کي مشين پڙهڻ جي قابل، عام ڪرڻ، ۽ سخت فارميٽ هجڻ گهرجي.
- واقعي نازڪ لاگن کي الڳ اسٽريم ۾ موڪليو وڃي، جنهن کي مکيه کان الڳ ڪيو وڃي.
- اهو هڪ لاگ جمع ڪندڙ تي غور ڪرڻ جي قابل آهي، جيڪو توهان کي تيز لوڊ جي دفن کان بچائي سگهي ٿو ۽ اسٽوريج تي لوڊ وڌيڪ يونيفارم ٺاهيندو.
اهي سادي ضابطا، جيڪڏهن هر جڳهه تي لاڳو ٿين ٿا، مٿي بيان ڪيل سرڪٽ کي ڪم ڪرڻ جي اجازت ڏين ٿا - جيتوڻيڪ اهي اهم جزا (بيٽري) غائب آهن. جيڪڏهن توهان اهڙن اصولن تي عمل نه ڪندا، اهو ڪم آساني سان توهان کي ۽ انفراسٽرڪچر کي سسٽم جي ٻئي انتهائي لوڊ ٿيل (۽ ساڳئي وقت غير موثر) جزو ڏانهن وٺي ويندو.
پي ايس
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com