آشنایی کامل با Netwatch در RouterOS v7 میکروتیک؛ آموزش مانیتورینگ هوشمند و مدیریت خودکار شبکه

Netwatch در میکروتیک چیست و چگونه کار می‌کند؟

Netwatch ابزاری برای نظارت بر وضعیت یک مقصد یا سرویس مشخص در شبکه است. هر ورودی Netwatch یک Probe مستقل محسوب می‌شود که می‌تواند با فاصله زمانی تعیین‌شده، وضعیت مقصد را آزمایش کند.

برای مثال، مدیر شبکه می‌تواند Netwatch را به‌گونه‌ای پیکربندی کند که هر 30 ثانیه وضعیت یک مقصد مشخص در اینترنت را بررسی کند.

در صورت تغییر وضعیت ارتباط، Netwatch می‌تواند رویداد را در Log ثبت کند یا اسکریپتی برای انجام یک عملیات مشخص اجرا کند.

Netwatch چه کاربردهایی دارد؟

• بررسی وضعیت دسترسی به اینترنت
• مانیتورینگ روترها، سرورها و تجهیزات شبکه
• بررسی پاسخ‌گویی پورت‌های TCP
• شناسایی اختلال در سرویس وب
• پایش عملکرد DNS Server
• کنترل Packet Loss و Jitter
• اجرای Script هنگام قطع و وصل ارتباط
• کمک به مدیریت Failover بین دو اینترنت
• ثبت رویدادها و ارسال هشدار در صورت پیکربندی سرویس اطلاع‌رسانی

مفهوم وضعیت‌های Unknown، Up و Down

Netwatch برای هر Probe سه وضعیت اصلی دارد:

بنابراین وضعیت Up همیشه به معنی سالم بودن کامل سرویس نیست؛ بلکه نشان می‌دهد Probe انتخاب‌شده موفق بوده است.

برای مثال، موفق بودن Ping لزوماً به معنای سالم بودن وب‌سایت، دیتابیس یا سرویس VPN نیست.

Netwatch جدید در RouterOS v7 چه تفاوتی با نسخه قدیمی دارد؟

توسعه اصلی Netwatch از نسخه RouterOS 7.4 آغاز شد. در نسخه‌های قدیمی‌تر، این ابزار عمدتاً از بررسی ساده ICMP استفاده می‌کرد.

در نسخه‌های جدید، Netwatch امکان تحلیل شاخص‌های ارتباطی، بررسی پروتکل‌های مختلف و تعریف Thresholdهای متنوع را فراهم می‌کند.

آشنایی با شش نوع Probe در Netwatch جدید

Netwatch در RouterOS 7 از شش نوع Probe پشتیبانی می‌کند:

۱. Simple Probe؛ بررسی دسترسی با Ping

در حالت Simple، روتر یک ICMP Echo Request ارسال می‌کند و دریافت پاسخ را بررسی می‌کند.

این روش برای سناریوهایی که صرفاً دسترسی به یک Host اهمیت دارد، ساده و کم‌هزینه است.

مثال تنظیم:

/tool/netwatch/add \
 name="Internet-Simple" \
 host=8.8.8.8 \
 type=simple \
 interval=30s \
 timeout=3s \
 up-script=":log info \"Internet UP\"" \
 down-script=":log warning \"Internet DOWN\""

در این نمونه، وضعیت مقصد 8.8.8.8 هر 30 ثانیه بررسی می‌شود.

پس از تغییر وضعیت، پیام مناسب در Log روتر ثبت خواهد شد.

۲. ICMP Probe؛ مانیتورینگ پیشرفته کیفیت شبکه

یکی از مهم‌ترین قابلیت‌های Netwatch جدید، Probe پیشرفته ICMP است.

برخلاف حالت Simple، این روش چندین بسته ICMP ارسال می‌کند و کیفیت ارتباط را بر اساس شاخص‌های مختلف ارزیابی می‌کند.

شاخص‌های قابل اندازه‌گیری

• RTT: زمان رفت‌وبرگشت بسته بین مبدأ و مقصد
• Packet Loss: درصد یا تعداد بسته‌های بدون پاسخ
• Jitter: تغییرات تأخیر بسته‌ها
• RTT Average: میانگین زمان رفت‌وبرگشت
• RTT Maximum: بیشترین مقدار RTT
• RTT Standard Deviation: پراکندگی زمان پاسخ‌ها

