تور آشنایی با پلتفرم خودکار قسمت بیستم

متن صدای ویدیو :

دوستان تو این قسمت میخوام در مورد Log صحبت کنم. ما توی پلتفرم دو نوع Log داریم یکی Log رویدادها و یکی Log خطاها که شما می تونید اونها رو از قسمت توسعه گزارشات سیستمی و تاریخچه خطاها و تاریخچه رویدادها و تاریخچه رویدادها بر اساس سرویس ببینید. تاریخچه خطاها که همون Log خطاها هست و تاریخچه رویدادها هم Log رویدادها هست. من اول میرم تو قسمت تاریخچه خطاها و شما اینجا میتونید ببینید که ما Log خطاها رو با جست و جویی که با تاریخ و ساعت و کاربر و نوع منبع و پیام می کنیم میتونیم انجام بدیم و جزئیات خطا رو هم میتونیم ببینیم که حالا دقیقا توی Stack ما چی بوده، میزبان کوکی ها، اطلاعات Form، اطلاعات QueryString، متغیرهای Server و کاربر موبایله کاربر در حالت Debug هست یا خطای داخلی اگر وجود داشته باشه و سایر موارد. 

تو قسمت تاریخچه رویدادها هم همونطور که قبلا گفتیم پلتفرم، Service base هست و شما می تونید Log رو برای یک سرویس فعال بکنید یا نه. من اگر برگردم به قسمت مدیریت سرویس ها و یک سرویس رو انتخاب کنم شما میبینید که ما اینجا یک قسمتی داریم به اسم ثبت وقایع سرویس که اگر این روشن باشه عملیات Log برای اون سرویس عملیات Log رویدادهای اون سرویس انجام میشه. تو رویدادها هم ما پارمترهای مختلفی داریم که به شما نشون میدم و یکی از پارامترهای خیلی جالبش زمان اجرا هست که به میلی ثانیه نشون میده که من اگه اونو مرتب کنم شما میینید که سریع ترین آیتم هایی که اجرا شدن حالا صفر میلی ثانیه و سه میلی ثانیه بوده و بیشترین طول زمان اجرا هم مال یه URL بوده که حول و هوش 4 ثانیه طول کشیده لودش. این میتونه خیلی به شما کمک کنه که در اصل اونجاهایی که وب سایتتون کند هست رو شناسایی کنید و ببینید که در اصل چه گیری داره و اون گیر رو بتونید برطرف کنید.

حالا غیر از این باز جزئیات داره که هر Logی که انجام شده اطلاعات اون درخواست، پارمترها و کوکی هاشو، آدرس یا آدرس مراجعشو، کابر موبایل هست IP رو، اجرا موفق بوده یا نه رو، کاربر در حالت Debug هست و جزئیات اون Logی که برای شما ثبت شده رو بتونید ببینید. تو قسمت پارامترها هم که هر پارامتری که به اون سرویس پاس داده شده و نوع درخواست سرویس Get بوده یا Post بوده رو هم شما میتونید ببینید و همچنین Title اون سرویسی که وجود داشته. این هم از قسمت تاریخچه رویداد ها بود.

یه قسمت هم هست تاریخچه رویدادها بر اساس سرویس. شما یه زمانی هست که به برنامه نویستون نمیخوایین دسترسی بدین کل رویدادها رو ببینه میخوایین برنامه نویس دسترسی داشته باشه به اون سرویس هایی که داره کار میکنه و فقط Log اون سرویس ها رو ببینه از اینجا میتونه اون سرویسش رو انتخاب کنه و اگر اون سرویس Logی داشته باشه فقط Log اون سرویس رو ببینه.

