ساعت ۲ بامداد، تلفن زنگ می‌زند. مشتری می‌گوید سایت از کار افتاده. شما که خواب بودید حالا باید بدون هیچ اطلاعاتی شروع به عیب‌یابی کنید. اما اگر مانیتورینگ داشتید، ساعت ۱:۴۸ هشداری دریافت می‌کردید که CPU سرور به ۹۵٪ رسیده — قبل از اینکه سایت واقعاً down شود.

مانیتورینگ سرور یعنی جمع‌آوری مداوم داده‌ها، تحلیل روندها و اطلاع‌رسانی فوری هنگام بروز مشکل. این راهنما همه جنبه‌های آن را پوشش می‌دهد: از متریک‌های مهم و ابزارهای ساده تا سیستم‌های پیشرفته alerting.

متریک‌های حیاتی که باید مانیتور کنید

CPU

CPU بالا نشانه مشکل است. دلایل احتمالی:

  • ترافیک غیرعادی یا حمله DDoS
  • کد ناکارآمد با حلقه‌های بی‌نهایت یا query های سنگین
  • پروسس‌های معیوب که در حلقه گیر کرده‌اند
  • cryptomining malware — اگر CPU ناگهان پریده بالا بدون دلیل مشخص، این گزینه را جدی بگیرید

آستانه هشدار معمول: CPU بالای ۸۰٪ برای بیش از ۵ دقیقه. برای بررسی لحظه‌ای، دستور htop نشان می‌دهد کدام پروسس بیشترین CPU می‌گیرد.

RAM (حافظه)

وقتی RAM تمام می‌شود، سرور شروع به استفاده از swap می‌کند که روی دیسک است و بسیار کندتر. این می‌تواند سرور را کامل از کار نیندازد اما عملکرد آن را به شدت تخریب کند. دلایل مصرف زیاد RAM:

  • Memory leak در اپلیکیشن
  • تعداد زیاد درخواست‌های همزمان
  • Worker های زیاد PHP-FPM یا Nginx
  • دیتابیس با buffer pool بزرگ

آستانه هشدار: RAM بالای ۸۵٪. دستور مفید: free -m — خط دوم (Mem) نشان می‌دهد چقدر آزاد است.

فضای دیسک

پر شدن دیسک یکی از رایج‌ترین و قابل پیشگیری‌ترین مشکلات است. وقتی دیسک کاملاً پر شود، وب سرور دیگر نمی‌تواند حتی فایل‌های log بنویسد و ممکن است crash کند. عوامل اصلی:

  • فایل‌های لاگ که rotate نمی‌شوند — این شایع‌ترین دلیل است
  • بکاپ‌های قدیمی که پاک نشده‌اند
  • فایل‌های آپلودی کاربران
  • session files انباشته شده
  • فایل‌های tmp پردازش‌های قدیمی