در Netwatch، مقدار rtt-jitter بر اساس اختلاف بیشترین و کمترین RTT محاسبه می‌شود. این تعریف الزاماً با روش‌های محاسبه Jitter در RTP یا VoIP یکسان نیست.

پارامترهای مهم ICMP Probe

مثال عملی: بررسی Packet Loss

فرض کنید می‌خواهیم کیفیت یک ارتباط را با پنج Ping در هر آزمایش بررسی کنیم و در صورت عبور Packet Loss از 40 درصد، آن را ناموفق بدانیم.

/tool/netwatch/add \
 name="WAN-Quality" \
 host=8.8.8.8 \
 type=icmp \
 interval=20s \
 packet-count=5 \
 packet-interval=100ms \
 thr-loss-percent=40% \
 thr-avg=500ms \
 thr-max=2s \
 thr-jitter=2s \
 thr-stdev=1s \
 down-script=":log warning \"WAN quality failed\"" \
 up-script=":log info \"WAN quality restored\""

در این مثال، پنج بسته ICMP در هر دوره ارسال می‌شوند. بیش از 40 درصد Packet Loss می‌تواند Probe را ناموفق کند.

مقادیر RTT و Jitter نیز در تصمیم نهایی تأثیر دارند. بنابراین این تنظیم صرفاً یک آزمایش Packet Loss نیست، بلکه چندین معیار را هم‌زمان بررسی می‌کند.

Early Failure Detection چیست؟

در Netwatch جدید دو گزینه با نام‌های زیر وجود دارند:

• early-failure-detection
• early-success-detection

این قابلیت‌ها به Netwatch اجازه می‌دهند زمانی که نتیجه نهایی بر اساس تعداد بسته‌های ارسال‌شده دیگر قابل تغییر نیست، پیش از اتمام کل مجموعه Pingها وضعیت را مشخص کند.

کاربرد اصلی آن‌ها در ترکیب با Threshold تعداد بسته‌های ازدست‌رفته thr-loss-count است.

در نتیجه، برای مانیتورینگ حساس می‌توان مدت تشخیص بعضی خطاها را کاهش داد.

۳. TCP-Conn Probe؛ بررسی سرویس‌ها بر اساس پورت TCP

در بسیاری از مواقع، پاسخ دادن یک سرور به Ping به معنی فعال بودن سرویس‌های آن نیست.

برای مثال ممکن است یک سرور Linux روشن باشد، اما سرویس SSH یا وب‌سرور آن متوقف شده باشد.

با tcp-conn می‌توان بررسی کرد آیا اتصال TCP به پورت موردنظر قابل برقراری است یا خیر.

مثال: مانیتورینگ SSH Server

فرض کنید یک سرور داخلی با آدرس 192.168.10.10 داریم.

برای بررسی پورت 22 آن:

/tool/netwatch/add \
 name="SSH-Monitor" \
 host=192.168.10.10 \
 type=tcp-conn \
 port=22 \
 interval=30s \
 down-script=":log warning \"SSH TCP port unavailable\"" \
 up-script=":log info \"SSH TCP port reachable\""

این Probe تلاش می‌کند TCP Three-Way Handshake را با مقصد انجام دهد.

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

کاربردهای TCP Probe

• مانیتورینگ SSH روی پورت 22
• بررسی اتصال TCP به سرویس HTTPS روی 443
• بررسی دسترسی به SQL Server روی پورت 1433
• بررسی MySQL روی پورت 3306
• مانیتورینگ سرویس‌های TCP اختصاصی سازمان

۴. HTTP-GET و HTTPS-GET؛ مانیتورینگ سرویس وب

در بسیاری از شبکه‌های سازمانی، بررسی Ping یا باز بودن پورت TCP برای سنجش سلامت یک وب‌سرویس کافی نیست.

Netwatch جدید امکان ارسال درخواست HTTP GET و HTTPS GET و بررسی کد پاسخ دریافتی را فراهم می‌کند.

HTTP Probe چگونه کار می‌کند؟

این Probe درخواست GET را به سرویس موردنظر ارسال می‌کند و کد وضعیت HTTP و زمان پاسخ را بررسی می‌کند.

برای مثال:

