فرض کنید لینک WAN یک شعبه فقط برای ۴۵ ثانیه دچار اختلال میشود. Polling دورهای ممکن است این رخداد کوتاه را نبیند، اما روتر همان لحظه SNMP Trap میفرستد. در سناریوی دیگری، Firewall یک Login ناموفق یا تغییر Policy را در Syslog ثبت میکند؛ رخدادی که اصلاً با Polling قابل مشاهده نیست. اینجاست که تفاوت میان مانیتورینگ دورهای و رویدادمحور اهمیت پیدا میکند.
OpManager برای مانیتورینگ شبکه فقط به Polling متکی نیست و میتواند SNMP Trap و Syslog را نیز در کنار Availability و Performance Monitoring دریافت و پردازش کند. هدف این مقاله، طراحی یک معماری Alerting متعادل است؛ بهطوری که Polling برای وضعیت و Trend استفاده شود و Trap/Syslog برای رخدادهای فوری و Event-driven.
Polling، Trap و Syslog چه تفاوتی دارند؟
| روش | ماهیت | کاربرد اصلی |
|---|---|---|
| Polling | درخواست دورهای از مانیتور | Availability، CPU، Memory، Interface |
| SNMP Trap | Push از Device | Link Down، Hardware Alarm، State Change |
| Syslog | پیام متنی Event | Security، Configuration، Authentication، System Event |
هیچکدام جای دیگری را کامل نمیگیرد. معماری خوب از هر سه بر اساس نوع سیگنال استفاده میکند.
چرا فقط Polling کافی نیست؟
Polling Snapshot میگیرد. اگر Interval پنج دقیقه باشد، رویدادی که بین دو Poll رخ دهد ممکن است دیده نشود. کاهش Interval هم Load شبکه و Monitoring Server را بالا میبرد. بنابراین Event-driven Signalها برای رخدادهای لحظهای ارزش زیادی دارند.
SNMP Trap در OpManager چه نقشی دارد؟
طبق مستندات ManageEngine، OpManager میتواند Trapهای SNMP را دریافت، پردازش و بر اساس Trap Processor آنها را به Alarm تبدیل کند. Vendorها معمولاً برای رخدادهایی مانند Link State Change، Temperature Alarm، Fan Failure و Redundancy State Trap ارسال میکنند.
Trap Processor چه کاری میکند؟
- شناخت OID و Vendor Trap؛
- تعیین Severity؛
- فیلتر کردن Trapهای بیاهمیت؛
- تبدیل پیام خام به Alarm قابل فهم؛
- اتصال Event به Device مربوطه.
Syslog چه چیزی اضافه میکند؟
Syslog برای بسیاری از تجهیزات شبکه، Firewall، Linux Server و Applianceها منبع اصلی Event است. پیام Syslog میتواند اطلاعاتی بدهد که در SNMP وجود ندارد؛ مانند Login Failure، Configuration Change، ACL Event یا پیام سرویس خاص.
طراحی Severity Mapping
| Event | Severity پیشنهادی | اقدام |
|---|---|---|
| Core Link Down | Critical | Notification + Ticket |
| Interface Flap | Trouble | Correlation و Threshold |
| Fan Warning | Attention | بررسی Hardware |
| Successful Config Change | Informational | Audit/Correlation |
| Repeated Login Failure | Security/Trouble | بررسی SOC |
اگر همه Eventها Critical باشند، Alarm Fatigue ایجاد میشود.
مشکل Trap Storm
در خرابی بزرگ، یک Device ممکن است دهها یا صدها Trap بفرستد. اگر Processing Rule و Correlation مناسب نباشد، NOC با صدها Alarm تکراری روبهرو میشود. Trap Storm باید با Suppression، Deduplication و Dependency Awareness مدیریت شود.
Correlation با Device Dependency
اگر Router بالادستی Down باشد، Alarmهای دهها Device پاییندستی ارزش عملیاتی کمتری دارند. OpManager با Dependency و Root Cause Logic میتواند کمک کند تیم روی Parent Failure تمرکز کند.
مقاله Network Path Analysis در OpManager مکمل خوبی برای تحلیل مسیر و تشخیص Hop مسئلهدار است.
Syslog Rule را بر اساس Use Case بسازید
بهجای جمعآوری همه چیز با Severity بالا، Ruleها را بر اساس Intent طراحی کنید:
- Configuration Change؛
- Authentication Failure؛
- Interface Error؛
- Routing Neighbor Change؛
- Hardware Failure؛
- VPN Tunnel Event.
چه زمانی Polling بهتر است؟
برای Metricهای Trend مانند CPU، Bandwidth، Memory، Disk و Interface Utilization، Polling مناسبتر است. Trap و Syslog بیشتر Event هستند و برای Trend Long-term جای Metric Collection را نمیگیرند.
Alert-to-Ticket Integration
Alarmهای مهم OpManager بهتر است به Incident در ServiceDesk Plus تبدیل شوند. اما همه Trapها نباید Ticket بسازند. فقط Eventهای Actionable و Correlated باید وارد ITSM شوند تا Noise ایجاد نشود.
برای طراحی Integration میتوانید از مقاله Webhook در ServiceDesk Plus و منابع سرویسدسک مدانت استفاده کنید.
سناریوی عملی: Flapping Interface
Interface هر چند دقیقه Up/Down میشود. Trap هر State Change را اعلام میکند، Polling Bandwidth و Error Counter را نشان میدهد و Syslog ممکن است پیام Driver یا Negotiation بدهد. کنار هم قرار دادن این سه منبع Root Cause را سریعتر میکند.
سناریوی عملی: تغییر Configuration روی Switch
Syslog تغییر را ثبت میکند، Trap ممکن است State Change ایجاد کند و OpManager Availability را پایش میکند. اگر Network Configuration Manager هم استفاده شود، میتوان تغییر Config را دقیقتر Audit کرد.
بهترین مدل Notification
- Critical: SMS/Call/Push + Ticket؛
- Trouble: Email/Chat + Ticket در صورت استمرار؛
- Attention: Dashboard و Queue؛
- Informational: Audit و Report.
شاخصهای پیشنهادی
- Trap-to-Alarm Ratio؛
- False Positive Rate؛
- Alarm Deduplication Rate؛
- MTTA؛
- تعداد Alarmهای Actionable؛
- درصد Eventهایی که Root Cause شدند.
مسیر تجاری مدانت
برای بررسی لایسنس، Edition و طراحی معماری مانیتورینگ، مقاله لایسنس OpManager؛ محاسبه Device و Edition و صفحه OpManager Plus مدانت مسیرهای مرتبط هستند.
منابع
نکات کلیدی
- Polling برای Metric و Trend مناسب است؛ Trap/Syslog برای Event.
- Trap Storm بدون Correlation میتواند Alarm Fatigue ایجاد کند.
- Severity Mapping باید Use Case محور باشد.
- فقط Alarmهای Actionable را به ITSM بفرستید.
- ترکیب Polling، Trap و Syslog Blind Spot شبکه را کم میکند.
سخن پایانی
مانیتورینگ موثر شبکه یعنی استفاده از سیگنال درست برای مسئله درست. Polling وضعیت را میسنجد، Trap تغییر ناگهانی را اعلام میکند و Syslog Context رویداد را میدهد.
مدانت خدمات استعلام و خرید لایسنس OpManager، طراحی Monitoring Architecture، پیادهسازی SNMP/Syslog/Trap، Integration با ServiceDesk Plus، آموزش و پشتیبانی ارائه میکند. برای طراحی Scope مناسب با مدانت تماس بگیرید.
