Alarm در OpManager فقط وقتی ارزش عملیاتی پیدا می‌کند که به فرد یا تیم درست، در زمان درست و با اطلاعات کافی برسد. اگر همه Alarmها به یک Mailbox فرستاده شوند، تیم NOC خیلی زود با Alert Fatigue روبه‌رو می‌شود. اگر Notification بدون Criteria یا Time Window طراحی شود، رخداد کم‌اهمیت نصف شب همان رفتاری را ایجاد می‌کند که یک Critical Alarm روی Core Switch. راه درست این است که Notification Profile بر اساس Severity، نوع Event، Device Group، زمان کاری و نیاز واقعی Escalation طراحی شود.

این راهنما بر اساس مستند رسمی ManageEngine برای OpManager نوشته شده و مسیر ساخت Notification Profile را از انتخاب نوع اعلان تا Criteria، Device Assignment، Time Window، Delayed Trigger و کنترل Duplicate Notification پوشش می‌دهد.

سناریوی واقعی

فرض کنید سازمان سه تیم دارد: NOC، Network Engineering و تیم On-call شبانه. می‌خواهید Critical Alarmهای تجهیزات Core بلافاصله به NOC برسند، اگر ۱۰ دقیقه Acknowledge نشدند به تیم On-call تکرار شوند، و هشدارهای Warning مربوط به Access Switchها فقط در ساعات کاری ایمیل شوند. اگر همه این رفتارها در یک Profile عمومی تعریف شوند، کنترل و عیب‌یابی سخت می‌شود. بهتر است Profileها بر اساس هدف عملیاتی تفکیک شوند.

پیش‌نیازها

مرحله ۱: مسیر Notification Profiles را باز کنید

در OpManager به Settings > Notifications > Notification Profiles بروید و روی Add کلیک کنید. این همان مسیر رسمی فعلی برای ساخت Profile جدید است.

در همین صفحه Profileهای موجود را نیز می‌بینید و می‌توانید بعداً آن‌ها را Enable یا Disable کنید. برای تغییر آزمایشی بهتر است Profile جدید بسازید و Profile Production را بی‌دلیل دستکاری نکنید.

مرحله ۲: نوع Notification را انتخاب کنید

OpManager چند نوع Profile ارائه می‌کند، از جمله Email، Email-based SMS، SMS، Chat، Run a system command، Run a program، Log a ticket، Web alarm، Syslog، Trap، Webhook، Ansible Integration، Custom Integration و SIEM Integration.

نوع را بر اساس Workflow انتخاب کنید. اگر هدف فقط اطلاع‌رسانی انسانی است، Email یا Chat معمولاً کافی است. اگر Alarm باید وارد Workflow یک سامانه دیگر شود، Webhook یا Log a ticket منطقی‌تر است. اگر قصد اجرای Action خودکار دارید، Command یا Program نیازمند کنترل امنیتی بیشتری است.

مرحله ۳: پیام را با Variableهای مفید بسازید

در هنگام ساخت Profile می‌توانید Variableهای پویا را در Subject، Message، Title یا Argument قرار دهید. هدف این است که گیرنده بدون باز کردن چند صفحه اضافی بفهمد چه Deviceای، با چه Alarmی و در چه وضعیتی مشکل دارد.

پیام خوب معمولاً شامل Device Name، IP، Severity، Alarm Message و زمان رخداد است. از پر کردن پیام با ده‌ها Variable غیرضروری خودداری کنید؛ پیام On-call باید سریع قابل فهم باشد.

مرحله ۴: Criteria را دقیق تنظیم کنید

بعد از مشخصات Notification، OpManager مرحله Criteria را نمایش می‌دهد. اینجا تعیین می‌کنید Profile در چه شرایطی Trigger شود. مثلاً می‌توانید Profile را فقط برای Alarmهای Critical یا برای Event Ruleهای مشخص محدود کنید.

چرا Criteria مهم است؟

اگر Profile بدون Scope مناسب روی همه Alarmها اعمال شود، Notification Channel خیلی سریع پر می‌شود. نتیجه معمولاً این است که تیم اعلان‌ها را Ignore می‌کند و حتی Alarm واقعی هم دیده نمی‌شود.

مرحله ۵: Device یا Group هدف را انتخاب کنید

در مرحله انتخاب Device، تجهیزات موردنظر را به ستون Selected Devices منتقل کنید. در نسخه‌های جدید، OpManager امکان اعمال Profile به Device Group یا Interface Group را نیز فراهم کرده است.

برای محیط بزرگ، Group-based Assignment معمولاً بهتر از انتخاب دستی تک‌تک Deviceهاست. مثلاً گروه Core، Branch-Routers یا Datacenter-Firewalls را جدا نگه دارید تا تغییر Scope بدون ویرایش ده‌ها Profile انجام شود.

مرحله ۶: Time Window را طراحی کنید

OpManager اجازه می‌دهد Profile همیشه فعال باشد یا فقط در Time Window مشخص Trigger شود. می‌توانید ساعت شروع و پایان و روزهای هفته را تعیین کنید. برای بازه‌ای که از نیمه‌شب عبور می‌کند نیز مستند رسمی مثال می‌زند که From را دیرتر از To تنظیم کنید؛ مثلاً 18:00 تا 06:00.