• کد 200 معمولاً نشان‌دهنده پاسخ موفق است.
• کد 301 یا 302 معمولاً به Redirect اشاره دارد.
• کد 404 نشان می‌دهد Resource موردنظر پیدا نشده است.
• کد 500 معمولاً مربوط به خطای سمت سرور است.

پارامتر http-codes در RouterOS 7.26

در مستندات جدید MikroTik، پارامتر http-codes برای تعیین کدهای قابل‌قبول HTTP استفاده می‌شود.

محدوده پیش‌فرض آن 100-299 است.

بنابراین اگر سرویس HTTP پاسخ Redirect با کد 301 یا 302 برگرداند، ممکن است Probe با وجود قابل‌دسترس بودن سرویس، وضعیت Down دریافت کند.

در صورت نیاز می‌توان محدوده را به شکل زیر تغییر داد:

http-codes=100-399

البته پذیرفتن همه Redirectها برای هر نوع مانیتورینگ مناسب نیست. اگر قرار است سلامت یک API بررسی شود، ممکن است صرفاً پاسخ 200 معیار صحیح‌تری باشد.

مثال: مانیتورینگ HTTP Server داخلی

فرض کنید یک وب‌سرور داخلی با IP برابر 192.168.10.20 روی پورت 80 فعال است.

/tool/netwatch/add \
 name="Web-HTTP-Monitor" \
 host=192.168.10.20 \
 type=http-get \
 port=80 \
 interval=30s \
 http-codes=200-299 \
 thr-http-time=5s \
 down-script=":log warning \"HTTP service failed\"" \
 up-script=":log info \"HTTP service restored\""

در این سناریو، دریافت پاسخ موفق HTTP در زمان مجاز، معیار سلامت سرویس خواهد بود.

HTTPS-GET چه تفاوتی دارد؟

HTTPS-GET مشابه HTTP-GET عمل می‌کند، اما ارتباط بر بستر HTTPS برقرار می‌شود.

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

• port: پورت مقصد که معمولاً 443 است.
• check-certificate: فعال‌سازی اعتبارسنجی زنجیره گواهی
• certificate: تنظیمات گواهی مرتبط با Probe
• thr-http-time: حداکثر زمان پاسخ قابل‌قبول

در مستندات جدید، حالت پیش‌فرض check-certificate=no است.

۵. DNS Probe؛ بررسی عملکرد سرویس DNS

یکی دیگر از قابلیت‌های مهم Netwatch جدید، امکان مانیتورینگ DNS Server است.

در این روش، Netwatch یک DNS Query ارسال می‌کند و بررسی می‌کند آیا رکورد موردنظر دریافت می‌شود یا خیر.

این قابلیت زمانی مفید است که اینترنت برقرار باشد اما کاربران به دلیل اختلال DNS نتوانند نام دامنه‌ها را Resolve کنند.

رکوردهای پشتیبانی‌شده

مثال عملی: مانیتورینگ DNS گوگل

/tool/netwatch/add \
 name="DNS-Monitor" \
 host=mikrotik.com \
 type=dns \
 dns-server=8.8.8.8 \
 record-type=A \
 interval=30s \
 down-script=":log warning \"DNS resolution failed\"" \
 up-script=":log info \"DNS resolution restored\""

در این مثال Netwatch از DNS Server با آدرس 8.8.8.8 می‌خواهد رکورد A دامنه mikrotik.com را Resolve کند.

اگر پاسخ معتبر دریافت شود، Probe می‌تواند وضعیت Up داشته باشد.

اگر DNS Server پاسخ ندهد یا رکورد موردنظر قابل دریافت نباشد، Probe ناموفق خواهد بود.

پارامترهای مهم Netwatch در RouterOS 7

علاوه بر گزینه‌های اختصاصی هر Probe، تعدادی پارامتر عمومی برای کنترل زمان‌بندی، رفتار و اسکریپت‌ها وجود دارد.

تفاوت Interval و Timeout

پارامتر interval فاصله زمانی آزمایش‌ها را مشخص می‌کند؛ درحالی‌که timeout مدت انتظار برای دریافت پاسخ را محدود می‌کند.

برای مثال:

interval=20s
timeout=3s

در این حالت Probe به‌صورت دوره‌ای اجرا می‌شود و برای دریافت پاسخ، محدودیت زمانی مشخصی دارد.

