لاگ ها از کجا می آیند؟ غواصی Veeam Log

ما به غوطه ور شدن خود در دنیای شگفت انگیز حدس زدن ادامه می دهیم ... عیب یابی توسط سیاهه ها. که در مقاله قبلی ما در مورد معنای اصطلاحات اساسی توافق کردیم و به ساختار کلی Veeam به عنوان یک برنامه واحد با یک چشم نگاه کردیم. وظیفه این یکی این است که بفهمد فایل های گزارش چگونه تشکیل می شوند، چه نوع اطلاعاتی در آنها نمایش داده می شود و چرا به نظر می رسد.

به نظر شما این "لوگ ها" چیست؟ به عقیده اکثر افراد، لاگ های هر برنامه ای باید نقش نوعی موجودیت قادر مطلق را به خود اختصاص دهند که بیشتر اوقات در جایی در حیاط خلوت سبز می شود، اما در لحظه مناسب از هیچ جا در زره درخشان ظاهر می شود و همه را نجات می دهد. به این معنا که آنها باید شامل همه چیز باشند، از کوچکترین خطا در هر جزء گرفته تا تراکنش های پایگاه داده منفرد. و به طوری که پس از خطا بلافاصله نوشته شد که چگونه آن را برطرف کنیم. و همه اینها باید در چند مگابایت جای بگیرد، نه بیشتر. این فقط یک متن است! فایل های متنی نمی توانند ده ها گیگابایت ببرند، جایی شنیدم!

بنابراین سیاهههای مربوط

در دنیای واقعی، لاگ ها فقط یک آرشیو از اطلاعات تشخیصی هستند. و اینکه چه چیزی در آنجا ذخیره شود، از کجا اطلاعات را برای ذخیره سازی بدست آوریم و جزئیات آن چقدر باید باشد، تصمیم خود توسعه دهندگان است. کسی مسیر مینیمالیسم را با نگه داشتن سوابق سطح ON / OFF دنبال می کند و کسی با پشتکار هر چیزی را که می تواند به دست آورد، جمع آوری می کند. اگرچه یک گزینه میانی با قابلیت انتخاب به اصطلاح Logging Level نیز وجود دارد، اما وقتی خودتان مشخص می کنید که چقدر اطلاعات دقیق را می خواهید ذخیره کنید و چقدر فضای اضافی دیسک دارید =) اتفاقاً VBR دارای شش سطح از این قبیل است. و، باور کنید، شما نمی خواهید ببینید که با جزیی ترین گزارش ها با فضای خالی روی دیسک شما چه اتفاقی می افتد.

خوب. ما تقریباً فهمیدیم که می خواهیم چه چیزی را ذخیره کنیم، اما یک سؤال قانونی مطرح می شود: این اطلاعات را از کجا باید دریافت کرد؟ البته، ما بخشی از رویدادها را برای ثبت خود توسط فرآیندهای داخلی خود تشکیل می دهیم. اما در صورت تعامل با محیط خارجی چه باید کرد؟ برای اینکه به جهنم عصا و دوچرخه سر نخورد، Veeam تمایل به اختراع اختراعاتی ندارد که قبلاً اختراع شده اند. هر زمان که یک API آماده، تابع داخلی، کتابخانه و غیره وجود داشته باشد، قبل از شروع به حصار کردن ابزارهای خود، گزینه های آماده را ترجیح می دهیم. اگرچه دومی نیز کافی است. بنابراین، هنگام تجزیه و تحلیل گزارش‌ها، درک این نکته مهم است که سهم بزرگ خطاها به پیام‌های APIهای شخص ثالث، تماس‌های سیستمی و سایر کتابخانه‌ها می‌رسد. در این مورد، نقش VBR به ارسال این خطاها به فایل‌های گزارش همانطور که هست خلاصه می‌شود. و وظیفه اصلی کاربر این است که یاد بگیرد بفهمد کدام خط از چه کسی است و این "چه کسی" مسئول چیست. بنابراین اگر یک کد خطا از گزارش VBR شما را به یک صفحه MSDN برد، خوب و صحیح است.

