نوشتہ جات کہاں سے آتے ہیں؟ ویم لاگ ڈائیونگ

ہم اندازہ لگانے کی دلچسپ دنیا میں اپنا ڈوبنا جاری رکھتے ہیں... نوشتہ جات کے ذریعے مسئلہ حل کرنا۔ میں پچھلا مضمون ہم نے بنیادی اصطلاحات کے معنی پر اتفاق کیا اور Veeam کے مجموعی ڈھانچے کو ایک آنکھ سے ایک ہی درخواست کے طور پر دیکھا۔ اس کا کام یہ معلوم کرنا ہے کہ لاگ فائلیں کیسے بنتی ہیں، ان میں کس قسم کی معلومات ظاہر ہوتی ہیں اور وہ جس طرح سے نظر آتی ہیں وہ کیوں نظر آتی ہیں۔

آپ کے خیال میں یہ "لاگز" کیا ہیں؟ زیادہ تر کے مطابق، کسی بھی ایپلیکیشن کے لاگز کو ایک قسم کی قادر مطلق ہستی کا کردار تفویض کیا جانا چاہئے جو زیادہ تر وقت گھر کے پچھواڑے میں کہیں نہ کہیں سبزیاں اگتی ہے، لیکن صحیح وقت پر چمکتی ہوئی بکتر میں کہیں سے باہر نظر آتی ہے اور سب کو بچا لیتی ہے۔ یعنی، ان میں ہر ایک جزو کی معمولی غلطیوں سے لے کر انفرادی ڈیٹا بیس کے لین دین تک ہر چیز پر مشتمل ہونا چاہیے۔ اور یہ کہ غلطی کے بعد فوراً لکھا گیا کہ اسے کیسے ٹھیک کیا جائے۔ اور یہ سب کچھ میگا بائٹس میں فٹ ہونا چاہیے، مزید نہیں۔ یہ صرف متن ہے! ٹیکسٹ فائلیں دسیوں گیگا بائٹس نہیں لے سکتی، میں نے اسے کہیں سنا ہے!

تو نوشتہ جات

حقیقی دنیا میں، نوشتہ جات تشخیصی معلومات کا محض ایک ذخیرہ ہیں۔ اور وہاں کیا ذخیرہ کرنا ہے، سٹوریج کے لیے معلومات کہاں سے حاصل کرنی ہے اور یہ کتنی تفصیلی ہونی چاہیے، یہ فیصلہ خود ڈویلپرز پر منحصر ہے۔ کوئی آن/آف لیول کا ریکارڈ رکھ کر minimalism کی راہ پر گامزن ہے، اور کوئی پوری تندہی سے ہر وہ چیز تیار کرتا ہے جس تک وہ پہنچ سکتا ہے۔ اگرچہ نام نہاد لاگنگ لیول کو منتخب کرنے کی صلاحیت کے ساتھ ایک انٹرمیڈیٹ آپشن بھی موجود ہے، جب آپ خود اس بات کی نشاندہی کرتے ہیں کہ آپ کتنی تفصیلی معلومات کو ذخیرہ کرنا چاہتے ہیں اور آپ کے پاس کتنی اضافی ڈسک اسپیس ہے =) ویسے، وی بی آر میں ایسی چھ سطحیں ہیں۔ اور، مجھ پر یقین کریں، آپ یہ نہیں دیکھنا چاہتے کہ آپ کی ڈسک پر خالی جگہ کے ساتھ سب سے زیادہ تفصیلی لاگنگ کے ساتھ کیا ہوتا ہے۔