حالا اگه ویدئو قبلی هم یادتون باشه غیر از این که ما تو مدیریت سرویس ها میتونیم ثبت وقایع سرویس رو فعال کنیم برای Log رویدادها یه قسمت دیگه ای که من براتون توضیح دادم گفتم این کنترل پنل کد شما هست ما اگر تو قسمت توسعه مدیریت کدها، کدهای تحت سیستم عامل، کدهای تحت NET. و مدیریت اسمبلی ها بریم توی فریم ورک خودکار ، KS.Dynamic.UI و فضای نام  StartApp (من تغییر ابعادو میزنم و Log رو سرچ کنم) قبلا هم اینو توضیح دادم که شما میتونید روی Controllerاتون که اون سرویس ها هستن با استفاده از Attribute ها Log رو فعال بکنید یا نه یعنی حالا سوای اون دکمه ای که تو این قسمت داریم Log فعال بشه یا نه این خودش یک Over Head ی داره که میره دیتابیسرو چک میکنه که ببینه برای این سرویس Logش فعال شده یا نه. شما اصلا از این قسمت میتونید کلا قطعش کنید اون Over Head رو هم حتی نره برای چک کردن Log سرویس که ببینه سرویس Logش فعال هست یا نه، یا هم میتونید این Log رو برای Controller خاصی یا یک Base Controller، از طریق Attribute هایی که Assign می کنید به اون Controllerتون که اینجا مثلا BaseAuthorize ODataController هست بتونید عملیات Log رو کنترل کنید که Log انجام بشه یا نشه.

خوب دوستان ما همونجوری که قبلا توضیح دادم دو نوع Log داریم در پلتفرم: Log Exception یا خطاها، Log Event یا رویدادها. Log Exception ما بر اساس Library، Elmah  هست که در اصل Elmah  معروفترین Logger، ASP.NET هست که جلوتر بیشتر راجع بهش توضیح میدیم. منتها تنها تفاوتی که ما تو پیاده سازی Elmah  داریم ما از یک دیتابیس خاص استفاده می کنیم نه از SqlServer. این دیتابیس خاص رو برای Log Event ها هم استفاده می کنیم. تو قسمت Log Event ها ما با دو تا چالش روبرو بودیم:

چالش اول محدودیت در حجم به علت گران بودن دیتابیسی مثل SQL. ما میخواییم حجم بالایی از اطلاعات رو Log کنیم و این قابلیت رو بعدا به مشتری بدیم که از این اطلاعاتی Log شده آنالیز کنه و Data mining کنه و بتونه از مشتری های خودش حالا کسب و کار خودش اطلاعات خوبی رو دربیاره که حالا اینو جلوتر توضیح میدم و دومین مورد کاهش سرعت اجرای بیزینس مشتری بوده اساسا یه کدهای مثل Log وامنیت رو در اصطلاح بهش میگن Aspect یا کدهای جانبی و برنامه نویس ها همیشه باید مراقب باشن که اجرای این کدهای جانبی روی بیزینس اصلی تاثیر منفی و کاهش سرعت اجرای اونا رو نداشته باشه.

ما با این دو تا چالش روبرو بودیم و برای این چالش ها دو تا راه حل داشتیم. برای چالش اولمون که محدودیت حجم و ارزشمند بودن دیتابیس SQL که بخواد برای Log استفاده بشه به جای بیزینس اصلی ما اومدیم از یه دیتابیس NoSQL به نام LiteDb به جای SQL برای Log مون استفاده کردیم. این LiteDb برای Log خطاها هم از همین دیتابیس استفاده می کنیم.

و برای چالش دوم که مانع تاثیر منفی یا کاهش سرعت اجرای بیزینس مشتری بر اثر Log بشیم ما اومدیم از مکانیسم Log دو مرحله ای استفاده کردیم. مکانیسم Log دو مرحله ای چجوریه اینه که اولا یک رویدادی اتفاق میوفته مدیر Log اون رویداد رو تبدیل به یک Object Log می کنه و تو مرحله اول که ممکنه تاثیر داشته باشه رو سرعت اجرای کد کاربر اون روی توی مموری ذخیره می کنه که بسیار سریع هست و کوچکترین تاثیری روی اجرای کد کاربر نخواهد داشت چون به سرعت توی مموری ذخیره میشه و بعدا توسط Job که روی مدیریت Log و در پشت صحنه روی Server در حال اجراست طی یک زمان های مشخصی که توی Webconfig تون میتونید مشخص کنید مثلا هر 10 ثانیه یا هر 15 ثانیه میاد مموری رو میخونه و اگر Logی وجود داشته باشه اون Log رو میبره توی دیتابیس NoSQL مون که LiteDb هست ذخیره می کنه.

