نوٹ. ترجمہ: اس مواد کی مصنفہ سنڈی سریدھرن ہیں، imgix کی ایک انجینئر جو API کی ترقی اور خاص طور پر مائیکرو سروس ٹیسٹنگ میں مہارت رکھتی ہے۔ اس مواد میں، وہ تقسیم شدہ ٹریسنگ کے میدان میں موجودہ مسائل کے بارے میں اپنا تفصیلی وژن شیئر کرتی ہے، جہاں، ان کی رائے میں، دبانے والے مسائل کو حل کرنے کے لیے واقعی موثر ٹولز کی کمی ہے۔
[تصویر سے لیا گیا ہے۔ تقسیم شدہ ٹریسنگ کے بارے میں۔]
یہ خیال کیا جاتا ہے کہ لاگو کرنے کے لئے مشکل، اور اس پر واپسی . بہت ساری وجوہات ہیں جن کی وجہ سے ٹریس کرنا مشکل ہوتا ہے، اکثر ہر درخواست کے ساتھ مناسب ہیڈر منتقل کرنے کے لیے سسٹم کے ہر جزو کو ترتیب دینے میں شامل محنت کا حوالہ دیتے ہیں۔ اگرچہ یہ مسئلہ موجود ہے، لیکن یہ کسی بھی طرح سے ناقابل تسخیر نہیں ہے۔ ویسے، یہ اس بات کی وضاحت نہیں کرتا ہے کہ ڈویلپرز کو ٹریس کرنا کیوں پسند نہیں ہے (یہاں تک کہ جب یہ پہلے سے کام کر رہا ہو)۔
تقسیم شدہ ٹریسنگ کے ساتھ بنیادی چیلنج ڈیٹا اکٹھا نہیں کرنا، نتائج کی تقسیم اور پیش کرنے کے لیے فارمیٹس کو معیاری بنانا، یا یہ تعین کرنا کہ کب، کہاں، اور کیسے نمونہ لیا جائے۔ میں تصور کرنے کی کوشش نہیں کر رہا ہوں۔ معمولی یہ "فہم کے مسائل" درحقیقت کافی اہم تکنیکی ہیں اور (اگر ہم واقعی اوپن سورس پر غور کر رہے ہیں) ) سیاسی چیلنجز جن پر قابو پانے کی ضرورت ہے تاکہ ان مسائل کو حل کیا جاسکے۔
تاہم، اگر ہم یہ تصور کریں کہ یہ تمام مسائل حل ہو گئے ہیں، تو اس بات کا بہت زیادہ امکان ہے کہ اس معاملے میں کوئی خاص تبدیلی نہیں آئے گی۔ اختتامی صارف کا تجربہ. ڈیبگنگ کے سب سے عام منظرناموں میں ٹریسنگ اب بھی عملی طور پر استعمال کی نہیں ہو سکتی ہے - یہاں تک کہ اس کے تعینات ہونے کے بعد بھی۔
اس طرح ایک مختلف ٹریس
تقسیم شدہ ٹریسنگ میں کئی مختلف اجزاء شامل ہیں:
- ایپلی کیشنز اور مڈل ویئر کو کنٹرول ٹولز سے لیس کرنا؛
- تقسیم شدہ سیاق و سباق کی منتقلی؛
- نشانات کا مجموعہ؛
- ٹریس اسٹوریج؛
- ان کا اخراج اور تصور
ڈسٹری بیوٹڈ ٹریسنگ کے بارے میں بہت ساری باتیں اسے ایک قسم کے غیر منظم آپریشن کے طور پر پیش کرتی ہیں جس کا واحد مقصد نظام کی مکمل تشخیص میں مدد کرنا ہے۔ یہ بڑی حد تک اس وجہ سے ہے کہ کس طرح تقسیم شدہ ٹریسنگ کے بارے میں نظریات تاریخی طور پر تشکیل پائے ہیں۔ میں جب زپکن کے ذرائع کھولے گئے تو اس کا ذکر کیا گیا۔ یہ [زپکن] ٹویٹر کو تیز تر بناتا ہے۔. ٹریسنگ کے لیے پہلی تجارتی پیشکشوں کو بھی فروغ دیا گیا۔ .
نوٹ. ترجمہ: مزید متن کو سمجھنے میں آسانی پیدا کرنے کے لیے آئیے اس کے مطابق دو بنیادی اصطلاحات کی وضاحت کرتے ہیں۔ :
- پھیلاؤ - تقسیم شدہ ٹریسنگ کا بنیادی عنصر۔ یہ ایک مخصوص ورک فلو کی تفصیل ہے (مثال کے طور پر، ایک ڈیٹا بیس استفسار) جس میں نام، آغاز اور اختتام کے اوقات، ٹیگز، لاگز اور سیاق و سباق شامل ہیں۔
- اسپین میں عام طور پر دوسرے اسپین کے لنک ہوتے ہیں، جس سے متعدد اسپین کو جوڑنے کی اجازت ملتی ہے ٹریس - درخواست کی زندگی کا تصور جب یہ تقسیم شدہ نظام سے گزرتی ہے۔
نشانات میں ناقابل یقین حد تک قیمتی ڈیٹا ہوتا ہے جو پروڈکشن ٹیسٹنگ، ڈیزاسٹر ریکوری ٹیسٹنگ، ایرر انجیکشن ٹیسٹنگ وغیرہ جیسے کاموں میں مدد کر سکتا ہے۔ درحقیقت، کچھ کمپنیاں پہلے ہی اسی طرح کے مقاصد کے لیے ٹریسنگ کا استعمال کرتی ہیں۔ آئیے شروع کرتے ہیں۔ سٹوریج سسٹم میں اسپین کو منتقل کرنے کے علاوہ دیگر استعمالات ہیں:
- مثال کے طور پر، Uber ٹیسٹ ٹریفک اور پروڈکشن ٹریفک کے درمیان فرق کرنے کے لیے نتائج کا سراغ لگانا۔
- فیس بک ریگولر ڈیزاسٹر ریکوری ٹیسٹ کے دوران اہم راستے کے تجزیہ اور ٹریفک سوئچنگ کے لیے ڈیٹا کا سراغ لگانا۔
- سوشل نیٹ ورک بھی Jupyter نوٹ بک جو ڈویلپرز کو ٹریس نتائج پر من مانی سوالات چلانے کی اجازت دیتی ہیں۔
- پیروکار (نسب پر مبنی ناکامی انجکشن) غلطی کے انجیکشن کے ساتھ جانچ کے لئے نشانات تقسیم کیے گئے۔
اوپر دیے گئے اختیارات میں سے کوئی بھی مکمل طور پر منظر نامے پر لاگو نہیں ہوتا ہے۔ ڈیبگنگ، جس کے دوران انجینئر ٹریس کو دیکھ کر مسئلہ حل کرنے کی کوشش کرتا ہے۔
جب آتا ہے۔ ابھی تک ڈیبگنگ اسکرپٹ تک پہنچ جاتا ہے، بنیادی انٹرفیس خاکہ ہی رہتا ہے۔ ٹریس ویو (حالانکہ کچھ اسے بھی کہتے ہیں۔ "Gantt چارٹ" یا "آبشار کا خاکہ")۔ کے تحت ٹریس ویو я تمام اسپین اور اس کے ساتھ میٹا ڈیٹا جو مل کر ٹریس بناتے ہیں۔ ہر اوپن سورس ٹریسنگ سسٹم، نیز ہر کمرشل ٹریسنگ سلوشن، پیش کرتا ہے۔ ٹریس ویو نشانات کو دیکھنے، تفصیل اور فلٹر کرنے کے لیے صارف انٹرفیس۔
میں نے اب تک جتنے بھی ٹریسنگ سسٹمز دیکھے ہیں ان میں مسئلہ یہ ہے کہ اس کے نتیجے میں تصور (ٹریس ویو) تقریبا مکمل طور پر ٹریس نسل کے عمل کی خصوصیات کی عکاسی کرتا ہے. یہاں تک کہ جب متبادل تصورات تجویز کیے جاتے ہیں: ہیٹ میپس، سروس ٹوپولاجیز، لیٹنسی ہسٹوگرام، وہ اب بھی بالآخر نیچے آتے ہیں۔ ٹریس ویو.
ماضی میں I کہ UI/UX ٹریسنگ میں زیادہ تر "بدعتیں" تک محدود دکھائی دیتی ہیں۔ ٹریس میں اضافی میٹا ڈیٹا، ان میں اعلی کارڈنلٹی کے ساتھ معلومات کی سرمایہ کاری (اعلیٰ شخصیت) یا مخصوص اسپین میں ڈرل ڈاؤن کرنے یا سوالات چلانے کی صلاحیت فراہم کرنا انٹر اور انٹرا ٹریس... جس میں ٹریس ویو بنیادی ویژولائزیشن ٹول رہتا ہے۔ جب تک یہ حالت جاری رہے گی، تقسیم شدہ ٹریسنگ (بہترین طور پر) میٹرکس، لاگز اور اسٹیک ٹریس کے بعد، ڈیبگنگ ٹول کے طور پر چوتھا مقام لے گا، اور بدترین طور پر یہ پیسے اور وقت کا ضیاع ثابت ہوگا۔
ٹریس ویو کے ساتھ مسئلہ
مقصد ٹریس ویو - تقسیم شدہ نظام کے تمام اجزاء میں ایک درخواست کی نقل و حرکت کی مکمل تصویر فراہم کریں جس سے اس کا تعلق ہے۔ کچھ مزید جدید ٹریسنگ سسٹمز آپ کو انفرادی اسپین میں ڈرل ڈاون کرنے اور وقت کے ساتھ خرابی دیکھنے کی اجازت دیتے ہیں۔ اندر ایک عمل (جب اسپین کی فعال حدود ہوتی ہیں)۔
مائیکرو سروسز فن تعمیر کی بنیادی بنیاد یہ خیال ہے کہ تنظیمی ڈھانچہ کمپنی کی ضروریات کے ساتھ بڑھتا ہے۔ مائیکرو سروسز کے حامیوں کا استدلال ہے کہ مختلف کاروباری کاموں کو انفرادی خدمات میں تقسیم کرنا چھوٹی، خود مختار ترقیاتی ٹیموں کو اس طرح کی خدمات کے پورے لائف سائیکل کو کنٹرول کرنے کی اجازت دیتا ہے، جس سے انہیں ان خدمات کو آزادانہ طور پر بنانے، جانچنے اور تعینات کرنے کی صلاحیت ملتی ہے۔ تاہم، اس تقسیم کا نقصان اس بارے میں معلومات کا نقصان ہے کہ ہر سروس دوسروں کے ساتھ کیسے تعامل کرتی ہے۔ ایسے حالات میں، تقسیم شدہ ٹریسنگ کے لیے ایک ناگزیر ٹول ہونے کا دعویٰ کرتا ہے۔ ڈیبگنگ خدمات کے درمیان پیچیدہ تعامل۔
اگر آپ واقعی پھر کوئی بھی شخص اسے اپنے سر میں رکھنے کے قابل نہیں ہے۔ مکمل تصویر درحقیقت، اس مفروضے کی بنیاد پر ایک ٹول تیار کرنا کہ یہ ممکن بھی ہے ایک مخالف پیٹرن (ایک غیر موثر اور غیر پیداواری نقطہ نظر) ہے۔ مثالی طور پر، ڈیبگنگ کے لیے ایک ایسے ٹول کی ضرورت ہوتی ہے جو مدد کرتا ہو۔ اپنی تلاش کے علاقے کو تنگ کریں۔، تاکہ انجینئر زیر غور مسئلے کے منظر نامے سے متعلقہ طول و عرض کے ذیلی سیٹ (سروسز/صارفین/میزبان وغیرہ) پر توجہ مرکوز کر سکیں۔ ناکامی کی وجہ کا تعین کرتے وقت، انجینئرز کو یہ سمجھنے کی ضرورت نہیں ہے کہ اس دوران کیا ہوا تھا۔ تمام خدمات ایک ساتھچونکہ اس طرح کی ضرورت مائیکرو سروس فن تعمیر کے تصور سے متصادم ہوگی۔
تاہم، ٹریس ویو ہے یعنی یہ. ہاں، کچھ ٹریسنگ سسٹم کمپریسڈ ٹریس ویوز پیش کرتے ہیں جب ٹریس میں اسپین کی تعداد اتنی زیادہ ہوتی ہے کہ انہیں ایک تصور میں ظاہر نہیں کیا جا سکتا۔ تاہم، اتنی بڑی تعداد میں معلومات موجود ہونے کی وجہ سے، یہاں تک کہ اس طرح کے سٹریپ ڈاون ویژولائزیشن میں، انجینئرز اب بھی مجبور اسے "چھاننا"، دستی طور پر انتخاب کو خدمات کے ایک سیٹ تک محدود کرتے ہوئے جو مسائل کے ذرائع ہیں۔ بدقسمتی سے، اس میدان میں، مشینیں انسانوں کے مقابلے بہت تیز ہیں، غلطیوں کا کم خطرہ ہے، اور ان کے نتائج زیادہ دہرائے جا سکتے ہیں۔
میرے خیال میں ٹریس ویو کے غلط ہونے کی ایک اور وجہ یہ ہے کہ یہ مفروضے پر مبنی ڈیبگنگ کے لیے اچھا نہیں ہے۔ اس کے مرکز میں، ڈیبگنگ ہے۔ تکراری ایک مفروضے سے شروع ہونے والا عمل، جس کے بعد مختلف ویکٹرز، نتائج/عمومی اور مفروضے کی سچائی کا مزید جائزہ لینے کے ساتھ نظام سے حاصل کردہ مختلف مشاہدات اور حقائق کی تصدیق ہوتی ہے۔
موقع تیز اور سستا مفروضوں کی جانچ کرنا اور اس کے مطابق ذہنی ماڈل کو بہتر بنانا ہے۔ سنگ بنیاد ڈیبگنگ کوئی بھی ڈیبگنگ ٹول ہونا چاہیے۔ انٹرایکٹو اور تلاش کی جگہ کو تنگ کریں یا، غلط لیڈ کی صورت میں، صارف کو واپس جانے اور سسٹم کے مختلف حصے پر توجہ مرکوز کرنے کی اجازت دیں۔ کامل ٹول یہ کرے گا۔ فعال طور پرفوری طور پر صارف کی توجہ ممکنہ مسائل والے علاقوں کی طرف مبذول کرانا۔
افسوس، ٹریس ویو انٹرایکٹو انٹرفیس کے ساتھ ٹول نہیں کہا جا سکتا۔ اس کا استعمال کرتے وقت آپ جس بہترین کی امید کر سکتے ہیں وہ یہ ہے کہ تاخیر کا کوئی ذریعہ تلاش کریں اور اس سے وابستہ تمام ممکنہ ٹیگز اور لاگز کو دیکھیں۔ اس سے انجینئر کو شناخت کرنے میں مدد نہیں ملتی پیٹرن ٹریفک میں، جیسے تاخیر کی تقسیم کی تفصیلات، یا مختلف پیمائشوں کے درمیان ارتباط کا پتہ لگانا۔ ان مسائل میں سے کچھ کو حل کرنے میں مدد مل سکتی ہے۔ واقعی، غیر متزلزل اسپین کی نشاندہی کرنے اور ٹیگز کے ذیلی سیٹ کی نشاندہی کرنے کے لیے مشین لرننگ کا استعمال کرتے ہوئے کامیاب تجزیہ جو غیر معمولی رویے سے وابستہ ہو سکتے ہیں۔ تاہم، میں نے ابھی تک اسپین پر لاگو مشین لرننگ یا ڈیٹا مائننگ کے نتائج کے زبردست تصورات دیکھے ہیں جو ٹریس ویو یا ڈی اے جی (ڈائریکٹڈ ایسکلک گراف) سے نمایاں طور پر مختلف ہیں۔
اسپین بہت کم سطح کے ہیں۔
ٹریس ویو کے ساتھ بنیادی مسئلہ یہ ہے۔ پھیلا ہوا تاخیر کے تجزیہ اور بنیادی وجہ کے تجزیہ دونوں کے لیے بہت کم درجے کے قدیم ہیں۔ یہ کسی استثناء کو حل کرنے کی کوشش کرنے کے لیے انفرادی پروسیسر کمانڈز کو پارس کرنے جیسا ہے، یہ جانتے ہوئے کہ بیک ٹریس جیسے اعلیٰ سطح کے ٹولز موجود ہیں جن کے ساتھ کام کرنا زیادہ آسان ہے۔
مزید یہ کہ، میں مندرجہ ذیل باتوں پر زور دینے کی آزادی لوں گا: مثالی طور پر، ہمیں ضرورت نہیں ہے۔ مکمل تصویر درخواست کے لائف سائیکل کے دوران ہوا، جس کی نمائندگی جدید ٹریسنگ ٹولز کے ذریعے کی جاتی ہے۔ اس کے بجائے، اعلیٰ سطحی تجرید کی کچھ شکل درکار ہے جس میں کس چیز کے بارے میں معلومات ہوں۔ غلط ہو گیا (بیک ٹریس کی طرح)، کچھ سیاق و سباق کے ساتھ۔ پورے سراغ کو دیکھنے کے بجائے، میں اسے دیکھنا پسند کرتا ہوں۔ часть، جہاں کچھ دلچسپ یا غیر معمولی ہوتا ہے۔ فی الحال، تلاش دستی طور پر کی جاتی ہے: انجینئر ٹریس حاصل کرتا ہے اور آزادانہ طور پر کسی دلچسپ چیز کی تلاش میں اسپین کا تجزیہ کرتا ہے۔ مشتبہ سرگرمی کا پتہ لگانے کی امید میں انفرادی نشانات میں اسپین کو گھورنے والے لوگوں کا نقطہ نظر بالکل بھی پیمانہ نہیں ہوتا ہے (خاص طور پر جب انہیں مختلف اسپین میں انکوڈ کردہ تمام میٹا ڈیٹا کا احساس کرنا ہوتا ہے، جیسے اسپین ID، RPC طریقہ کا نام، مدت کا دورانیہ۔ 'a، logs، tags، وغیرہ)۔
ٹریس ویو کے متبادل
ٹریس کے نتائج سب سے زیادہ کارآمد ہوتے ہیں جب انہیں اس طرح سے تصور کیا جا سکتا ہے جو نظام کے باہم منسلک حصوں میں کیا ہو رہا ہے اس کے بارے میں غیر معمولی بصیرت فراہم کرتا ہے۔ جب تک ایسا نہیں ہوتا، ڈیبگنگ کا عمل بڑی حد تک باقی رہتا ہے۔ غیر فعال اور صارف کی صحیح ارتباط کو محسوس کرنے، سسٹم کے صحیح حصوں کو چیک کرنے، یا پہیلی کے ٹکڑوں کو ایک ساتھ رکھنے کی صلاحیت پر منحصر ہے - جیسا کہ آلہ، صارف کو ان مفروضوں کی تشکیل میں مدد کرنا۔
میں ایک بصری ڈیزائنر یا UX ماہر نہیں ہوں، لیکن اگلے حصے میں میں اس بارے میں چند خیالات کا اشتراک کرنا چاہتا ہوں کہ یہ تصورات کیسی ہو سکتی ہیں۔
مخصوص خدمات پر توجہ دیں۔
ایک ایسے وقت میں جب صنعت خیالات کے گرد مضبوط ہو رہی ہے۔ یہ مناسب معلوم ہوتا ہے کہ انفرادی ٹیموں کو اس بات کو یقینی بنانا چاہیے کہ ان کی خدمات ان اہداف کے ساتھ ہم آہنگ ہوں۔ اس کی پیروی کرتا ہے۔ خدمت پر مبنی ایسی ٹیموں کے لیے تصور بہترین ہے۔
نشانات، خاص طور پر بغیر نمونے کے، تقسیم شدہ نظام کے ہر جزو کے بارے میں معلومات کا خزانہ ہیں۔ یہ معلومات ایک ہوشیار پروسیسر کو کھلایا جا سکتا ہے جو صارفین کو فراہم کرے گا۔ خدمت پر مبنی نتائج۔ ان کی شناخت پہلے سے کی جا سکتی ہے - اس سے پہلے کہ صارف نشانات کو دیکھے:
- تاخیر کی تقسیم کا خاکہ صرف انتہائی نمایاں درخواستوں کے لیے (بیرونی درخواستیں);
- ایسے معاملات میں تاخیر کی تقسیم کا خاکہ جب سروس SLO کے اہداف حاصل نہیں ہوتے ہیں۔
- سوالات میں سب سے زیادہ "عام"، "دلچسپ" اور "عجیب" ٹیگز جو اکثر دہرائے جاتے ہیں;
- ایسے معاملات کے لیے لیٹینسی بریک ڈاؤن جہاں انحصار خدمات اپنے SLO کے اہداف حاصل نہیں کرتی ہیں۔
- مختلف ڈاون اسٹریم سروسز کے لیے لیٹنسی بریک ڈاؤن۔
ان میں سے کچھ سوالات کا جواب بلٹ ان میٹرکس کے ذریعہ نہیں دیا جاتا ہے، جو صارفین کو اسپین کی جانچ پڑتال کرنے پر مجبور کرتے ہیں۔ نتیجے کے طور پر، ہمارے پاس ایک انتہائی صارف دشمن طریقہ کار ہے۔
اس سے سوال پیدا ہوتا ہے: مختلف ٹیموں کے زیر کنٹرول متنوع خدمات کے درمیان پیچیدہ تعاملات کا کیا ہوگا؟ ہے نا؟ ٹریس ویو ایسی صورت حال کو اجاگر کرنے کا سب سے مناسب ذریعہ نہیں سمجھا جاتا؟
موبائل ڈویلپرز، اسٹیٹ لیس سروسز کے مالکان، منظم اسٹیٹفول سروسز کے مالکان (جیسے ڈیٹا بیس) اور پلیٹ فارم کے مالکان کسی اور چیز میں دلچسپی لے سکتے ہیں۔ پیشکش تقسیم شدہ نظام؛ ٹریس ویو ان بنیادی طور پر مختلف ضروریات کے لیے بہت عام حل ہے۔ یہاں تک کہ ایک بہت ہی پیچیدہ مائیکرو سروس فن تعمیر میں، سروس مالکان کو دو یا تین سے زیادہ اپ اسٹریم اور ڈاون اسٹریم سروسز کے بارے میں گہرے علم کی ضرورت نہیں ہے۔ بنیادی طور پر، زیادہ تر منظرناموں میں، صارفین کو صرف سوالات کے جوابات دینے کی ضرورت ہوتی ہے۔ خدمات کا محدود سیٹ.
یہ اس کی جانچ پڑتال کی خاطر میگنفائنگ گلاس کے ذریعے خدمات کے ایک چھوٹے ذیلی سیٹ کو دیکھنے کے مترادف ہے۔ یہ صارف کو ان خدمات اور ان کے فوری انحصار کے درمیان پیچیدہ تعاملات کے بارے میں مزید اہم سوالات پوچھنے کی اجازت دے گا۔ یہ خدمات کی دنیا میں بیک ٹریس کی طرح ہے، جہاں انجینئر جانتا ہے۔ کہ غلط ہے، اور اسے سمجھنے کے لیے ارد گرد کی سروسز میں کیا ہو رہا ہے اس کی کچھ سمجھ بھی ہے۔ کیوں.
میں جس نقطہ نظر کو فروغ دے رہا ہوں وہ اوپر سے نیچے، ٹریس ویو پر مبنی نقطہ نظر کے بالکل برعکس ہے، جہاں تجزیہ پورے ٹریس سے شروع ہوتا ہے اور پھر آہستہ آہستہ انفرادی اسپین تک کام کرتا ہے۔ اس کے برعکس، نیچے سے اوپر کا نقطہ نظر واقعے کی ممکنہ وجہ کے قریب ایک چھوٹے سے علاقے کا تجزیہ کرنے سے شروع ہوتا ہے، اور پھر ضرورت کے مطابق تلاش کی جگہ کو بڑھاتا ہے (خدمات کی وسیع رینج کا تجزیہ کرنے کے لیے دوسری ٹیموں کو لانے کی صلاحیت کے ساتھ)۔ ابتدائی مفروضوں کی فوری جانچ کے لیے دوسرا نقطہ نظر بہتر ہے۔ ٹھوس نتائج حاصل ہونے کے بعد، مزید ہدفی اور تفصیلی تجزیہ کی طرف بڑھنا ممکن ہو گا۔
ٹوپولوجی کی تعمیر
اگر صارف کو معلوم ہو تو سروس کے مخصوص خیالات ناقابل یقین حد تک مفید ہو سکتے ہیں۔ کون سا ہے سروس یا سروسز کا گروپ تاخیر میں اضافے یا خرابیوں کی وجہ سے ذمہ دار ہے۔ تاہم، ایک پیچیدہ نظام میں، ناکارہ سروس کی شناخت ناکامی کے دوران ایک غیر معمولی کام ہو سکتا ہے، خاص طور پر اگر خدمات سے کوئی غلطی کے پیغامات کی اطلاع نہ ہو۔
سروس ٹوپولوجی کی تعمیر یہ معلوم کرنے میں ایک بڑی مدد ہو سکتی ہے کہ کون سی سروس خرابی کی شرح میں اضافے یا تاخیر میں اضافے کا سامنا کر رہی ہے جو سروس کو نمایاں طور پر تنزلی کا باعث بن رہی ہے۔ جب میں ٹوپولوجی بنانے کے بارے میں بات کرتا ہوں تو میرا مطلب یہ نہیں ہے۔ خدمات کا نقشہ، سسٹم میں دستیاب ہر سروس کو ظاہر کرنا اور اس کے لیے جانا جاتا ہے۔ . یہ نقطہ نظر ایک ڈائریکٹڈ ایسکلک گراف پر مبنی ٹریس ویو سے بہتر نہیں ہے۔ اس کے بجائے میں دیکھنا چاہوں گا۔ متحرک طور پر تیار کردہ سروس ٹوپولوجی, کچھ خاص صفات پر مبنی جیسے خرابی کی شرح، رسپانس ٹائم، یا صارف کی طرف سے متعین کردہ پیرامیٹر جو مخصوص مشکوک سروسز کے ساتھ صورتحال کو واضح کرنے میں مدد کرتا ہے۔
آئیے ایک مثال لیتے ہیں۔ آئیے ایک فرضی نیوز سائٹ کا تصور کریں۔ ہوم پیج سروس (فرنٹ پیج) Redis کے ساتھ ڈیٹا کا تبادلہ، سفارشی سروس کے ساتھ، اشتہاری سروس اور ویڈیو سروس کے ساتھ۔ ویڈیو سروس S3 سے ویڈیوز اور DynamoDB سے میٹا ڈیٹا لیتی ہے۔ سفارشی سروس DynamoDB سے میٹا ڈیٹا وصول کرتی ہے، Redis اور MySQL سے ڈیٹا لوڈ کرتی ہے، اور کافکا کو پیغامات لکھتی ہے۔ ایڈورٹائزنگ سروس MySQL سے ڈیٹا حاصل کرتی ہے اور کافکا کو پیغامات لکھتی ہے۔
ذیل میں اس ٹوپولوجی کی منصوبہ بندی کی نمائندگی کی گئی ہے (کئی تجارتی روٹنگ پروگرام ٹوپولوجی بناتے ہیں)۔ اگر آپ کو سروس کے انحصار کو سمجھنے کی ضرورت ہو تو یہ مفید ہو سکتا ہے۔ تاہم، دوران ڈیبگنگ، جب کوئی خاص سروس (کہیں کہ ایک ویڈیو سروس) جوابی وقت میں اضافہ دکھاتی ہے، تو ایسی ٹوپولوجی زیادہ مفید نہیں ہوتی۔
فرضی خبروں کی سائٹ کا سروس ڈایاگرام
نیچے دیا گیا خاکہ زیادہ موزوں ہوگا۔ سروس کے ساتھ ایک مسئلہ ہے (ویڈیو) دائیں مرکز میں دکھایا گیا ہے۔ صارف اسے فوری طور پر محسوس کرتا ہے۔ اس تصور سے، یہ واضح ہو جاتا ہے کہ S3 رسپانس ٹائم میں اضافے کی وجہ سے ویڈیو سروس غیر معمولی طور پر کام کر رہی ہے، جو مرکزی صفحہ کے کچھ حصے کی لوڈنگ کی رفتار کو متاثر کرتی ہے۔
متحرک ٹوپولوجی صرف "دلچسپ" خدمات کی نمائش کرتی ہے۔
متحرک طور پر تیار کردہ ٹوپولاجی جامد سروس کے نقشوں سے زیادہ کارآمد ہو سکتی ہے، خاص طور پر لچکدار، آٹو سکیلنگ انفراسٹرکچر میں۔ سروس ٹوپولاجی کا موازنہ اور اس کے برعکس کرنے کی صلاحیت صارف کو مزید متعلقہ سوالات پوچھنے کی اجازت دیتی ہے۔ سسٹم کے بارے میں زیادہ درست سوالات اس بات کی بہتر تفہیم کا باعث بنتے ہیں کہ نظام کیسے کام کرتا ہے۔
تقابلی ڈسپلے
ایک اور مفید تصور تقابلی ڈسپلے ہوگا۔ فی الحال ٹریسز بہ پہلو موازنہ کے لیے زیادہ موزوں نہیں ہیں، اس لیے موازنہ عام طور پر پھیلا ہوا. اور اس مضمون کا بنیادی خیال بالکل واضح طور پر یہ ہے کہ ٹریس کے نتائج سے انتہائی قیمتی معلومات نکالنے کے لیے اسپین بہت کم سطح کے ہیں۔
دو نشانات کا موازنہ کرنے کے لیے بنیادی طور پر نئے تصورات کی ضرورت نہیں ہے۔ درحقیقت، ہسٹوگرام جیسی کوئی چیز جو ٹریس ویو جیسی معلومات کی نمائندگی کرتی ہے کافی ہے۔ حیرت کی بات یہ ہے کہ یہ آسان طریقہ بھی صرف دو نشانات کا الگ الگ مطالعہ کرنے سے کہیں زیادہ پھل لا سکتا ہے۔ اس سے بھی زیادہ طاقتور امکان ہوگا۔ تصور کرنا نشانات کا موازنہ کل ملا کر. یہ دیکھنا انتہائی مفید ہوگا کہ GC (کوڑا جمع کرنے) کو فعال کرنے کے لیے حال ہی میں تعینات ڈیٹا بیس کنفیگریشن کی تبدیلی کئی گھنٹوں کے پیمانے پر ڈاؤن اسٹریم سروس کے رسپانس ٹائم کو کیسے متاثر کرتی ہے۔ اگر میں یہاں جو کچھ بیان کر رہا ہوں وہ بنیادی ڈھانچے کی تبدیلیوں کے اثرات کے A/B تجزیہ کی طرح لگتا ہے۔ بہت ساری خدمات میں ٹریس کے نتائج کا استعمال کرتے ہوئے، پھر آپ سچ سے زیادہ دور نہیں ہیں.
حاصل يہ ہوا
میں خود ٹریسنگ کی افادیت پر سوال نہیں اٹھاتا ہوں۔ میں خلوص دل سے یقین رکھتا ہوں کہ ڈیٹا اکٹھا کرنے کا کوئی دوسرا طریقہ نہیں ہے جیسا کہ ٹریس میں موجود ہے جیسا کہ بھرپور، وجہ اور سیاق و سباق۔ تاہم، میں یہ بھی مانتا ہوں کہ تمام ٹریسنگ حل اس ڈیٹا کو انتہائی غیر موثر طریقے سے استعمال کرتے ہیں۔ جب تک ٹریسنگ ٹولز ٹریس ویو کی نمائندگی پر پھنسے رہیں گے، وہ ان قیمتی معلومات سے زیادہ سے زیادہ فائدہ اٹھانے کی صلاحیت میں محدود رہیں گے جو ٹریس میں موجود ڈیٹا سے نکالی جا سکتی ہیں۔ اس کے علاوہ، مکمل طور پر غیر دوستانہ اور غیر فطری بصری انٹرفیس کو مزید تیار کرنے کا خطرہ ہے جو ایپلی کیشن میں غلطیوں کا ازالہ کرنے کی صارف کی صلاحیت کو سختی سے محدود کر دے گا۔
پیچیدہ سسٹمز کو ڈیبگ کرنا، حتیٰ کہ جدید ترین ٹولز کے ساتھ بھی، ناقابل یقین حد تک مشکل ہے۔ ٹولز کو ڈویلپر کو ایک مفروضہ تیار کرنے اور جانچنے میں مدد کرنی چاہیے، فعال طور پر فراہم کرتا ہے متعلقہ معلومات، آؤٹ لیرز کی شناخت اور تاخیر کی تقسیم میں خصوصیات کو نوٹ کرنا۔ پیداواری ناکامیوں کا ازالہ کرتے وقت یا متعدد سروسز پر محیط مسائل کو حل کرنے کے لیے ڈویلپرز کے لیے انتخاب کا ٹول بننے کے لیے ٹریسنگ کے لیے، اصل یوزر انٹرفیس اور ویژولائزیشنز کی ضرورت ہوتی ہے جو ان سروسز کو تخلیق کرنے اور چلانے والے ڈویلپرز کے ذہنی ماڈل سے زیادہ مطابقت رکھتے ہوں۔
ایک ایسے نظام کو ڈیزائن کرنے کے لیے خاصی ذہنی محنت درکار ہوگی جو ٹریس کے نتائج میں دستیاب مختلف سگنلز کو اس طریقے سے پیش کرے جو تجزیہ اور اندازہ میں آسانی کے لیے موزوں ہو۔ آپ کو یہ سوچنے کی ضرورت ہے کہ ڈیبگنگ کے دوران سسٹم ٹوپولوجی کو اس طرح سے کیسے خلاصہ کیا جائے جس سے صارف کو انفرادی نشانات یا اسپین کو دیکھے بغیر اندھے دھبوں پر قابو پانے میں مدد ملے۔
ہمیں اچھی تجریدی اور تہہ بندی کی صلاحیتوں کی ضرورت ہے (خاص طور پر UI میں)۔ وہ جو مفروضے پر مبنی ڈیبگنگ کے عمل میں اچھی طرح سے فٹ ہوں گے جہاں آپ تکراری طور پر سوالات پوچھ سکتے ہیں اور مفروضوں کی جانچ کر سکتے ہیں۔ وہ خود بخود تمام مشاہداتی مسائل کو حل نہیں کریں گے، لیکن یہ صارفین کو ان کے وجدان کو تیز کرنے اور بہتر سوالات تیار کرنے میں مدد کریں گے۔ میں تصور کے لیے زیادہ سوچ سمجھ کر اور اختراعی نقطہ نظر کا مطالبہ کرتا ہوں۔ یہاں افق کو وسعت دینے کا ایک حقیقی امکان ہے۔
مترجم سے PS
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com