آستانه هشدار: دیسک ۸۵٪ پر. هشدار بحرانی: ۹۵٪. دستور: df -h برای کل سیستم، du -sh /var/log/* برای پیدا کردن پوشه‌های سنگین.

ترافیک شبکه

ترافیک غیرعادی می‌تواند نشانه حمله DDoS، اسکن بدافزار یا حتی کاربری باشد که فایل‌های بزرگ دانلود می‌کند. باید موارد زیر را مانیتور کنید:

  • Bandwidth مصرفی (inbound و outbound) در طول زمان
  • تعداد اتصالات همزمان
  • packet error و drop rate — اگر بالا باشد مشکل سخت‌افزاری یا شبکه دارید

آپتایم سرویس‌ها

وب سرور، دیتابیس، Redis، PHP-FPM و هر سرویسی که پروژه به آن وابسته است باید مانیتور شود. اگر MySQL از کار بیفتد و کسی نفهمد، تمام سایت down است. یک دستور سریع برای چک وضعیت:

  • systemctl status nginx
  • systemctl status mysql
  • systemctl status php8.1-fpm

زمان پاسخ و Uptime سایت

از خارج سرور، سایت را چک کنید: چقدر طول می‌کشد لود شود؟ این متفاوت از مانیتورینگ منابع سرور است. سایت ممکن است از داخل سرور در دسترس به نظر برسد اما از نظر کاربران خارجی down باشد — مثلاً به دلیل مشکل DNS یا CDN.

Queue Jobs (صف پردازش)

اگر از queue برای پردازش‌های پس‌زمینه (ارسال ایمیل، پردازش تصویر) استفاده می‌کنید، تعداد job های در انتظار را مانیتور کنید. اگر صف مدام رشد می‌کند، worker های کافی ندارید یا worker ها crash کرده‌اند.

ابزارهای مانیتورینگ: از ساده تا پیشرفته

ابزارهای Command Line

برای مانیتورینگ سریع از خط فرمان، این ابزارها همیشه در دسترس هستند:

  • htop: نمایش لحظه‌ای CPU، RAM و لیست پروسس‌ها با رابط رنگی. نسخه بهبود یافته top است
  • df -h: فضای دیسک همه partition ها به صورت خوانا
  • iostat: آمار I/O دیسک — اگر سرور کند است و CPU پایین است، I/O گلوگاه است
  • ss -tn state established: اتصالات TCP فعال
  • iftop: نمایش لحظه‌ای ترافیک شبکه بر اساس IP
  • vmstat 1 5: آمار حافظه مجازی، CPU و I/O هر ثانیه (۵ بار)

سرویس‌های آنلاین مانیتورینگ Uptime

این سرویس‌ها از خارج سرور، دسترسی به سایت را چک می‌کنند و اگر down شود هشدار می‌فرستند:

  • UptimeRobot: رایگان، هر ۵ دقیقه چک می‌کند. ایمیل، SMS یا Telegram می‌فرستد. برای اکثر سایت‌ها کافی است
  • Freshping: مشابه UptimeRobot با چک هر ۱ دقیقه در پلن رایگان
  • Pingdom: علاوه بر uptime، عملکرد سایت را هم مانیتور می‌کند
  • Better Uptime: ادغام با Slack، alerting پیشرفته و status page

ابزارهای APM (Application Performance Monitoring)

APM ها نه فقط سرور، بلکه اپلیکیشن را هم مانیتور می‌کنند: کدام endpoint کند است؟ کدام query دیتابیس وقت زیادی می‌گیرد؟ کجا خطا رخ می‌دهد؟

  • New Relic: مانیتورینگ کامل اپلیکیشن، دیتابیس، خطاها و تجربه کاربر. برای PHP، Node.js، Python و زبان‌های دیگر agent دارد
  • Datadog: یکی از کامل‌ترین پلتفرم‌های مانیتورینگ — Metrics، لاگ، APM و tracing را یکجا مدیریت می‌کند
  • Sentry: تخصصی برای ردیابی خطاهای اپلیکیشن. وقتی یک exception رخ می‌دهد، Sentry آن را با stack trace، دیتای request و context کامل ثبت می‌کند

سیستم‌های مانیتورینگ متن‌باز

اگر می‌خواهید همه چیز روی سرور خودتان باشد، این ابزارها عالی هستند:

  • Prometheus + Grafana: محبوب‌ترین ترکیب. Prometheus داده‌های time-series جمع‌آوری می‌کند و Grafana داشبوردهای زیبا می‌سازد. برای Kubernetes و container ها بسیار مناسب است
  • Netdata: نصب با یک دستور، بلافاصله داشبورد real-time می‌دهد. برای شروع سریع عالی است
  • Zabbix: سیستم مانیتورینگ کامل و بالغ. agent روی سرورهای target نصب می‌کنید و همه چیز را مانیتور می‌کند. برای زیرساخت‌های بزرگ مناسب است
  • Nagios: یکی از قدیمی‌ترین و پایدارترین ابزارهای مانیتورینگ با plugin های زیاد

ELK Stack برای لاگ‌ها

ELK (Elasticsearch + Logstash + Kibana) برای جمع‌آوری، ذخیره و جستجو در لاگ‌ها ایده‌آل است. تمام لاگ‌های سرورهای مختلف را یکجا جمع می‌کند و می‌توانید با زبان Lucene Query جستجو کنید. Loki + Grafana گزینه سبک‌تری است که برای تیم‌های کوچک‌تر مناسب‌تر است.

راه‌اندازی سیستم Alerting

مانیتورینگ بدون alerting تقریباً بی‌فایده است. باید وقتی مشکلی پیش می‌آید، فوری مطلع شوید — نه وقتی که کاربر گزارش می‌دهد.

کانال‌های Alert

  • ایمیل: برای مشکلات غیر اورژانسی یا گزارش‌های روزانه مناسب است
  • SMS: برای مشکلات بحرانی که نیاز به اقدام فوری دارند — ساعت ۳ بامداد ایمیل نمی‌بینید
  • Slack یا Teams: برای اطلاع‌رسانی به تیم در ساعات کاری
  • PagerDuty: برای on-call rotation — می‌توانید تعریف کنید کدام عضو تیم در چه ساعتی مسئول است

سطح‌بندی Alert ها

نه همه مشکلات یکسان هستند. سطح‌بندی کنید تا هر alert معنادار باشد:

  • Warning: وضعیت نگران‌کننده اما هنوز بحران نیست — CPU بالای ۷۰٪، دیسک ۸۰٪ پر
  • Critical: مشکل جدی که نیاز به اقدام فوری دارد — سایت down، CPU بالای ۹۵٪، دیسک ۹۵٪ پر

Alert Fatigue: دشمن پنهان

اگر alert های زیادی بفرستید که اهمیت واقعی ندارند، تیم به مرور آن‌ها را نادیده می‌گیرد. این وضعیت به اصطلاح "alert fatigue" است و خطرناک‌تر از نداشتن alert است. threshold ها را واقع‌بینانه تنظیم کنید و فقط برای چیزهایی alert بفرستید که واقعاً نیاز به اقدام دارند.

داشبورد مانیتورینگ

یک داشبورد خوب به شما امکان می‌دهد با یک نگاه وضعیت سرور را بفهمید. Grafana محبوب‌ترین ابزار برای ساخت داشبورد است. یک داشبورد کامل شامل:

  • نمودار CPU، RAM و دیسک در ۲۴ ساعت گذشته
  • وضعیت سرویس‌های اصلی (سبز/قرمز)
  • تعداد request در ثانیه
  • Error rate — درصد درخواست‌هایی که با خطا پاسخ داده شدند
  • زمان پاسخ متوسط و P95 (percentile 95)

مانیتورینگ دیتابیس

دیتابیس اغلب گلوگاه عملکرد است و نیاز به مانیتورینگ اختصاصی دارد:

  • Slow queries: در MySQL با slow_query_log=1 و long_query_time=1 فعال کنید — کوئری‌هایی که بیشتر از ۱ ثانیه طول می‌کشند ثبت می‌شوند
  • تعداد اتصالات فعال در مقایسه با max_connections
  • Buffer pool hit rate — باید بالای ۹۵٪ باشد وگرنه buffer pool کوچک است
  • Replication lag اگر replica دارید — تاخیر بالا نشانه مشکل است

سوالات متداول

از کجا شروع کنم؟

گام اول: UptimeRobot رایگان را راه‌اندازی کنید تا اگر سایت down شد فوری ایمیل بگیرید. گام دوم: Netdata را نصب کنید (یک دستور نصب دارد) تا داشبورد real-time از سرور داشته باشید. گام سوم: alerting مناسب تنظیم کنید برای CPU، RAM و دیسک. این سه قدم برای اکثر سایت‌ها کافی است.

مانیتورینگ هر چند وقت باید داده جمع کند؟

برای uptime monitoring، هر ۱ تا ۵ دقیقه کافی است. برای متریک‌های سرور، هر ۱۰ تا ۶۰ ثانیه معمول است. برای لاگ‌ها، باید real-time یا نزدیک به real-time باشد. هرچه فرکانس بیشتر باشد، ذخیره‌سازی بیشتری نیاز دارید. Prometheus پیش‌فرض ۱۵ ثانیه دارد که برای اکثر موارد مناسب است.

چقدر داده مانیتورینگ را نگه دارم؟

یک رویکرد منطقی: داده‌های دقیق (scrape interval) را ۷ روز نگه دارید، داده‌های aggregate شده هر ساعت را ۳۰ روز، و داده‌های روزانه را ۱ سال. برای لاگ‌ها معمولاً ۳۰ تا ۹۰ روز کافی است — بیشتر از این حجم زیادی اشغال می‌کند بدون فایده عملی.

آیا مانیتورینگ خودش روی سرور تأثیر می‌گذارد؟

مانیتورینگ سبک (مثل Prometheus node exporter یا Netdata) تأثیر ناچیزی دارد — معمولاً کمتر از ۱٪ CPU. اما APM هایی مثل New Relic overhead بیشتری دارند چون کد اپلیکیشن را instrument می‌کنند. در اکثر موارد، مزایای مانیتورینگ بسیار بیشتر از این overhead است. اگر overhead مهم است، می‌توانید sampling rate را کاهش دهید.

جمع‌بندی

مانیتورینگ یک ضرورت است، نه یک لوکس. بدون آن، اولین باری که می‌فهمید سرور مشکل داشته از طریق مشتری ناراضی است — نه از طریق dashboard. با ابزارهای ساده مثل UptimeRobot و Netdata شروع کنید و به مرور به سیستم‌های پیشرفته‌تر مثل Prometheus و Grafana برسید.

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