OpManager Plus
اگر هر بالا رفتن CPU و هر Packet Loss یک آلارم قرمز بسازد، مانیتورینگ به جای کمک‌کردن، تیم را بی‌حس می‌کند.
یک NOC خوب با تعداد بیشتر آلارم شناخته نمی‌شود؛ با سرعت فهمیدن اثر واقعی یک رخداد شناخته می‌شود. Threshold باید متناسب با رفتار تجهیز، زمان و اهمیت سرویس باشد.
OpManager ابزارهای لازم برای پایش Availability، Performance و وابستگی‌ها را فراهم می‌کند، اما ارزش آن زمانی آشکار می‌شود که Alarmها به یک مدل عملیاتی روشن وصل شوند.
سناریو: لینک شعبه‌ای که هر روز چند دقیقه نوسان دارد
یک شعبه روی لینک WAN با ظرفیت محدود کار می‌کند. در ساعات ۱۰ تا ۱۲ مصرف پهنای باند معمولاً بالاست و CPU روتر هم بیشتر می‌شود. Threshold ثابت ۸۰ درصد باعث می‌شود هر روز ده‌ها Alarm ایجاد شود، در حالی که کاربران مشکلی حس نمی‌کنند.
یک روز همان لینک ۳۰ درصد Packet Loss دارد و ERP شعبه کند می‌شود، اما این رخداد بین صدها Alarm معمولی گم می‌شود. مسئله کمبود مانیتورینگ نیست؛ کیفیت پایین سیگنال است.
مسئله را درست تعریف کنیم
Threshold باید رفتار طبیعی را از رفتار خطرناک جدا کند. برای برخی شاخص‌ها مقدار لحظه‌ای مهم است، برای بعضی روند چنددقیقه‌ای و برای بعضی ترکیب چند Metric.
Alarm نیز باید اثر را نشان دهد: خرابی Core Switch با پرشدن حافظه یک Access Point هم‌وزن نیست.
| حوزه | روش بهتر | خطر روش ضعیف |
|---|---|---|
| CPU | میانگین چند نمونه + مدت عبور | Alarm لحظه‌ای و کاذب |
| WAN | Latency + Loss + Utilization | تمرکز فقط روی Up/Down |
| Device Dependency | Suppress آلارم فرزند هنگام خرابی والد | صدها Alarm زنجیره‌ای |
| Escalation | مالک و زمان واکنش مشخص | فقط ایمیل عمومی |
| Maintenance | پنجره نگهداری تعریف‌شده | ثبت خرابی هنگام تغییر برنامه‌ریزی‌شده |
مسیر اجرایی پیشنهادی
1. Baseline بسازید
یک یا دو هفته رفتار معمول تجهیز را ببینید. Threshold بدون شناخت Baseline اغلب یا بسیار حساس است یا آن‌قدر باز که رخداد مهم را دیر نشان می‌دهد.
2. Duration را کنار مقدار قرار دهید
CPU صددرصد برای ده ثانیه ممکن است طبیعی باشد؛ همان وضعیت برای پانزده دقیقه معنا دارد. شرط مدت، بسیاری از Alarmهای کم‌ارزش را حذف می‌کند.
3. وابستگی تجهیزات را مدل کنید
اگر روتر شعبه Down است، Alarm ده‌ها تجهیز پشت آن اطلاعات جدیدی نمی‌دهد. Dependency باعث می‌شود تیم علت بالادستی را زودتر ببیند.
4. Severity را به اثر سرویس وصل کنید
Critical باید واقعاً به معنی نیاز به واکنش فوری باشد. اگر نیمی از Alarmها Critical هستند، این برچسب دیگر ارزش عملیاتی ندارد.
5. Escalation را عملیاتی کنید
برای Alarmهای مهم، مشخص کنید بعد از چند دقیقه و به چه کسی ارجاع می‌شوند. Escalation خوب باید مسئول اقدام تولید کند، نه فقط گیرنده ایمیل بیشتر.
از کجا بفهمیم مسیر درست است؟
به جای تعداد کل Alarm، نسبت Alarmهای قابل‌اقدام، Mean Time to Acknowledge و Mean Time to Restore را دنبال کنید. کاهش Alarm بدون افزایش رخداد از دست‌رفته نشانه تنظیم بهتر است.
همچنین تعداد Alarmهای تکراری هر تجهیز سرنخ خوبی برای اصلاح Threshold یا حل یک مشکل مزمن است.
خطاهای رایج
- استفاده از Threshold یکسان برای همه تجهیزات.
- Critical کردن تقریباً همه رخدادها.
- نداشتن Maintenance Window.
- نادیده‌گرفتن Dependency و تولید Alarm زنجیره‌ای.
لینک‌های داخلی برای ادامه مطالعه
جمع‌بندی
مانیتورینگ مفید باید به تیم کمک کند مهم‌ترین مسئله را زودتر ببیند. کیفیت Alarm از تعداد Monitor مهم‌تر است.
با Baseline، Duration، Dependency و Escalation می‌توان OpManager را از یک صفحه پر از چراغ رنگی به ابزار واقعی عملیات شبکه تبدیل کرد.
کلیدواژه‌های این راهنما: مانیتورینگ شبکه با OpManager، Threshold، Alarm Fatigue، NOC، Network Monitoring
