مانیتورینگ سرور در سه سطح؛ از دستور top تا مانیتورینگ حرفه‌ای

وقتی کسی می‌گوید «سرور را مانیتور می‌کنیم»، ممکن است منظورش این باشد که هر چند وقت یک‌بار با دستور top وضعیت CPU و RAM را می‌بیند. تیم دیگری ممکن است یک داشبورد دائمی، تاریخچه چندماهه، هشدار خودکار و برنامه مدیریت ظرفیت داشته باشد. هر دو در حال مشاهده سرور هستند، اما سطح مانیتورینگ آن‌ها یکسان نیست.

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

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

خلاصه سه سطح مانیتورینگ سرور

این سه سطح جایگزین یکدیگر نیستند. حتی در یک تیم حرفه‌ای نیز هنگام بررسی Incident از top، vmstat یا iostat استفاده می‌شود. تفاوت در این است که دستور دستی دیگر تنها راه دیدن وضعیت سرور نیست.

قبل از سطح‌بندی: چه بخش‌هایی از هر سرور باید مانیتور شوند؟

فارغ از اینکه روی سرور وب‌سایت، Worker، دیتابیس یا هیچ سرویس خاصی اجرا می‌شود، حداقل شش گروه اطلاعات باید زیر نظر باشند:

1. CPU: میزان استفاده، Load Average، پردازش‌های پرمصرف، iowait و در ماشین مجازی steal time
2. Memory: حافظه Available، Swap، فشار حافظه و رخدادهای OOM
3. Disk: فضای آزاد، inode، IOPS، Throughput، Latency و خطاهای دیسک
4. Network: پهنای باند، Packet Drop، Error، Retransmission و وضعیت اتصال‌ها
5. System: Uptime، Load، تعداد Processها، File Descriptor و وضعیت سرویس‌های سیستم
6. دسترسی‌پذیری: آیا سرور روشن، قابل دسترسی و پاسخ‌گو است؟

فقط دیدن درصد مصرف کافی نیست. در مانیتورینگ منابع باید سه سؤال بپرسید: چقدر از منبع استفاده می‌شود؟ آیا درخواست‌ها برای آن منتظر مانده‌اند؟ آیا خود منبع خطا تولید می‌کند؟ این همان نگاه USE یعنی Utilization، Saturation و Errors است.

سطح اول: بررسی دستی و واکنشی با ابزارهای خود Linux

در سطح اول، معمولاً بعد از کندشدن یا دریافت گزارش مشکل وارد سرور می‌شوید و وضعیت را بررسی می‌کنید. این سطح برای یادگیری رفتار Linux، عیب‌یابی لحظه‌ای و سرورهای آزمایشی ضروری است؛ اما برای یک سرور Production به‌تنهایی کافی نیست.

۱. بررسی سریع وضعیت کلی با uptime و top

uptime
top

دستور uptime مدت روشن‌بودن سرور، تعداد Sessionها و Load Average در ۱، ۵ و ۱۵ دقیقه گذشته را نشان می‌دهد. top علاوه‌بر Load، مصرف CPU و حافظه و پردازش‌های پرمصرف را نمایش می‌دهد. اگر htop نصب باشد، همین اطلاعات را با رابط خواناتر و امکان جست‌وجو و مرتب‌سازی بهتر می‌بینید.

Load Average درصد CPU نیست؛ تعداد تقریبی کارهایی است که در حال اجرا هستند یا برای CPU و در Linux برای بعضی عملیات غیرقابل‌وقفه مانند I/O منتظرند. بنابراین Load را باید نسبت به تعداد هسته‌ها و همراه با جزئیات دیگر تفسیر کرد. Load برابر ۴ روی سرور ۴ هسته‌ای با همان عدد روی سرور ۳۲ هسته‌ای معنای یکسانی ندارد.

۲. CPU را فقط با عدد 100% نسنجید

در خروجی ابزارها به اجزای مصرف CPU توجه کنید:

• user: زمان مصرف‌شده توسط پردازش‌های کاربر
• system: زمان مصرف‌شده در Kernel
• iowait: زمانی که CPU بیکار است اما سیستم منتظر I/O مانده است
• steal: زمانی که ماشین مجازی آماده اجرا بوده، اما Hypervisor پردازنده را به ماشین دیگری داده است

