فیل را تکه تکه می خوریم. استراتژی نظارت بر سلامت کاربردی با مثال

خوش آمدید!

شرکت ما در توسعه نرم افزار و پشتیبانی فنی بعدی مشغول است. پشتیبانی فنی نه تنها به رفع خطاها، بلکه نظارت بر عملکرد برنامه های ما نیاز دارد.

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

ما یک شرکت کوچک داریم، ما منابعی برای مطالعه و نگهداری راه حل های پیچیده برای نظارت بر برنامه ها نداریم، ما باید یک راه حل ساده و موثر پیدا کنیم.

استراتژی نظارت

بررسی عملکرد یک برنامه آسان نیست؛ این کار بی اهمیت است، حتی می توان گفت خلاقانه. تأیید یک سیستم پیچیده چند پیوندی به ویژه دشوار است.

چگونه می توان فیل را خورد؟ فقط در قطعات! ما از این روش برای نظارت بر برنامه ها استفاده می کنیم.

ماهیت استراتژی نظارت ما:

برنامه خود را به اجزاء تقسیم کنید.
برای هر جزء چک های کنترلی ایجاد کنید.

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

بنابراین، هر سیستمی را می توان به عنوان درختی از اجزاء نمایش داد. اجزای پیچیده به اجزای ساده تر تقسیم می شوند. اجزای ساده دارای چک هستند.

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

هیچ معجزه ای وجود ندارد، بیشتر چک ها باید به طور مستقل توسعه یابند. اما نترسید، زیرا در بیشتر موارد یک چک 5-10 خط کد می گیرد، اما شما می توانید هر منطقی را پیاده سازی کنید و به وضوح متوجه خواهید شد که چک چگونه کار می کند.

سیستم نظارت

فرض کنید برنامه را به اجزا تقسیم کردیم، بررسی هایی را برای هر جزء ایجاد کردیم و اجرا کردیم، اما با نتایج این بررسی ها چه باید کرد؟ چگونه بفهمیم برخی از چک ها شکست خورده اند؟

ما به یک سیستم نظارتی نیاز خواهیم داشت. او وظایف زیر را انجام خواهد داد:

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

شرح مختصری از سیستم ASMO

بهتر است با یک مثال توضیح دهید. بیایید به نحوه سازماندهی نظارت بر عملکرد سیستم ASMO نگاه کنیم.

ASMO یک سیستم خودکار پشتیبانی هواشناسی است. این سیستم به متخصصان خدمات جاده ای کمک می کند تا بفهمند کجا و چه زمانی لازم است جاده را با مواد یخ زدا درمان کنند. این سیستم داده ها را از نقاط کنترل جاده جمع آوری می کند. نقطه کنترل جاده مکانی در جاده است که تجهیزات نصب شده است: ایستگاه هواشناسی، دوربین فیلمبرداری و غیره. برای پیش بینی موقعیت های خطرناک، سیستم پیش بینی آب و هوا را از منابع خارجی دریافت می کند.

بنابراین، ترکیب سیستم کاملاً معمولی است: وب سایت، عامل، تجهیزات. بیایید نظارت را شروع کنیم.

تجزیه سیستم به اجزاء

اجزای زیر را می توان در سیستم ASMO متمایز کرد:

1. حساب شخصی
این یک برنامه وب است. حداقل، باید بررسی کنید که برنامه در اینترنت در دسترس است.

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

3. سرور
منظور ما از سرور سخت افزاری است که برنامه ها روی آن اجرا می شوند. بررسی وضعیت HDD، RAM، CPU ضروری است.

4. عامل
این یک سرویس ویندوزی است که وظایف مختلفی را بر اساس یک برنامه زمان بندی انجام می دهد. حداقل باید بررسی کنید که سرویس در حال اجرا است.

5. وظیفه نماینده
فقط دانستن اینکه یک نماینده کار می کند کافی نیست. یک نماینده ممکن است کار کند، اما وظایف محول شده خود را انجام ندهد. بیایید جزء عامل را به وظایف تقسیم کنیم و بررسی کنیم که آیا هر وظیفه عامل با موفقیت کار می کند یا خیر.