در ICMP پیشرفته، اگر تعداد بسته‌ها و مدت موردنیاز آزمایش از Interval بیشتر شود، RouterOS ممکن است فاصله عملی آزمایش‌ها را افزایش دهد و هشدار مربوط به Packet Train ثبت کند.

Start Delay و Startup Delay

start-delay در مستندات جدید به‌صورت پیش‌فرض 3 ثانیه است.

startup-delay نیز به‌صورت پیش‌فرض 5 دقیقه تعیین شده است.

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

پشتیبانی از VRF و IPv6

Netwatch جدید امکان کار با آدرس‌هایی همراه شناسه VRF و آدرس‌های IPv6 را فراهم می‌کند.

نمونه قالب آدرس با VRF:

192.0.2.1@customer-vrf

و برای IPv6 Link-Local همراه با رابط:

fe80::1%ether1

این قابلیت برای شبکه‌های چندمشتری، سناریوهای VRF و زیرساخت‌های IPv6 اهمیت دارد.

آموزش راه‌اندازی Netwatch از طریق WinBox

برای استفاده از Netwatch نیازی نیست حتماً از Terminal استفاده کنید. تنظیمات اصلی از محیط WinBox نیز در دسترس هستند.

مرحله اول: ورود به Netwatch

1. به روتر MikroTik متصل شوید.
2. از منوی اصلی وارد Tools شوید.
3. گزینه Netwatch را انتخاب کنید.
4. برای اضافه کردن Probe جدید، دکمه افزودن را بزنید.

مرحله دوم: تعریف مقصد و نوع Probe

در پنجره تنظیمات، اطلاعات زیر را وارد کنید:

• Host: آدرس مقصد
• Type: نوع Probe
• Interval: فاصله زمانی بررسی
• Timeout: زمان انتظار پاسخ

برای مثال، یک Probe پیشرفته ICMP می‌تواند برای بررسی 8.8.8.8 تعریف شود.

مرحله سوم: تنظیم Thresholdها

با انتخاب ICMP پیشرفته، گزینه‌هایی برای تعیین Packet Count، RTT و Packet Loss در دسترس قرار می‌گیرند.

این مقادیر را با توجه به کیفیت طبیعی لینک تنظیم کنید. برای مثال، RTT مناسب یک لینک داخلی دیتاسنتر ممکن است با یک لینک بین‌المللی یا ارتباط ماهواره‌ای کاملاً متفاوت باشد.

مرحله چهارم: تعریف Up و Down Script

در قسمت Script می‌توانید دستورات موردنظر را برای زمان تغییر وضعیت وارد کنید.

نمونه Up Script:

:log info "Connection restored"

نمونه Down Script:

:log warning "Connection lost"

مرحله پنجم: بررسی نتایج

پس از ذخیره Probe، وضعیت آن را در پنجره Netwatch بررسی کنید.

بسته به نوع Probe می‌توانید اطلاعاتی مانند وضعیت، زمان آخرین تغییر، Packet Loss یا زمان پاسخ را مشاهده کنید.

آموزش Up Script، Down Script و Test Script در Netwatch

یکی از قابلیت‌های اصلی Netwatch، اجرای خودکار دستورات RouterOS هنگام رویدادهای شبکه است.

Up Script چه زمانی اجرا می‌شود؟

زمانی که Probe از Down به Up تغییر وضعیت می‌دهد، Up Script اجرا می‌شود.

برای مثال می‌توان بازگشت ارتباط اینترنت را در Log ثبت کرد.

Down Script چه زمانی اجرا می‌شود؟

هنگامی که Probe از Up به Down تغییر وضعیت می‌دهد، Down Script اجرا خواهد شد.

از این قابلیت می‌توان برای ثبت هشدار، تغییر مسیر یا اجرای عملیات مدیریتی کنترل‌شده استفاده کرد.

Test Script چیست؟

برخلاف Up و Down Script که به تغییر وضعیت وابسته‌اند، Test Script پس از هر آزمایش اجرا می‌شود.

برای مثال می‌توان از آن برای ثبت نتایج دوره‌ای در یک سیستم مانیتورینگ استفاده کرد.

متغیرهای داخلی Netwatch

Netwatch به اسکریپت‌ها امکان دسترسی به اطلاعات Probe را می‌دهد.

برخی متغیرهای مهم عبارت‌اند از:

برای استفاده از متغیرهایی که در نام آن‌ها خط تیره وجود دارد، باید از ساختار $"variable-name" استفاده کرد.

