Threshold Profile در Applications Manager؛ هشدار دقیق به‌جای Alert Flood

مانیتورینگ بدون Threshold فقط جمع‌آوری عدد است. تا وقتی مشخص نکنیم چه زمانی CPU، Memory، Response Time، Queue، Session یا هر Metric دیگر از وضعیت عادی خارج شده، داشبورد فقط داده نشان می‌دهد. در ManageEngine Applications Manager، Thresholdها همان مرزی هستند که داده را به Alert عملیاتی تبدیل می‌کنند.

مشکل از جایی شروع می‌شود که Thresholdها با حدس، کپی‌کردن یا یک عدد ثابت برای همه سیستم‌ها تعریف شوند. نتیجه معمولاً Alert Flood، بی‌اعتمادی تیم NOC و نادیده‌گرفتن هشدارهای مهم است. هدف این آموزش طراحی Threshold Profile قابل اتکاست؛ نه صرفاً فعال‌کردن Alarm.

Threshold Profile چیست؟

Threshold Profile مجموعه‌ای از قواعد هشدار برای Metricهاست که می‌تواند سطح‌هایی مانند Warning و Critical را تعریف کند و به Monitorها یا گروهی از Monitorها اعمال شود. این مدل باعث می‌شود به‌جای تنظیم جداگانه هر Attribute، سیاست هشدار قابل استفاده مجدد داشته باشید.

Profile زمانی ارزشمند است که چند Monitor رفتار مشابهی دارند؛ مثلاً سرورهای یک Tier، پایگاه‌داده‌های Production یا سرویس‌های یک Business Service.

اول Baseline، بعد Threshold

قبل از تعیین عدد، رفتار واقعی سیستم را ببینید. CPU یک سرور ممکن است در ساعات کاری دائماً ۷۵ درصد باشد و کاملاً سالم کار کند، در حالی که برای سرور دیگری همین مقدار نشانه Bottleneck باشد. Response Time نیز بدون Context قابل قضاوت نیست.

چند روز یا چند هفته داده تاریخی را بررسی کنید و Patternهای ساعت کاری، Batch Job، Backup، Month-end و Peak Usage را بشناسید. Threshold خوب باید رفتار عادی را از وضعیت غیرعادی جدا کند.

Warning و Critical را متفاوت تعریف کنید

Warning برای «نیاز به توجه» است؛ Critical برای «نیاز به اقدام». اگر هر دو تقریباً یک مقدار داشته باشند، تیم عملیات زمان واکنش مرحله‌ای را از دست می‌دهد.

برای مثال می‌توانید Warning را زمانی فعال کنید که Response Time از Baseline معنادار فاصله می‌گیرد و Critical را برای سطحی قرار دهید که تجربه کاربر یا SLA واقعاً در خطر است. عدد دقیق باید از داده همان سرویس استخراج شود.

Metric درست مهم‌تر از عدد درست است

گاهی تیم‌ها روی CPU تمرکز می‌کنند در حالی که مشکل اصلی Queue Length، Connection Pool، Disk Latency یا Transaction Time است. Threshold روی Metric اشتباه حتی اگر عددش دقیق باشد، ارزش کمی دارد.

برای هر سرویس از خودتان بپرسید: «کدام Metric زودتر از شکایت کاربر نشان می‌دهد سرویس در حال افت است؟» این سؤال معمولاً Alert Design را بهتر از تنظیم کورکورانه انجام می‌دهد.

Threshold را بر اساس Business Service طراحی کنید

همه Monitorها اهمیت یکسان ندارند. یک Development Server نباید همان حساسیت سیستم پرداخت Production را داشته باشد. Applications Manager با Monitor Groupها کمک می‌کند Monitoring را حول سرویس کسب‌وکار سازمان‌دهی کنید.

اگر هنوز ساختار گروهی ندارید، مقاله ساخت Monitor Group در Applications Manager مکمل این آموزش است.

از Alert Flood جلوگیری کنید

یکی از بدترین طراحی‌ها، Thresholdی است که با هر Spike کوتاه Alert تولید می‌کند. باید بررسی کنید آیا Metric لازم است برای چند Poll متوالی از حد عبور کند یا یک جهش لحظه‌ای هم اهمیت دارد.

این تصمیم به نوع Metric وابسته است. یک Failure در Availability ممکن است فوری مهم باشد، اما CPU Spike چندثانیه‌ای لزوماً Incident نیست.

وابستگی‌ها را در نظر بگیرید

اگر Database Down شود، ده‌ها Application وابسته ممکن است هم‌زمان هشدار بدهند. اگر تیم عملیات فقط Alertهای فرزند را ببیند، Root Cause گم می‌شود.

Threshold Design باید در کنار Dependency و RCA دیده شود. هدف این نیست که «بیشترین Alert» تولید شود؛ هدف این است که «کمترین Alert لازم برای تصمیم درست» تولید شود.

Threshold ثابت یا پویا؟

Threshold ثابت برای Metricهایی مناسب است که Limit فنی یا SLA مشخص دارند. Threshold پویا یا Baseline-based زمانی مفید است که رفتار سیستم در ساعت‌ها و روزهای مختلف تغییر می‌کند.

اگر ظرفیت سرویس در طول روز متغیر است، Threshold ثابت ممکن است صبح حساسیت بیش از حد و عصر حساسیت کم داشته باشد. در چنین شرایطی باید از قابلیت‌های Baseline و رفتار تاریخی Applications Manager استفاده کنید.

سناریوی عملی: Response Time وب‌سرویس

