کاربر شعبه میگوید «سامانه کند است». تیم سرور میگوید CPU و Memory طبیعیاند. تیم شبکه Ping میگیرد و Destination پاسخ میدهد. ISP هم میگوید لینک Up است. با این حال تجربه کاربر همچنان ضعیف است و کسی دقیقاً نمیداند مشکل در کدام بخش مسیر رخ میدهد.
در چنین سناریویی، پاسخ «Ping سالم است» کافی نیست. بسته برای رسیدن از شعبه به دیتاسنتر، Cloud، سرویس SaaS یا سایت مرکزی از چندین Hop عبور میکند و هر Hop میتواند Delay، Packet Loss یا تغییر Route ایجاد کند. Network Path Analysis در OpManager برای همین فاصله طراحی شده است: مسیر را Hop-by-Hop میبیند، Latency و Packet Loss را در طول مسیر ثبت میکند و کمک میدهد محل واقعی افت کیفیت را سریعتر محدود کنید.
این مقاله راهنمای عملی طراحی Network Path Monitoring است؛ از تفاوت آن با Ping و Traceroute تا Threshold، Path History، Remote Source، WAN، ISP Escalation و اتصال آن به Root Cause Analysis.
Network Path Analysis در OpManager چیست؟
طبق مستند رسمی ManageEngine، قابلیت Network Path Analysis در OpManager مسیر بین یک Source و Destination را مرحلهبهمرحله دنبال میکند. Source میتواند خود سرور OpManager یا یک Remote Machine دارای Agent باشد. OpManager هر Hop را شناسایی میکند و برای مسیر، دادههایی مانند Latency، Packet Loss و وضعیت Nodeها را نگه میدارد.
ارزش اصلی این قابلیت در «تاریخچه» است. Traceroute دستی فقط وضعیت همین لحظه را نشان میدهد؛ اما Network Path Monitor میتواند مسیر را در طول زمان Poll کند، تغییرهای Path را ثبت کند و Threshold بسازد.
چرا Ping بهتنهایی برای عیبیابی WAN کافی نیست؟
Ping معمولاً سه سؤال را جواب میدهد: آیا Destination پاسخ میدهد؟ Round Trip Time چقدر است؟ Packet Loss کلی چقدر است؟ اما اگر Latency از ۲۰ میلیثانیه به ۱۸۰ میلیثانیه برسد، Ping نمیگوید افزایش Delay در کدام بخش مسیر ایجاد شده است.
مثلاً مسیر زیر را فرض کنید:
Branch → CE Router → ISP-1 → Backbone → Datacenter Edge → Core → Application
اگر فقط Destination را Ping کنید، میبینید RTT بالا رفته است. با Path Analysis میتوانید تشخیص دهید افزایش Delay از Hop مربوط به ISP شروع شده یا داخل دیتاسنتر شکل گرفته است.
Network Path Analysis چه تفاوتی با Traceroute دارد؟
| قابلیت | Traceroute دستی | Network Path Analysis در OpManager |
|---|---|---|
| نمایش Hopها | دارد | دارد |
| اجرای مداوم | خیر | بله |
| Path History | خیر | بله |
| Latency بین Hopها | لحظهای | قابل پایش و تحلیل |
| Packet Loss | محدود | قابل مانیتورینگ و Threshold |
| Alert | خیر | بله |
| Remote Source | نیازمند اجرای دستی | از Remote Agent قابل طراحی است |
| تاریخچه تغییر Route | خیر | دارد |
Traceroute همچنان ابزار مهم Troubleshooting است؛ اما برای NOC که باید ۲۴×۷ مسیرهای حیاتی را زیر نظر داشته باشد، اجرای دستی مقیاسپذیر نیست.
سناریوی عملی: شعبه میگوید ERP کند شده است
فرض کنید ERP در دیتاسنتر مرکزی است و یک شعبه از طریق MPLS یا VPN به مرکز متصل میشود. کاربرها در ساعات خاص کندی دارند، اما وقتی تیم شبکه وارد سیستم میشود مشکل برطرف شده است.
بهجای منتظر ماندن برای تکرار مشکل، یک Network Path Monitor از شعبه تا IP سرویس ERP تعریف میکنید. اگر Source روی Remote Agent شعبه باشد، دید شما به تجربه واقعی همان Site نزدیکتر میشود.
چه چیزهایی را باید ثبت کنید؟
- Overall Latency از Source تا Destination؛
- Packet Loss کلی؛
- Latency بین Hopهای میانی؛
- Packet Loss در Hopهای میانی؛
- زمان تغییر Route؛
- زمان شروع Alarm؛
- همزمانی با Utilization لینک یا Interface Error.
اگر کندی از Hop سوم آغاز شود و Hop سوم متعلق به Provider باشد، Escalation به ISP مستندتر میشود. اگر Delay از آخرین Hopهای دیتاسنتر شروع شود، مسئله را داخل شبکه خودتان دنبال میکنید.
Path History چرا مهمتر از یک Snapshot است؟
مشکلات شبکه همیشه دائمی نیستند. Route Flap، تغییر مسیر Backup، Congestion دورهای، تغییر Provider Path و اختلالهای چنددقیقهای ممکن است قبل از ورود کارشناس ناپدید شوند.
OpManager تاریخچه Network Path را نگه میدارد و اجازه میدهد مسیرهای قبلی را بررسی کنید. طبق مستند ManageEngine، میتوان مسیرهایی را که بسته در طول زمان طی کرده مشاهده کرد و از این History برای شناسایی Anomaly و مشکلات سمت Service Provider استفاده کرد.
مثال تغییر مسیر
در حالت عادی:
Branch → ISP-A → POP-1 → DC
در زمان Incident:
Branch → ISP-A → POP-2 → Transit Provider → POP-1 → DC
ممکن است Availability همچنان ۱۰۰ درصد باشد، اما Route جدید سه Hop اضافه کند و Latency کاربر دو برابر شود. بدون Path History، این تغییر بهسادگی دیده نمیشود.
Latency را Source-to-Destination ببینیم یا Hop-to-Hop؟
هر دو مهماند و پاسخ متفاوتی میدهند.
| نوع اندازهگیری | سؤال اصلی | کاربرد |
|---|---|---|
| Source to Destination | تجربه End-to-End چقدر خوب است؟ | SLA و تجربه Site |
| Hop to Hop | Delay دقیقاً کجا اضافه شد؟ | Root Cause و Provider Escalation |
طبق راهنمای فعلی OpManager، Threshold برای Latency و Packet Loss را میتوان هم برای Source-to-Destination و هم برای Hop-to-Hop تعریف کرد.
Threshold مناسب برای Network Path چگونه تعیین شود؟
یک عدد ثابت برای همه مسیرها معمولاً اشتباه است. Latency طبیعی یک مسیر داخل Campus با مسیر تهران تا یک Region خارجی یکسان نیست. Baseline باید برای هر Path ساخته شود.
گام اول: Baseline بسازید
حداقل چند روز رفتار عادی را مشاهده کنید. Median، Peak و ساعات پرترافیک را بشناسید. اگر مسیر در حالت عادی بین ۲۰ تا ۳۰ ms است، Threshold ۲۰۰ ms بیش از حد دیر هشدار میدهد.
گام دوم: سه سطح Severity تعریف کنید
OpManager امکان تعریف Attention، Trouble و Critical را برای Latency و Packet Loss فراهم میکند. بهجای Alarm دودویی، شدت اختلال را مرحلهای کنید.
گام سوم: مسیرها را Classify کنید
- Datacenter Critical Path؛
- Branch WAN؛
- Internet/SaaS؛
- Backup Link؛
- Non-critical Test Path.
برای هر Class Threshold جداگانه داشته باشید.
Packet Loss در Hop میانی همیشه به معنی مشکل نیست
یکی از خطاهای رایج در تحلیل Traceroute این است که Packet Loss روی یک Router میانی مستقیماً به معنی Loss واقعی Forwarding فرض شود. بعضی Routerها پاسخ ICMP یا Probe را Rate-limit یا De-prioritize میکنند، در حالی که Traffic عبوری سالم است.
بنابراین یک Hop را فقط زمانی متهم کنید که الگوی Loss یا Latency در Hopهای بعدی هم ادامه پیدا کند یا با Metricهای دیگر همبستگی داشته باشد.
قاعده عملی:
- Loss فقط روی یک Hop و Hopهای بعدی سالم: احتمال ICMP De-prioritization؛
- Loss از یک Hop شروع و در Hopهای بعدی ادامه دارد: احتمال مشکل واقعی مسیر؛
- Latency فقط یک Hop بالا ولی Hop بعدی عادی: لزوماً Bottleneck نیست؛
- Latency از یک نقطه بالا میرود و تا Destination باقی میماند: نقطه مشکوکتر است.
Remote Source؛ چرا مسیر را فقط از سرور OpManager مانیتور نکنیم؟
اگر OpManager در دیتاسنتر مرکزی است، مانیتور کردن مسیر از همان سرور فقط دید «مرکز» را نشان میدهد. مشکل ممکن است مخصوص شعبه، VLAN، ISP یا Segment کاربر باشد.
ManageEngine اجازه میدهد Source مسیر از یک Remote Machine دارای Agent انتخاب شود. این قابلیت برای سازمانهای چندشعبهای مهم است؛ چون میتوان چند Perspective ساخت:
- Branch A → Datacenter؛
- Branch B → Datacenter؛
- Branch A → Microsoft 365؛
- Branch B → SaaS CRM؛
- Datacenter → Public API.
در نتیجه NOC میفهمد Incident Global است یا Site-specific.
Windows و Linux در Network Path Analysis
مستند رسمی OpManager میگوید Network Path Analysis روی Windows و Linux پشتیبانی میشود. در Windows، نوع Trace به محل Source بستگی دارد. برای Monitoring از Local OpManager Server، TraceTCP استفاده میشود. در Remote Windows Machine، Tracert بهصورت پیشفرض استفاده میشود؛ برای استفاده از TraceTCP روی Remote Machine نیاز به Npcap و هماهنگی با Support وجود دارد.
این تفاوت مهم است، چون Tracert مبتنی بر ICMP است و Port مشخص نمیکند؛ در حالی که TCP-based Path میتواند برای شبکههایی که ICMP در آنها محدود است رفتار متفاوتی داشته باشد.
چه Pathهایی ارزش مانیتورینگ دائمی دارند؟
هر Destination را وارد Path Analysis نکنید. مسیر باید Business Value داشته باشد.
| Path | دلیل | اولویت |
|---|---|---|
| شعبه → Core Banking/ERP | اثر مستقیم روی عملیات | بسیار بالا |
| شعبه → Datacenter | WAN Health | بالا |
| HQ → Microsoft 365 | SaaS Productivity | بالا |
| Datacenter → Payment/API | وابستگی سرویس | بسیار بالا |
| Primary ISP Path | SLA Provider | بالا |
| Backup ISP Path | Failover Readiness | متوسط تا بالا |
| Lab → Internet | کماهمیت | پایین |
Network Path Analysis و WAN IP Monitoring چه تفاوتی دارند؟
OpManager قابلیت WAN IP Monitoring هم دارد. WAN IP Monitoring با ICMP Ping، Availability، Response Time و Packet Loss آدرسهای WAN را در Siteهای مختلف بررسی میکند و اطلاعاتی مانند ISP Vendor، Bandwidth، Link Type، SLA، Circuit ID و Primary/Secondary/Tertiary بودن لینک را نگه میدارد.
تفاوت اصلی:
- WAN IP Monitoring: آیا لینک WAN در دسترس و مطابق SLA است؟
- Network Path Analysis: مسیر دقیق تا Destination چگونه است و مشکل در کدام Hop ایجاد میشود؟
در NOC بالغ، این دو مکمل یکدیگرند.
Network Path Analysis و Cisco IP SLA چه تفاوتی دارند؟
ManageEngine برای اندازهگیری Round-Trip Latency در سناریوهای Cisco، IP SLA Monitoring را نیز ارائه میدهد. IP SLA برای WAN/VoIP و Measurement فعال بین Deviceهای سازگار ارزش زیادی دارد.
Network Path Analysis بیشتر روی مشاهده Step-by-Step Route و Hop-level Latency/Packet Loss تمرکز دارد. اگر سؤال شما «کیفیت کل مسیر چقدر است؟» باشد IP SLA مفید است؛ اگر سؤال «کدام Hop گلوگاه شده؟» باشد Path Analysis دید متفاوتی میدهد.
Network Path Analysis و NetFlow Analyzer چه تفاوتی دارند؟
Path Analysis نشان میدهد Delay یا Loss در کجای مسیر رخ داده است، اما نمیگوید چه Application یا Conversationی پهنای باند را مصرف کرده است.
برای سؤالهایی مثل «چه کسی لینک را پر کرده؟»، «کدام Application بیشترین Traffic را دارد؟» یا «Top Talker چیست؟» باید از Flow Analysis استفاده کنید. مقاله لایسنس NetFlow Analyzer و معماری Flow Monitoring مسیر این بخش را توضیح میدهد.
ترکیب این دو بسیار قدرتمند است:
- Path Analysis: محل افت کیفیت؛
- NetFlow: علت ترافیکی احتمالی؛
- Interface Monitoring: Error/Discard/Utilization؛
- Device Monitoring: CPU/Memory/Availability.
چگونه Network Path را در OpManager بسازیم؟
طبق راهنمای رسمی ManageEngine:
- به Settings → Monitoring → Network Path Analysis بروید.
- گزینه Create New Path را انتخاب کنید.
- Source مناسب را مشخص کنید.
- Hostname یا IP مقصد را وارد کنید.
- Path Name، Port و Monitoring Interval را تنظیم کنید.
- Path را Save کنید.
- بعد از جمع شدن داده، Path Graph و Path History را بررسی کنید.
برای Production بهتر است Naming Convention مشخص داشته باشید؛ مثلاً:
BR-TEH-01_to_DC-ERP
یا:
HQ_to_M365_Internet1
Threshold را در OpManager چگونه تنظیم کنیم؟
برای هر Path میتوانید Threshold مربوط به Latency و Packet Loss را فعال کنید. Thresholdها در دو سطح Source-to-Destination و Hop-to-Hop قابل تعریف هستند.
همچنین Notification Profile را میتوان به Network Path متصل کرد تا در صورت عبور از Threshold، Email، SMS، Ticket یا Integration مناسب فعال شود.
اگر NOC شما درگیر Alarm Noise است، مقاله Adaptive Thresholds در OpManager؛ چطور هشدار کاذب NOC را کم کنیم؟ مکمل خوبی برای طراحی Alarm Strategy است.
سناریوی ISP Escalation؛ چه Evidenceای ارائه کنیم؟
جمله «اینترنت کند است» برای Provider کافی نیست. بهتر است Incident شامل Evidence مشخص باشد:
- زمان شروع و پایان Incident؛
- Source Site؛
- Destination؛
- Overall Latency Baseline و Incident Value؛
- Packet Loss؛
- Hop مشکوک؛
- Path قبل و هنگام Incident؛
- WAN IP Availability؛
- Circuit ID؛
- Interface Utilization و Error.
این اطلاعات زمان Ping-Pong بین NOC و ISP را کم میکند.
سناریوی Multi-ISP؛ Primary Up است اما Route بد شده
در معماری Dual ISP، گاهی لینک Primary Down نمیشود اما کیفیت آن افت میکند. بنابراین Failover سنتی که فقط Availability را بررسی میکند، Trigger نمیشود.
Path Analysis میتواند نشان دهد Route Primary طولانیتر شده، Packet Loss بالا رفته یا Hop خاصی در Provider مشکل دارد. در کنار WAN IP Monitoring و Policyهای SD-WAN، این داده برای تصمیمگیری بهتر روی Path Selection مفید است.
چه زمانی Path Change خودش Incident است؟
هر تغییر Route الزاماً Incident نیست. اینترنت ذاتاً Dynamic است. اما Path Change در این شرایط ارزش بررسی بیشتری دارد:
- همزمان با افزایش محسوس Latency؛
- همزمان با Packet Loss؛
- ورود Transit Provider غیرمنتظره؛
- تغییر مکرر Path در فاصله کوتاه؛
- عبور Traffic حساس از Route غیرمعمول؛
- همزمانی با شکایت کاربر یا SLA Violation.
هدف این نیست که هر Path Change Alarm Critical شود؛ باید با Performance Context دیده شود.
Network Path Analysis در کنار Root Cause Analysis
Path Analysis یک Signal تخصصی شبکه است. برای Incidentهای پیچیده، باید آن را با Device Health، Interface، URL، VM و سایر Metricها Correlate کرد.
مقاله Root Cause Analysis در OpManager توضیح میدهد چگونه داده چند Monitor را برای محدود کردن علت اصلی کنار هم بگذارید. در سناریوی WAN، Path Analysis میتواند یکی از مهمترین ورودیهای RCA باشد.
یک Runbook کوتاه برای «کاربر میگوید شبکه کند است»
- Availability مقصد را بررسی کنید.
- Overall Latency و Packet Loss را ببینید.
- Path History را با بازه سالم مقایسه کنید.
- Hop-to-Hop Latency را بررسی کنید.
- مشخص کنید Delay از کدام Hop شروع میشود.
- Interface Utilization/Error/Discard همان Segment را ببینید.
- اگر Congestion محتمل است، NetFlow را بررسی کنید.
- اگر مشکل Provider است Evidence جمع کنید.
- اگر مشکل داخل شبکه است Device/Interface RCA را ادامه دهید.
- پس از رفع، Threshold و Runbook را بازبینی کنید.
اشتباههای رایج در Network Path Monitoring
- ساخت Path برای صدها مقصد بدون Business Priority؛
- تنظیم Threshold یکسان برای LAN، WAN و Internet؛
- تفسیر هر ICMP Loss در Hop میانی بهعنوان Fault؛
- مانیتور کردن همه مسیرها فقط از OpManager Server مرکزی؛
- نادیده گرفتن Path History؛
- نداشتن Naming Convention؛
- نداشتن Owner برای Alert؛
- جدا دیدن Path Analysis از Interface و Flow Monitoring؛
- ارسال Alert خام به ISP بدون Evidence.
لایسنس و Edition را قبل از Rollout بررسی کنید
اگر قصد دارید OpManager را در تعداد زیادی Site، Device و Path استفاده کنید، فقط Feature را نبینید؛ معماری Deployment، Edition، تعداد Device و مدل Standalone یا Enterprise هم مهم است.
راهنمای لایسنس OpManager؛ محاسبه Device و Edition برای Sizing تجاری نوشته شده است. برای دید جامعتر محصول نیز صفحه OpManager Plus مدانت مرجع اصلی Pillar مانیتورینگ شبکه و ITOM است.
برای استعلام Quote نهایی میتوانید از استعلام قیمت لایسنس ManageEngine استفاده کنید.
چکلیست طراحی Network Path Analysis
- Business-critical Pathها مشخص شدهاند.
- Source هر Path براساس تجربه واقعی کاربر انتخاب شده است.
- برای شعب مهم Remote Source در نظر گرفته شده است.
- Baseline Latency ساخته شده است.
- Threshold Source-to-Destination تعریف شده است.
- Threshold Hop-to-Hop تعریف شده است.
- Packet Loss با احتیاط تفسیر میشود.
- Path History در Incident Review استفاده میشود.
- WAN IP و Circuit ID مستند شدهاند.
- Notification Profile Owner مشخص دارد.
- Interface Utilization و Error کنار Path دیده میشود.
- NetFlow برای تحلیل Congestion در دسترس است.
- Runbook Escalation به ISP آماده است.
نکات کلیدی
- Ping میگوید Destination چگونه پاسخ میدهد؛ Path Analysis میگوید مشکل در کدام بخش مسیر شکل گرفته است.
- Path History برای Incidentهای Intermittent و تغییر Route حیاتی است.
- Latency و Packet Loss را هم End-to-End و هم Hop-to-Hop ببینید.
- Remote Source برای سازمانهای چندشعبهای دید واقعیتری میدهد.
- هر Packet Loss در Hop میانی الزاماً Fault نیست.
- Network Path Analysis جای NetFlow یا IP SLA را نمیگیرد؛ مکمل آنهاست.
- بهترین Path Monitor مسیری است که Business Service واقعی را نمایندگی کند.
منابع
- ManageEngine — Network Path Analysis Tool
- ManageEngine — Network Path Analysis How-to
- ManageEngine — Network Path Analysis Help
- ManageEngine — WAN IP Monitoring
- ManageEngine — Monitor Latency Between Devices
- ManageEngine — Troubleshooting Network Latency
سخن پایانی
وقتی کاربر میگوید «شبکه کند است»، سختترین بخش معمولاً اثبات کندی نیست؛ پیدا کردن نقطهای است که کیفیت از آنجا افت کرده است. Network Path Analysis در OpManager همین مسئله را هدف میگیرد: تبدیل یک شکایت مبهم End-to-End به مسیر قابل مشاهدهای از Hopها، Latency، Packet Loss و تاریخچه Route.
اگر این قابلیت در کنار WAN IP Monitoring، Interface Monitoring، NetFlow و Root Cause Analysis استفاده شود، NOC میتواند سریعتر تشخیص دهد Incident داخل شبکه سازمان است، روی WAN رخ داده یا باید با Evidence دقیق به Provider ارجاع شود.
مدانت میتواند در استعلام و خرید لایسنس OpManager و OpManager Plus، طراحی معماری مانیتورینگ شعب و دیتاسنتر، استقرار، تنظیم Threshold، طراحی NOC Dashboard، Integration، آموزش و پشتیبانی همراه سازمان باشد. برای بررسی Scope از درخواست جلسه فنی و دمو یا تماس با مدانت استفاده کنید.
