وقتی یک وبسایت یا سامانه سازمانی روی IIS اجرا میشود، صرف Up بودن Windows Server برای اطمینان از سلامت سرویس کافی نیست. ممکن است Server روشن باشد اما Application Pool متوقف شده باشد، Response Time بالا رفته باشد، تعداد Connectionها غیرعادی شده باشد یا Website با Response Code نامناسب پاسخ دهد. Applications Manager برای این سناریو IIS Monitor مستقل دارد و میتواند وضعیت Web Server، Website و Application Pool را در یک مسیر متمرکز پایش کند.
این راهنما بر اساس مستند رسمی ManageEngine نوشته شده و مسیر افزودن IIS Server Monitor را با پیشنیازهای WMI/WinRM، تنظیم SSL، Credential، Response Code Check، Polling Interval، Monitor Group و Verify اولیه پوشش میدهد.
سناریوی واقعی
فرض کنید سامانه ERP داخلی شرکت روی IIS نصب شده و کاربران بعضی صبحها از کندی یا خطای Login شکایت میکنند. تیم زیرساخت فقط CPU و Memory سرور را مانیتور میکند و در زمان رخداد معمولاً سیستمعامل سالم است. مشکل واقعی ممکن است در Application Pool، تعداد Connection، Response Time یا خود Website باشد. با IIS Monitor میتوان این لایه را جداگانه زیر مانیتورینگ برد.
پیشنیازها قبل از Add Monitor
ManageEngine تأکید میکند URL مربوط به IIS باید از Server نصبشده Applications Manager قابل دسترس باشد، چون محصول Response را بررسی میکند. برای جمعآوری Statistics مربوط به Website و Application Pool نیز Credential و مسیر Remote Management باید درست باشد.
| مورد | توضیح |
|---|---|
| URL/Host قابل دسترس | Applications Manager باید بتواند http(s)://Host:Port را Reach کند |
| Credential معتبر | برای خواندن Website و Application Pool Statistics |
| WMI یا WinRM | روش ارتباط مدیریتی با Windows Server |
| پورت Web | پورت واقعی IIS، مثلاً 80/443 یا Custom Port |
| Monitor Group | اختیاری اما برای محیط Production توصیه میشود |
WMI یا WinRM؟
در هنگام ساخت Monitor میتوانید Mode را بین WMI و WinRM انتخاب کنید. طبق مستند رسمی، WinRM در Applications Manager نسخه 16820 و بالاتر پشتیبانی میشود. اگر نسخه شما قدیمیتر است، قبل از طراحی روی WinRM باید Build را بررسی کنید.
پورتهای مهم WMI
برای WMI، ManageEngine دسترسی به TCP 445 برای WMI/SMB، TCP 135 برای RPC و پورتهای Dynamic مربوط به DCOM را بهعنوان پیشنیاز ذکر میکند. در محیطهای سختگیرانه، باز کردن Range گسترده بدون طراحی Firewall مناسب توصیه نمیشود؛ باید دقیقاً با معماری امنیتی Windows و Policy سازمان هماهنگ شود.
پورتهای WinRM
در WinRM، HTTP بهصورت پیشفرض روی 5985 و HTTPS روی 5986 استفاده میشود. Applications Manager امکان Custom WinRM Port را نیز فراهم میکند.
مرحله ۱: New Monitor را باز کنید
در Applications Manager روی New Monitor کلیک کنید و از فهرست Monitorها گزینه IIS Server را انتخاب کنید.
اگر چند Monitor مشابه دارید، از همین ابتدا Display Name استانداردی تعریف کنید؛ مثلاً IIS-ERP-PROD-01. نامهای مبهم مثل IIS1 یا Server-Web در Dashboard و Alertها بعداً دردسر ایجاد میکنند.
مرحله ۲: Host و Port را وارد کنید
در فیلدهای مربوطه Display Name، IP Address یا Hostname و Port را وارد کنید. اگر IIS روی SSL کار میکند، گزینه SSL را فعال کنید.
Port باید همان پورتی باشد که Monitor واقعاً از طریق آن به IIS متصل میشود. در محیطی که Website روی 443 و Bindings چندگانه دارد، قبل از Add Monitor از Server Applications Manager یک تست Reachability و HTTP/HTTPS انجام دهید.
مرحله ۳: Mode of Monitoring را انتخاب کنید
WMI یا WinRM را متناسب با Policy شبکه انتخاب کنید. اگر WinRM انتخاب شده است، Protocol را هم مشخص کنید و در صورت نیاز Custom WinRM Port را فعال کنید.
انتخاب Mode فقط موضوع Preference نیست؛ اگر Firewall بین Applications Manager و IIS سختگیرانه است، WinRM HTTPS معمولاً مسیر مدیریتی قابل کنترلتری ایجاد میکند، ولی باید Build محصول، WinRM Configuration و Certificate/Policy محیط بررسی شود.
مرحله ۴: Credential را تنظیم کنید
برای Versionهای جدید Applications Manager، Credential مربوط به IIS هنگام Add/Edit خود IIS Monitor وارد میشود. ManageEngine در مستند پیشنیازها توضیح میدهد که از نسخه 15120 به بعد، Credential مربوط به IIS Server برای Website و Application Pool Statistics در همین Monitor لازم است.
حساب مورد استفاده باید فقط دسترسی لازم برای مانیتورینگ داشته باشد. دادن Domain Admin صرفاً برای اینکه Monitor سریع کار کند، الگوی مناسبی برای Production نیست. ابتدا Requirement واقعی WMI/WinRM را تأمین کنید و بعد حداقل دسترسی را اعمال کنید.
مرحله ۵: Response Code Check را آگاهانه فعال کنید
Applications Manager گزینه Enable Response Code Check دارد. این گزینه بهصورت پیشفرض غیرفعال است. اگر فعال شود، Response Codeهای بزرگتر از صفر و کمتر از 400 معتبر تلقی میشوند.
این کنترل برای Websiteهایی مفید است که Up بودن TCP کافی نیست. مثلاً اگر Application بهجای صفحه سالم 500 برگرداند، Response Code Check کمک میکند خطا زودتر دیده شود. اما اگر Endpoint شما عمداً Redirect یا رفتار خاصی دارد، قبل از فعالسازی باید Response واقعی آن را در نظر بگیرید.
مرحله ۶: Polling Interval را تنظیم کنید
Polling Interval را بر اساس اهمیت سرویس و ظرفیت مانیتورینگ انتخاب کنید. فاصله خیلی کوتاه برای صدها IIS Server میتواند Load غیرضروری بسازد و فاصله خیلی بلند ممکن است اختلال کوتاه اما مهم را پنهان کند.
برای سرویسهای حیاتی، Polling باید با SLA و Alerting هماهنگ باشد. برای سرویس آزمایشی یا کماهمیت میتوان Interval طولانیتر در نظر گرفت.
مرحله ۷: Monitor Group را انتخاب کنید
اگر از Central Server استفاده میکنید، Probe Server مربوطه را انتخاب کنید. سپس در صورت نیاز Monitor را به یک یا چند Monitor Group متصل کنید.
برای محیط واقعی بهتر است IIS Monitor تنها نماند. آن را در Group سرویس قرار دهید؛ مثلاً ERP شامل IIS، SQL Server، URL Monitor و Server Monitor باشد. در این حالت Alarmها و Dashboardها از دید سرویس خواناتر میشوند.
مرحله ۸: Add Monitor(s) و Discovery
روی Add Monitor(s) کلیک کنید. Applications Manager IIS Server را Discover کرده و Monitoring را آغاز میکند.
بعد از Add موفق، کار تمام نشده است. باید داده واقعی را Verify کنید.
مرحله ۹: Verify اولیه را انجام دهید
به Monitors بروید و از Category مربوط به Web Server / Services، IIS Server را باز کنید. Availability و دادههای مربوط به IIS را بررسی کنید.
حداقل کنترلهای Verify
- Availability Monitor سبز است.
- Response Time عدد منطقی دارد.
- Website موردنظر دیده میشود.
- Application Poolها در صورت پشتیبانی و Credential صحیح نمایش داده میشوند.
- Connection و Traffic Metricها Data Point میگیرند.
- اگر Response Code Check فعال است، Status مطابق پاسخ واقعی Website است.
مرحله ۱۰: یک Fault کنترلشده تست کنید
در محیط Pilot، اگر امکان دارد یک Application Pool آزمایشی یا Website غیرProduction را برای مدت کوتاه Stop کنید و ببینید Monitor چه رفتاری دارد. هدف این نیست که سرویس Production را مختل کنید؛ هدف این است که قبل از وابستگی عملیاتی، Alarm Path را Verify کنید.
بعد از بازگرداندن سرویس، Recovery را هم بررسی کنید. Monitor خوب باید هم Fault و هم Clear شدن Fault را درست نشان دهد.
خطاهای رایج و مسیر Troubleshooting
| نشانه | بررسی اول | احتمال رایج |
|---|---|---|
| IIS Monitor Add نمیشود | URL Reachability | Host/Port/SSL یا Firewall |
| Server Up است ولی Poolها دیده نمیشوند | Credential و WMI/WinRM | دسترسی Remote Management ناقص |
| WinRM کار نمیکند | Build و Port | نسخه پایینتر از 16820 یا Config WinRM |
| Response Code نامعتبر است | URL واقعی | Application Error یا Redirect/Binding اشتباه |
| Data Gap وجود دارد | Polling و Network | قطع ارتباط یا Credential intermittent |
چه چیزی را مانیتور کنیم؟
خود IIS Monitor میتواند Visibility روی Response Time، Connection Statistics، Data/File Transaction Rate و Website/Application Pool ایجاد کند. اما برای Root Cause کامل، معمولاً باید Monitoring لایههای دیگر را هم در کنار آن قرار دهید.
اگر Backend دیتابیس است، مقاله مانیتورینگ SQL Server با Applications Manager مکمل مناسبی است. برای معماری کلی Monitor Group و Alarm نیز راهنمای ادمین Applications Manager را ببینید.
اگر سازمان چند IIS Farm، Load Balancer و Backend Database دارد، بهتر است Monitorها بهصورت Service Model کنار هم طراحی شوند. صفحه Applications Manager مدانت برای بررسی استقرار، لایسنس و پشتیبانی این معماری مناسب است؛ تصمیم خرید یا توسعه Scope باید بر اساس تعداد Monitor و سناریوی واقعی انجام شود، نه صرفاً تعداد Server.
چکلیست نهایی
- URL از Applications Manager قابل دسترس است.
- Port و SSL مطابق Binding واقعی IIS است.
- WMI یا WinRM بر اساس Build و Policy انتخاب شده است.
- Credential با حداقل دسترسی لازم تست شده است.
- Response Code Check در صورت نیاز فعال شده است.
- Polling Interval منطقی است.
- Monitor Group و Probe درست انتخاب شدهاند.
- Website و Application Pool Data Verify شدهاند.
- یک Fault آزمایشی کمریسک برای Alert Verification انجام شده است.
سخن پایانی
مانیتورینگ IIS زمانی مفید است که از «Server Up/Down» عبور کند و سلامت واقعی Website و Application Pool را ببیند. اگر Connectivity، Credential و Mode of Monitoring از ابتدا درست طراحی شوند، Applications Manager میتواند قبل از شکایت کاربر نشانههای خرابی Web Layer را نشان دهد و مسیر Root Cause را کوتاهتر کند.
منابع
- ManageEngine Applications Manager — IIS Server Monitoring
- ManageEngine Applications Manager — Monitoring Prerequisites
