اسان هڪ LLM کي CI لاگ جا ٽيرا بائيٽ ڏنا

توهان جي CI پائيپ لائين ۾ لڪيل سون جي مائن

هر انجنيئرنگ ٽيم انهن کي ٺاهي ٿي. لکين لائينون، هر هڪ ڏينهن - ٽائم اسٽيمپ، اسٽيڪ جا نشان، انحصار جي قراردادون، ٽيسٽ جا نتيجا، تعميراتي نمونا، ۽ خفيه غلطي پيغام جيڪي ماضي کان تيزيءَ سان طومار ڪن ٿا ان کان به وڌيڪ ڪنهن به پڙهي سگهي ٿو. سي آءِ لاگز جديد سافٽ ويئر ڊولپمينٽ جا خارجي ڌماڪا آهن، ۽ اڪثر تنظيمن لاءِ، انهن کي بلڪل خارج ڪرڻ جهڙو علاج ڪيو ويندو آهي: اسٽوريج ۾ داخل ڪيو ويو ۽ وساريو ويو. پر ڇا ڪجي جيڪڏهن اهي لاگ ان نمونن تي مشتمل هجن جيڪي ٿيڻ کان اڳ ناڪامين جي اڳڪٿي ڪري سگھن ٿيون، توهان جي ٽيم جي قيمتن ۾ رڪاوٽن جي نشاندهي ڪن ٿا سئو ڪلاڪ في ڪلاڪ، ۽ سسٽماتي مسئلن کي ظاهر ڪن ٿا جيڪي ڪو به انجنيئر ڪڏهن به نه ڏسندو آهي؟ اسان هڪ وڏي ٻولي ماڊل ۾ CI لاگ ڊيٽا جي terabytes کي فيڊ ڪندي ڳولڻ جو فيصلو ڪيو - ۽ جيڪو اسان دريافت ڪيو اهو تبديل ٿي ويو ته اسان مڪمل طور تي DevOps بابت ڪيئن سوچيو.

ڇو CI لاگز سافٽ ويئر انجنيئرنگ ۾ سڀ کان وڌيڪ غير استعمال ٿيل ڊيٽا آهن

سرسري مقدار تي غور ڪريو. هڪ وچولي سائز جي انجنيئرنگ ٽيم 200 بلڊز في ڏينهن ڪيترن ئي ذخيرن تي هلائي ٿي روزانو تقريبن 2-4 GB خام لاگ ڊيٽا ٺاهي ٿي. هڪ سال کان وڌيڪ، اهو هڪ ٽيرا بائيٽ کان وڌيڪ منظم ۽ نيم ٺهيل متن جو آهي جيڪو هر تالیف، هر ٽيسٽ سوٽ جي عملدرآمد، هر مقرري واري مرحلي، ۽ هر ناڪامي موڊ کي پڪڙي ٿو جيڪو توهان جو سسٽم ڪڏهن به سامهون آيو آهي. اهو توهان جي انجنيئرنگ تنظيم جي پيداوار جو هڪ مڪمل آرڪيالاجيڪل رڪارڊ آهي - ۽ تقريبن ڪو به ان کي نه ٿو پڙهي.

مسئلو اهو ناهي ته ڊيٽا جي قيمت نه آهي. اهو آهي ته سگنل کان شور جو تناسب وحشي آهي. هڪ عام سي آءِ رن هزارين لائينن جي پيداوار پيدا ڪري ٿي، ۽ ٿي سگهي ٿو انهن مان 3-5 لائينون قابل عمل معلومات تي مشتمل هجن. انجنيئر ڳاڙهي متن لاءِ اسڪين ڪرڻ سکن ٿا، گريپ لاءِ ”ناڪام، ۽ اڳتي وڌو. پر اهي نمونا جيڪي سڀ کان وڌيڪ اهميت رکن ٿا - فلڪي ٽيسٽ جيڪو هر اڱاري تي ناڪام ٿئي ٿو، انحصار جيڪو هر تعمير ۾ 40 سيڪنڊن جو اضافو ڪري ٿو، ميموري ليڪ جيڪا صرف سطح تي ٿئي ٿي جڏهن ٽي مخصوص خدمتون گڏ هلن ٿيون - اهي نمونا انفرادي لاگ سطح تي پوشيده آهن. اهي صرف پيماني تي ظاهر ٿيندا آهن.

