نوٽ. ترجمو: هن مواد جو ليکڪ آهي Cindy Sridharan، هڪ انجنيئر imgix تي جيڪو API ڊولپمينٽ ۽ خاص طور تي مائڪرو سروس ٽيسٽنگ ۾ ماهر آهي. هن مواد ۾، هوء ورهايل ٽريڪنگ جي ميدان ۾ موجوده مسئلن جي تفصيلي نظر کي حصيداري ڪري ٿي، جتي، هن جي راء ۾، دٻائڻ واري مسئلن کي حل ڪرڻ لاء واقعي اثرائتي اوزار جي کوٽ آهي.
[مثال مان ورتل ورهايل ٽريڪنگ بابت.]
اهو يقين آهي ته عمل ڪرڻ ڏکيو، ۽ ان تي واپسي . هتي ڪيترائي سبب آهن ڇو ته ٽريڪنگ مشڪل آهي، اڪثر ڪري هر سسٽم جي اجزاء کي ترتيب ڏيڻ ۾ ملوث مزدور جو حوالو ڏئي ٿو ته هر درخواست سان مناسب هيڊر منتقل ڪرڻ لاء. جيتوڻيڪ اهو مسئلو موجود آهي، اهو ڪنهن به طرح ناقابل حل ناهي. رستي ۾، اهو وضاحت نٿو ڪري ته ڊولپرز واقعي پسند نه ڪندا آهن ٽريڪنگ (جيتوڻيڪ جڏهن اهو اڳ ۾ ئي ڪم ڪري رهيو آهي).
ورهايل ٽريڪنگ سان گڏ بنيادي چئلينج ڊيٽا گڏ نه ڪرڻ، نتيجن کي ورهائڻ ۽ پيش ڪرڻ لاء فارميٽ کي معياري ڪرڻ، يا اهو طئي ڪرڻ آهي ته ڪڏهن، ڪٿي، ۽ ڪيئن نموني ڪجي. مان تصور ڪرڻ جي ڪوشش نه ڪري رهيو آهيان معمولي اهي "سمجهڻ جا مسئلا" آهن، حقيقت ۾، ڪافي اهم ٽيڪنيڪل ۽ (جيڪڏهن اسان واقعي اوپن سورس تي غور ڪري رهيا آهيون) انهن مسئلن کي حل ڪرڻ لاءِ سياسي چئلينجز جن تي ضابطو آڻڻ جي ضرورت آهي.
بهرحال، جيڪڏهن اسان تصور ڪريون ته اهي سڀئي مسئلا حل ٿي ويا آهن، اتي هڪ وڏو امڪان آهي ته ڪجهه به اهم طور تي تبديل نه ٿيندو. آخر استعمال ڪندڙ تجربو. ٽريڪنگ اڃا تائين عملي استعمال جي نه ٿي سگھي ٿي سڀ کان وڌيڪ عام ڊيبگنگ منظرنامن ۾- جيتوڻيڪ ان کي ترتيب ڏيڻ کان پوءِ.
اهڙي طرح هڪ مختلف نشان
ورهايل ٽريڪنگ ۾ ڪيترائي مختلف جزا شامل آھن:
- ايپليڪيشنن ۽ وچولي ويئر کي ڪنٽرول اوزار سان ليس ڪرڻ؛
- ورهايل حوالن جي منتقلي؛
- نشانن جو مجموعو؛
- ٽريڪ اسٽوريج؛
- انهن جي ڪڍڻ ۽ ڏسڻ.
ورهايل ٽريڪنگ بابت تمام گهڻيون ڳالهيون ان کي هڪ قسم جي غير معمولي آپريشن جي طور تي علاج ڪرڻ جي ڪوشش ڪري ٿو جنهن جو واحد مقصد سسٽم جي مڪمل تشخيص ۾ مدد ڪرڻ آهي. اهو گهڻو ڪري ان ڪري آهي ته ڪيئن ورهايل ٽريڪنگ بابت خيال تاريخي طور تي ٺاهيا ويا آهن. IN ، ٺاهيو ويو جڏهن زپڪن ذريعن کي کوليو ويو، اهو ذڪر ڪيو ويو آهي اهو [Zipkin] Twitter کي تيز ڪري ٿو. ٽريڪنگ لاءِ پهرين تجارتي پيشڪش پڻ ترقي ڪئي وئي جيئن .
نوٽ. ترجمو: وڌيڪ متن کي سمجھڻ ۾ آسان بڻائڻ لاءِ، اچو ته ٻن بنيادي اصطلاحن جي وضاحت ڪريون :
- span - ورهايل ٽريڪنگ جو بنيادي عنصر. اهو هڪ مخصوص ڪم فلو جي وضاحت آهي (مثال طور، هڪ ڊيٽابيس جو سوال) نالي سان، شروع ۽ آخر جي وقت، ٽيگ، لاگز ۽ حوالي سان.
- اسپن ۾ عام طور تي ٻين اسپنن جي لنڪ شامل هوندي آهي، ڪيترن ئي اسپن کي گڏ ڪرڻ جي اجازت ڏئي ٿي ٽريڪ - هڪ درخواست جي زندگي جو تصور جيئن ته اهو هڪ ورهايل نظام ذريعي هلندو آهي.
نشانن ۾ ناقابل اعتبار حد تائين قيمتي ڊيٽا شامل آهن جيڪي ڪمن ۾ مدد ڪري سگھن ٿيون جهڙوڪ پيداوار جي جاچ، آفت جي بحالي جي جاچ، غلطي انجڻ جي جاچ، وغيره. حقيقت ۾، ڪجهه ڪمپنيون اڳ ۾ ئي ساڳئي مقصدن لاء ٽريڪنگ استعمال ڪن ٿيون. اچو ته شروع ڪريون اسٽوريج سسٽم ۾ صرف اسپن کي منتقل ڪرڻ کان علاوه ٻيا استعمال آهن:
- مثال طور، Uber جاچ جا نتيجا ٽيسٽ ٽرئفڪ ۽ پيداوار جي ٽرئفڪ جي وچ ۾ فرق ڪرڻ لاءِ.
- ڪريو نازڪ رستي جي تجزيي لاءِ ۽ ٽريفڪ سوئچنگ لاءِ باقاعده آفت جي بحالي واري ٽيسٽ دوران ڊيٽا کي ڇڪيو.
- پڻ سماجي نيٽ ورڪ Jupyter نوٽ بڪ جيڪي ڊولپرز کي اجازت ڏين ٿا ته اھي پاڻمرادو سوالن جا نشان ھلائين.
- پيروڪار (نسب تي هلندڙ ناڪامي انجکشن) نقص انجيڪشن سان جاچ لاءِ ورهايل نشان.
مٿي ڏنل فهرستن مان ڪوبه به مڪمل طور تي منظرنامي تي لاڳو نٿو ٿئي ڊيبگ، جنهن دوران انجنيئر ٽريس کي ڏسي مسئلو حل ڪرڻ جي ڪوشش ڪري ٿو.
جڏهن اهو اچي ٿو اڃا تائين ڊيبگنگ اسڪرپٽ تائين پهچي ٿو، بنيادي انٽرفيس ڊاگرام رهي ٿو سراغ ڏسڻ (جيتوڻيڪ ڪجھ به ان کي سڏين ٿا "گنٽ چارٽ" يا "آبشار خاڪو"). هيٺ سراغ ڏسڻ я سڀئي اسپانس ۽ گڏوگڏ ميٽاداٽا جيڪي گڏ ٿين ٿا سراغ. هر اوپن سورس ٽريڪنگ سسٽم، گڏوگڏ هر تجارتي ٽريڪنگ حل، پيش ڪري ٿو a سراغ ڏسڻ يوزر انٽرفيس ڏسڻ لاءِ، تفصيل ڏيڻ ۽ فلٽر ڪرڻ جا نشان.
مون ڏٺو آهي سڀني ٽريڪنگ سسٽم سان مسئلو اهو آهي ته نتيجو اهو آهي بصري (سراغ ڏسڻ) تقريبن مڪمل طور تي ٽريس نسل جي عمل جي خاصيتن کي ظاهر ڪري ٿو. جيتوڻيڪ جڏهن متبادل تصورات تجويز ڪيا ويا آهن: هيٽ ميپس، سروس ٽوپولاجس، ليٽيسي هسٽوگرامس، اهي اڃا تائين آخرڪار هيٺ اچن ٿا. سراغ ڏسڻ.
ماضي ۾ I جيڪي UI/UX ٽريڪنگ ۾ اڪثر ”جدت“ تائين محدود نظر اچن ٿا اضافي ميٽاداٽا ٽريڪ ۾، انهن ۾ سيڙپڪاري جي معلومات اعلي ڪارڪردگي سان (اعلي شخصيت) يا مخصوص اسپنن ۾ ڊرل ڪرڻ جي صلاحيت مهيا ڪرڻ يا سوالن کي هلائڻ inter- and intra-trace... جتي سراغ ڏسڻ بنيادي بصري اوزار رهي ٿو. جيستائين اها حالت جاري رهندي، تقسيم ٿيل ٽريڪنگ (بهترين طور تي) ڊيبگنگ ٽول جي طور تي 4th جاء وٺندو، ميٽرڪس، لاگز ۽ اسٽيڪ جي نشانين کان پوء، ۽ بدترين طور تي اهو پئسا ۽ وقت جو ضايع ٿيندو.
Traceview سان مسئلو
مقصد سراغ ڏسڻ - ورهايل سسٽم جي سڀني حصن ۾ هڪ واحد درخواست جي حرڪت جي مڪمل تصوير مهيا ڪريو جنهن سان اهو لاڳاپيل آهي. ڪجهه وڌيڪ ترقي يافته ٽريڪنگ سسٽم توهان کي اجازت ڏين ٿا ته توهان انفرادي اسپن ۾ ڊرل ڪريو ۽ وقت سان گڏ خرابي کي ڏسو اندر ھڪڙو عمل (جڏھن اسپينن کي فنڪشنل حدون آھن).
مائڪرو سروسز آرڪيٽيڪچر جو بنيادي بنياد اهو خيال آهي ته تنظيمي جوڙجڪ ڪمپني جي ضرورتن سان وڌي ٿي. microservices جا حامي دليل ڏين ٿا ته مختلف ڪاروباري ڪمن کي انفرادي خدمتن ۾ ورهائڻ ننڍڙن، خودمختيار ڊولپمينٽ ٽيمن کي اجازت ڏئي ٿو ته اهي اهڙين خدمتن جي پوري زندگي کي ڪنٽرول ڪن، انهن کي انهن خدمتن کي آزاديءَ سان تعمير ڪرڻ، ٽيسٽ ڪرڻ ۽ ترتيب ڏيڻ جي صلاحيت ڏئي ٿي. بهرحال، هن ورڇ جو نقصان معلومات جو نقصان آهي ته هر خدمت ٻين سان ڪيئن لهي ٿي. اهڙين حالتن ۾، ورهايل ٽريڪنگ دعويٰ لاءِ هڪ لازمي اوزار آهي ڊيبگ خدمتن جي وچ ۾ پيچيده رابطي.
جيڪڏهن توهان واقعي پوءِ ڪو به ماڻهو ان کي پنهنجي سر ۾ رکڻ جي قابل ناهي مڪمل ڪيو تصوير. حقيقت ۾، هڪ اوزار کي ترقي ڪرڻ جي بنياد تي مفروضو ته اهو ممڪن آهي ته هڪ مخالف نموني جي شيء آهي (هڪ غير موثر ۽ غير پيداوار واري طريقي سان). مثالي طور، ڊيبگنگ کي هڪ اوزار جي ضرورت آهي جيڪا مدد ڪري ٿي توهان جي ڳولا واري علائقي کي تنگ ڪريو, ته جيئن انجنيئر غور ڪيو پيو وڃي مسئلي جي منظر سان لاڳاپيل طول و عرض جي ذيلي سيٽ (سروسز/استعمال ڪندڙ/ميزبان، وغيره) تي ڌيان ڏئي سگهي ٿو. جڏهن ناڪامي جي سبب کي طئي ڪندي، انجنيئرن کي اهو سمجهڻ جي ضرورت ناهي ته ڇا ٿيو هڪ ئي وقت ۾ سڀ خدمتون, جيئن ته اهڙي گهرج microservice فن تعمير جي بلڪل خيال جي تضاد ڪندو.
تنهن هوندي به، traceview آهي انهيء کان هي. ها، ڪجهه ٽريڪنگ سسٽم پيش ڪن ٿا ڪمپريسڊ ٽريس ويوز جڏهن ٽريس ۾ اسپانن جو تعداد ايترو وڏو آهي جو اهي هڪ تصوير ۾ ظاهر نه ٿي سگهن. تنهن هوندي به، معلومات جي وڏي مقدار ۾ موجود هجڻ جي ڪري جيتوڻيڪ اهڙي پٽي-ڊائون ڏسڻ ۾، انجنيئر اڃا تائين مجبور ان کي "ٻاهرايو"، دستي طور تي چونڊ کي محدود ڪندي خدمتن جي سيٽ تائين جيڪي مسئلن جا ذريعا آهن. بدقسمتي سان، هن فيلڊ ۾، مشينون انسانن جي ڀيٽ ۾ تمام تيز آهن، گهٽ غلطيون آهن، ۽ انهن جا نتيجا وڌيڪ ورجائي سگهجن ٿا.
ٻيو سبب مان سمجهان ٿو ته traceview غلط آهي ڇو ته اهو فرضي بنيادن تي هلندڙ ڊيبگنگ لاءِ سٺو ناهي. ان جي بنياد تي، ڊيبنگ آهي ورجائيندڙ هڪ عمل جيڪو هڪ مفروضي سان شروع ٿئي ٿو، جنهن کان پوءِ مختلف مشاهدن ۽ حقيقتن جي تصديق ڪئي وڃي ٿي ۽ مختلف ویکٹرن سان گڏ سسٽم مان حاصل ڪيل حقيقتن، نتيجن/جنرلائيزيشنز ۽ مفروضي جي سچائي جو وڌيڪ جائزو.
موقعو تيز ۽ سستو مفروضن کي جانچڻ ۽ ان جي مطابق ذهني ماڊل کي بهتر ڪرڻ بنياد جو پٿر ڊيبگنگ ڪنهن به debugging اوزار هجڻ گهرجي انٽرويو ۽ ڳولا جي جڳھ کي تنگ ڪريو يا، غلط ليڊ جي صورت ۾، صارف کي واپس وڃڻ جي اجازت ڏيو ۽ سسٽم جي مختلف علائقي تي ڌيان ڏيڻ. مڪمل اوزار اهو ڪم ڪندو فعال طور تي، فوري طور تي صارف جي ڌيان ڇڪائيندي امڪاني مسئلن وارن علائقن ڏانهن.
افسوس، سراغ ڏسڻ انٽرفيس سان گڏ هڪ اوزار نه ٿو چئي سگهجي. بهترين توهان اميد ڪري سگهو ٿا جڏهن ان کي استعمال ڪيو وڃي ته وڌايل ويڪرائي جو ڪجهه ذريعو ڳولڻ ۽ ان سان لاڳاپيل سڀني ممڪن ٽيگ ۽ لاگز کي ڏسو. اهو انجنيئر کي سڃاڻڻ ۾ مدد نٿو ڪري نمونو ٽرئفڪ ۾، جيئن ته دير جي ورڇ جي وضاحت، يا مختلف ماپن جي وچ ۾ لاڳاپا ڳولڻ. انهن مسئلن مان ڪجهه حل ڪرڻ ۾ مدد ڪري سگهي ٿي. واقعي، ڪامياب تجزيو مشين لرننگ استعمال ڪندي غير معمولي اسپن کي سڃاڻڻ ۽ ٽيگ جي هڪ ذيلي سيٽ کي سڃاڻڻ لاءِ جيڪو شايد غير معمولي رويي سان لاڳاپيل هجي. بهرحال، مون اڃا تائين مشين لرننگ يا ڊيٽا مائننگ جي نتيجن جا زبردست تصور ڏسڻا آهن جيڪي اسپن تي لاڳو ڪيا ويا آهن جيڪي خاص طور تي ٽريڪ وييو يا DAG (هدايت ڪيل ايڪائيڪل گراف) کان مختلف آهن.
اسپين تمام گهٽ سطح تي آهن
traceview سان بنيادي مسئلو اهو آهي اسپانس تمام گھٽ-سطح جي پريميٽوز ٻنهي ويڪرائي تجزيي ۽ بنيادي سببن جي تجزيي لاءِ. اهو هڪ استثنا کي حل ڪرڻ جي ڪوشش ڪرڻ لاءِ انفرادي پروسيسر حڪمن کي پارس ڪرڻ وانگر آهي، اهو ڄاڻڻ ته اتي تمام اعليٰ سطحي اوزار آهن جهڙوڪ backtrace جيڪي ڪم ڪرڻ لاءِ وڌيڪ آسان آهن.
ان کان علاوه، مان هيٺ ڏنل بيان ڪرڻ جي آزادي وٺندس: مثالي طور تي، اسان کي ضرورت ناهي مڪمل تصوير درخواست جي زندگي جي چڪر دوران واقع ٿيو، جيڪو جديد ٽريڪنگ اوزار جي نمائندگي ڪري ٿو. ان جي بدران، اعلي سطحي تجريد جي ڪجهه شڪل گهربل آهي جنهن ۾ ڪهڙي معلومات شامل آهي غلط ويو (بئڪٽريس وانگر)، ڪجهه حوالي سان. سڄو سراغ ڏسڻ بدران، مان ان کي ڏسڻ پسند ڪريان ٿو часть، جتي ڪجهه دلچسپ يا غير معمولي ٿئي ٿي. في الحال، ڳولها دستي طور تي ڪئي وئي آهي: انجنيئر ٽريڪ حاصل ڪري ٿو ۽ آزاديء سان تجزيه ڪري ٿو اسپين کي دلچسپ شيء جي ڳولا ۾. مشڪوڪ سرگرمي کي ڳولڻ جي اميد ۾ انفرادي نشانن ۾ اسپانن تي گھمڻ وارن ماڻهن جو انداز بلڪل به ماپ نٿو ڪري (خاص طور تي جڏهن انهن کي مختلف اسپنن ۾ انڪوڊ ٿيل سڀني ميٽا ڊيٽا جو احساس ڪرڻ گهرجي، جهڙوڪ اسپين ID، RPC طريقي جو نالو، مدت جو مدو 'a، لاگ، ٽيگ، وغيره).
ٽريڪ ڏسڻ لاء متبادل
ٽريس جا نتيجا تمام گهڻا ڪارآمد هوندا آهن جڏهن انهن کي اهڙي طريقي سان تصور ڪري سگهجي ٿو جيڪو غير معمولي بصيرت مهيا ڪري ٿو ته سسٽم جي هڪٻئي سان ڳنڍيل حصن ۾ ڇا ٿي رهيو آهي. جيستائين اهو ٿئي ٿو، ڊيبگنگ عمل گهڻو ڪري رهي ٿو بيڪار ۽ استعمال ڪندڙ جي قابليت تي دارومدار رکي ٿو صحيح رابطي کي محسوس ڪرڻ، سسٽم جي ساڄي حصن کي چيڪ ڪرڻ، يا پزل جي ٽڪرن کي گڏ ڪرڻ - جي مخالفت جي طور تي اوزار, استعمال ڪندڙ جي مدد ڪندي انهن مفروضن کي ترتيب ڏيڻ.
مان هڪ بصري ڊيزائنر يا UX ماهر نه آهيان، پر ايندڙ حصي ۾ آئون ڪجهه خيالن جو حصيداري ڪرڻ چاهيان ٿو ته اهي تصويرون ڪيئن نظر اچن ٿيون.
خاص خدمتن تي ڌيان ڏيڻ
هڪ وقت ۾ جڏهن صنعت خيالن جي چوڌاري مضبوط ٿي رهي آهي ، اهو مناسب لڳي ٿو ته انفرادي ٽيمن کي ترجيح ڏيڻ گهرجي انهي کي يقيني بڻائڻ ته انهن جون خدمتون انهن مقصدن سان ترتيب ڏنل آهن. ان جي پٺيان آهي خدمت تي مبني visualization اهڙي ٽيمن لاء بهترين موزون آهي.
نشان، خاص طور تي بغير نموني جي، هڪ ورهايل نظام جي هر جزو بابت معلومات جو خزانو آهي. اها معلومات هڪ چالاڪ پروسيسر کي فيڊ ڪري سگهجي ٿي جيڪا صارفين کي فراهم ڪندي خدمت تي مبني نتيجن. اهي اڳ ۾ سڃاڻي سگهجن ٿا - جيتوڻيڪ صارف جي نشانن کي ڏسڻ کان اڳ:
- دير سان ورهائڻ جا ڊراگرام صرف انتهائي نمايان درخواستن لاءِ (ٻاهرين درخواستون);
- ڪيسن لاءِ دير جي ورڇ جا ڊراگرام جڏهن سروس SLO جا مقصد حاصل نه ڪيا ويا آهن؛
- سوالن ۾ سڀ کان وڌيڪ "عام"، "دلچسپ" ۽ "عجيب" ٽيگ جيڪي اڪثر ڪري رهيا آهن بار بار آهن;
- ڪيسن لاءِ دير جي ڀڃڪڙي جتي зависимости خدمتون سندن SLO مقصدن حاصل نه ڪندا آھن؛
- مختلف ھيٺئين خدمتن لاءِ دير جي وقفي.
انهن مان ڪجهه سوالن جو جواب نه ڏنو ويو آهي صرف ٺهيل ميٽرڪس طرفان، صارفين کي اسپن جي ڇنڊڇاڻ ڪرڻ تي مجبور ڪري ٿو. نتيجي طور، اسان وٽ هڪ انتهائي صارف دشمن ميڪانيزم آهي.
اهو سوال پيدا ڪري ٿو: مختلف ٽيمن پاران ڪنٽرول ڪيل مختلف خدمتن جي وچ ۾ پيچيده رابطي بابت ڇا؟ آهي نه سراغ ڏسڻ اهڙي صورتحال کي اجاگر ڪرڻ لاء سڀ کان مناسب اوزار نه سمجهيو ويندو آهي؟
موبائيل ڊولپرز، بي رياست خدمتن جا مالڪ، منظم رياستي خدمتن جا مالڪ (جهڙوڪ ڊيٽابيس) ۽ پليٽ فارم مالڪن کي شايد ڪنهن ٻي ۾ دلچسپي هجي پيشڪش تقسيم نظام؛ سراغ ڏسڻ انهن بنيادي طور تي مختلف ضرورتن لاء هڪ تمام عام حل آهي. جيتوڻيڪ هڪ تمام پيچيده microservice فن تعمير ۾، خدمت جي مالڪن کي ٻن يا ٽن کان وڌيڪ اپ اسٽريم ۽ ڊائون اسٽريم سروسز جي گهڻي ڄاڻ جي ضرورت ناهي. لازمي طور تي، اڪثر حالتن ۾، صارفين کي صرف سوالن جا جواب ڏيڻ جي ضرورت آهي خدمتن جي محدود سيٽ.
اهو ڏسڻ جهڙو آهي خدمت جي هڪ ننڍڙي ذيلي سيٽ کي هڪ ميگنفائنگ شيشي ذريعي ان جي ڇنڊڇاڻ لاءِ. هي صارف کي انهن خدمتن ۽ انهن جي فوري انحصار جي وچ ۾ پيچيده رابطي جي حوالي سان وڌيڪ دٻاءُ وارا سوال پڇڻ جي اجازت ڏيندو. اهو ساڳيو آهي backtrace خدمتن جي دنيا ۾، جتي انجنيئر ڄاڻي ٿو ته غلط آهي، ۽ انهي کي پڻ ڪجهه سمجھڻ آهي ته ڀرپاسي جي خدمتن ۾ ڇا ٿي رهيو آهي سمجهڻ لاء ڇو.
جنهن طريقي کي مان پروموٽ ڪري رهيو آهيان اهو مٿين-هيٺ، ٽريڪ وييو تي ٻڌل انداز جي بلڪل ابتڙ آهي، جتي تجزيي پوري سراغ سان شروع ٿئي ٿي ۽ پوءِ آهستي آهستي انفرادي اسپن تائين ڪم ڪري ٿي. ان جي ابتڙ، هيٺيون اپ اپروچ شروع ٿئي ٿو هڪ ننڍڙي علائقي جو تجزيو ڪندي واقعي جي امڪاني سبب جي ويجهو، ۽ پوءِ ضرورت مطابق ڳولا واري جاءِ کي وڌايو (ٻين ٽيمن کي آڻڻ جي صلاحيت سان جيئن خدمتن جي وسيع رينج جو تجزيو ڪرڻ لاءِ). ٻيو طريقو بھتر آھي بھترين ابتدائي مفروضن کي جانچڻ لاءِ. هڪ دفعو ٺوس نتيجا حاصل ڪيا ويندا، اهو ممڪن ٿيندو ته اڳتي وڌو وڌيڪ ٽارگيٽ ۽ تفصيلي تجزيو.
ٽوپولوجي جي تعمير
خدمت جي مخصوص نظريات ناقابل يقين حد تائين ڪارائتو ٿي سگهي ٿي جيڪڏهن صارف ڄاڻي ٿو ڇا آهي هڪ خدمت يا خدمتن جو گروپ دير سان وڌائڻ يا غلطيون پيدا ڪرڻ جو ذميوار آهي. بهرحال، هڪ پيچيده سسٽم ۾، ناڪاري خدمت جي سڃاڻپ ناڪامي جي دوران هڪ غير معمولي ڪم ٿي سگهي ٿو، خاص طور تي جيڪڏهن خدمتن مان ڪو به غلط پيغام نه ٻڌايو ويو آهي.
خدمت جي ٽوپولوجي جي تعمير هڪ وڏي مدد ٿي سگهي ٿي اهو معلوم ڪرڻ ۾ ته ڪهڙي خدمت غلطي جي شرحن ۾ واڌ جو تجربو ڪري رهي آهي يا دير سان وڌي رهي آهي جيڪا خدمت کي خاص طور تي خراب ڪرڻ جو سبب بڻائيندي آهي. جڏهن مان هڪ ٽوپولوجي جي تعمير بابت ڳالهائيندو آهيان، منهنجو مطلب اهو ناهي خدمتن جو نقشو، سسٽم ۾ موجود هر خدمت کي ظاهر ڪندي ۽ ان لاءِ سڃاتل آهي . هي نظارو ڪو به بهتر نه آهي traceview جي بنياد تي هڪ هدايت ٿيل ايڪيلڪ گراف جي بنياد تي. ان جي بدران مان ڏسڻ چاهيان ٿو متحرڪ طور تي ٺاهيل سروس ٽوپولوجي, ڪجهه خاصيتن جي بنياد تي جيئن ته غلطي جي شرح، جوابي وقت، يا ڪنهن به صارف جي وضاحت ڪيل پيٽرولر جيڪا مخصوص مشڪوڪ خدمتن سان صورتحال کي واضح ڪرڻ ۾ مدد ڪري ٿي.
اچو ته هڪ مثال وٺون. اچو ته تصور ڪريون هڪ فرضي خبر سائيٽ. گھر جي صفحي جي خدمت (اڳيون صفحو) ريڊس سان ڊيٽا مٽائي ٿو، سفارش جي خدمت سان، اشتهارن جي خدمت ۽ وڊيو سروس سان. وڊيو سروس S3 کان وڊيوز ۽ ميٽاداٽا DynamoDB کان وٺي ٿي. سفارش واري خدمت DynamoDB کان ميٽا ڊيٽا وصول ڪري ٿي، ريڊيس ۽ MySQL کان ڊيٽا لوڊ ڪري ٿي، ۽ ڪافڪا ڏانهن پيغام لکي ٿي. اشتهارن جي خدمت MySQL کان ڊيٽا وصول ڪري ٿي ۽ ڪافڪا ڏانهن پيغام لکي ٿي.
هيٺ ڏنل اسڪيمياتي نمائندگي آهي هن ٽوپولوجي جي (ڪيترائي تجارتي روٽنگ پروگرام ٽوپولوجي کي ٺاهيندا آهن). اهو ڪارائتو ٿي سگهي ٿو جيڪڏهن توهان کي خدمت جي انحصار کي سمجهڻ جي ضرورت آهي. بهرحال، دوران ڊيبگ، جڏهن هڪ خاص خدمت (چئو، هڪ وڊيو سروس) ڏيکاري ٿو وڌندڙ جوابي وقت، اهڙي ٽوپولوجي تمام مفيد نه آهي.
هڪ فرضي خبرن جي سائيٽ جو خدمت ڊراگرام
هيٺ ڏنل نقشو بهتر ٿيندو. خدمت سان مسئلو آهي (وڊيو) صحيح مرڪز ۾ ڏيکاريل آهي. صارف ان کي فوري طور تي نوٽيس ڪري ٿو. هن تصوير مان، اهو واضح ٿئي ٿو ته وڊيو سروس غير معمولي ڪم ڪري رهي آهي S3 جوابي وقت ۾ واڌ جي ڪري، جيڪو مکيه صفحي جي حصي جي لوڊشيڊنگ جي رفتار کي متاثر ڪري ٿو.
متحرڪ ٽوپولوجي صرف "دلچسپ" خدمتون ڏيکاريندي
متحرڪ طور تي ٺاهيل ٽوپولوجيز جامد سروس نقشن کان وڌيڪ ڪارائتو ٿي سگھن ٿيون، خاص طور تي لچڪدار، خودڪار اسڪيلنگ انفراسٽرڪچر ۾. خدمت جي ٽوپولوجيز جي مقابلي ۽ برعڪس ڪرڻ جي صلاحيت صارف کي وڌيڪ لاڳاپيل سوال پڇڻ جي اجازت ڏئي ٿي. سسٽم جي باري ۾ وڌيڪ صحيح سوالن جا وڌيڪ امڪان آهن ته بهتر سمجھڻ لاءِ ته سسٽم ڪيئن ڪم ڪري ٿو.
تقابلي ڊسپلي
هڪ ٻيو مفيد تصور هڪ تقابلي ڊسپلي هوندو. في الحال نشانيون هڪ طرفي مقابلي لاءِ بلڪل موزون نه آهن، تنهن ڪري مقابلو عام طور تي اسپانس. ۽ هن مضمون جو بنيادي خيال اهو آهي ته اسپانس تمام گهٽ سطح وارا آهن جن کي ڳولڻ جي نتيجن مان تمام قيمتي معلومات ڪڍڻ لاء.
ٻن نشانن جي ڀيٽ ڪرڻ لاءِ بنيادي طور نئين تصورن جي ضرورت نه آهي. حقيقت ۾، هڪ هسٽوگرام وانگر ڪجهه ساڳيو معلومات جي نمائندگي ڪري ٿو جيئن هڪ ٽريڪ وييو ڪافي آهي. حيرت انگيز طور تي، هي سادو طريقو به وڌيڪ ميوو آڻي سگهي ٿو صرف ٻه نشان الڳ الڳ پڙهڻ کان. اڃا به وڌيڪ طاقتور امڪان هوندو تصور ڪرڻ نشانن جو مقابلو ڪل. اهو ڏسڻ لاءِ انتهائي ڪارائتو هوندو ته ڪيئن تازو ڊيليٽ ٿيل ڊيٽابيس جي ترتيب واري تبديلي GC (کچري کي گڏ ڪرڻ) کي فعال ڪرڻ لاءِ ڪيترن ئي ڪلاڪن جي اسڪيل تي هيٺيون وهڪرو سروس جي جوابي وقت کي متاثر ڪري ٿي. جيڪڏهن مان هتي بيان ڪري رهيو آهيان ته بنيادي ڍانچي جي تبديلين جي اثر جي A/B تجزيو وانگر. ڪيترن ئي خدمتن ۾ نتيجن کي استعمال ڪندي، پوء توهان سچ کان تمام پري نه آهيو.
ٿڪل
مان پاڻ کي ٽريڪنگ جي افاديت تي سوال نٿو ڪريان. مان خلوص سان يقين رکان ٿو ته ڊيٽا گڏ ڪرڻ لاءِ ٻيو ڪو به طريقو نه آهي جيترو وسيع، سبب ۽ حوالي سان آهي، جيڪو هڪ سراغ ۾ موجود آهي. تنهن هوندي، مان اهو پڻ سمجهان ٿو ته سڀئي ٽريڪنگ حل هن ڊيٽا کي انتهائي غير موثر طريقي سان استعمال ڪن ٿا. جيستائين ٽريڪنگ ٽولز ٽريس وييو جي نمائندگي تي بيٺا رھندا، اھي پنھنجي قابليت ۾ محدود رھندا جيڪي قيمتي معلومات جو تمام گھڻو استعمال ڪري سگھن ٿيون جيڪي نشانن ۾ موجود ڊيٽا مان ڪڍي سگھجن ٿيون. ان کان علاوه، هڪ مڪمل طور تي غير دوستانه ۽ غير معمولي بصري انٽرفيس کي وڌيڪ ترقي ڪرڻ جو خطرو آهي جيڪو صارف جي ايپليڪيشن ۾ غلطين کي حل ڪرڻ جي صلاحيت کي سختي سان محدود ڪندو.
پيچيده سسٽم کي ڊيبگ ڪرڻ، جيتوڻيڪ جديد اوزار سان، ناقابل يقين حد تائين ڏکيو آهي. اوزارن کي ڊولپر جي مدد ڪرڻ گھرجي ھڪڙي مفروضي کي تيار ڪرڻ ۽ جانچڻ، فعال طور تي مهيا ڪرڻ لاڳاپيل معلومات، ٻاهر نڪرڻ وارن کي سڃاڻڻ ۽ تاخير جي ورڇ ۾ خاصيتن کي نوٽ ڪرڻ. ڊولپرز لاءِ چونڊ جو اوزار بڻجڻ لاءِ ٽريڪنگ ڪرڻ لاءِ جڏهن پيداوار جي ناڪامين کي حل ڪرڻ يا مسئلن کي حل ڪرڻ لاءِ جيڪي گھڻن خدمتن تي پکڙيل آهن، اصل يوزر انٽرفيس ۽ ويزولائيزيشنز جي ضرورت هوندي آهي جيڪي ڊولپرز جي ذهني ماڊل سان وڌيڪ مطابقت رکندڙ هجن جيڪي انهن خدمتن کي ٺاهي ۽ هلائيندا آهن.
اهو هڪ سسٽم ڊزائين ڪرڻ لاءِ اهم ذهني ڪوششون وٺندو جيڪو مختلف نشانين جي نمائندگي ڪندو جنهن جي نتيجن ۾ موجود مختلف نشانين کي اهڙي طريقي سان بهتر ڪيو ويو آهي جيڪو تجزيو ۽ انفرنس جي آسانيءَ لاءِ بهتر ڪيو ويو آهي. توهان کي سوچڻ جي ضرورت آهي ته ڊيبگنگ دوران سسٽم جي ٽوپولوجي کي ڪيئن خلاصو ڪجي انهي طريقي سان جيڪو صارف کي انفرادي نشانن يا اسپانن کي ڏسڻ کان سواءِ انڌا اسپاٽ تي قابو پائڻ ۾ مدد ڪري ٿو.
اسان کي سٺي تجريد ۽ ليئرنگ صلاحيتن جي ضرورت آهي (خاص طور تي UI ۾). اهي جيڪي چڱيءَ طرح سان ٺهندا هوندا هڪ مفروضي تي ٻڌل ڊيبگنگ جي عمل ۾ جتي توهان بار بار سوال پڇي سگهو ٿا ۽ فرضن جي جانچ ڪري سگهو ٿا. اهي خودڪار طريقي سان سڀني مشاهدي جا مسئلا حل نه ڪندا، پر اهي صارفين کي انهن جي وجدان کي تيز ڪرڻ ۽ هوشيار سوالن کي ترتيب ڏيڻ ۾ مدد ڪندا. مان تصور ڪرڻ لاءِ وڌيڪ سوچيل ۽ جديد طريقي جي لاءِ سڏيان ٿو. افق کي وڌائڻ لاءِ هتي هڪ حقيقي امڪان آهي.
پي ايس مترجم کان
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com