ٹھیک. ہم تقریباً سمجھ گئے کہ ہم کیا بچانا چاہتے ہیں، لیکن ایک جائز سوال پیدا ہوتا ہے کہ یہ معلومات کہاں سے حاصل کی جائیں؟ بلاشبہ، ہم اپنے اندرونی عمل سے خود کو لاگ ان کرنے کے لیے واقعات کا حصہ بناتے ہیں۔ لیکن جب بیرونی ماحول سے تعامل ہو تو کیا کیا جائے؟ بیساکھیوں اور سائیکلوں کے جہنم میں نہ پھسلنے کے لیے، Veeam ایسی ایجادات کو ایجاد نہیں کرتا جو پہلے ہی ایجاد ہو چکی ہیں۔ جب بھی کوئی ریڈی میڈ API، بلٹ ان فنکشن، لائبریری وغیرہ ہو، تو ہم اپنے کنٹراپشن کو باڑ لگانے سے پہلے ریڈی میڈ آپشنز کو ترجیح دیں گے۔ اگرچہ مؤخر الذکر بھی کافی ہے۔ لہذا، لاگز کا تجزیہ کرتے وقت، یہ سمجھنا ضروری ہے کہ غلطیوں کا بڑا حصہ فریق ثالث APIs، سسٹم کالز، اور دیگر لائبریریوں کے پیغامات پر آتا ہے۔ اس صورت میں، VBR کا کردار ان غلطیوں کو لاگ فائلوں کی طرح آگے بھیجنے پر آتا ہے۔ اور صارف کا بنیادی کام یہ سمجھنا سیکھنا ہے کہ کون سی لائن کس کی طرف سے ہے، اور یہ "کون" کیا ذمہ دار ہے۔ لہذا اگر VBR لاگ سے غلطی کا کوڈ آپ کو MSDN صفحہ پر لے جاتا ہے، تو یہ ٹھیک اور درست ہے۔

جیسا کہ ہم نے پہلے اتفاق کیا تھا: Veeam ایک نام نہاد SQL پر مبنی ایپلی کیشن ہے۔ اس کا مطلب یہ ہے کہ تمام ترتیبات، تمام معلومات اور عام طور پر ہر وہ چیز جو صرف عام کام کے لیے ضروری ہے - ہر چیز اس کے ڈیٹا بیس میں محفوظ ہے۔ لہذا سادہ سچائی: جو لاگز میں نہیں ہے وہ سب سے زیادہ امکان ڈیٹا بیس میں ہے۔ لیکن یہ چاندی کی گولی بھی نہیں ہے: کچھ چیزیں Veeam اجزاء کے مقامی لاگ میں نہیں ہیں، اور نہ ہی اس کے ڈیٹا بیس میں۔ لہذا، آپ کو یہ سیکھنے کی ضرورت ہے کہ میزبان لاگز، لوکل مشین کے لاگز، اور بیک اپ اور بحالی کے عمل میں شامل ہر چیز کے لاگز کا مطالعہ کیسے کریں۔ اور یہ بھی ہوتا ہے کہ ضروری معلومات کہیں بھی دستیاب نہیں ہوتیں۔ یہی طریقہ ہے۔ 

ایسے APIs کی کچھ مثالیں۔

اس فہرست کا مقصد غیر معمولی طور پر مکمل ہونا نہیں ہے، اس لیے اس میں حتمی سچائی تلاش کرنے کی ضرورت نہیں ہے۔ اس کا مقصد صرف سب سے عام تیسرے فریق APIs اور ہماری مصنوعات میں استعمال ہونے والی ٹیکنالوجیز کو دکھانا ہے۔

آئیے شروع کرتے ہیں۔ VMware. 

فہرست میں پہلے نمبر پر ہوں گے۔ vSphere API. تصدیق کرنے، درجہ بندی کو پڑھنے، سنیپ شاٹس بنانے اور حذف کرنے، مشینوں کے بارے میں معلومات کی درخواست کرنے اور بہت کچھ (بہت زیادہ) کے لیے استعمال کیا جاتا ہے۔ حل کی فعالیت بہت وسیع ہے، لہذا میں ورژن کے لیے VMware vSphere API حوالہ کی سفارش کر سکتا ہوں۔ 5.5 и 6.0. مزید موجودہ ورژنز کے لیے، سب کچھ صرف گوگل کیا گیا ہے۔

VIX API. ہائپرائزر کا کالا جادو، جس کے لیے الگ ہے۔ غلطی کی فہرست. نیٹ ورک پر ان سے جڑے بغیر میزبان پر فائلوں کے ساتھ کام کرنے کے لیے VMware API۔ ایک آخری ریزورٹ آپشن جب آپ کو کسی مشین میں فائل ڈالنے کی ضرورت ہو جس سے بہتر مواصلاتی چینل نہیں ہے۔ اگر فائل بڑی ہو اور میزبان لوڈ ہو تو یہ تکلیف اور تکلیف ہے۔ لیکن یہاں یہ اصول کام کرتا ہے کہ 56,6 Kb/s بھی 0 Kb/s سے بہتر ہے۔ Hyper-V میں، اس چیز کو PowerShell Direct کہا جاتا ہے۔ لیکن یہ صرف پہلے تھا۔