6. نقاط کنترل جاده (کانتینر تمام MPCها)
نقاط کنترل جاده زیادی وجود دارد، بنابراین بیایید همه MPC ها را در یک جزء ترکیب کنیم. این کار خواندن داده های نظارت را راحت تر می کند. هنگام مشاهده وضعیت جزء "سیستم ASMO" بلافاصله مشخص می شود که مشکلات کجا هستند: در برنامه ها، سخت افزار یا در سیستم کنترل حداکثر.

7. نقطه کنترل جاده (یک حد حداکثر)
اگر همه دستگاه‌های موجود در این MPC قابل سرویس باشند، این کامپوننت را قابل تعمیر می‌دانیم.

8. دستگاه
این یک دوربین فیلمبرداری یا ایستگاه هواشناسی است که در حد حداکثر غلظت نصب شده است. لازم است بررسی شود که دستگاه به درستی کار می کند.

در سیستم مانیتورینگ، درخت کامپوننت به شکل زیر خواهد بود:

نظارت بر برنامه های وب

بنابراین، ما سیستم را به اجزاء تقسیم کرده ایم، اکنون باید برای هر جزء بررسی کنیم.

برای نظارت بر یک برنامه وب، از بررسی های زیر استفاده می کنیم:

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

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

3. بررسی گواهی SSL
امروزه تقریبا تمامی وب سایت ها از پروتکل https برای دسترسی استفاده می کنند. برای اینکه پروتکل به درستی کار کند، به یک گواهی SSL معتبر نیاز دارید.

در زیر جزء "حساب شخصی" در سیستم نظارت است:

تمام بررسی های بالا برای اکثر برنامه ها کار می کنند و نیازی به کدنویسی ندارند. این بسیار جالب است زیرا می توانید در عرض 5 دقیقه نظارت بر هر برنامه وب را شروع کنید. در زیر بررسی‌های اضافی وجود دارد که می‌توان برای یک برنامه وب انجام داد، اما پیاده‌سازی آنها پیچیده‌تر و مختص برنامه‌ها است، بنابراین در این مقاله به آن‌ها نمی‌پردازیم.

چه چیز دیگری را می توانید بررسی کنید؟

برای نظارت بیشتر بر برنامه وب خود، می توانید بررسی های زیر را انجام دهید:

• تعداد خطاهای جاوا اسکریپت در هر دوره
• تعداد خطاها در سمت برنامه وب (back-end) برای دوره
• تعداد پاسخ های ناموفق برنامه وب (کد پاسخ 404، 500 و غیره)
• میانگین زمان اجرای پرس و جو

نظارت بر یک سرویس ویندوز (نماینده)

در سیستم ASMO، عامل نقش یک زمانبندی کار را ایفا می کند که وظایف برنامه ریزی شده را در پس زمینه اجرا می کند.

اگر تمام وظایف نماینده با موفقیت انجام شود، عامل به درستی کار می کند. به نظر می رسد که برای نظارت بر یک عامل، باید وظایف آن را نظارت کنید. بنابراین، ما جزء "عامل" را به وظایف تقسیم می کنیم. برای هر کار، ما یک مؤلفه جداگانه در سیستم نظارت ایجاد خواهیم کرد که در آن مؤلفه «عامل» «والد» خواهد بود.

ما مؤلفه Agent را به مؤلفه های فرزند (وظایف) تقسیم می کنیم:

بنابراین، ما یک جزء پیچیده را به چندین جزء ساده تقسیم کرده ایم. اکنون باید برای هر جزء ساده چک هایی ارائه کنیم. لطفاً توجه داشته باشید که مؤلفه مادر «عامل» هیچ گونه بررسی نخواهد داشت، زیرا سیستم نظارت وضعیت آن را به طور مستقل بر اساس وضعیت مؤلفه‌های فرزند خود محاسبه می‌کند. به عبارت دیگر، اگر تمام وظایف با موفقیت انجام شود، عامل با موفقیت اجرا می شود.

بیش از صد کار در سیستم ASMO وجود دارد، آیا واقعاً لازم است برای هر کار بررسی های منحصر به فردی ارائه شود؟ البته اگر چک های مخصوص خود را برای هر کار عاملی بیاوریم و اجرا کنیم، کنترل بهتر خواهد بود، اما در بیشتر موارد استفاده از چک های جهانی کافی است.