ممکن است CPU فقط ۳۰ درصد مصرف شود، اما iowait بالا باشد و سرور کند کار کند. در این حالت خرید CPU بیشتر احتمالاً مشکل را حل نمی‌کند؛ باید دیسک یا مسیر I/O را بررسی کنید. steal بالا در سرور مجازی نیز می‌تواند نشانه فشار روی Host یا کیفیت نامناسب زیرساخت باشد.

mpstat -P ALL 1
pidstat 1

mpstat اختلاف مصرف بین هسته‌ها را نشان می‌دهد و pidstat برای پیدا کردن Processهایی که CPU، حافظه یا I/O مصرف می‌کنند مفید است. پرشدن یک هسته ممکن است در میانگین کل CPU پنهان شود.

۳. حافظه: Free پایین همیشه نشانه کمبود RAM نیست

free -h
vmstat 1

Linux از RAM آزاد برای Cache استفاده می‌کند، بنابراین ستون free به‌تنهایی معیار خوبی نیست. معمولاً available تصویر بهتری از حافظه‌ای می‌دهد که بدون فشار جدی قابل استفاده است. Swap فعال نیز الزاماً مشکل نیست؛ مهم این است که سیستم با چه نرخی بین RAM و Swap جابه‌جا می‌شود و آیا این جابه‌جایی باعث کندی شده است.

در خروجی vmstat ستون‌های si و so را بررسی کنید. Swap in/out مداوم همراه با کندی و حافظه Available پایین نشانه فشار حافظه است. برای دیدن رخدادهای OOM نیز می‌توانید لاگ Kernel را بررسی کنید:

journalctl -k | grep -i -E 'oom|out of memory|killed process'

اگر OOM Killer پردازشی را متوقف کرده باشد، ممکن است سرویس شما بدون آنکه کل سرور Down شود از دسترس خارج شده باشد.

۴. دیسک: ظرفیت، inode و سرعت سه موضوع جدا هستند

df -h
df -i
du -xhd1 /var
iostat -xz 1

df -h فضای مصرف‌شده Filesystem و df -i میزان مصرف inode را نشان می‌دهد. ممکن است چند گیگابایت فضای آزاد داشته باشید اما به‌دلیل تمام‌شدن inode دیگر نتوانید فایل جدید بسازید؛ اتفاقی که در سرورهای دارای تعداد بسیار زیاد فایل کوچک یا Logهای پراکنده رخ می‌دهد.

فضای آزاد نیز درباره سرعت دیسک چیزی نمی‌گوید. iostat برای مشاهده نرخ عملیات، حجم خواندن و نوشتن، زمان انتظار و میزان مشغول‌بودن Device مفید است. دیسکی که فقط ۵۰ درصد پر شده می‌تواند به‌دلیل Latency بالا گلوگاه اصلی سرور باشد.

قبل از اجرای du روی مسیرهای بسیار بزرگ و شلوغ توجه کنید که خود این دستور می‌تواند I/O قابل‌توجهی ایجاد کند. در محیط حساس، محدوده جست‌وجو را کوچک نگه دارید.

۵. شبکه: فقط Ping کافی نیست

ip -s link
ss -s
sar -n DEV 1
sar -n TCP,ETCP 1

Ping فقط دسترسی و زمان رفت‌وبرگشت ICMP را در همان لحظه می‌سنجد. برای سلامت شبکه باید حجم ورودی و خروجی، Error و Drop روی Interface، تعداد Connectionها، Retransmissionهای TCP و وضعیت Socketها را ببینید.

افزایش TCP Retransmission می‌تواند از Packet Loss، ازدحام شبکه یا مشکل مسیر ناشی شود. تعداد بسیار زیاد Connection در وضعیت‌هایی مثل TIME_WAIT نیز باید همراه با الگوی ترافیک و تنظیمات سیستم تحلیل شود، نه اینکه خودکار به‌عنوان خرابی تلقی شود.

۶. وضعیت Processها و سرویس‌های سیستم

systemctl --failed
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
journalctl -p err -S today

این دستورها سرویس‌های Failشده، Processهای پرمصرف و خطاهای مهم امروز را نشان می‌دهند. علاوه‌بر روشن‌بودن Process، تعداد Process و Thread، تعداد File Descriptorهای باز، Processهای Zombie و Restartهای مکرر نیز مهم هستند.

چک‌لیست پنج‌دقیقه‌ای سطح اول

1. با uptime و top Load و پردازش‌های پرمصرف را ببینید.
2. با free -h مقدار Available و با vmstat فشار حافظه و I/O را بررسی کنید.
3. با df -h و df -i ظرفیت و inode را جداگانه ببینید.
4. با iostat -xz 1 دیسک کند یا اشباع‌شده را پیدا کنید.
5. با ip -s link و ss -s خطاها و وضعیت کلی شبکه را ببینید.
6. با systemctl --failed و journalctl خطاهای سیستم را بررسی کنید.