مثال Test Script با متغیرهای ICMP

نمونه زیر را می‌توان در فیلد Test Script یک ICMP Probe در محیط WinBox وارد کرد:

:log info ("Host: " . $host)
:log info ("Status: " . $status)
:log info ("Average RTT (us): " . $"rtt-avg")
:log info ("Packet Loss (%): " . $"loss-percent")

بر اساس مستندات جدید، مقادیر RTT در محیط Script بر حسب میکروثانیه ارائه می‌شوند؛ بنابراین هنگام مقایسه یا نمایش آن‌ها، واحد اندازه‌گیری را در نظر بگیرید.

Ignore Initial Up و Down

Netwatch دارای دو پارامتر دیگر برای کنترل اجرای Script در اولین تغییر وضعیت است:

• ignore-initial-up
• ignore-initial-down

برای مثال، با فعال کردن ignore-initial-down، تغییر اولیه از Unknown به Down باعث اجرای Down Script نخواهد شد.

این قابلیت می‌تواند از برخی واکنش‌های اشتباه هنگام شروع مانیتورینگ جلوگیری کند.

سناریوی عملی: استفاده از Netwatch برای Failover دو اینترنت

یکی از کاربردهای مهم Netwatch در شبکه‌های سازمانی، کمک به مدیریت خودکار ارتباطات WAN است.

فرض کنید یک سازمان دو سرویس اینترنت دارد:

• WAN1: اینترنت اصلی
• WAN2: اینترنت پشتیبان

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

پس از بازیابی ارتباط WAN1، مسیر اصلی دوباره فعال خواهد شد.

مرحله اول: طراحی مسیرها

فرض کنید در محیط آزمایشگاهی Gatewayهای زیر را داریم:

• WAN1 Gateway: 192.0.2.1
• WAN1 Router IP: 192.0.2.2
• WAN2 Gateway: 198.51.100.1

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

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

/ip/route/add \
 dst-address=0.0.0.0/0 \
 gateway=192.0.2.1 \
 distance=1 \
 comment="BISTOON-WAN1-PRIMARY"

/ip/route/add \
 dst-address=0.0.0.0/0 \
 gateway=198.51.100.1 \
 distance=2 \
 comment="BISTOON-WAN2-BACKUP"

در این طراحی، WAN1 اولویت بالاتری دارد؛ زیرا Distance آن کمتر است.

مرحله دوم: ثابت نگه داشتن مسیر Probe

یکی از اشتباهات مهم در Netwatch Failover این است که پس از غیرفعال شدن مسیر WAN1، Probe از طریق WAN2 به مقصد برسد.

در چنین وضعیتی ممکن است Netwatch به‌اشتباه تصور کند WAN1 دوباره فعال شده است.

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

برای مثال، در آزمایشگاه می‌توان یک Host Route مخصوص 8.8.8.8 تعریف کرد:

/ip/route/add \
 dst-address=8.8.8.8/32 \
 gateway=192.0.2.1 \
 distance=1 \
 comment="BISTOON-WAN1-CHECK"

همچنین می‌توان یک مسیر Blackhole با Distance بالاتر برای همین مقصد در نظر گرفت تا هنگام غیرفعال شدن مسیر مستقیم WAN1، ترافیک آزمایش از WAN2 عبور نکند.

/ip/route/add \
 dst-address=8.8.8.8/32 \
 blackhole \
 distance=254 \
 comment="BISTOON-WAN1-BLACKHOLE"

نتیجه نهایی باید با جدول Routing واقعی، وضعیت Gateway و Routing Tableهای مورد استفاده آزمایش شود.

مرحله سوم: ایجاد Probe مربوط به WAN1

در این مرحله یک ICMP Probe برای نظارت بر کیفیت مسیر WAN1 تعریف می‌کنیم.

/tool/netwatch/add \
 name="WAN1-Health" \
 host=8.8.8.8 \
 type=icmp \
 src-address=192.0.2.2 \
 interval=20s \
 packet-count=5 \
 thr-loss-percent=60% \
 thr-avg=500ms \
 thr-max=2s \
 thr-jitter=2s \
 thr-stdev=1s \
 startup-delay=2m \
 ignore-initial-up=no \
 ignore-initial-down=no \
 down-script="/ip route disable [find where comment=\"BISTOON-WAN1-PRIMARY\"]" \
 up-script="/ip route enable [find where comment=\"BISTOON-WAN1-PRIMARY\"]"

