وقتی تعداد Monitorها در Applications Manager زیاد میشود، مشاهده تکتک Server، Database، URL و Application دیگر تصویر قابل استفادهای از سرویس نمیدهد. Monitor Group برای همین مسئله است: چند Monitor مرتبط را زیر یک نمای واحد قرار میدهد تا ادمین بتواند سلامت یک شعبه، سرویس یا Business Application را یکجا ببیند.
این راهنما بر اساس مستند رسمی Applications Manager، ساخت Monitor Group، تعیین Owner، افزودن Monitorها، ساخت Sub-Group، کنترل دسترسی و Verify کردن نتیجه را توضیح میدهد. هدف فقط ساخت یک Container نیست؛ هدف این است که Group واقعاً مدل عملیاتی سرویس را بازتاب دهد.
سناریوی واقعی
فرض کنید سامانه فروش از یک Web Server، یک Application Server، یک Database، چند URL و یک Integration Service تشکیل شده است. اگر هرکدام جدا دیده شوند، ادمین برای پاسخ به سؤال ساده «سامانه فروش سالم است؟» باید چند صفحه را بررسی کند. با Monitor Group میتوان همه این اجزا را زیر یک نام منطقی مثل Sales-Service قرار داد.
اما اگر Group بدون طراحی ساخته شود و هر چیزی که اسم Sales دارد داخل آن ریخته شود، نتیجه فقط یک صفحه شلوغ دیگر است. قبل از ساخت Group باید بدانید این Group نمای یک Business Service است، یک Location است یا یک لایه فنی.
Monitor Group چه زمانی مناسب است؟
| نیاز | انتخاب مناسب | دلیل |
|---|---|---|
| گروهبندی منابع یک شعبه | Monitor Group | نمای عملیاتی بر اساس Location |
| گروهبندی اجزای یک Business Application | Monitor Group | نمای سلامت سرویس |
| ساخت ساختار چندلایه مانند App / DB / Web | Monitor Group + Sub-Group | نمای Dependency فنی |
| تمرکز روی Journey وب | Web Application Group در صورت نیاز | مدل متفاوت برای Web Application |
پیشنیازها
- Monitorهای موردنظر قبلاً در Applications Manager اضافه شده باشند.
- نام و Purpose گروه از قبل مشخص باشد.
- اگر قرار است Owner تعیین شود، User مربوطه در محصول تعریف شده باشد.
- اگر Group سرویسمحور است، فهرست Dependencyهای اصلی آن مشخص باشد.
- برای ساختارهای بزرگ، قبل از Production یک Group آزمایشی بسازید.
مرحله ۱: New Monitor Group را باز کنید
در کنسول Applications Manager گزینه New Monitor Group را انتخاب کنید. طبق مستند رسمی، ابتدا نام گروه باید وارد شود. نام میتواند شامل حروف و اعداد، Dash، Underscore، نقطه و فاصله باشد.
نام گروه را بر اساس سرویس یا Location انتخاب کنید؛ مثلاً Finance-ERP یا Tehran-Branch. نامهایی مثل Group1 یا Servers بعداً در Dashboard و Alarmها ارزش کمی دارند.
مرحله ۲: Description و Owner را تعیین کنید
Description را برای توضیح Scope گروه استفاده کنید. بهتر است بنویسید این Group چه چیزی را نمایندگی میکند، چه تیمی Owner است و چه چیزی عمداً خارج از Scope مانده است. این توضیح هنگام تحویل شیفت یا تغییر ادمین بسیار مفید میشود.
در بخش Advanced Options میتوان Owner را از میان Userهای موجود انتخاب کرد. مستند رسمی توضیح میدهد Operator در صورت Owner شدن، دسترسی Read Only به همان Monitor Group خواهد داشت. Admin همه Monitor Groupها را میبیند و Manager نیز بر اساس Association میتواند گروه را در Manager Console مشاهده کند.
مرحله ۳: Location را در صورت نیاز تنظیم کنید
اگر از World Map Business View استفاده میکنید، میتوانید Location را به Monitor Group مرتبط کنید. این کار برای شعب یا دیتاسنترها مفید است؛ اما اگر Group صرفاً یک Business Application است، Location را فقط زمانی اضافه کنید که واقعاً معنا دارد.
یک اشتباه متداول این است که Location را صرفاً چون فیلد وجود دارد پر کنیم. در Monitor Group سرویسمحور، Location اشتباه میتواند مدیر را به این تصور برساند که Group فقط یک Site را پوشش میدهد، در حالی که سرویس در چند Location توزیع شده است.
مرحله ۴: Finish و سپس Associate کردن Monitorها
با Finish گروه ساخته میشود و میتوانید Monitorها را به آن اضافه کنید. پیشنهاد عملی این است که ابتدا فقط اجزای اصلی سرویس را Associate کنید و بعد از Verify شدن Scope، Monitorهای فرعی را اضافه کنید.
برای مثال در ERP ابتدا Database، Application Server، URL اصلی و Middleware را اضافه کنید. اگر بعداً مشخص شد یک Queue یا Integration Endpoint برای Availability سرویس حیاتی است، آن را نیز وارد Group کنید.
مرحله ۵: Sub-Group بسازید
برای سرویسهای بزرگ، در صفحه Monitor Group از Monitor Group Actions گزینه New Sub-Group را انتخاب کنید. نام و Description بدهید و Monitorهای مناسب را Associate کنید.
Applications Manager بهصورت پیشفرض تا شش سطح Sub-Group را پشتیبانی میکند. این قابلیت برای مدلهای پیچیده مفید است، اما عمق زیاد همیشه بهتر نیست. ساختار باید برای ادمین شیفت قابل فهم بماند.
| سطح | نمونه | هدف |
|---|---|---|
| Monitor Group | ERP | نمای کل سرویس |
| Sub-Group 1 | Web Tier | تفکیک Frontend |
| Sub-Group 2 | Database Tier | تفکیک Data Layer |
| Sub-Group 3 | Integration Services | مشاهده وابستگیهای بیرونی |
مرحله ۶: مدل Owner را Verify کنید
بعد از ساخت Group با یک User غیر Admin وارد شوید و ببینید Scope همان چیزی است که انتظار دارید. اگر Operator قرار است فقط این Group را ببیند، دسترسی Read Only او را تست کنید. اگر Manager Console دارید، بررسی کنید Group موردنظر برای Manager قابل مشاهده است.
این تست مهم است چون طراحی Group فقط مسئله Visualization نیست؛ میتواند بخشی از تفکیک مسئولیت تیمها باشد.
مرحله ۷: Availability گروه را با سرویس واقعی مقایسه کنید
صرف دیدن سبز بودن Group کافی نیست. یک سناریوی واقعی را بررسی کنید: اگر Database Critical شود، آیا Group وضعیت قابل انتظار نشان میدهد؟ اگر URL خارجی Down شود اما سرویس داخلی هنوز کار کند، آیا این Monitor واقعاً باید روی سلامت کلی Group اثر داشته باشد؟
هدف این است که Monitor Group به مدل سرویس نزدیک شود. اگر هر Alarm کوچک کل Group را Critical میکند، احتمالاً باید Threshold، Dependency یا ترکیب Monitorها را بازبینی کنید.
مرحله ۸: Maintenance و تغییرات برنامهریزیشده را در نظر بگیرید
وقتی یک جزء سرویس Maintenance برنامهریزیشده دارد، تیم باید بداند اثر آن روی Group چیست. قبل از Window نگهداری، Dashboard و Alarm Behavior را مرور کنید تا Maintenance برنامهریزیشده بهعنوان اختلال ناشناخته تفسیر نشود.
چگونه Group را برای NOC قابل استفاده کنیم؟
NOC به Groupهایی نیاز دارد که نام، Owner و Failure Domain روشن داشته باشند. اگر Alarm روی Group ایجاد شد، ادمین شیفت باید بتواند سریع تشخیص دهد کدام لایه مشکل دارد و Owner کیست. بنابراین Description، Sub-Group و Labelهای واضح مستقیماً روی MTTR اثر دارند.
اشتباهات رایج
| مشکل | علت | راهحل |
|---|---|---|
| Group بیش از حد شلوغ است | Scope مشخص نیست | بر اساس Business Service یا Location بازطراحی کنید |
| Owner اشتباه است | گروه بدون مدل مسئولیت ساخته شده | Owner را با تیم عملیاتی هماهنگ کنید |
| Sub-Group زیاد است | مدل بیش از حد ریز شده | لایههای کمارزش را ادغام کنید |
| سلامت گروه قابل تفسیر نیست | Monitorهای نامرتبط کنار هم هستند | Dependency واقعی سرویس را مبنا قرار دهید |
| Operator داده بیش از نیاز میبیند | Owner/Scope درست طراحی نشده | User و Role را مجدداً Verify کنید |
Monitor Group را با CMDB اشتباه نگیرید
Monitor Group برای نمای عملیاتی و مانیتورینگ است، نه جایگزین کامل CMDB. اگر هدف ثبت Ownership، Relationship و Lifecycle داراییهاست، مدل CMDB باید منبع ساختاری باشد. Monitor Group میتواند همان مدل سرویس را برای Operations بازتاب دهد.
چه زمانی Group را بازبینی کنیم؟
بعد از اضافه شدن Component جدید، Migration، تغییر Owner، تغییر Location یا حذف Application باید Monitor Group هم Review شود. Group قدیمی که Architecture جدید را منعکس نمیکند، در Incident بعدی تیم را به مسیر اشتباه میبرد.
برای آشنایی با پایههای ادمین این محصول، راهنمای ادمین Applications Manager را ببینید. اگر ساختار Monitoring سازمان باید بر اساس سرویس، شعبه و مسئولیت تیمها بازطراحی شود، پشتیبانی مدانت میتواند مدل Group و Dashboard را قبل از گسترش Production بازبینی کند.
چکلیست نهایی
- نام Group نشاندهنده سرویس یا Location است.
- Description و Owner مشخصاند.
- Monitorهای مرتبط Associate شدهاند.
- Sub-Group فقط در صورت ارزش عملیاتی ساخته شده است.
- Scope با User واقعی Verify شده است.
- Availability Group با رفتار واقعی سرویس مقایسه شده است.
- ساختار برای ادمین شیفت قابل فهم است.
- Review بعد از تغییر معماری انجام میشود.
سخن پایانی
Monitor Group زمانی ارزش دارد که پیچیدگی را کم کند. اگر بعد از ساخت گروه هنوز ادمین برای فهم سلامت یک سرویس مجبور است دهها Monitor نامرتبط را مرور کند، گروهبندی درست انجام نشده است. ساختار خوب باید از نگاه کسبوکار شروع شود و اجزای فنی را زیر همان سرویس قابل مشاهده کند.
منابع
- ManageEngine Applications Manager — Creating Monitor Groups
- ManageEngine Applications Manager — Monitor Groups