سیستم ASMO فقط از چک های جهانی برای وظایف استفاده می کند و این برای نظارت بر عملکرد سیستم کافی است.

بررسی پیشرفت
ساده ترین و موثرترین چک، چک اجراست. بررسی تأیید می کند که کار بدون خطا انجام شده است. همه کارها این چک را دارند.

بررسی الگوریتم

پس از اجرای هر کار، در صورت موفقیت آمیز بودن اجرای کار، باید نتیجه بررسی SUCCESS را به سیستم مانیتورینگ ارسال کنید، یا اگر اجرای با خطا کامل شد، ERROR را ارسال کنید.

این بررسی می تواند مشکلات زیر را شناسایی کند:

1. کار اجرا می شود اما با یک خطا ناموفق است.
2. کار متوقف شده است، به عنوان مثال، ثابت شده است.

بیایید نحوه حل این مشکلات را با جزئیات بیشتری بررسی کنیم.

مسئله 1 - کار اجرا می شود اما با یک خطا شکست می خورد
در زیر موردی است که در آن کار بین ساعت 14:00 تا 16:00 اجرا می شود اما با شکست مواجه می شود.

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

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

مشکل 2 - اجرای کار متوقف شد (یخ زده)
چگونه سیستم نظارت متوجه خواهد شد که یک کار گیر کرده است؟

نتیجه چک دارای یک دوره اعتبار است، به عنوان مثال، 1 ساعت. اگر یک ساعت بگذرد و نتیجه آزمایش جدیدی وجود نداشته باشد، سیستم مانیتورینگ وضعیت تست را روی آلارم تنظیم می کند.

در تصویر بالا، چراغ ها ساعت 14 خاموش شده است. در ساعت 00:15 سیستم نظارت تشخیص می دهد که نتیجه آزمایش (از ساعت 00:14) پوسیده است، زیرا زمان ارتباط منقضی شده است (یک ساعت)، اما نتیجه جدیدی وجود ندارد و بررسی را به وضعیت هشدار تغییر می دهد.

در ساعت 16:00 دوباره چراغ ها روشن شد، برنامه کار را کامل می کند و نتیجه اجرا را به سیستم نظارت ارسال می کند، وضعیت آزمایش دوباره موفقیت آمیز خواهد بود.

از چه زمان مربوط به چک استفاده کنم؟

زمان ارتباط باید بیشتر از دوره اجرای کار باشد. من توصیه می کنم زمان ارتباط را 2-3 برابر بیشتر از دوره اجرای کار تنظیم کنید. این برای جلوگیری از دریافت اعلان‌های نادرست، زمانی که، برای مثال، زمانی که یک کار بیشتر از حد معمول طول می‌کشد یا شخصی برنامه را دوباره بارگیری می‌کند، ضروری است.

بررسی پیشرفت

سیستم ASMO دارای یک وظیفه "پیش بینی بار" است که سعی می کند هر ساعت یک بار پیش بینی جدید را از یک منبع خارجی دانلود کند. زمان دقیق ظاهر شدن یک پیش بینی جدید در سیستم خارجی مشخص نیست، اما مشخص است که این اتفاق 2 بار در روز می افتد. معلوم می شود که اگر برای چندین ساعت پیش بینی جدیدی وجود نداشته باشد، این طبیعی است، اما اگر پیش بینی جدیدی برای بیش از یک روز وجود نداشته باشد، چیزی در جایی شکسته است. به عنوان مثال، قالب داده ها در یک سیستم پیش بینی خارجی ممکن است تغییر کند، به همین دلیل است که ASMO نسخه پیش بینی جدیدی را مشاهده نخواهد کرد.

بررسی الگوریتم

هنگامی که این کار موفق به پیشرفت (دانلود یک پیش بینی آب و هوای جدید) شد، نتیجه بررسی SUCCESS را به سیستم نظارت ارسال می کند. اگر پیشرفتی نداشته باشد یا خطایی رخ دهد، چیزی به سیستم مانیتورینگ ارسال نمی شود.