همانطور که قبلاً توافق کردیم: Veeam یک برنامه به اصطلاح مبتنی بر SQL است. این بدان معنی است که تمام تنظیمات، تمام اطلاعات و به طور کلی هر چیزی که فقط برای عملکرد عادی لازم است - همه چیز در پایگاه داده خود ذخیره می شود. از این رو حقیقت ساده: آنچه در گزارش ها نیست به احتمال زیاد در پایگاه داده است. اما این یک گلوله نقره ای نیز نیست: برخی چیزها در گزارش های محلی اجزای Veeam و یا در پایگاه داده آن نیستند. بنابراین، شما باید یاد بگیرید که چگونه لاگ های میزبان، لاگ های ماشین محلی و گزارش های هر چیزی که در فرآیند پشتیبان گیری و بازیابی دخیل است را مطالعه کنید. و همچنین اتفاق می افتد که اطلاعات لازم در هیچ کجا در دسترس نیست. راهش همین است. 

چند نمونه از این گونه API ها

هدف این فهرست این نیست که به طور استثنایی کامل باشد، بنابراین نیازی به جستجوی حقیقت نهایی در آن نیست. هدف آن فقط نشان دادن متداول ترین API ها و فناوری های شخص ثالث مورد استفاده در محصولات ما است.

بیایید شروع کنیم آموزش VMware. 

اولین نفر در لیست خواهد بود vSphere API. برای احراز هویت، خواندن سلسله‌مراتب، ایجاد و حذف عکس‌های فوری، درخواست اطلاعات در مورد ماشین‌ها و بسیاری (خیلی زیاد) موارد دیگر استفاده می‌شود. عملکرد راه حل بسیار گسترده است، بنابراین می توانم مرجع VMware vSphere API را برای نسخه توصیه کنم. 5.5 и 6.0. برای نسخه های فعلی بیشتر، همه چیز فقط گوگل شده است.

VIX API. جادوی سیاه هایپروایزر که برای آن جداگانه وجود دارد لیست خطا. VMware API برای کار با فایل ها در هاست بدون اتصال به آنها از طریق شبکه. یک نوع آخرین راه حل زمانی که باید فایلی را در دستگاهی قرار دهید که کانال ارتباطی بهتری برای آن وجود ندارد. اگر فایل بزرگ باشد و هاست بارگذاری شود درد و رنج است. اما در اینجا قانون کار می کند که حتی 56,6 کیلوبایت بر ثانیه بهتر از 0 کیلوبایت بر ثانیه است. در Hyper-V، این مورد PowerShell Direct نامیده می شود. اما این فقط قبل بود

vSpehere Web Services API با شروع از vSphere 6.0 (تقریباً از آنجایی که این API برای اولین بار در نسخه 5.5 معرفی شد) برای کار با ماشین های مهمان استفاده می شود و تقریباً در همه جا جایگزین VIX شده است. در واقع این یک API دیگر برای مدیریت vSphere است. به علاقه مندان توصیه می کنم مطالعه کنند عالی است کتابچه راهنمای. 

vddk (کیت توسعه دیسک مجازی). کتابخانه ای که تا حدودی در این مورد بحث شد مقاله. برای خواندن دیسک های مجازی استفاده می شود. روزی روزگاری بخشی از VIX بود، اما با گذشت زمان به یک محصول جداگانه منتقل شد. اما به عنوان وارث، از همان کدهای خطای VIX استفاده می کند. اما بنا به دلایلی هیچ توضیحی در مورد این خطاها در خود SDK وجود ندارد. بنابراین، به طور تجربی مشخص شد که خطاهای VDDK با سایر کدها فقط ترجمه ای از کد باینری به اعشاری است. این شامل دو بخش است - نیمه اول اطلاعات غیر مستند در مورد زمینه، و بخش دوم خطاهای سنتی VIX / VDDK است. مثلاً اگر ببینیم:

VDDK error: 21036749815809.Unknown error

سپس با جسارت این را به هگز تبدیل می کنیم و 132200000001 می گیریم. ما به سادگی شروع غیر اطلاعاتی 132200 را کنار می گذاریم و بقیه کد خطای ما خواهد بود (VDDK 1: خطای ناشناخته). در مورد متداول ترین خطاهای VDDK، اخیراً یک خطای جداگانه وجود دارد مقاله.

حالا بیایید نگاه کنیم پنجره ها.

