در لایسنس Applications Manager مهمترین عدد، تعداد کارمند یا تعداد سرور فیزیکی سازمان نیست؛ معیار اصلی تعداد Monitorهایی است که در محصول ایجاد میکنید. علاوه بر آن، Edition، تعداد Userهای Console و بعضی Add-onها روی هزینه نهایی اثر دارند.
اگر مفهوم Monitor از ابتدا درست فهمیده نشود، یک محیط ظاهراً کوچک ممکن است در زمان Discovery تعداد بسیار بیشتری از برآورد اولیه ایجاد کند. این راهنما برای Sizing و استعلام سازمانی Applications Manager نوشته شده است؛ نه برای اعلام قیمت ثابت، بلکه برای اینکه Quote بر اساس Scope واقعی تهیه شود.
Monitor در Applications Manager چیست؟
طبق راهنمای رسمی ManageEngine، هر Application، Server، Service یا URL مشخصی که برای پایش به Applications Manager اضافه میشود یک Monitor محسوب میشود. بنابراین تعداد Hostها همیشه با تعداد Monitorها برابر نیست.
برای مثال اگر ۳۰ SQL Server، ۲۰ Web Server، ۱۵ سرویس Java و ۱۰ URL حیاتی را مانیتور کنید، Sizing باید از مجموع Monitorهای واقعی انجام شود، نه صرفاً تعداد ماشینهای فیزیکی.
مدل لایسنس بر چه اساسی است؟
| متغیر | اثر روی Quote |
|---|---|
| Monitor | Metric اصلی ظرفیت |
| Edition | Professional / Enterprise / Free |
| User | Userهای اضافی Console میتوانند هزینه مستقل داشته باشند |
| Add-on | APM Insight، End User Monitoring، RUM و موارد مشابه |
| Contract | Annual Subscription یا Perpetual در مدل مربوط |
Host Count با Monitor Count چه تفاوتی دارد؟
فرض کنید روی یک VM هم OS، هم Tomcat، هم یک Database و هم یک URL Application پایش میشود. از دید Infrastructure فقط یک Host دارید، اما Monitoring Scope میتواند چند Monitor داشته باشد.
این تفاوت باعث میشود Inventory ساده سرورها برای Sizing کافی نباشد. باید Inventory را به «فهرست اشیای قابل پایش» تبدیل کنید.
چطور Monitorها را قبل از خرید بشماریم؟
- Business Applicationهای مهم را فهرست کنید.
- Serverهای مرتبط را مشخص کنید.
- Database Instanceها را جدا بشمارید.
- Middleware و Application Serverها را ثبت کنید.
- URL و Web Serviceهای مستقل را اضافه کنید.
- Cloud Service و Container Scope را در صورت نیاز مشخص کنید.
- Monitorهای آزمایشی یا Out-of-Scope را حذف کنید.
- برای رشد نزدیک ظرفیت معقول در نظر بگیرید.
Service Map برای Sizing چه کمکی میکند؟
اگر Service Map دارید، میتوانید هر Business Service را به اجزای زیرساختی آن بشکنید و Monitorهای موردنیاز را دقیقتر تخمین بزنید. این روش از «شمردن تصادفی سرورها» بهتر است، چون Monitoring Scope را به سرویسهای واقعی کسبوکار متصل میکند.
مثلاً سامانه فروش ممکن است Web، Application، Database، Queue و چند URL داشته باشد. همه این اجزا برای دید End-to-End اهمیت دارند.
Professional یا Enterprise؟
Professional برای بسیاری از محیطهای متمرکز مناسب است. Enterprise برای معماری Distributed و مقیاس بزرگتر طراحی شده و زمانی مطرح میشود که چند Site، شبکه توزیعشده یا تعداد بالای Application/Server باید زیر یک دید مرکزی مدیریت شوند.
انتخاب Edition را با Architecture انجام دهید، نه فقط تعداد Monitor. اگر سازمان چند دیتاسنتر یا شعب متعدد دارد، Topology استقرار میتواند حتی از تعداد Host مهمتر باشد.
چه زمانی Enterprise را بررسی کنیم؟
| نشانه | چرا مهم است؟ |
|---|---|
| چند دیتاسنتر | نیاز به معماری توزیعشده |
| شعب متعدد | کنترل Connectivity و Scale |
| Monitor بسیار زیاد | نیاز به Scale Architecture |
| تیمهای منطقهای | مدیریت دسترسی و Operation توزیعشده |
این جدول حکم قطعی نیست؛ Feature Matrix و Architecture Guide رسمی باید تصمیم نهایی را تأیید کنند.
Free Edition کجا مفید است؟
Free Edition برای Lab، آشنایی یا Scope محدود مفید است، اما برای Production باید Limitهای رسمی همان نسخه بررسی شوند. POC را طوری طراحی کنید که Edition هدف Production مشخص باشد.
Userهای Console را فراموش نکنید
اگر تیمهایی مانند NOC، DBA، Application Team و مدیران باید به Console دسترسی مستقل داشته باشند، تعداد Userهای موردنیاز را پیش از Quote مشخص کنید. User اضافی در Pricing رسمی میتواند آیتم مستقل باشد.
Role Matrix کمک میکند هر شخصی که فقط Report ایمیلی میخواهد الزاماً Console User نشود. این موضوع هم Governance را بهتر میکند و هم Sizing را واقعی نگه میدارد.
Add-onها چه زمانی مهم میشوند؟
قابلیتهایی مانند APM Insight، End User Monitoring، Real User Monitoring یا Add-onهای مرتبط ممکن است مدل قیمتگذاری جدا داشته باشند. اگر POC با این قابلیتها انجام شده، مطمئن شوید Quote نهایی هم همان Scope را پوشش میدهد.
در مقایسه فروشندگان، Base License و Add-on را در ستونهای جدا بنویسید تا پیشنهادها واقعاً همارز باشند.
نمونه Sizing سازمانی
فرض کنید یک سازمان ۴۰ Server دارد اما روی آنها ۲۵ Database Instance، ۳۵ Application Server، ۳۰ URL و ۲۰ سرویس Middleware را جداگانه پایش میکند. تعداد Host فقط ۴۰ است، اما Monitoring Scope بهمراتب بزرگتر است. Quote باید بر اساس Monitor واقعی محاسبه شود.
اگر این محیط در سه Site مستقل است و مدیریت مرکزی لازم دارد، علاوه بر تعداد Monitor، Enterprise Architecture نیز باید بررسی شود.
یک سناریوی اشتباه رایج
تیم خرید میگوید «ما ۶۰ سرور داریم» و بر همین اساس Quote میگیرد. بعد از استقرار مشخص میشود روی این ۶۰ سرور بیش از ۱۸۰ Monitor واقعی لازم است. نتیجه یا Upgrade اضطراری License است یا حذف بخشی از Monitoring Scope. این مشکل با یک Discovery Worksheet ساده قبل از خرید قابل پیشگیری است.
Annual یا Perpetual؟
Pricing رسمی Applications Manager برای Editionهای تجاری مدل Subscription و Perpetual را ارائه میکند. در مقایسه این دو، فقط سال اول را نبینید؛ Support، Upgrade، AMS و افق بهرهبرداری باید وارد TCO شوند.
اگر مدل Perpetual انتخاب میشود، برنامه Renewal و Maintenance را از ابتدا در بودجه چندساله قرار دهید. راهنمای انقضای AMS ManageEngine برای همین تصمیم مفید است.
Growth Planning را چطور انجام دهیم؟
رشد Monitor باید از Roadmap برنامهها و زیرساخت بیاید. اگر دو پروژه جدید ERP و CRM در شش ماه آینده Production میشوند، Monitorهای آنها باید در Capacity Plan دیده شوند. در مقابل، خرید ظرفیت زیاد صرفاً «برای روز مبادا» باعث Over-Licensing میشود.
Quote حرفهای چه ستونهایی دارد؟
| فیلد | هدف |
|---|---|
| Edition | مشخصشدن Architecture و Feature Scope |
| Monitor Count | ظرفیت اصلی |
| User Count | دسترسی Console |
| Add-on | تفکیک قابلیتهای اضافی |
| Contract | Annual/Perpetual |
| Support/AMS | برآورد TCO |
خطاهای رایج خرید لایسنس Applications Manager
- شمردن Server به جای Monitor؛
- نادیدهگرفتن Database و Middlewareهای مستقل؛
- فراموشکردن URL Monitorها؛
- انتخاب Professional برای معماری توزیعشده بدون بررسی Enterprise؛
- فراموشکردن Userهای اضافی؛
- POC با Add-on و Quote بدون همان Add-on؛
- خرید ظرفیت بسیار بزرگ بدون Growth Plan واقعی؛
- ندیدن سرویسهای جدید در Roadmap.
Metric محصولات ManageEngine یکسان نیست
Applications Manager بر Monitor تمرکز دارد؛ در حالی که Endpoint Central بر Endpoint و Server و AssetExplorer بر IT Asset Sizing میشوند. برای همین یک فرمول عمومی برای تمام ManageEngine وجود ندارد.
راهنمای مادر خرید لایسنس ManageEngine این تفاوتها را یکجا توضیح میدهد.
چکلیست استعلام
- تعداد تقریبی Monitorها مشخص است.
- نوع Monitorها دستهبندی شدهاند.
- Service Map یا Application Inventory بررسی شده است.
- Professional/Enterprise بر اساس معماری بررسی شده است.
- تعداد Userهای Console مشخص است.
- Add-onها ثبت شدهاند.
- Annual/Perpetual مقایسه شده است.
- رشد ۱۲ تا ۱۸ ماه آینده در نظر گرفته شده است.
برای Quote مبتنی بر Sizing واقعی، مرکز استعلام مدانت میتواند Monitor Worksheet و معماری شما را مبنای پیشنهاد قرار دهد.
نکات کلیدی
در Applications Manager، Monitor واحد اصلی محاسبه است. یک Host میتواند چند Monitor داشته باشد و معماری Enterprise نیز ممکن است مستقل از تعداد Host تعیینکننده باشد. ابتدا Monitoring Scope را بسازید، سپس License Tier را انتخاب کنید.
سخن پایانی
بهترین Sizing برای Applications Manager از این پرسش شروع میشود: «واقعاً چه چیزهایی باید دیده و اندازهگیری شوند؟» وقتی Monitorها، Userها، Edition و Add-onها شفاف باشند، مقایسه Quoteها معنیدار میشود و احتمال خرید اضافه یا کمبود ظرفیت کاهش پیدا میکند.