حالا من این مورد رو هم روی کد به شما نشون میدم که در اصل اون Job پشت صحنه ای که داره اجرا میشه از امکانات جدید خود NET. هست که من بهتون نشون میدم این مکانیزم دو مرحله ای برای Log خطاها هم استفاده میشه یعنی هم دیتابیس تو جفت Log ها یکی هم مکانیزم مون هم تو جفت Log ها یکی هست هم Log خطا هم Log رویدادها، به این طریق ما جلوی کاهش سرعت رو هم گرفتیم و با استفاده از اون دیتابیس LiteDb محدودیت حجم خودمون رو هم برداشتیم من حالا تو Source code یه مقدار بیشتر توضیح میدم.

دوستان من قبل از اینکه Source رو بگم سایت خود Elmah رو به شما نشون بدم که یکی از معروفترین Logger هایASP.NET هست که شما میتونید تو سایتش راجع بهش مطالعه کنید و مورد دوم هم دیتابیس LiteDb هست که سایتش LiteDb.org هست یک دیتابیس، Open Source شبیه  MongoDB که Mobile ready هم هست و امکانات خیلی خوبی داره که شما میتونید روش linq هم بزنید سرعت خیلی خوبی داره Indexing داره و امکانات دیگه ای که شما میتونید از اون استفاده کنید.

برگردیم به Source همونطور که من گفتم مدیریت Log مون یک Job هستش که پشت صحنه روی Server مون اجرا میشه و تو یک زمان مشخصی به صورت Interval هی میاد Memory رو میخونه که اگر Log ی وجود داشته باشه چه خطا چه exception اون رو ببره تو دیتابیس ما ذخیره کنه اولا اون Interval توی Webconfig  شماست شما میتونید تو قسمت توسعه - مدیریت توسعه –مدیریت وبکانفیگ  تنظیمات ،  LogBackgroundJobIntervalInmillisecond، الان میبیند که تو هر 10 ثانیه به صورت پیش فرض میره مموری رو چک می کنه که آیا Log خطا یا Log exception وجود داره برای ذخیره در دیتابیس یا نه.

این عمل رو هم به وسیله یک امکان جدیدی در NET. به نام QueueBackgroundWorkItem که Job شما رو توی پشت صحنه queue می کنه و با اون زمانی که دادین مثلا هر 10 ثانیه 10 ثانیه اجراش می کنه خوبی این امکان این هست که خودش مراقب Shutdown شدن یا Restart شدن اپلیکیشن شما هست و Job شما رو تو این زمان ها به سلامت می تونه انجام بده ، وقتی تموم شد عملیات Shutdown یا Restart رو انجام بده و حالا امکان Cancel شدنش رو هم داریم که من جلوتر این رو برا شما توضیح میدم.

اما غیر از عملیات Log ما عملیات exception handling  هم داریم توی KS.Core که در اصل فریم ورک اصلی سمت سرور ما هست ما تو فولدر exception یه سری exception، customize تعریف کردیم که بتونیم exception handling رو به کمک اونا انجام بدیم که حالا پرکاربردترینش KhodkarInvalidException هست که میاد یک Massage رو با یک method ی که در language manager هست تبدیل می کنه به too ToAsErrorMessage وقتی که massage خطای شما تبدیل به  ToAsErrorMessage میشه اولا تو سمت Client به صورت Json قابلیت نمایش داره به کاربر به شکل درست، دوما توسط language manager شماها خطا رو میتونید به اون زبان کاربر از دیتابیس بخونید لیست خطاها هم توی اطلاعات پایه ما هست.