محدودیت اصلی سطح اول

اگر مشکل ساعت ۳ بامداد رخ داده و ساعت ۸ وارد سرور شوید، خروجی top وضعیت ساعت ۸ را نشان می‌دهد. نمی‌دانید هنگام Incident چه اتفاقی افتاده، روند مصرف در هفته گذشته چگونه بوده یا مشکل چند بار تکرار شده است. همچنین تا وقتی کسی سرور را بررسی نکند، ممکن است از پرشدن دیسک یا Downشدن Host باخبر نشوید.

اگر برای فهمیدن خرابی باید منتظر گزارش کاربر بمانید و سپس SSH بزنید، هنوز در سطح اول هستید.

سطح دوم: جمع‌آوری دائمی، داشبورد و هشدار خودکار

در سطح دوم، یک Agent یا Exporter اطلاعات سرور را به‌صورت دوره‌ای جمع‌آوری می‌کند و در یک سیستم مرکزی نگه می‌دارد. ابزارهایی مانند Watchlog، Prometheus به‌همراه Grafana، Zabbix و محصولات SaaS مانیتورینگ می‌توانند این نقش را انجام دهند. تفاوت مهم با سطح اول، داشتن تاریخچه و هشدار است.

داشبورد پایه سرور باید چه چیزهایی داشته باشد؟

داشبورد خوب باید امکان مقایسه بازه‌ها را بدهد. مثلاً آیا مصرف حافظه از زمان آخرین تغییر دائماً در حال افزایش است؟ آیا هر روز در ساعت مشخص Load بالا می‌رود؟ آیا افزایش iowait هم‌زمان با Backup شبانه رخ می‌دهد؟ تاریخچه، یک عدد لحظه‌ای را به الگوی قابل تحلیل تبدیل می‌کند.

Alert روی چه مواردی تعریف کنیم؟

اولین نسخه هشدارها می‌تواند موارد زیر را پوشش دهد، اما عدد دقیق باید با ظرفیت و رفتار عادی هر سرور تنظیم شود:

• سرور یا Agent برای چند دقیقه در دسترس نیست.
• فضای Filesystem یا inode به محدوده خطر رسیده و همچنان در حال رشد است.
• حافظه Available برای یک بازه معنادار پایین است یا OOM رخ داده است.
• CPU یا Load برای چند دقیقه بالا مانده و صف کار در حال شکل‌گیری است.
• iowait یا Disk Latency از مقدار عادی فاصله گرفته است.
• Network Error، Drop یا TCP Retransmission افزایش معنادار دارد.
• یک سرویس مهم Systemd متوقف یا چند بار Restart شده است.

چرا Alert ساده CPU بالای 80% معمولاً خوب نیست؟

CPU ممکن است چند ثانیه برای انجام یک Job به ۱۰۰ درصد برسد و این کاملاً طبیعی باشد. هشدار روی یک نمونه کوتاه، فقط Noise تولید می‌کند. هشدار بهتر مدت، شدت و نشانه فشار را با هم در نظر می‌گیرد:

CPU > 90% for 10 minutes
AND Load / CPU Cores > 1
AND server is in production

همه Alertها لازم نیست فردی را بیدار کنند. هشدار مربوط به Downشدن سرور حیاتی می‌تواند فوری باشد، درحالی‌که رسیدن دیسک به ۷۰ درصد شاید فقط یک Ticket برای بررسی روند رشد ایجاد کند. کانال اطلاع‌رسانی باید متناسب با فوریت باشد.

محدودیت اصلی سطح دوم

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

اگر تاریخچه و Alert دارید ولی بیشتر هشدارها نادیده گرفته می‌شوند یا Incidentها همچنان شما را غافلگیر می‌کنند، در سطح دوم قرار دارید.

سطح سوم: مانیتورینگ حرفه‌ای، پیشگیرانه و مبتنی بر ظرفیت

در سطح سوم هدف فقط مشاهده مصرف نیست؛ باید رفتار عادی هر سرور را بشناسید، نزدیک‌شدن به محدودیت را پیش‌بینی کنید و برای هشدارهای مهم واکنش تعریف‌شده داشته باشید. این سطح بیشتر از خرید ابزار، به طراحی درست و نظم عملیاتی وابسته است.

