مانیتورینگ سرور: راهنمای عملی پایش و هشداردهی هوشمند

چرا مانیتورینگ سرور به یک استراتژی نیاز دارد، نه فقط ابزار

بیشتر تیم‌های فنی وقتی تازه مانیتورینگ سرور را راه می‌اندازند، همه‌چیز را پایش می‌کنند: CPU، RAM، دیسک، شبکه، سرویس‌ها. نتیجه؟ در روز اول ۴۰ هشدار دریافت می‌کنند، در روز سوم ۲۰، و در پایان هفته دیگر هیچ‌کس به هشدارها نگاه نمی‌کند. این پدیده «خستگی هشدار» (Alert Fatigue) است و دقیقاً همان چیزی است که باعث می‌شود یک قطعی واقعی ساعت‌ها بی‌صدا بماند.

مانیتورینگ سرور مؤثر یعنی بدانید چه چیزی را پایش کنید، چه آستانه‌ای منطقی است، و چه زمانی واقعاً باید به کسی زنگ بزنید. این مقاله یک نقشه راه عملی است: از انتخاب متریک‌های کلیدی تا تنظیم هشدارهایی که ارزش پاسخ‌دهی دارند.

چه چیزی را پایش کنیم؟ متریک‌های حیاتی که واقعاً مهم هستند

همه متریک‌ها ارزش یکسان ندارند. پایش ۲۰۰ متریک فقط نویز ایجاد می‌کند. تمرکز روی ۵–۷ متریک کلیدی که مستقیماً به تجربه کاربر و سلامت سرویس مرتبط‌اند، نتیجه بسیار بهتری دارد.

متریک‌های زیرساختی پایه

• CPU: میانگین بار (Load Average) را نسبت به تعداد هسته‌ها بسنجید. اگر لود اوریج روی یک سرور ۴ هسته‌ای به ۴ برسد، یعنی CPU کاملاً اشباع است. اما CPU بالا همیشه بد نیست؛ اگر سرویس شما پردازش ویدیو یا محاسبات سنگین انجام می‌دهد، ۸۰٪ استفاده عادی است.
• RAM: درصد استفاده مهم است، اما مهم‌تر از آن swap usage است. اگر سیستم شروع به سواپ کند، یعنی RAM واقعاً کم است و عملکرد به شدت افت می‌کند. آستانه هشدار برای سواپ را روی ۱۰٪ بگذارید، نه ۵۰٪.
• دیسک: پر شدن دیسک یکی از رایج‌ترین دلایل قطعی سرویس است. اما به‌جای هشدار روی ۸۰٪، به نرخ رشد فکر کنید. اگر دیسک ۷۰٪ پر است و روزانه ۲٪ رشد می‌کند، ۱۵ روز دیگر مشکل دارید. هشدار باید بر اساس پیش‌بینی باشد، نه فقط وضعیت لحظه‌ای.
• شبکه: پهنای باند مصرفی و خطاهای رابط شبکه (RX/TX errors) را پایش کنید. خطاهای شبکه اغلب نشانه خرابی سخت‌افزار یا کابل هستند و قبل از قطعی کامل ظاهر می‌شوند.

متریک‌های سرویس‌محور

زیرساخت فقط وسیله است. چیزی که واقعاً مهم است، سلامت سرویس شماست. این متریک‌ها را حتماً اضافه کنید:

• در دسترس بودن (Uptime): یک چک خارجی (External Check) از یک مکان دیگر که هر ۶۰ ثانیه به سایت یا API شما درخواست می‌فرستد. این تنها راهی است که می‌فهمید سرویس از دید کاربر واقعاً بالاست.
• زمان پاسخ (Latency): میانگین زمان پاسخ در ۵ دقیقه اخیر. اگر از ۵۰۰ میلی‌ثانیه به ۲ ثانیه برسد، چیزی خراب شده، حتی اگر CPU و RAM سالم باشند.
• خطاهای اپلیکیشن: تعداد خطاهای 5xx در وب‌سرور یا لاگ‌های خطای اپلیکیشن. این متریک معمولاً اولین نشانه یک باگ یا نشت حافظه است.
• صف‌های پیام (Message Queues): اگر از Redis یا RabbitMQ استفاده می‌کنید، طول صف را پایش کنید. رشد بی‌وقفه صف یعنی مصرف‌کننده (Consumer) از کار افتاده است.

