جواب کوتاه: برای مانیتور کردن قطعی اینترنت یا یک سرویس در MikroTik، Netwatch را فقط روی Ping ساده تنظیم نکنید. بسته به چیزی که واقعاً میخواهید بسنجید از probe مناسب مثل ICMP، TCP، HTTP/HTTPS یا DNS استفاده کنید، آستانهها را طوری تنظیم کنید که قطعی لحظهای باعث هشدار کاذب نشود و در up-script/down-script فقط اقدامهای محدود و قابل برگشت انجام دهید.
Netwatch در MikroTik دقیقاً چه چیزی را مانیتور میکند؟
Netwatch در RouterOS وضعیت یک Host یا سرویس را در بازههای زمانی مشخص بررسی میکند. طبق مستندات رسمی MikroTik، probeهای فعلی شامل Simple، ICMP، TCP-conn، HTTP-GET، HTTPS-GET و DNS هستند. تفاوت مهم این است که Ping فقط Reachability را میسنجد؛ ممکن است سرور Ping بدهد اما وبسایت، DNS یا Port موردنظر از کار افتاده باشد.
پیشنیازها و سناریوی این آموزش
فرض میکنیم RouterOS 7 دارید و میخواهید سه وضعیت را جداگانه تشخیص دهید: دسترسی IP به اینترنت، باز بودن یک Port مشخص و پاسخگویی DNS یا وبسایت. قبل از تغییر تنظیمات، وضعیت فعلی را ذخیره کنید:
/tool/netwatch/print detail
/log/print where topics~"netwatch"اگر در شبکه چند WAN یا Policy Routing دارید، مطمئن شوید Probe از مسیر موردنظر خارج میشود؛ در غیر این صورت ممکن است Failover باعث False Positive شود.
مرحله ۱: تست ساده قطعی اینترنت با ICMP
برای شروع میتوانید یک مقصد پایدار را مانیتور کنید:
/tool/netwatch/add host=8.8.8.8 type=icmp interval=30s up-script=":log info "NETWATCH: internet probe UP"" down-script=":log warning "NETWATCH: internet probe DOWN""برای دیدن وضعیت:
/tool/netwatch/print detail
/log/print where message~"NETWATCH"ICMP نسبت به Simple اجازه تنظیم Thresholdهای دقیقتری میدهد. اگر شبکه شما Packet Loss یا Latency مقطعی دارد، آستانه را قبل از اجرای اسکریپت Failover با داده واقعی تنظیم کنید.
مرحله ۲: وقتی Ping کافی نیست، TCP Port را تست کنید
اگر هدف شما سلامت یک سرویس است، TCP probe بهتر از Ping است. برای مثال بررسی DNS روی TCP/53:
/tool/netwatch/add host=8.8.8.8 type=tcp-conn port=53 interval=30s up-script=":log info "NETWATCH: TCP 53 UP"" down-script=":log warning "NETWATCH: TCP 53 DOWN""این Probe بررسی میکند RouterOS بتواند TCP handshake را روی Port تعیینشده کامل کند. برای وبسرور میتوانید Port 443 و برای سرویسهای دیگر Port واقعی همان سرویس را بسنجید.
مرحله ۳: سلامت وبسایت یا API را با HTTP/HTTPS بررسی کنید
HTTP/HTTPS probe در لایه Application کار میکند و فقط باز بودن Port را نمیسنجد. در مستندات MikroTik، HTTP probe علاوه بر Response Code، زمان پاسخ را نیز ارزیابی میکند. این نکته مهم است چون Redirect مثل 301/302 ممکن است خارج از بازه http-codes تعریفشده باشد و Probe را Down کند.
/tool/netwatch/add host=example.com type=https-get interval=1m up-script=":log info "NETWATCH: HTTPS UP"" down-script=":log warning "NETWATCH: HTTPS DOWN""بعد از ساخت Probe، یک بار مقصد را عمداً با Host آزمایشی یا Rule موقت مسدود کنید تا Down و سپس Up را واقعاً ببینید؛ صرفاً وجود Entry در Netwatch به معنی درست بودن مانیتورینگ نیست.
مرحله ۴: DNS را مستقل از Ping تست کنید
اگر اینترنت برقرار است ولی کاربران میگویند «سایتها با نام باز نمیشوند»، DNS probe مناسبتر است:
/tool/netwatch/add host=mikrotik.com type=dns dns-server=8.8.8.8 record-type=A interval=1m up-script=":log info "NETWATCH: DNS resolution UP"" down-script=":log warning "NETWATCH: DNS resolution DOWN""در این حالت Netwatch واقعاً Query DNS میفرستد و وجود Record معتبر را بررسی میکند. بنابراین خرابی DNS از قطعی کامل اینترنت جدا میشود.
چطور False Positive را کم کنیم؟
به یک مقصد واحد وابسته نباشید. اگر تصمیم شما حساس است، مثلاً خاموش کردن Route اصلی، ابتدا با چند Probe مستقل وضعیت را تأیید کنید. Interval خیلی کوتاه، Threshold سختگیرانه یا مقصد ناپایدار باعث Flapping میشود. همچنین ICMP ممکن است در مقصد Rate-limit یا Block شده باشد، درحالیکه سرویس اصلی سالم است.
up-script و down-script را امن نگه دارید
Netwatch میتواند با تغییر وضعیت Probe اسکریپت اجرا کند، اما MikroTik برای آن محدودیت Policy دارد. طبق Manual، Netwatch به policyهای read,write,test,reboot محدود است. اگر Script مجوز لازم نداشته باشد اجرا نمیشود. غیرفعال کردن Permission Checking ممکن است مشکل را ظاهراً حل کند اما امنیت را پایین میآورد؛ روش بهتر، دادن حداقل Permission لازم است.
برای شروع، Script را فقط به Log محدود کنید. وقتی چند چرخه Up/Down را بدون خطای کاذب دیدید، Action واقعی مثل Enable/Disable Route یا ارسال Notification را اضافه کنید.
عیبیابی: Netwatch Down میشود ولی اینترنت سالم است
این موارد را بهترتیب بررسی کنید:
/tool/netwatch/print detail
/ping 8.8.8.8 count=5
/ip/route/print detail
/log/print where topics~"netwatch|script"اگر Ping دستی موفق است ولی Netwatch Fail میشود، نوع Probe، Source Address، Route، Threshold و Permission اسکریپت را بررسی کنید. Probeهای Simple، ICMP، HTTP و TCP-connect با DF ارسال میشوند؛ در سناریوهای MTU نیز این موضوع میتواند در تشخیص مشکل مفید باشد.
Verify نهایی
بعد از تنظیم، فقط منتظر قطعی واقعی نمانید. یک تست کنترلشده انجام دهید: مقصد آزمایشی را موقتاً Block کنید یا Probe را روی سرویس تستی قرار دهید، Down شدن را در Log ببینید، سپس شرایط را برگردانید و Up شدن را تأیید کنید.
/tool/netwatch/print detail
/log/print where topics~"netwatch"
/log/print where message~"NETWATCH"نتیجه مطلوب این است که تغییر State فقط در شرایط تعریفشده رخ دهد و بعد از Recovery نیز به Up برگردد.
Rollback و حذف تنظیم آزمایشی
قبل از حذف، شماره Entry را پیدا کنید:
/tool/netwatch/printسپس فقط Entry آزمایشی را حذف کنید:
/tool/netwatch/remove [find where host="8.8.8.8"]اگر down-script شما Route یا Rule دیگری را تغییر میدهد، Rollback همان تغییر را نیز از قبل طراحی کنید؛ Netwatch نباید در زمان خطا Router را در وضعیت مبهم رها کند.
Netwatch با مانیتورینگ کامل شبکه چه تفاوتی دارد؟
Netwatch ابزار سبک برای Health Check و اجرای Action روی تغییر State است؛ جایگزین سامانه کامل Monitoring نیست. برای دید کلیتر، مقاله مانیتورینگ در MikroTik را ببینید. اگر مشکل شما رفتار Queue است، راهنمای رفع مشکل Simple Queue و FastTrack مرتبط است و برای مشکلات بعد از Upgrade نیز عیبیابی ناپدید شدن WiFi بعد از آپدیت RouterOS را بررسی کنید.
اگر RouterOS را روی زیرساخت مجازی اجرا میکنید و به منابع مستقل نیاز دارید، پلنهای سرور مجازی وانسرور مرتبطاند.
جمعبندی
برای مانیتورینگ درست با Netwatch ابتدا مشخص کنید «چه چیزی» باید سالم باشد: IP، Port، HTTP/HTTPS یا DNS. Probe را متناسب با همان سرویس انتخاب کنید، Threshold و Route را Verify کنید، ابتدا Script را فقط Log کنید و پس از تست Up/Down کنترلشده سراغ Actionهای خودکار بروید.