در این نمونه، هنگام ناموفق شدن Probe، مسیر اصلی با Comment مشخص غیرفعال می‌شود.

پس از بازیابی وضعیت Up، همان مسیر دوباره فعال خواهد شد.

برای بررسی مسیرهای مربوط:

/ip/route/print detail \
 where comment~"BISTOON-WAN1"

و برای بررسی وضعیت Netwatch:

/tool/netwatch/print stats

نکات مهم در Failover عملیاتی

• تست چند مقصد: قطع پاسخ یک IP عمومی لزوماً به معنای قطع کل اینترنت نیست.
• جلوگیری از Flapping: Thresholdها باید طوری تنظیم شوند که افت مقطعی کیفیت موجب تغییر مسیر پیاپی نشود.
• مسیر مستقل Probe: بررسی WAN1 نباید پس از Failover ناخواسته از WAN2 انجام شود.
• تست بعد از بوت: رفتار اولیه Netwatch و Routeها باید بررسی شود.
• سازگاری با Routing: در شبکه‌های دارای PCC، VRF یا چند Routing Table، منطق انتخاب مسیر پیچیده‌تر از مثال بالا است.

برای آشنایی بیشتر با طراحی ارتباطات چند WAN، مقاله آموزش Load Balancing و Failover دو اینترنت در میکروتیک را نیز می‌توانید مطالعه کنید.

محدودیت‌ها و نکات امنیتی اجرای Script در Netwatch

یکی از مهم‌ترین موضوعات هنگام استفاده حرفه‌ای از Netwatch جدید، آشنایی با محدودیت‌های اجرای Script است.

طبق مستندات رسمی MikroTik، اسکریپت‌های Netwatch توسط کاربر داخلی *sys اجرا می‌شوند.

همچنین Netwatch در حالت عادی به Policyهای زیر محدود است:

• read
• write
• test
• reboot

اگر Script به مجوزهایی خارج از این محدوده نیاز داشته باشد، ممکن است به دلیل محدودیت Permission اجرا نشود.

آیا می‌توان محدودیت Permission را غیرفعال کرد؟

در RouterOS برای Scriptهای سیستمی امکان استفاده از تنظیماتی مانند dont-require-permissions وجود دارد.

اما این قابلیت کنترل مجوز اجرای Script را تغییر می‌دهد و ممکن است سطح خطر امنیتی را افزایش دهد.

Global Variable در Netwatch

یکی دیگر از نکات مهم این است که Scriptهای Netwatch در محیط اجرایی داخلی خود اجرا می‌شوند.

Global Variable تعریف‌شده در یک Netwatch Script الزاماً از Scheduler یا Script کاربران دیگر قابل مشاهده نیست.

بنابراین برای تبادل وضعیت میان بخش‌های مختلف اتوماسیون، نباید بدون طراحی مشخص به Global Variable تکیه کرد.

عیب‌یابی Netwatch در RouterOS 7

اگر Probe مطابق انتظار عمل نمی‌کند، بهتر است از یک فرآیند عیب‌یابی مرحله‌ای استفاده کنید.

مرحله اول: بررسی وضعیت و آمار

/tool/netwatch/print detail
/tool/netwatch/print stats

در خروجی، به پارامترهای زیر توجه کنید:

• Status
• Since
• Done Tests
• Failed Tests
• Loss Percent
• RTT Average
• HTTP Status Code

مقادیر آماری وابسته به نوع Probe هستند؛ مثلاً در TCP-Conn مقدار زمان اتصال و در HTTP وضعیت پاسخ سرویس اهمیت دارد.

مرحله دوم: بررسی Log

/log/print where topics~"netwatch"

برای مشاهده جزئیات بیشتر می‌توان Logging مخصوص Netwatch را با سطح Debug تنظیم کرد.

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

مرحله سوم: بررسی Thresholdها

گاهی Probe وضعیت Down دارد، اما مقصد به Ping پاسخ می‌دهد.

در این حالت ممکن است میانگین RTT، Packet Loss یا Jitter از Threshold تعریف‌شده عبور کرده باشد.

بنابراین نتیجه آزمایش را با مقادیر Threshold مقایسه کنید.

مرحله چهارم: بررسی Source Address