این قابلیت برای جدا کردن تیم Day Shift و On-call بسیار کاربردی است. به جای اینکه یک Profile با Recipientهای زیاد بسازید، می‌توانید Profileهای جداگانه برای ساعات مختلف داشته باشید.

مرحله ۷: Delayed Trigger را برای کاهش Noise استفاده کنید

در بخش Time Window می‌توانید Trigger after را بر حسب دقیقه تنظیم کنید. این یعنی Notification فقط زمانی ارسال شود که Alarm بیش از آن مدت باقی مانده باشد.

گزینه Do not trigger if alarm is acknowledged بسیار مهم است. اگر ادمین Alarm را قبل از پایان Delay Acknowledge کرده باشد، Notification اضافی ارسال نمی‌شود. این رفتار برای Warningهایی که معمولاً سریع بررسی می‌شوند، Noise را کاهش می‌دهد.

مرحله ۸: Recurring Trigger را برای Escalation کنترل‌شده تنظیم کنید

Recurring Trigger باعث می‌شود Profile در بازه‌های مشخص دوباره اجرا شود تا Alarm Clear شود. می‌توانید Trigger Interval و حداکثر تعداد تکرار را تعیین کنید.

مثلاً اگر Interval برابر ۱۰ دقیقه و تعداد Trigger برابر ۵ باشد، Notification هر ۱۰ دقیقه تا ۵ بار یا تا زمان Clear شدن Alarm تکرار می‌شود. اگر تعداد را خالی بگذارید، تکرار تا Clear شدن ادامه پیدا می‌کند. برای جلوگیری از مزاحمت بعد از Acknowledge، گزینه عدم Trigger در صورت Acknowledge را فعال کنید.

مرحله ۹: Duplicate Notification را کنترل کنید

اگر یک Device عضو چند Group باشد، OpManager برای یک Profile مشترک Duplicate Notification را به‌صورت داخلی کنترل می‌کند. اما اگر همان Device در Groupهایی باشد که Profileهای متفاوت دارند، ممکن است چند Notification منطقی ولی ناخواسته تولید شود.

ManageEngine برای نسخه‌های جدید گزینه Ignore Notifications for Group را برای مدیریت این وضعیت ارائه کرده است. در طراحی Groupها از ابتدا مشخص کنید کدام Group Parent و کدام Group تخصصی است تا یک Alarm چند مسیر موازی غیرضروری نداشته باشد.

مرحله ۱۰: Profile را قبل از Production تست کنید

یک Device آزمایشی یا Group کوچک انتخاب کنید و Alarm کنترل‌شده بسازید. سپس این موارد را Verify کنید:

• Profile فقط در Severity موردنظر Trigger می‌شود.
• Device خارج از Scope Notification دریافت نمی‌کند.
• Time Window درست اعمال می‌شود.
• Delayed Trigger قبل از زمان تعیین‌شده اجرا نمی‌شود.
• Acknowledge مانع Notification غیرضروری می‌شود.
• Recurring Trigger بیش از تعداد تعیین‌شده تکرار نمی‌شود.
• Message شامل Device و Context کافی است.

الگوی پیشنهادی سه‌لایه

این فقط یک مدل نمونه است؛ Severity و Delay باید با SLA و Operational Model واقعی سازمان تنظیم شوند.

Notification جای Threshold خوب را نمی‌گیرد

اگر Threshold یا Event Rule بد طراحی شده باشد، Profile فقط Noise را سریع‌تر توزیع می‌کند. برای طراحی Alerting رویدادمحور، مقاله SNMP Trap و Syslog در OpManager مکمل این آموزش است. برای معماری پایه و Roleها نیز راهنمای ادمین OpManager را ببینید.

در محیط‌هایی که ده‌ها Site و چند شیفت NOC دارند، طراحی Notification باید همراه با Grouping، Escalation و Integration با ITSM انجام شود. اگر این مدل هنوز پراکنده است، آموزش تخصصی مانیتورینگ مدانت می‌تواند Profileها را بر اساس سناریوی واقعی NOC طراحی کند، نه صرفاً فعال کردن Email.

Troubleshooting سریع

چک‌لیست نهایی

• Profile نام قابل فهم دارد.
• Notification Type با Workflow واقعی هماهنگ است.
• Criteria محدود و مشخص است.
• Device/Group Scope بازبینی شده است.
• Time Window صحیح است.
• Delay و Recurring Trigger فقط در صورت نیاز فعال شده‌اند.
• Duplicate Notification بررسی شده است.
• Profile روی Pilot تست شده است.
• پیام Alert Context کافی دارد.

سخن پایانی

Notification Profile خوب یعنی رساندن Alarm درست به فرد درست در زمان درست. هدف افزایش تعداد پیام‌ها نیست؛ هدف کاهش زمان تشخیص و پاسخ است. اگر Criteria، Scope، Time Window و Escalation دقیق طراحی شوند، OpManager از یک مانیتور تولیدکننده Alarm به ابزار عملیاتی قابل اتکای NOC تبدیل می‌شود.

منابع

• ManageEngine OpManager — Configuring Notification Profiles
• ManageEngine OpManager — Notifications REST API