چک باید یک بازه مرتبط داشته باشد به طوری که در طول این مدت پیشرفت جدید تضمین شود.

لطفاً توجه داشته باشید که با تأخیر متوجه مشکل خواهیم شد، زیرا سیستم نظارت تا پایان دوره اعتبار آخرین نتیجه اسکن صبر می کند. بنابراین، مدت اعتبار چک نیازی به طولانی شدن ندارد.

نظارت بر پایگاه داده

برای کنترل پایگاه داده در سیستم ASMO، بررسی های زیر را انجام می دهیم:

1. تأیید ایجاد پشتیبان
2. بررسی فضای آزاد دیسک

تأیید ایجاد پشتیبان
در اکثر برنامه ها، داشتن نسخه پشتیبان از پایگاه داده به روز بسیار مهم است تا در صورت خرابی سرور، بتوانید برنامه را در یک سرور جدید مستقر کنید.

ASMO یک بار در هفته یک نسخه پشتیبان ایجاد می کند و آن را به ذخیره سازی می فرستد. هنگامی که این روش با موفقیت انجام شد، نتیجه بررسی موفقیت آمیز به سیستم نظارت ارسال می شود. نتیجه تأیید به مدت 9 روز معتبر است. آن ها برای کنترل ایجاد پشتیبان‌گیری، از مکانیسم "بررسی پیشرفت" که در بالا به آن پرداختیم استفاده می‌شود.

بررسی فضای آزاد دیسک
اگر فضای خالی کافی بر روی دیسک وجود نداشته باشد، پایگاه داده نمی تواند به درستی کار کند، بنابراین کنترل مقدار فضای آزاد بسیار مهم است.

استفاده از معیارها برای بررسی پارامترهای عددی راحت است.

معیارهای یک متغیر عددی است که مقدار آن به سیستم مانیتورینگ منتقل می شود. سیستم مانیتورینگ مقادیر آستانه را بررسی می کند و وضعیت متریک را محاسبه می کند.

در زیر تصویری از آنچه مؤلفه "پایگاه داده" در سیستم نظارت به نظر می رسد را نشان می دهد:

نظارت بر سرور

برای نظارت بر سرور، از بررسی ها و معیارهای زیر استفاده می کنیم:

1. فضای دیسک آزاد
اگر فضای دیسک تمام شود، برنامه قادر به کار نخواهد بود. ما از 2 مقدار آستانه استفاده می کنیم: سطح اول WARNING، سطح دوم ALARM است.

2. میانگین مقدار RAM بر حسب درصد در ساعت
ما از میانگین ساعتی استفاده می کنیم زیرا ... ما علاقه ای به نژادهای کمیاب نداریم.

3. میانگین درصد CPU در ساعت
ما از میانگین ساعتی استفاده می کنیم زیرا ... ما علاقه ای به نژادهای کمیاب نداریم.

4. پینگ چک
بررسی می کند که سرور آنلاین است. سیستم مانیتورینگ می تواند این بررسی را انجام دهد؛ نیازی به نوشتن کد نیست.

در زیر تصویری از ظاهر مولفه "سرور" در سیستم مانیتورینگ آمده است:

نظارت بر تجهیزات

من به شما خواهم گفت که چگونه داده ها به دست می آیند. برای هر نقطه کنترل جاده (MPC) یک وظیفه در برنامه ریز وظیفه وجود دارد، به عنوان مثال، "Survey MPC M2 km 200". وظیفه هر 30 دقیقه یک بار داده ها را از تمام دستگاه های MPC دریافت می کند.

مشکل کانال ارتباطی
بیشتر تجهیزات در خارج از شهر قرار دارند؛ یک شبکه GSM برای انتقال داده استفاده می شود که به طور پایدار کار نمی کند (شبکه وجود دارد یا وجود ندارد).

به دلیل خرابی های مکرر شبکه، در ابتدا بررسی MPC در نظارت به این صورت بود:

مشخص شد که این یک گزینه کاربردی نیست، زیرا اعلان های نادرست زیادی در مورد مشکلات وجود دارد. سپس تصمیم گرفته شد که برای هر دستگاه از "بررسی پیشرفت" استفاده شود. تنها زمانی که دستگاه بدون خطا نظرسنجی می شود، سیگنال موفقیت به سیستم مانیتورینگ ارسال می شود. زمان مربوطه روی 5 ساعت تنظیم شد.

اکنون مانیتورینگ فقط زمانی اعلان‌های مربوط به مشکلات را ارسال می‌کند که دستگاه را نتوان برای بیش از 5 ساعت نظرسنجی کرد. با احتمال زیاد، اینها هشدارهای کاذب نیستند، بلکه مشکلات واقعی هستند.

در زیر تصویری از ظاهر تجهیزات در سیستم مانیتورینگ مشاهده می شود:

مهم!
وقتی شبکه GSM از کار می افتد، همه دستگاه های MDC نظرسنجی نمی شوند. برای کاهش تعداد ایمیل‌های سیستم مانیتورینگ، مهندسان ما مشترک اعلان‌های مربوط به مشکلات قطعات با نوع «MPC» به جای «دستگاه» می‌شوند. این به شما امکان می دهد به جای دریافت یک اعلان جداگانه برای هر دستگاه، یک اعلان برای هر MPC دریافت کنید.

طرح نظارت نهایی ASMO

بیایید همه چیز را کنار هم بگذاریم و ببینیم چه نوع طرح نظارتی داریم.

نتیجه

بیایید خلاصه کنیم.
نظارت بر عملکرد ASMO چه چیزی به ما داد؟

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

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

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

4. افزایش وفاداری مشتریان و کاربران
مشتری متوجه تغییرات مثبت در پایداری سیستم شد. کاربران در استفاده از سیستم با مشکلات کمتری مواجه می شوند.

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

مهم!
شما نمی توانید سیستم مانیتورینگ را روی همان سروری که برنامه های شما در آن اجرا می شوند نصب کنید. اگر سرور از کار بیفتد، برنامه‌ها از کار می‌افتند و کسی وجود نخواهد داشت که در مورد آن مطلع شود.

سیستم مانیتورینگ باید روی یک سرور جداگانه در مرکز داده دیگری اجرا شود.

اگر نمی خواهید از سرور اختصاصی در یک مرکز داده جدید استفاده کنید، می توانید از سیستم مانیتورینگ ابری استفاده کنید. شرکت ما از سیستم مانیتورینگ ابری Zidium استفاده می کند، اما شما می توانید از هر سیستم مانیتورینگ دیگری استفاده کنید. هزینه سیستم مانیتورینگ ابری کمتر از اجاره سرور جدید است.

توصیه ها:

1. برنامه ها و سیستم ها را در قالب درختی از اجزاء با جزئیات هر چه بیشتر تجزیه کنید، بنابراین درک مکان و آنچه شکسته است راحت خواهد بود و کنترل کامل تر خواهد بود.
2. برای بررسی عملکرد یک جزء، از تست ها استفاده کنید. بهتر است از چندین چک ساده استفاده کنید تا یک چک پیچیده.
3. به جای نوشتن کد، آستانه های متریک را در کنار سیستم مانیتورینگ پیکربندی کنید. این شما را از کامپایل مجدد، پیکربندی مجدد یا راه اندازی مجدد برنامه نجات می دهد.
4. برای بررسی‌های سفارشی، از حاشیه زمان مرتبط استفاده کنید تا از دریافت اعلان‌های نادرست جلوگیری کنید زیرا تکمیل برخی از بررسی‌ها کمی بیشتر از حد معمول طول کشید.
5. سعی کنید اجزای سیستم مانیتورینگ فقط زمانی قرمز شوند که قطعا مشکلی وجود دارد. اگر آنها بیهوده قرمز شوند ، دیگر توجهی به اعلان های سیستم نظارت نخواهید داشت ، معنای آن از بین می رود.

اگر هنوز از سیستم نظارتی استفاده نمی کنید، شروع کنید! آنقدرها هم که به نظر می رسد سخت نیست. از نگاه کردن به درخت مواد سبزی که خودتان پرورش دادید، لذت ببرید.

موفق باشید.

منبع: www.habr.com