۱. Baseline؛ رفتار عادی این سرور چیست؟

CPU برابر ۷۰ درصد برای یک Worker ممکن است عادی و برای یک سرور تقریباً بیکار غیرعادی باشد. Baseline الگوی معمول هر سرور را براساس ساعت، روز هفته، فصل کاری و نوع نقش آن مشخص می‌کند. به‌جای اینکه یک Threshold ثابت را روی همه Hostها اعمال کنید، تغییر معنادار نسبت به رفتار گذشته را نیز می‌بینید.

Anomaly Detection می‌تواند به پیدا کردن تغییرات غیرعادی کمک کند، اما جای شناخت سیستم را نمی‌گیرد. هر انحرافی Incident نیست؛ Deploy، Backup، Batch Job یا افزایش برنامه‌ریزی‌شده ترافیک می‌تواند دلیل تغییر باشد.

۲. Saturation؛ منبع فقط پر نیست، کارها پشت آن منتظرند

Utilization می‌گوید چه مقدار از منبع مصرف شده است، اما Saturation نشان می‌دهد کار بیشتری وجود دارد که به‌دلیل محدودیت ظرفیت منتظر مانده است. نمونه‌های Saturation عبارت‌اند از:

• Run Queue طولانی‌تر از ظرفیت CPU
• صف درخواست‌های دیسک و افزایش I/O Latency
• Swap شدید و Reclaim مداوم حافظه
• پرشدن Connection Tracking یا محدوده Portها
• نزدیک‌شدن تعداد File Descriptorها به Limit

ممکن است فضای دیسک ۶۰ درصد و CPU فقط ۴۰ درصد باشد، اما دیسک از نظر IOPS اشباع شده باشد. مانیتورینگ حرفه‌ای محدودیت عملکردی را در کنار ظرفیت اسمی می‌سنجد.

۳. Capacity Planning؛ مشکل هفته آینده را امروز ببینید

به‌جای Alert صرف روی «Disk بالای 90%»، نرخ رشد را نیز محاسبه کنید. اگر Filesystem اکنون ۷۰ درصد پر است اما روزانه ۳ درصد رشد می‌کند، فقط حدود ده روز تا پرشدن فاصله دارید. در مقابل، دیسک ۸۵ درصدی که شش ماه ثابت مانده ممکن است فوریت کمتری داشته باشد.

برای برنامه‌ریزی ظرفیت این روندها ارزشمندند:

• روزهای باقی‌مانده تا پرشدن دیسک و inode
• رشد Peak مصرف CPU و حافظه در هفته‌های اخیر
• رشد پهنای باند و تعداد Connectionهای هم‌زمان
• ظرفیت آزاد واقعی در زمان از دست‌دادن یک Node
• اثر Backup، Log rotation و Jobهای زمان‌بندی‌شده بر منابع

۴. Alert چندسیگناله و قابل اقدام

در سطح حرفه‌ای هشدار تا جای ممکن به اثری که نیاز به اقدام دارد نزدیک می‌شود. به‌جای چند هشدار جدا برای CPU، Load و Process count می‌توان شرایط مرتبط را Correlate کرد و یک Incident معنادار ساخت.

۵. هر Alert باید Owner و Runbook داشته باشد

هشدار خوب باید به چهار سؤال پاسخ دهد: چه چیزی خراب شده؟ شدت و اثر احتمالی آن چیست؟ چه کسی مسئول بررسی است؟ قدم اول چیست؟ Runbook می‌تواند شامل دستورهای بررسی، لینک داشبورد مرتبط، روش کاهش موقت فشار و شرایط Escalation باشد.

برای مثال هشدار رشد غیرعادی دیسک باید Filesystem، Host، نرخ رشد، Processهای محتمل و روش امن پیدا کردن مسیرهای حجیم را نشان دهد. پیام «Disk is high» بدون Context، بخشی از کار تشخیص را به فرد On-call منتقل می‌کند.

۶. تغییرات زیرساخت را کنار متریک‌ها ببینید

زمان Deploy، تغییر Kernel، Resize ماشین، اجرای Maintenance و تغییر تنظیمات باید روی Timeline مشخص باشد. اگر steal time دقیقاً بعد از انتقال VM یا مصرف حافظه پس از تغییر تنظیمات افزایش یافته، این هم‌بستگی مسیر بررسی را بسیار کوتاه می‌کند.

۷. مانیتورینگ خود مانیتورینگ