فرض کنید API معمولاً در ۳۰۰ تا ۵۰۰ میلی‌ثانیه پاسخ می‌دهد. در Peak Hour تا ۸۰۰ میلی‌ثانیه طبیعی است، اما بالاتر از ۱.۵ ثانیه کاربران افت را حس می‌کنند. اگر Threshold روی ۶۰۰ میلی‌ثانیه باشد، تیم دائماً هشدار می‌گیرد؛ اگر روی ۵ ثانیه باشد، خیلی دیر متوجه می‌شود.

راه درست این است که داده تاریخی، SLA و تجربه کاربر را کنار هم بگذارید و Warning و Critical را با فاصله معنادار تعریف کنید.

سناریوی عملی: Disk Usage

برای Disk Usage، فقط درصد مصرف مهم نیست؛ سرعت رشد هم مهم است. دیسکی که امروز ۸۰ درصد پر است اما شش ماه ثابت مانده، با دیسکی که در دو روز از ۵۰ به ۸۰ رسیده یکسان نیست.

Threshold باید با Capacity Planning ترکیب شود. هشدار زمانی ارزشمند است که فرصت اقدام ایجاد کند، نه وقتی فضای دیسک عملاً تمام شده است.

Maintenance و Schedule را فراموش نکنید

اگر سیستم در بازه نگهداری رسمی عمداً Restart می‌شود، Alert Availability در آن بازه ارزش عملیاتی ندارد. نگهداری برنامه‌ریزی‌شده را با Maintenance Window و Schedule هماهنگ کنید.

این کار Noise را کم می‌کند و مهم‌تر از آن، اعتماد تیم به Alarmها را حفظ می‌کند.

چه کسانی باید Threshold را تعیین کنند؟

فقط تیم Monitoring نه. Application Owner، DBA، Infra و در سرویس‌های حساس حتی Service Owner باید در تعریف Threshold نقش داشته باشند. NOC می‌داند چه چیزی قابل عملیات است، اما Owner سرویس بهتر می‌داند چه سطحی واقعاً روی کاربر اثر می‌گذارد.

Threshold خوب نقطه اتصال Technical Metric و Business Impact است.

چطور Profileها را نام‌گذاری کنیم؟

نام‌هایی مثل Profile1 یا Critical2 بعد از چند ماه بی‌معنا می‌شوند. از الگوی قابل فهم استفاده کنید؛ مثلاً PROD-WEB-RESPONSE، DB-STORAGE-CAPACITY یا SAP-AVAILABILITY.

نام باید Scope و هدف Profile را نشان دهد. اگر Versioning یا Change Control دارید، Owner و تاریخ بازبینی را هم مستند کنید.

Threshold را بعد از Incident بازبینی کنید

هر Major Incident فرصتی برای بازبینی Monitoring است. سؤال کنید: آیا Threshold قبل از شکایت کاربر هشدار داد؟ اگر داد، آیا خیلی زود یا خیلی دیر بود؟ آیا Alert درست به تیم درست رسید؟

اگر جواب منفی است، Incident فقط مشکل سرویس نبوده؛ مشکل Monitoring Design هم بوده است.

KPIهای کیفیت Alert

تعداد Alert معیار موفقیت نیست. بهتر است False Positive Rate، درصد Alertهای Actionable، تعداد Alertهای تکراری برای یک Root Cause و Lead Time بین Warning و Impact واقعی را بسنجید.

اگر Alert زیاد است ولی اقدام کمی از آن حاصل می‌شود، Thresholdها نیاز به بازطراحی دارند.

Threshold و Automation

بعد از اینکه Alert قابل اعتماد شد، می‌توان آن را به Notification، Ticket Creation یا Automation متصل کرد. اما Automation روی Alert بی‌کیفیت فقط Noise را سریع‌تر پخش می‌کند.

اول کیفیت Signal را درست کنید؛ بعد Workflow را خودکار کنید.

ارتباط با ServiceDesk Plus

در محیط‌هایی که Applications Manager با ServiceDesk Plus یکپارچه است، Alertهای مهم می‌توانند به Incident تبدیل شوند. اینجا Severity Mapping اهمیت دارد؛ Warning نباید الزاماً Ticket بحرانی بسازد.

هدف Integration این است که فقط رخدادهای Actionable وارد ITSM شوند.

یک Checklist کوتاه برای Threshold خوب

آیا Metric به تجربه سرویس مرتبط است؟ آیا Baseline را دیده‌اید؟ آیا Warning و Critical فاصله منطقی دارند؟ آیا Spike کوتاه را از وضعیت پایدار جدا کرده‌اید؟ آیا Maintenance حذف شده؟ آیا Owner مشخص است؟ آیا بعد از Incident بازبینی می‌شود؟

اگر پاسخ بیشتر این سؤال‌ها مثبت باشد، احتمالاً Alert Design شما قابل اعتمادتر خواهد بود.

سخن پایانی

Threshold Profile در Applications Manager چیزی بیشتر از چند عدد است؛ ترجمه رفتار فنی سیستم به زبان عملیات است. Threshold ضعیف باعث Alert Fatigue می‌شود و Threshold خوب فرصت واکنش قبل از اثر جدی روی کاربر ایجاد می‌کند.

از Baseline شروع کنید، Metricهای معنادار را انتخاب کنید، Warning و Critical را هدفمند بسازید و کیفیت Alert را مثل هر Service دیگری اندازه بگیرید. Monitoring زمانی بالغ می‌شود که تیم به هشدارها اعتماد کند.

منابع

ManageEngine Applications Manager Help
ManageEngine Applications Manager