روايتي لاگ تجزيي جا اوزار جهڙوڪ ELK اسٽيڪ ۽ Datadog مجموعي طور تي ميٽرڪس ۽ سطحي لفظن جي ميلاپ کي گڏ ڪري سگھن ٿا، پر اهي CI پيداوار جي بنيادي پيچيدگي سان جدوجهد ڪن ٿا. هڪ تعميراتي ناڪامي جو پيغام جيڪو پڙهي ٿو "connection refued on port 5432" ۽ هڪ جيڪو پڙهي ٿو "FATAL: password authentication fail for user 'deploy'" ٻئي ڊيٽابيس سان لاڳاپيل ناڪاميون آهن، پر انهن جا بنيادي سبب ۽ حل بلڪل مختلف آهن. ان فرق کي سمجھڻ لاءِ ان قسم جي واسطيدار استدلال جي ضرورت آھي، جيڪا، تازو وقت تائين، رڳو ماڻھو ئي مهيا ڪري سگھن ٿا.

تجربو: LLM کي 3.2 ٽيرابائيٽ بلڊ هسٽري فيڊنگ

سيٽ اپ تصور ۾ بلڪل سادو هو ۽ عمل ۾ رات جو خواب. اسان هڪ پليٽ فارم تان 14 مهينن جي CI لاگ گڏ ڪيا جيڪي 138,000 کان وڌيڪ صارفين جي خدمت ڪن ٿا - ڪيترن ئي خدمتن، ماحوليات، ۽ مقرري جي هدفن تي تعميرات کي ڍڪيندي. خام ڊيٽا سيٽ 3.2 terabytes تي آيو: تقريبن 847 ملين انفرادي لاگ لائينون جيڪي 1.6 ملين سي آءِ پائپ لائن تي پکڙيل آهن. اسان هن ڊيٽا کي ڇڪايو، شامل ڪيو، ۽ انڊيڪس ڪيو، پوءِ هڪ ٻيهر حاصل ڪرڻ لاءِ وڌيل نسل (RAG) پائپ لائن ٺاهي جيڪا اسان جي تعمير جي تاريخ بابت قدرتي ٻولي سوالن جا جواب ڏئي سگهي ٿي.

پهريون چئلينج اڳي پروسيسنگ هو. CI لاگز صاف متن نه آهن. انهن تي مشتمل آهي ANSI رنگ ڪوڊ، ترقي واري بار جيڪي پاڻ کي مٿي لکندا آهن، بائنري آرٽيڪل چيڪسم، ۽ ٽائم اسٽيمپ گهٽ ۾ گهٽ چار مختلف فارميٽ ۾ ان تي منحصر ڪري ٿو ته ڪهڙو اوزار انهن کي ٺاهي ٿو. اسان ٽي هفتا صرف نارملائيزيشن تي گذاريا - شور کي ختم ڪرڻ، ٽائم اسٽيمپ کي معياري ڪرڻ، ۽ هر لاگ سيگمينٽ کي ميٽا ڊيٽا سان ٽيگ ڪرڻ جنهن بابت پائپ لائن اسٽيج، ريپوزٽري، برانچ ۽ ماحول ان سان تعلق رکي ٿو.

ٻيو چئلينج خرچ هو. ٽيرا بائيٽس جي ٽيڪسٽ تي رننگ انفرنس سستو ناهي، ايستائين جو جارحاڻي چنڪنگ ۽ ٻيهر حاصل ڪرڻ جي اصلاح سان. اسان صرف پهرين مهيني دوران اهم ڪمپيوٽ ڪريڊٽ ذريعي ساڙيو، گهڻو ڪري ڇاڪاڻ ته اسان جو شروعاتي نقطو تمام غير معمولي هو - هر سوال تي تمام گهڻو حوالو موڪلڻ ۽ ڪافي چونڊيل نه هجڻ بابت جيڪي لاگ حصا لاڳاپيل هئا. ٻئي مهيني جي آخر تائين، اسان بهتر ايمبيڊنگ حڪمت عملين ذريعي في سوال جي قيمتن ۾ 87% گهٽتائي ڪري ڇڏينداسين ۽ ٻه-اسٽيج ٻيهر حاصل ڪرڻ وارو نظام جيڪو هڪ ننڍڙو ماڊل استعمال ڪيو ويو آهي اڳي فلٽر ڪرڻ لاءِ وڏي ۾ موڪلڻ کان اڳ.