توی مدیریت محتوا – مدیریت اطلاعات پایه – قسمت خطاها، تمام خطاهای ما اینجا وجود داره که پارامتر هم میتونید بهش پاس بدین و ترجمش هم برای سایر زبان ها اینجا وجود داره و شما میتونید ازش استفاده کنید به کمک اون language manager که زبان Defaults که کاربر انتخاب کرده رو تشخیص میده و اون خطا رو هم تبدیل می کنه به خطای Defaultsپلتفرم ، خطای Defaults پلتفرم با کلمه کلیدی asError شروع میشه بنابراین ما یه قسمتی داریم به اسم exception filter attribute ، در اصل یه دونه attribute مخصوص WebApiها هست که میاد عملیات exception handling رو انجام میده ما خیلی ساده گفتیم اگه asError توی خطا بود بیا اون پیغام رو به کاربر نشون بده در غیر این صورت معلوم میشه که این یک خطایی هست که توسط ما raise  نشده و یک خطای unhandled  هست یه پیغام پیش فرضی برای کاربر نشون میدیم و خطاهاروهم Log می کنیم این یه مکانیزم ساده ای هست برای exception handling و البته ساده و موثر. 

اما نکته آخر و خیلی مهمی که میخوام بگم ، تو قسمت گزارشات سیستمی یک قسمت بود به اسم مدیریت گزارشات که خواستم آخر توضیح بدم. ما تو قسمت مدیریت گزارشات اولا یه قسمت داریم وضیعت ثبت وقایع رویدادها که می تونیم اصلا کلا Log، Action هامونو خاموش کنیم و زمان هایی که می بینیم به هر علتی یه Over Head به وجود اومده یا یه مشکلی به وجود اومده میتونیم برای افزایش سرعت Log رویدادها رو خاموش کنیم.

اما یه گزینه ای هم داریم فعال یا غیرفعال کردن موقتی، این فعال یا غیرفعال کردن موقتی به این درد می خوره که شما می تونین Log تون رو غیر فعال کنین و هم از Log رویدادها و هم از Log خطاهاتون یه کپی بگیرید و یه دیتابیس خالی برا هر کدوم بسازید که از اول ، چه خطاها و چه رویدادهای شما ذخیره شه وقتی که از این دیتابیس ها کپی گرفتین و اون دیتابیس هایی که ازشون کپی گرفتین و پر هستند (میتونید در پایان هر سال کاری این کارو برا مشتری هاتون انجام بدید) رو از طریق یه اپلیکیشن ساده موبایل (چون اون LiteDb، Mobile ready هم هست) مثلا با اندروید یه داشبورد خیلی حرفه ای برای مشتری تون بنویسید و به عنوان اشانتیون بهش بدین. مشتری میتونه از انواع و اقسام رفتارهایی که مشتری هاش داشتن و پارامترهایی که پاس دادن اطلاعات خیلی خوبی راجع به فروش خودش، جستجوهای مشتری های خودش به دست بیاره و از این اطلاعات استفاده کنه که کسب و کار خودشو رونق بده و این میتونه یه موضوع خیلی خوبی باشه.

خود فایل Log ها هم بعد از کپی گرفتن تو قسمت مدیریت فایل سیستم توی ریشه سایتمون یه فولدری داریم به اسم Log که جفت دیتابیس ها اونجا هستن Error log و Action Log. وقتی هم که پشتیبان می گیرید دیتابیس های کپی شده میاد اینجا ساخته میشه که میتونین اونا رو دانلود کنید و بعدا انتقال بدید توی اپ اندرویدتون و چون Offline هم هست خیلی سریع اونجا Data mining رو مشتری تون انجام بده و از شما خیلی هم راضی باشه و یه نکته دیگه این که اگر Log خطاها یا Action Log ها موقع Log کردن خطا بده تو همین فولدر Log میاد به یه سری فایل متنی با تاریخ و ساعت واسه اون خطا ساخته میشه یعنی اگر احیانا تو همین فولدر یه سری فایل متنی دیدین احتمالا یه کدوم از این دو تا مکانیزم Log خودشون خطا دادن به هر علتی و میتونید باز کنید و خطا رو ببینید و متوجه بشید که چه مشکلی براتون پیش اومده.