اگر Agent متوقف شود، داده‌ای دریافت نمی‌کنید؛ اما نبود داده نباید به معنی سالم‌بودن سرور تعبیر شود. در سطح سوم باید Freshness داده، سلامت Agent، موفقیت ارسال Metric و ظرفیت Storage سامانه مانیتورینگ نیز بررسی شوند. مانیتورینگ اصلی بهتر است از مسیر مستقلی برای اعلام قطع کامل خود استفاده کند.

چه چیزهایی را نباید با هم اشتباه بگیریم؟

CPU Usage و Load Average

CPU Usage درصد زمان مشغول‌بودن پردازنده است. Load Average تعداد کارهای در حال اجرا یا منتظر را نشان می‌دهد. Load بالا ممکن است از CPU یا انتظار I/O ناشی شود؛ بنابراین همیشه اجزای CPU، Run Queue و دیسک را نیز ببینید.

Memory Used و Memory Pressure

Used بالا در Linux می‌تواند نتیجه Cache مفید باشد. Available پایین، Swap مداوم، Reclaim شدید و OOM نشانه‌های قوی‌تری از فشار واقعی حافظه هستند.

Disk Usage و Disk Saturation

Usage ظرفیت ذخیره‌سازی را نشان می‌دهد؛ Saturation به توان پردازش I/O مربوط است. دیسک می‌تواند فضای زیادی داشته باشد اما بسیار کند باشد، یا سریع باشد ولی چند دقیقه تا پرشدن فاصله داشته باشد.

Server Uptime و Service Availability

روشن‌بودن Host تضمین نمی‌کند سرویس‌های سیستم سالم یا Portهای موردنیاز قابل دسترسی باشند. برای خود سرور، Heartbeat و Ping مفیدند؛ برای هر سرویس حیاتی نیز حداقل وضعیت Process یا Port باید جداگانه بررسی شود. این مقاله وارد مانیتورینگ داخل اپلیکیشن نمی‌شود، اما مرز Host و سرویس باید روشن باشد.

اشتباهات رایج در مانیتورینگ سرور

• دیدن فقط CPU و RAM: دیسک، inode، شبکه و Limitهای سیستم نقاط کور مهمی می‌مانند.
• اعتماد به یک Snapshot: وضعیت فعلی علت Incident چند ساعت قبل را نشان نمی‌دهد.
• Threshold یکسان برای همه Hostها: نقش و Baseline سرورها متفاوت است.
• Alert بدون مدت: هر Spike کوتاه به هشدار تبدیل می‌شود.
• Alert بدون Owner: همه پیام را می‌بینند، اما هیچ‌کس مسئول اقدام نیست.
• نادیده‌گرفتن Missing Data: قطع Agent به‌اشتباه به‌عنوان وضعیت سالم دیده می‌شود.
• نگه‌داشتن تاریخچه بسیار کوتاه: مقایسه با هفته یا ماه قبل و برنامه‌ریزی ظرفیت ممکن نیست.
• رفع علامت به‌جای علت: Restart موقت ممکن است نمودار را سبز کند، اما Memory Leak یا فشار I/O باقی می‌ماند.
• نصب ابزار بدون بازبینی: داشبورد و Alert باید بعد از Incidentها و تغییر رفتار سیستم اصلاح شوند.

الان در کدام سطح هستید؟

مسیر عملی ارتقا از سطح اول به سوم

1. فهرست سرورها را کامل کنید: نقش، محیط، مالک، سیستم‌عامل و اهمیت هر Host را ثبت کنید.
2. شش گروه اصلی را جمع‌آوری کنید: CPU، Memory، Disk، Network، System و Availability.
3. تاریخچه بسازید: پیش از تعیین آستانه دقیق، حداقل رفتار عادی و Peakها را بشناسید.
4. با چند Alert حیاتی شروع کنید: Host down، OOM، پرشدن Disk و inode، فشار پایدار منابع و خرابی سرویس مهم.
5. هشدارها را طبقه‌بندی کنید: Incident فوری، هشدار کاری و گزارش ظرفیت را از هم جدا کنید.
6. برای هر Alert اقدام تعریف کنید: Owner، Dashboard، Runbook و مسیر Escalation مشخص باشد.
7. روند و Saturation را اضافه کنید: فقط درصد مصرف را نبینید؛ صف، انتظار، خطا و زمان باقی‌مانده تا محدودیت را بسنجید.
8. ماهانه بازبینی کنید: هشدارهای بی‌اثر را حذف، نقاط کور را اضافه و Retention را متناسب با نیاز تنظیم کنید.

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