در اینجا، هر آنچه برای ما ضروری و مهم است را می توان در استاندارد یافت رویداد بیننده. اما یک نکته وجود دارد: طبق یک سنت طولانی، ویندوز متن کامل خطا را ثبت نمی کند، بلکه فقط شماره آن را ثبت می کند. به عنوان مثال، خطای 5 "دسترسی رد شد" و 1722 "سرور RPC در دسترس نیست" و 10060 "زمان اتصال تمام شد". البته اگر معروف ترین آنها را به خاطر بسپارید عالی است، اما آنهایی که تا به حال دیده نشده بودند چطور؟ 

و برای اینکه زندگی اصلاً شبیه عسل به نظر نرسد، خطاها نیز به شکل هگزادسیمال با پیشوند 0x8007 ذخیره می شوند. به عنوان مثال، 0x8007000e در واقع 14 است، از حافظه خارج شده است. چرا و برای چه کسی این کار انجام شد یک راز است که در تاریکی پوشانده شده است. با این حال، لیست کاملی از خطاها را می توان به صورت رایگان و بدون پیامک از سایت دانلود کرد 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 ویژه برای این کار وجود دارد. اما همانطور که قبلاً ذکر شد، هر چیزی که فقط در پاسخ به ما می رسد وارد گزارش های ما می شود. و در اینجا، برای رمزگشایی آن، باید دائماً این جریان آگاهی را زیر نظر داشت، قطعاتی با خطاهای ویندوز را از آن بیرون کشید، آنها را رمزگشایی کرد و دوباره چسباند. بیایید صادق باشیم، هیجان انگیزترین فعالیت نیست.

Windows File Management API به هر طریق ممکن هنگام کار با فایل ها استفاده می شود. ایجاد فایل، حذف، باز کردن برای نوشتن، کار با ویژگی ها، و غیره و غیره.

در بالا ذکر شد PowerShell Direct به عنوان آنالوگ VIX API در دنیای Hyper-V. متأسفانه، چندان انعطاف پذیر نیست: محدودیت های زیادی در عملکرد وجود دارد، با هر نسخه از میزبان کار نمی کند و با همه مهمانان کار نمی کند.

RPC (تماس رویه از راه دور) فکر نمی‌کنم فردی وجود داشته باشد که با ویندوز کار کرده باشد که خطاهای مربوط به RPC را ندیده باشد. با وجود تصور غلط رایج، این یک پروتکل واحد نیست، بلکه هر پروتکل سرویس گیرنده-سرور است که تعدادی از پارامترها را برآورده می کند. با این حال، اگر یک خطای RPC در گزارش‌های ما وجود داشته باشد، 90٪ مواقع خطای مایکروسافت RPC است که بخشی از DCOM (Distributed Component Object Model) است. شما می توانید حجم زیادی از مستندات در مورد این موضوع را در شبکه بیابید، اما سهم شیر آن کاملاً قدیمی است. اما اگر تمایل شدیدی برای مطالعه موضوع وجود دارد، می توانم مقالاتی را توصیه کنم RPC چیست؟, چگونه RPC کار می کند و لیست طولانی خطاهای RPC.

دلایل اصلی خطاهای RPC در گزارش‌های ما، تلاش‌های ناموفق برای برقراری ارتباط بین اجزای VBR (مثلاً سرور > پروکسی) و اغلب به دلیل مشکلات ارتباطی است.

بالای صفحه در میان همه تاپ ها خطای The RPC server is unavailable (1722) است. به عبارت ساده، مشتری نمی تواند با سرور ارتباط برقرار کند. چگونه و چرا - هیچ پاسخ واحدی وجود ندارد، اما معمولاً این مشکل با احراز هویت یا دسترسی شبکه به پورت 135 است. مورد دوم برای زیرساخت‌هایی با تخصیص پورت پویا معمول است. در مورد این موضوع، حتی وجود دارد HF جدا. و مایکروسافت دارد راهنمای حجیم برای یافتن علت شکست

دومین خطای رایج: هیچ نقطه پایانی دیگری از نگاشت نقطه پایانی (1753) در دسترس نیست. سرویس گیرنده یا سرور RPC نتوانست به خود یک پورت اختصاص دهد. معمولاً زمانی اتفاق می‌افتد که سرور (در مورد ما، ماشین مهمان) برای تخصیص پویا پورت‌ها از محدوده باریکی که به پایان رسیده است پیکربندی شده باشد. و اگر از سمت مشتری (در مورد ما سرور VBR) وارد شوید، این بدان معنی است که VeeamVssAgent ما یا شروع نشده یا به عنوان یک رابط RPC ثبت نشده است. در مورد این موضوع نیز وجود دارد HF جدا.