تنظیم آستانه‌ها: چطور عدد مناسب را پیدا کنیم

آستانه‌ها را از روی حدس و گمان تنظیم نکنید. روش درست سه مرحله دارد:

1. دوره مبنا (Baseline) جمع کنید: حداقل ۲ هفته داده جمع‌آوری کنید بدون هیچ هشداری. ببینید در شرایط عادی، هر متریک چقدر نوسان دارد.
2. آستانه را روی ۲ تا ۳ برابر انحراف معیار بگذارید: اگر CPU در حالت عادی بین ۲۰ تا ۴۰٪ نوسان دارد، آستانه هشدار را روی ۷۰–۸۰٪ بگذارید، نه ۵۰٪. هشدارهای زودهنگام فقط نویز ایجاد می‌کنند.
3. آستانه را به‌مرور تنظیم کنید: بعد از هر حادثه واقعی، ببینید آیا آستانه زودتر از موعد هشدار داده یا دیرتر. آستانه‌ها باید موجود زنده باشند، نه یک بار برای همیشه.

مثال عملی: تنظیم هشدار برای دیسک

فرض کنید یک سرور دیتابیس با دیسک ۵۰۰ گیگابایت دارید. روش پیشنهادی:

# هشدار مرحله‌ای (Staged Alerts)
Warning:  disk usage > 75%  (اطلاع‌رسانی در تلگرام، بدون پیج)
Critical: disk usage > 85%  (پیامک + ایمیل به ادمین)
Emergency: disk usage > 92% (تماس تلفنی خودکار، فقط برای تیم آن‌کال)

# هشدار بر اساس نرخ رشد (برای پیش‌بینی)
اگر نرخ رشد روزانه > 1.5% و فضای باقی‌مانده < 20GB → هشدار فوری

نکته مهم: هشدار مرحله‌ای (Staged) باعث می‌شود تیم بداند هر هشدار چقدر اورژانسی است. اگر همه هشدارها یک‌سان باشند، تیم به‌سرعت بی‌حس می‌شود.

هشداردهی هوشمند: کمتر، اما مؤثرتر

هدف هشداردهی این نیست که هر مشکل کوچکی را گزارش کند. هدف این است که مشکلاتی که نیاز به اقدام انسانی دارند را گزارش کند. برای این کار چند تکنیک کلیدی وجود دارد:

۱. تجمیع و فشرده‌سازی هشدارها

اگر ۵ سرویس روی یک سرور از کار بیفتند، نباید ۵ هشدار جداگانه بفرستید. یک هشدار بفرستید که بگوید «سرور X از دسترس خارج شده و ۵ سرویس تحت تأثیر قرار گرفته‌اند». ابزارهایی مثل Alertmanager در Prometheus این کار را به‌صورت خودکار انجام می‌دهند.

۲. هشدار بر اساس وضعیت، نه رویداد

هشدار حالت (State-based) یعنی فقط وقتی وضعیت تغییر می‌کند هشدار بدهید، نه هر بار که چک انجام می‌شود. مثال:

# بد: هر ۵ دقیقه یک هشدار تا وقتی مشکل حل نشود
if cpu > 90% then alert

# خوب: فقط وقتی وضعیت از OK به CRITICAL تغییر کرد هشدار بده
state = OK
if cpu > 90% for 10 minutes then
    if state != CRITICAL then
        alert("CPU بحرانی شد")
        state = CRITICAL
    end
end

این کار به‌تنهایی تعداد هشدارها را ۹۰٪ کاهش می‌دهد.

۳. مدت زمان تداوم (Duration) را در نظر بگیرید

یک پیک ۵ ثانیه‌ای CPU معمولاً بی‌ضرر است. یک پیک ۱۵ دقیقه‌ای مشکل واقعی است. برای هر هشدار یک مدت زمان تداوم تعیین کنید:

• CPU > 90%: حداقل ۱۰ دقیقه تداوم
• دیسک > 85%: حداقل ۳۰ دقیقه تداوم (چون رشد دیسک تدریجی است)
• سرویس Down: بلافاصله (۰ دقیقه تداوم)

۴. مسیرهای اطلاع‌رسانی را لایه‌بندی کنید

همه هشدارها نباید به همه کانال‌ها بروند. یک ساختار پیشنهادی:

1. هشدارهای اطلاع‌رسانی (Info): فقط به کانال تلگرام یا Slack تیم. نیازی به اقدام فوری نیست.
2. هشدارهای هشدار (Warning): ایمیل + پیام به ادمین آن‌کال. باید ظرف ۱ ساعت بررسی شود.
3. هشدارهای بحرانی (Critical): پیامک + تماس تلفنی خودکار. باید ظرف ۱۵ دقیقه اقدام شود.

ابزارهای پیشنهادی و یک نمونه پیکربندی عملی

ابزارهای متن‌باز زیادی برای مانیتورینگ سرور وجود دارند. ترکیب Prometheus + Alertmanager + Grafana استاندارد صنعت است و برای تیم‌های کوچک و بزرگ جواب می‌دهد. اگر زیرساخت ساده‌تری دارید، Netdata یا Zabbix گزینه‌های سبک‌تری هستند.

یک نمونه قانون هشدار در Prometheus که مفاهیم بالا را پیاده می‌کند:

groups:
  - name: server-alerts
    rules:
      - alert: HighCPULoad
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU بالای ۹۰٪ روی {{ $labels.instance }}"

      - alert: DiskWillFillIn24h
        expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 24*3600) < 0
        for: 30m
        labels:
          severity: critical
        annotations:
          summary: "دیسک ریشه تا ۲۴ ساعت آینده پر خواهد شد"

توجه کنید که قانون دوم از تابع predict_linear استفاده می‌کند که نرخ رشد را پیش‌بینی می‌کند — این همان «هشدار بر اساس پیش‌بینی» است که در بخش آستانه‌ها گفتیم.

چگونه خستگی هشدار را از بین ببریم

اگر تیم شما هشدارها را نادیده می‌گیرد، مشکل از تیم نیست، از سیستم هشداردهی است. سه اصل طلایی:

• هر هشدار باید یک اقدام مشخص داشته باشد: اگر هشدار «CPU بالا» می‌فرستید، باید دقیقاً مشخص باشد که چه کسی، چه کاری، در چه زمانی انجام دهد. اگر اقدام مشخصی وجود ندارد، آن هشدار را حذف کنید.
• هر هشدار باید قابل آزمایش باشد: حداقل ماهی یک‌بار یک سناریوی خطای واقعی (مثلاً متوقف کردن یک سرویس) را شبیه‌سازی کنید و ببینید آیا هشدار درست می‌آید و به فرد درست می‌رسد.
• بازبینی دوره‌ای هشدارها: هر ماه یک جلسه ۳۰ دقیقه‌ای بگذارید و همه هشدارهای ماه گذشته را مرور کنید. هر هشداری که به اقدام منجر نشده را حذف یا اصلاح کنید.

جمع‌بندی: مانیتورینگ سرور یعنی آرامش، نه اضطراب

مانیتورینگ سرور خوب، سیستمی است که وقتی همه‌چیز عادی است، ساکت باشد و وقتی مشکلی واقعی پیش می‌آید، دقیقاً به فرد مناسب، در زمان مناسب، با اطلاعات کافی اطلاع دهد. با پایش متریک‌های درست، تنظیم آستانه‌های مبتنی بر داده، و طراحی هشدارهای مرحله‌ای، می‌توانید از قطعی‌های پرهزینه جلوگیری کنید و تیم‌تان را از خستگی هشدار نجات دهید.

اگر به‌دنبال زیرساختی هستید که این ابزارها را به‌راحتی روی آن اجرا کنید، سرورنت بستر ابری مناسبی برای راه‌اندازی مانیتورینگ سرور فراهم می‌کند. اما مهم‌تر از هر ابزاری، فرآیندی است که در این مقاله توضیح دادیم — آن را اجرا کنید و نتیجه را ببینید.