در Watchlog می‌توانید با نصب Agent، وضعیت Hostهای Linux و Windows را به‌صورت متمرکز مشاهده کنید؛ از CPU، Load و حافظه تا Disk، Network، Processها و Uptime. نگه‌داری تاریخچه کمک می‌کند به‌جای دیدن یک Snapshot، روند تغییر منابع و زمان دقیق شروع مشکل را بررسی کنید.

همچنین می‌توانید برای شرایط مهم Alert تعریف کنید و اعلان را از مسیرهایی مانند ایمیل، تلگرام، Slack یا Webhook دریافت کنید. هدف این است که برای بررسی روزمره مجبور نباشید به تک‌تک سرورها SSH بزنید و هنگام نزدیک‌شدن یک منبع به وضعیت خطر، پیش از اثرگذاری روی کاربران باخبر شوید.

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

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

برای مانیتورینگ یک سرور Linux از کجا شروع کنیم؟

ابتدا با top، free، df، vmstat، iostat و ss مفاهیم اصلی را یاد بگیرید. برای سرور Production سپس جمع‌آوری دائمی Metric، داشبورد تاریخچه‌دار و Alert خودکار را راه‌اندازی کنید.

هر چند ثانیه یک‌بار باید متریک سرور جمع شود؟

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

CPU بالای 80 درصد خطرناک است؟

نه لزوماً. مدت بالا بودن، تعداد Core، Load، Run Queue، iowait و اثر آن بر کار سرور مهم‌اند. CPU بالا هنگام یک Job برنامه‌ریزی‌شده ممکن است طبیعی باشد؛ CPU پایدار همراه با صف رو‌به‌رشد احتمال کمبود ظرفیت را بیشتر می‌کند.

برای RAM بهتر است Used را Alert کنیم یا Available را؟

در Linux معمولاً Available همراه با Swap activity، Memory Pressure و رخداد OOM تصویر دقیق‌تری از کمبود واقعی حافظه می‌دهد. Used شامل Cache مفید سیستم نیز می‌شود و به‌تنهایی می‌تواند گمراه‌کننده باشد.

چرا با وجود فضای آزاد، دیسک خطای No space left on device می‌دهد؟

یکی از علت‌های رایج تمام‌شدن inode است. در این شرایط فضای حجمی وجود دارد اما Filesystem دیگر نمی‌تواند فایل جدید ایجاد کند. خروجی df -i را در کنار df -h بررسی کنید.

آیا Ping برای تشخیص روشن‌بودن سرور کافی است؟

خیر. ممکن است ICMP مسدود باشد یا سرور به Ping پاسخ دهد اما سرویس‌های مهم آن متوقف باشند. Heartbeat عامل مانیتورینگ، بررسی Port و وضعیت سرویس‌های سیستم باید در کنار Ping دیده شوند.

آیا نصب Grafana به معنی رسیدن به مانیتورینگ حرفه‌ای است؟

خیر. Grafana یا هر ابزار دیگری فقط بخشی از راه‌حل است. مانیتورینگ حرفه‌ای به داده درست، تاریخچه کافی، هشدار قابل اقدام، Owner، Runbook، شناخت Baseline و برنامه‌ریزی ظرفیت نیاز دارد.

جمع‌بندی

سطح اول به شما کمک می‌کند با دستورهای Linux وضعیت فعلی را بررسی و مشکل را عیب‌یابی کنید. سطح دوم با جمع‌آوری دائمی، تاریخچه و Alert باعث می‌شود پیش از گزارش کاربر از بسیاری از مشکلات باخبر شوید. سطح سوم، مصرف ساده منابع را به شناخت Baseline، تشخیص Saturation، پیش‌بینی ظرفیت و واکنش استاندارد تبدیل می‌کند.

برای شروع لازم نیست صد متریک و ده‌ها داشبورد بسازید. CPU، حافظه، دیسک، شبکه، وضعیت سیستم و دسترسی‌پذیری را درست جمع‌آوری کنید؛ سپس چند هشدار مهم و قابل اقدام بسازید. بعد از هر Incident بپرسید چه سیگنالی کم بود، کدام هشدار دیر یا بی‌دلیل فعال شد و چه چیزی باید به Runbook اضافه شود.

معیار واقعی بلوغ این نیست که چند نمودار دارید؛ این است که آیا قبل از کاربر مشکل را می‌بینید، علت را با سرعت پیدا می‌کنید و پیش از تمام‌شدن ظرفیت برای آن برنامه دارید یا نه.