vSpehere ویب سروسز API vSphere 6.0 سے شروع ہو کر (تقریباً، چونکہ یہ API پہلی بار ورژن 5.5 پر متعارف کرایا گیا تھا) یہ مہمان مشینوں کے ساتھ کام کرنے کے لیے استعمال ہوتا ہے اور اس نے تقریباً ہر جگہ VIX کی جگہ لے لی ہے۔ درحقیقت، یہ vSphere کے انتظام کے لیے ایک اور API ہے۔ ان لوگوں کے لئے جو دلچسپی رکھتے ہیں، میں مطالعہ کرنے کی سفارش کرتا ہوں آن لائن دستی 

وی ڈی ڈی کے (ورچوئل ڈسک ڈویلپمنٹ کٹ)۔ لائبریری جس میں جزوی طور پر بات کی گئی۔ آرٹیکل. ورچوئل ڈسک کو پڑھنے کے لیے استعمال کیا جاتا ہے۔ ایک زمانے میں یہ VIX کا حصہ تھا لیکن وقت گزرنے کے ساتھ ساتھ اسے ایک الگ پروڈکٹ میں منتقل کر دیا گیا۔ لیکن ایک وارث کے طور پر، یہ وہی ایرر کوڈز استعمال کرتا ہے جیسے VIX۔ لیکن کسی وجہ سے، خود SDK میں ان خرابیوں کی کوئی تفصیل نہیں ہے۔ لہذا، یہ تجرباتی طور پر پتہ چلا کہ دوسرے کوڈز کے ساتھ VDDK کی غلطیاں صرف بائنری سے ڈیسیمل کوڈ تک کا ترجمہ ہے۔ یہ دو حصوں پر مشتمل ہے - پہلا حصہ سیاق و سباق کے بارے میں غیر دستاویزی معلومات ہے، اور دوسرا حصہ روایتی VIX/VDDK کی غلطیاں ہیں۔ مثال کے طور پر، اگر ہم دیکھتے ہیں:

VDDK error: 21036749815809.Unknown error

پھر ہم دلیری سے اسے ہیکس میں تبدیل کرتے ہیں اور 132200000001 حاصل کرتے ہیں۔ ہم صرف 132200 کی غیرمعلوماتی شروعات کو رد کر دیتے ہیں، اور باقی ہمارا ایرر کوڈ ہوگا (VDDK 1: نامعلوم غلطی)۔ اکثر VDDK کی غلطیوں کے بارے میں، حال ہی میں ایک الگ تھا۔ مضمون.

اب آئیے دیکھتے ہیں۔ ونڈوز.

یہاں، ہر وہ چیز جو ہمارے لیے سب سے زیادہ ضروری اور اہم ہے معیار میں مل سکتی ہے۔ وقوعہ کا شاہد. لیکن ایک کیچ ہے: ایک طویل روایت کے مطابق، ونڈوز غلطی کے مکمل متن کو لاگ نہیں کرتا، لیکن صرف اس کا نمبر۔ مثال کے طور پر، غلطی 5 "رسائی سے انکار" ہے، اور 1722 ہے "آر پی سی سرور دستیاب نہیں ہے"، اور 10060 ہے "کنکشن کا وقت ختم ہوگیا"۔ بلاشبہ، یہ بہت اچھا ہے اگر آپ کو سب سے مشہور یاد ہیں، لیکن اب تک ان دیکھے جانے والوں کا کیا ہوگا؟ 