خوب، برای تکمیل 3 خطای RPC برتر، بیایید به یاد داشته باشیم که فراخوانی تابع RPC ناموفق بود (1726). اگر اتصال برقرار شده باشد ظاهر می شود، اما درخواست های RPC پردازش نمی شوند. به عنوان مثال، ما اطلاعاتی در مورد وضعیت VSS درخواست می کنیم (ناگهان در حال حاضر یک مین سایه در آنجا ساخته می شود و ما سعی می کنیم صعود کنیم) و در پاسخ به ما سکوت کنید و نادیده بگیرید.

Windows Tape Backup API برای کار با کتابخانه ها یا درایوهای نوار مورد نیاز است. همانطور که در ابتدا اشاره کردم: ما هیچ لذتی از نوشتن درایورهای خود و سپس رنج کشیدن با پشتیبانی هر دستگاه نداریم. بنابراین، vim هیچ درایور مخصوص به خود را ندارد. همه از طریق یک API استاندارد که پشتیبانی از آن توسط خود فروشندگان سخت افزار پیاده سازی می شود. خیلی منطقی تر، درسته؟

SMB / CIFS از روی عادت، همه آنها را در کنار هم می نویسند، اگرچه همه به خاطر ندارند که CIFS (سیستم فایل اینترنتی مشترک) فقط یک نسخه خصوصی از SMB (Block Message Block) است. پس تعمیم این مفاهیم اشکالی ندارد. Samba در حال حاضر یک پیاده سازی LinuxUnix است، و ویژگی های خاص خود را دارد، اما من از آن پرسه می زنم. آنچه در اینجا مهم است: هنگامی که Veeam می‌خواهد چیزی در مسیر UNC (سرور دایرکتوری) بنویسد، سرور از سلسله مراتب درایورهای سیستم فایل، از جمله mup و mrxsmb برای نوشتن روی توپ استفاده می‌کند. بر این اساس، این درایورها نیز خطا ایجاد خواهند کرد.

نمی توان بدون Winsock API. اگر لازم باشد کاری از طریق شبکه انجام شود، VBR از طریق Windows Socket API که معمولاً به عنوان Winsock شناخته می شود، کار می کند. بنابراین اگر یک دسته از IP:Port را در گزارش مشاهده کنیم، این همان است. اسناد رسمی دارای لیست خوبی از موارد ممکن است اشتباهات.

در بالا ذکر شد WMI (Windows Management Instrumentation) نوعی API توانا برای مدیریت همه چیز و همه افراد در دنیای ویندوز است. به عنوان مثال، هنگام کار با Hyper-V، تقریباً تمام درخواست ها به هاست از طریق آن انجام می شود. در یک کلام، چیز کاملاً غیر قابل تعویض و در قابلیت های خود بسیار قدرتمند است. ابزار داخلی WBEMtest.exe در تلاش برای کمک به یافتن مکان و آنچه خراب است کمک زیادی می کند.

و آخرین در لیست، اما به هیچ وجه کم اهمیت ترین - VSS (Volume Shadow Storage). موضوع به همان اندازه پایان ناپذیر و مرموز است که اسناد زیادی در مورد آن نوشته شده است. Shadow Copy به سادگی به عنوان نوع خاصی از عکس فوری درک می شود که در اصل همینطور است. به لطف او، می‌توانید پشتیبان‌گیری سازگار با برنامه در VMware و تقریباً همه چیز در Hyper-V ایجاد کنید. من قصد دارم یک مقاله جداگانه با کمی فشار در VSS تهیه کنم، اما در حال حاضر می توانید سعی کنید آن را بخوانید این توصیف. فقط مراقب باشید، زیرا. تلاش برای درک سریع VSS می تواند منجر به آسیب مغزی شود.

در این مورد، شاید بتوانیم توقف کنیم. من وظیفه توضیح ابتدایی ترین چیزها را تکمیل شده می دانم، بنابراین در فصل بعدی قبلاً به گزارش ها نگاه خواهیم کرد. اما اگر سوالی دارید در نظرات بپرسید.

منبع: www.habr.com