یک روش ساده مانیتورینگ

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

راه حلی که بعد از مدتی به آن رسیدیم این بود که مشخص کردیم هر ایجنت به کدام قسمت از دیتابیس اثر می گذارد و دقیقا چه اثری.به طور مثال مشخص کردیم که اگر سرویس محاسبه حساب های مشتری اجرا شود باید تاریخ بروزشدن تمام رکورد های حساب برای امروز باشد.سپس یک کوئری نوشتیم که اگر در ساعت ۹ صبح آن را اجرا کنیم باید نشان دهنده تعداد کلی حساب هایی باشد که بروز شده است.بنابراین اگر این رکورد صفر بود یا عددی غیر از آن عددی که مد نظر ما است متوجه خطا می شدیم.به ازای هر سرویس ما چند کوئری به این سبک نوشتیم.مجموع این کوئری ها را به راحتی می توان توسط برنامه های مانیتورینگ مانیتور کرد.

برای مثال به کوئری زیر توجه کنید:

SELECT  TOP(1) 1 AS Id, 'dbo.Account' AS TableName, '> 0' AS ExpectedValue,COUNT(id) AS Value, N'در ساعت نه و دو دقیقه باید این رکورد بزرگتر از صفر باشد ' AS Description
FROM dbo.Account WITH (NOLOCK)
WHERE cast (GETDATE() as DATE)= cast (ModDate as DATE)

کوئری بالا نشان می دهد که در صورتی که در ساعت نه و دو دقیقه(با توجه به ساعتی که سرویس مورد نظر باید اجرا شود) این کوئری اجرا شد باید مقدارش بزرگتر از صفر باشد.در صورتی که این مقدار کوچکتر از صفر بود یعنی سرویس ما به درستی اجرا نشده است.در این حالت برنامه مانیتورینگ به راحتی متوجه شده افراد مسئول را باخبر می سازد.

علاوه بر آن نقاطی را مشخص کردیم که در صورتی که مثلا فلان اتفاق در سیستم رخ دهد یا ندهد یعنی سیستم با خطا روبرو است.برای این نقاط نیز کوئری های مشخصی را ایجاد کردیم.برای مثال در بازه ۹ تا ۱۲ صبح می بایست آخرین تراکنش ما کمتر از ۳۰ ثانیه قبل باشد.در صورتی که به هر علتی بیشتر از سی ثانیه شد،این یعنی زنگ خطر برای ما.

در کل به وسیله این روش مانیتورنیگ توانستیم تا حد زیادی از چک کردن های دستی سیستم راحت شویم و همچنین از اجرا شدن صحیح سرویس ها اطمینان حاصل کنیم.البته مطمئنا راه حل های دیگری نیز برای این کار وجود دارد ولی با توجه به منابع و نیاز ما تصمیم گرفتیم این راه را انتخاب کنیم.

پیام های مناسب برای لاگ کردن

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

بررسی لاگ های سیستم ممکن است خیلی سخت و زمانگیر باشد.مخصوصا زمانی که شما نتوانید به درستی متوجه شوید منظور از یک پیام در فایل لاگ چیست.فرض کنید در فایل لاگ نوشته شده :

User not found

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

برای مثال لاگ بالا را می توانیم به صورت زیر تغییر دهیم:

User id 1024 in recalculation account not found.

حالا اگر برنامه نویس سیستم لاگ را بررسی کند می تواند متوجه شود که در محاسبه حساب کاربر شماره ۱۰۲۴ مشکلی پیش آمده و احتمالا مغایرتی وجود خواهد داشت.

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