اور اس لیے کہ زندگی بالکل بھی شہد کی طرح نہیں لگتی، غلطیاں بھی ہیکساڈیسیمل شکل میں محفوظ کی جاتی ہیں، سابقہ ​​0x8007 کے ساتھ۔ مثال کے طور پر، 0x8007000e دراصل 14 ہے، میموری سے باہر۔ ایسا کیوں اور کس کے لیے کیا گیا یہ ایک راز ہے کہ اندھیرے میں ڈوبا ہوا ہے۔ تاہم، غلطیوں کی مکمل فہرست مفت میں اور بغیر SMS کے ڈاؤن لوڈ کی جا سکتی ہے۔ devcenter.

ویسے، بعض اوقات صرف 0x8007 نہیں بلکہ دوسرے سابقے بھی ہوتے ہیں۔ ایسی افسوسناک صورتحال میں، HRESULT ("رزلٹ ہینڈل") کو سمجھنے کے لیے، آپ کو مزید گہرائی میں جانے کی ضرورت ہے۔ دستاویزات ڈویلپرز کے لئے. عام زندگی میں، میں آپ کو ایسا کرنے کا مشورہ نہیں دیتا، لیکن اگر آپ اچانک دیوار سے ٹکراتے ہیں یا صرف متجسس ہیں، تو اب آپ جانتے ہیں کہ کیا کرنا ہے۔

لیکن مائیکروسافٹ کے ساتھیوں نے ہم پر تھوڑا سا رحم کیا اور دنیا کو ایک افادیت دکھائی ERR. یہ کنسول خوشی کا ایک چھوٹا سا ٹکڑا ہے جو گوگل کا استعمال کیے بغیر انسان میں ایرر کوڈز کا ترجمہ کر سکتا ہے۔ یہ اس طرح کام کرتا ہے۔

C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"

ایک جائز سوال پیدا ہوتا ہے: ہم فوری طور پر لاگز پر ڈکرپشن کیوں نہیں لکھتے، لیکن ان پراسرار کوڈز کو چھوڑ دیتے ہیں؟ جواب تھرڈ پارٹی ایپلی کیشنز میں ہے۔ جب آپ اپنے آپ کو کچھ WinAPI کال کھینچتے ہیں، تو اس کے ردعمل کو سمجھنا مشکل نہیں ہوتا، کیونکہ اس کے لیے ایک خصوصی WinAPI کال بھی ہے۔ لیکن جیسا کہ پہلے ہی ذکر کیا جا چکا ہے، ہر وہ چیز جو ہمارے پاس صرف جوابات میں آتی ہے ہمارے نوشتہ جات میں آتی ہے۔ اور یہاں، اسے ڈکرپٹ کرنے کے لیے، کسی کو شعور کے اس دھارے کی مسلسل نگرانی کرنی ہوگی، اس سے ونڈوز کی غلطیوں والے ٹکڑوں کو نکالنا ہوگا، ان کو ڈکرپٹ کرنا ہوگا اور انہیں واپس چسپاں کرنا ہوگا۔ آئیے ایماندار بنیں، سب سے زیادہ دلچسپ سرگرمی نہیں۔

ونڈوز فائل مینجمنٹ API فائلوں کے ساتھ کام کرتے وقت ہر ممکن طریقے سے استعمال کیا جاتا ہے۔ فائلیں بنانا، ڈیلیٹ کرنا، لکھنے کے لیے کھولنا، صفات کے ساتھ کام کرنا، وغیرہ وغیرہ۔

اوپر ذکر کیا پاور شیل ڈائریکٹ Hyper-V دنیا میں VIX API کے اینالاگ کے طور پر۔ بدقسمتی سے، اتنا لچکدار نہیں: فعالیت پر بہت سی پابندیاں، یہ میزبان کے ہر ورژن کے ساتھ کام نہیں کرتی اور نہ ہی تمام مہمانوں کے ساتھ۔