اگر برای Probe گزینه src-address تعیین شده است، مطمئن شوید آدرس موردنظر روی روتر وجود دارد.

در صورت حذف یا از دسترس خارج شدن این آدرس، ممکن است Probe وضعیت Down دریافت کند.

مرحله پنجم: بررسی Route و Firewall

وجود Route صحیح برای دسترسی به مقصد ضروری است.

همچنین Firewall نباید به‌صورت ناخواسته ترافیک Probe یا پاسخ‌های موردنیاز آن را مسدود کند.

مرحله ششم: بررسی Script Permissions

اگر وضعیت Probe تغییر می‌کند اما Script اجرا نمی‌شود، مجوزهای اجرای Script را بررسی کنید.

همچنین دستورات Script را جداگانه، در یک محیط کنترل‌شده آزمایش کنید.

جدول عیب‌یابی سریع

بهترین روش‌های استفاده از Netwatch در شبکه‌های سازمانی

1. Probe متناسب با سرویس انتخاب کنید. برای دسترسی عمومی ICMP، برای سرویس TCP از TCP-Conn، و برای سرویس وب از HTTP/HTTPS استفاده کنید.
2. Thresholdها را بر اساس کیفیت واقعی لینک تعیین کنید. مقادیر مناسب برای دیتاسنتر ممکن است با لینک وایرلس یا اینترنت بین‌المللی متفاوت باشد.
3. از مانیتورینگ چندلایه استفاده کنید. Up بودن یک IP به معنای عملکرد صحیح تمام سرویس‌ها نیست.
4. قبل از اجرای Scriptهای مدیریتی، ابتدا Log تهیه کنید. منطق Automation باید در محیط کنترل‌شده آزمایش شود.
5. برای Failover از طراحی صحیح Routing استفاده کنید. تشخیص قطعی و تغییر مسیر باید به‌صورت هماهنگ طراحی شوند.
6. امنیت Scriptها را جدی بگیرید. از مجوزهای اضافی و دستورات غیرضروری خودداری کنید.
7. مانیتورینگ بلندمدت را جداگانه طراحی کنید. Netwatch ابزار سبک پایش و Automation است و به‌تنهایی جایگزین سامانه‌های کامل NMS و گزارش‌گیری تاریخی نیست.

برای مدیریت و مانیتورینگ متمرکز تعداد بیشتری از تجهیزات MikroTik، می‌توانید مقاله آشنایی با CMR و مدیریت متمرکز RouterOS را نیز مطالعه کنید.

سؤالات متداول درباره Netwatch در RouterOS 7

جمع‌بندی: آیا Netwatch جدید ارزش استفاده دارد؟

Netwatch در RouterOS 7 از یک ابزار ساده مبتنی بر Ping به ابزاری کاربردی‌تر برای پایش سرویس‌ها و اجرای اتوماسیون شبکه تبدیل شده است.

پشتیبانی از ICMP پیشرفته، TCP Connection، HTTP، HTTPS و DNS باعث می‌شود مدیر شبکه بتواند وضعیت ارتباطات و سرویس‌ها را با دقت بیشتری بررسی کند.

همچنین امکان تعریف Thresholdهای مختلف و استفاده از Up، Down و Test Script، انعطاف بیشتری برای طراحی مانیتورینگ هوشمند فراهم می‌کند.

بااین‌حال، استفاده صحیح از Netwatch نیازمند شناخت دقیق Probeها، محدودیت Permission، ساختار Routing و رفتار اتصال هنگام خطا است.

 مهم‌ترین نکته این است که Netwatch صرفاً وضعیت موفقیت یا شکست Probe تعریف‌شده را گزارش می‌کند؛ کیفیت تصمیم‌گیری خودکار به طراحی صحیح Probe، Threshold و Script وابسته است.

منابع و مستندات رسمی

• مستندات جدید MikroTik: Netwatch در RouterOS 7.26
• مرجع دستورات و پارامترهای Netwatch
• مستندات قدیمی Netwatch در MikroTik
• تغییرات مستندات RouterOS

 این راهنما بر اساس مستندات RouterOS 7.26 تهیه شده است. برخی پارامترها ممکن است در نسخه‌های قدیمی‌تر RouterOS 7 متفاوت باشند. پیش از اعمال تنظیمات در شبکه عملیاتی، سازگاری با نسخه نصب‌شده را بررسی کنید.