ايل ايل ايم جا پنج نمونا مليا جيڪي انسان ڪڏهن به نه ڪندا

هلندڙ سوالن جي پهرين هفتي اندر، سسٽم بصيرت ظاهر ڪئي جيڪا دستي طور تي دريافت ڪرڻ لاءِ انساني تجزيه نگار کي مهينا لڳن ها. اهي ايج ڪيس يا تجسس نه هئا - اهي سسٽماتي مسئلا هئا جيڪي حقيقي انجنيئرنگ جا ڪلاڪ خون ڪري رهيا هئا.

1. The phantom dependency cascade. هڪ واحد npm پيڪيج اپڊيٽ 9 مهينا اڳ هر جاوا اسڪرپٽ جي تعمير لاءِ 22 سيڪنڊن جي دير متعارف ڪرائي هئي. دير کي نقاب ڪيو ويو ڇاڪاڻ ته اهو هڪ CI انفراسٽرڪچر اپ گريڊ سان ٺهڪي اچي ٿو جيڪو مجموعي طور تي تيزيءَ سان ٺاهي ٿو. Net-net، تعميرات تيزيءَ سان ظاھر ٿيا، پر اھي اڃا 22 سيڪنڊ تيز ٿي سگھن ٿا. هر روز 400+ JS ٺاهن ٿا، اهو هو 2.4 ڪلاڪ ضايع ٿيل حساب روزانو.
2. The Timezone flake. هڪ ٽيسٽ سوٽ ۾ ناڪامي جي شرح 4.7% هئي — صرف ايترو ته تمام وڏو آهي جيڪو پريشان ڪندڙ هجي، صرف ايترو گهٽ جو ڪنهن به ان کي درست ڪرڻ جي ترجيح نه ڏني. LLM جي نشاندهي ڪئي وئي آهي ته ناڪامي تقريبن مڪمل طور تي ٺهڪندڙ تعميرن سان لاڳاپيل آهي 23:00 ۽ 01:00 UTC جي وچ ۾، جڏهن هڪ تاريخ جي مقابلي واري فنڪشن هڪ ڏينهن جي حد کي پار ڪيو. هڪ ٻه-لائن واري فڪس فليڪ کي مڪمل طور تي ختم ڪري ڇڏيو.
3. خاموش رول بيڪ جو نمونو. اسٽيجنگ لاءِ ڊيپلائيمينٽس 99.2٪ وقت ڪامياب ٿي ويون، پر LLM ڏٺو ته 31 سيڪڙو ”ڪامياب“ اسٽيجنگ ڊيپلائيز 45 منٽن اندر ساڳئي سروس جي ٻي ڊيپلائي جي پٺيان هئي — تجويز ڪيو ته پهرين ڊيپلائي سڀني چيڪن پاس ڪرڻ جي باوجود فنڪشنل طور تي ٽوڙي وئي. اهو دريافت ڪرڻ جو سبب بڻيو ته هڪ انٽيگريشن ٽيسٽ پاس ٿي رهي هئي هڪ ٺٺولي سروس جي ڪيش ٿيل جوابن جي ڪري.
4. The Monday morning bottleneck. هر سومر جي مقامي وقت موجب 9:00 ۽ 10:30 AM جي وچ ۾ قطار جو وقت 340% وڌيو، ڇاڪاڻ ته ڊولپر جيڪي هفتي جي آخر ۾ ڪم ڪري رهيا هئا انهن سڀني پنهنجي تبديلين کي اسٽينڊ اپ کان اڳ وڌايو. حل ٽيڪنيڪل نه هو - اهو آپريشنل هو: سومر جي واڌ کي متوقع ڪرڻ لاءِ CI رنر پول اسڪيلنگ شيڊول کي حيران ڪرڻ.
5. ڏسڻ وارو جھنڊو جيڪو ڪنهن به مقرر نه ڪيو. 67% C++ تعميرات بغير ڪنهن واڌ ويجهه واري ڪمپيليشن جي هلندي رهي، في بلڊنگ ۾ اوسط 3.8 منٽ شامل ڪيا ويا. پرچم کي آن بورڊنگ گائيڊ ۾ دستاويز ڪيو ويو هو پر ڪڏهن به شيئر ڪيل CI ترتيب واري ٽيمپليٽ ۾ شامل نه ڪيو ويو.