آر پی سی (ریموٹ پروسیجر کال) مجھے نہیں لگتا کہ ایک بھی ایسا شخص ہے جس نے ونڈوز کے ساتھ کام کیا ہو جس نے RPC سے متعلق غلطیاں نہ دیکھی ہوں۔ مقبول غلط فہمی کے باوجود، یہ کوئی ایک پروٹوکول نہیں ہے، بلکہ کوئی بھی کلائنٹ سرور پروٹوکول ہے جو متعدد پیرامیٹرز کو پورا کرتا ہے۔ تاہم، اگر ہمارے لاگز میں کوئی RPC کی خرابی ہے، تو 90% وقت یہ Microsoft RPC کی غلطی ہوگی، جو DCOM (تقسیم شدہ اجزاء آبجیکٹ ماڈل) کا حصہ ہے۔ آپ کو نیٹ پر اس موضوع پر دستاویزات کی ایک بڑی رقم مل سکتی ہے، لیکن اس کا بڑا حصہ بہت پرانا ہے۔ لیکن اگر موضوع کا مطالعہ کرنے کی شدید خواہش ہے، تو میں مضامین کی سفارش کرسکتا ہوں۔ RPC کیا ہے؟, کس طرح آر پی سی ورکس اور لمبی فہرست RPC کی غلطیاں.

ہمارے لاگز میں RPC کی خرابیوں کی بنیادی وجوہات VBR اجزاء (مثال کے طور پر سرور> پراکسی) کے درمیان رابطے کی ناکام کوششیں ہیں اور اکثر مواصلاتی مسائل کی وجہ سے۔

تمام ٹاپس میں سب سے اوپر کی خرابی ہے RPC سرور غیر دستیاب ہے (1722)۔ آسان الفاظ میں، کلائنٹ سرور کے ساتھ کنکشن قائم نہیں کر سکا۔ کیسے اور کیوں - اس کا کوئی واحد جواب نہیں ہے، لیکن عام طور پر یہ تصدیق کے ساتھ یا پورٹ 135 تک نیٹ ورک تک رسائی کا مسئلہ ہوتا ہے۔ مؤخر الذکر متحرک پورٹ اسائنمنٹ والے انفراسٹرکچر کے لیے عام ہے۔ اس موضوع پر، بھی ہے علیحدہ HF. اور مائیکروسافٹ کے پاس ہے۔ بڑی گائیڈ ناکامی کی وجہ تلاش کرنے کے لیے۔

دوسری مقبول ترین خرابی: اینڈ پوائنٹ میپر (1753) سے مزید کوئی اینڈ پوائنٹ دستیاب نہیں ہیں۔ RPC کلائنٹ یا سرور خود کو ایک پورٹ تفویض کرنے میں ناکام رہا۔ عام طور پر اس وقت ہوتا ہے جب سرور (ہمارے معاملے میں، مہمان مشین) کو متحرک طور پر ایک تنگ رینج سے بندرگاہیں مختص کرنے کے لیے ترتیب دیا گیا ہے جو ختم ہو چکی ہے۔ اور اگر آپ کلائنٹ کی طرف سے لاگ ان کرتے ہیں (ہمارے معاملے میں، VBR سرور)، اس کا مطلب ہے کہ ہمارا VeeamVssAgent یا تو شروع نہیں ہوا یا RPC انٹرفیس کے طور پر رجسٹرڈ نہیں ہوا۔ اس موضوع پر بھی ہے۔ علیحدہ HF.

ٹھیک ہے، ٹاپ 3 RPC کی خرابیوں کو مکمل کرنے کے لیے، آئیے یاد رکھیں RPC فنکشن کال فیل ہو گئی (1726)۔ ظاہر ہوتا ہے اگر کنکشن قائم ہو گیا ہے، لیکن RPC کی درخواستوں پر کارروائی نہیں کی جاتی ہے۔ مثال کے طور پر، ہم VSS کی حیثیت کے بارے میں معلومات کی درخواست کرتے ہیں (اچانک ابھی وہاں ایک شیڈو مائن بنایا جا رہا ہے، اور ہم چڑھنے کی کوشش کر رہے ہیں)، اور ہمارے جواب میں، خاموش ہو جاتے ہیں اور نظر انداز کر دیتے ہیں۔

ونڈوز ٹیپ بیک اپ API ٹیپ لائبریریوں یا ڈرائیوز کے ساتھ کام کرنے کی ضرورت ہے۔ جیسا کہ میں نے شروع میں ذکر کیا ہے: ہمیں اپنے ڈرائیوروں کو لکھنے اور پھر ہر ڈیوائس کے سہارے تکلیف اٹھانے میں کوئی خوشی نہیں ہے۔ لہذا، ویم کا اپنا کوئی ڈرائیور نہیں ہے۔ ایک معیاری API کے ذریعے، جس کی حمایت خود ہارڈ ویئر فروشوں کے ذریعہ لاگو ہوتی ہے۔ اتنا زیادہ منطقی، ٹھیک ہے؟

SMB / CIFS عادت سے ہٹ کر، ہر کوئی انہیں ساتھ ساتھ لکھتا ہے، حالانکہ سب کو یاد نہیں ہوتا کہ CIFS (Common Internet File System) SMB (Server Message Block) کا محض ایک نجی ورژن ہے۔ لہذا ان تصورات کو عام کرنے میں کوئی حرج نہیں ہے۔ سامبا پہلے سے ہی لینکس یونکس کا نفاذ ہے، اور اس کی اپنی خصوصیات ہیں، لیکن میں پیچھے ہٹتا ہوں۔ یہاں کیا اہم ہے: جب Veeam UNC پاتھ (serverdirectory) پر کچھ لکھنے کو کہتا ہے، تو سرور گیند پر لکھنے کے لیے فائل سسٹم ڈرائیورز، بشمول mup اور mrxsmb کے درجہ بندی کا استعمال کرتا ہے۔ اس کے مطابق، یہ ڈرائیور بھی غلطیاں پیدا کریں گے۔

بغیر نہیں کر سکتے Winsock API. اگر نیٹ ورک پر کچھ کرنے کی ضرورت ہے تو، وی بی آر ونڈوز ساکٹ API کے ذریعے کام کرتا ہے، جسے ونساک کے نام سے جانا جاتا ہے۔ لہذا اگر ہم لاگ میں آئی پی:پورٹ کا ایک گروپ دیکھتے ہیں، تو یہ ہے۔ سرکاری دستاویزات میں ممکنہ کی ایک اچھی فہرست ہے۔ غلطیاں.

اوپر ذکر کیا WMI (Windows Management Instrumentation) ونڈوز کی دنیا میں ہر چیز اور ہر ایک کو منظم کرنے کے لیے ایک قسم کا غالب API ہے۔ مثال کے طور پر، Hyper-V کے ساتھ کام کرتے وقت، میزبان کو تقریباً تمام درخواستیں اس سے گزرتی ہیں۔ ایک لفظ میں، چیز بالکل اٹل ہے اور اپنی صلاحیتوں میں بہت طاقتور ہے۔ یہ جاننے میں مدد کرنے کی کوشش میں کہ کہاں اور کیا ٹوٹا ہے، بلٹ ان WBEMtest.exe ٹول بہت مدد کرتا ہے۔

اور فہرست میں سب سے آخر میں، لیکن کسی بھی لحاظ سے کم اہمیت کے لحاظ سے - VSS (حجم شیڈو اسٹوریج)۔ یہ موضوع اتنا ہی ناقابل فہم اور پراسرار ہے جتنا اس پر دستاویزات لکھی جاچکی ہیں۔ شیڈو کاپی کو ایک خاص قسم کے سنیپ شاٹ کے طور پر سمجھا جاتا ہے، جو حقیقت میں یہ ہے۔ اس کا شکریہ، آپ VMware میں ایپلیکیشن کے مطابق بیک اپ بنا سکتے ہیں، اور Hyper-V میں تقریباً ہر چیز۔ میرے پاس VSS پر کچھ نچوڑ کے ساتھ ایک الگ مضمون بنانے کا ارادہ ہے، لیکن ابھی آپ پڑھنے کی کوشش کر سکتے ہیں یہ تفصیل. بس ہوشیار رہو، کیونکہ. ایک فلیش میں VSS کو سمجھنے کی کوشش دماغی چوٹ کا باعث بن سکتی ہے۔

اس پر، شاید، ہم روک سکتے ہیں. میں سب سے بنیادی چیزوں کی وضاحت کرنے کے کام کو مکمل کرنے پر غور کرتا ہوں، لہذا اگلے باب میں ہم پہلے ہی نوشتہ جات کو دیکھیں گے۔ لیکن اگر آپ کے کوئی سوالات ہیں تو بلا جھجھک ان سے تبصرے میں پوچھیں۔

ماخذ: www.habr.com