"سڀ کان مهانگو بگ اهي نه هوندا آهن جيڪي توهان جي ايپليڪيشن کي خراب ڪري ڇڏيندا آهن. اهي اهي آهن جيڪي خاموشيءَ سان هر تعمير مان 30 سيڪنڊ چوري ڪندا آهن، هر روز، سالن تائين - جيستائين ڪو آخرڪار صحيح ڊيٽا سيٽ جو صحيح سوال نه پڇي."

هڪ عملي CI انٽيليجنس پرت جي تعمير

تجربو اسان کي يقين ڏياريو ته LLM-powered log analysis ڪا نئين ڳالهه ناهي - اها هڪ حقيقي آپريشنل صلاحيت آهي. پر ان کي عملي بڻائڻ لاءِ سوچيندڙ فن تعمير جي ضرورت آهي. توهان صرف خام لاگز کي چيٽ انٽرفيس ۾ پائپ نٿا ​​ڪري سگهو ۽ مفيد جوابن جي اميد رکون ٿا. سسٽم کي ڍانچي جي ضرورت آهي، ۽ ان کي ڪم فلوز ۾ ضم ٿيڻ جي ضرورت آهي انجنيئر اڳ ۾ ئي استعمال ڪري رهيا آهن.

اسان ٽن سطحن واري طريقي تي آباد ٿياسون. پهريون درجو آهي خودڪار ٽريج: هر ناڪامي تعمير خودڪار طريقي سان درجه بندي ڪئي ويندي آهي بنيادي سبب جي درجي (انفراسٽرڪچر، انحصار، ٽيسٽ منطق، ترتيب، يا فليڪ) اعتماد جي سکور سان. اهو اڪيلو تعميراتي ناڪامي لاءِ فيڪس ڪرڻ جو اوسط وقت 34 سيڪڙو گهٽائي ڇڏيو، ڇاڪاڻ ته انجنيئرن کي هاڻي 10 منٽ خرچ نه ڪرڻا پيا لاگ پڙهڻ لاءِ صرف اهو معلوم ڪرڻ لاءِ ته ڪٿي ڳولڻ شروع ڪيو وڃي. ٻيو درجو آهي رجحان جو پتو لڳائڻ: هڪ هفتيوار ڊائجسٽ جيڪو اڀرندڙ نمونن کي مٿاڇرو ڪري ٿو - ناڪامي جي شرح ۾ واڌ، وڌندڙ تعميراتي وقت، نئين غلطي جي دستخط - ان کان اڳ جو اهي نازڪ ٿي وڃن. ٽيون درجو آهي انٽرايڪٽو تحقيق: هڪ انٽرفيس جتي انجنيئر تعمير جي تاريخ بابت قدرتي ٻوليءَ جا سوال پڇي سگهن ٿا، جيئن ته "سروس X مارچ جي رليز کان پوءِ گهڻو ڪري ناڪام ڇو ٿيو؟" يا "ادائگي جي پائپ لائن ۾ وقت ختم ٿيڻ جي غلطين جو سڀ کان عام سبب ڇا آهي؟"

پيچيده عملن کي هلائڻ واري ٽيمن لاءِ - خاص طور تي جيڪي ڪيترن ئي ڪاروباري ڪمن کي منظم ڪن ٿيون جهڙوڪ CRM، انوائسنگ، پگهار، ۽ تجزياتي پليٽ فارمن ذريعي جيئن Mewayz، جيڪو 207 مربوط ماڊلز کي ترتيب ڏئي ٿو - اهڙي قسم جي مشاهدي اڃا به وڌيڪ نازڪ ٿي وڃي ٿي. جڏهن هڪ ئي ڊيپلائيمينٽ هڪ ئي وقت گراهڪ کي منهن ڏيڻ واري ڪم جي فلوز، بلنگ منطق، ۽ HR سسٽم کي ڇڪي ٿي، توهان جي CI پائپ لائن ۾ باهمي انحصار کي سمجهڻ اختياري ناهي. اهو اعتماد برقرار رکڻ لاءِ ضروري آهي جنهن تي 138,000+ صارفين انحصار ڪن ٿا.

ڇا ڪم نٿو ڪري (اڃا تائين)

ايمانداري hype کان وڌيڪ اهميت رکي ٿي. هن طريقي سان واضح حدون آهن ته هر ڪنهن کي ان تي غور ڪرڻ گهرجي. LLMs hallucinate، ۽ جڏھن اھي CI لاگن بابت hallucinate ڪندا آھن، نتيجن کي يقين سان غلط ٿي سگھي ٿو. اسان ڏٺو آهي ته سسٽم اعتماد سان هڪ تعميراتي ناڪامي کي انحصار جي تڪرار سان منسوب ڪري ٿو جيڪو ڪڏهن به موجود ناهي، ٺاهيل ورزن نمبرن سان مڪمل. RAG پائپ لائن هن کي خاص طور تي گھٽائي ٿو، پر اهو ان کي ختم نٿو ڪري. هر بصيرت جو نظام پيدا ڪري ٿو اڃا تائين عمل کان اڳ انساني تصديق جي ضرورت آهي.

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

سيڪيورٽي جو به سوال آهي. CI لاگز رازن تي مشتمل ٿي سگھن ٿا - API ڪي، ڪنيڪشن اسٽرنگ، اندروني URLs - انھن کي صاف ڪرڻ جي بهترين ڪوششن جي باوجود. ھن ڊيٽا کي ٻاھرين LLM APIs ڏانھن موڪلڻ خطري کي متعارف ڪرايو. اسان ھن کي گھٽائي سگھون ٿا مقامي اسڪربنگ پائپ لائن سان ۽ حساس ذخيرن لاءِ خود ميزباني ڪيل ماڊلز تي ھلائڻ سان، پر اھو پيچيدگي ۽ قيمت وڌائي ٿو. ٽيمن کي گهرجي ته انهن جي خطري واري نموني کي احتياط سان جائزو وٺڻ کان پهريان ان کي لاڳو ڪرڻ کان اڳ.

Terabytes کان سواءِ شروع ڪرڻ

توهان کي پنهنجي CI لاگن مان قيمت ڪڍڻ شروع ڪرڻ لاءِ وڏي ڊيٽا سيٽ يا هڪ وقف ٿيل ML انجنيئرنگ ٽيم جي ضرورت ناهي. ھتي ھڪڙو عملي نقطو آھي جنھن تي ھفتي چند سو بلڊنگز سان ڪا به ٽيم عمل ڪري سگھي ٿي:

• ناڪامي جي درجي بندي سان شروع ڪريو. هر ناڪامي کي ڀاڱن ۾ ورهائڻ لاءِ ڪو به LLM API استعمال ڪريو. ايستائين جو هڪ سادي ٽيڪنامي (انفرا بمقابله ڪوڊ بمقابله ترتيب بمقابله فليڪ) ترجيح ڏيڻ لاءِ فوري قدر فراهم ڪري ٿي.
• ٽريڪ ٺاھڻ جي مدي جي رجحانن کي. پنھنجي لاگز مان ٽائم اسٽيمپ پارس ڪريو ھڪ ٽائم سيريز ٺاھڻ لاءِ في پائپ لائن اسٽيج تي ٺاھڻ جي مدت جو. LLM ۾ بي ضابطگين کي ڀريو لاگ ان حوالي سان ۽ پڇو روٽ سبب مفروضن لاءِ.
• آٽوميٽ ڪريو "واضح" سوالن کي. هڪ ناڪامي کان پوءِ جو ٿلهو سيٽ اپ ڪريو جيڪو ناڪامي جي آخري 500 لائينون موڪلي ٿو هڪ LLM ڏانهن تڪڙي سان: "هڪ جملي ۾ هن CI ناڪامي کي مختصر ڪريو ۽ سڀ کان وڌيڪ ممڪن حل ڪرڻ جي صلاح ڏيو." اهو اڪيلو بچائي ٿو 5-10 منٽ في ناڪامي ٽيم تي هر انجنيئر لاءِ.
• هڪ ڳولهي سگهجي ٿو. اوزار جهڙوڪ LangChain ۽ LlamaIndex هن کي حيرت انگيز طور تي رسائي لائق بڻائي ٿو، ايستائين جو ٽيمن لاءِ ايم ايل تجربو کان سواءِ.