مانیتورینگ سرور فقط نمایش CPU و RAM در یک داشبورد نیست. هدف این است که پیش از گزارش کاربر بفهمید چه چیزی خراب شده، اثر آن چقدر است و چه کسی باید اقدام کند. سروری با CPU آرام ممکن است DNS خراب، گواهی منقضی یا Checkout ناموفق داشته باشد؛ بنابراین سلامت تجربه کاربر باید کنار منابع زیرساخت دیده شود.
پاسخ سریع: از بیرون DNS، TLS و چند مسیر واقعی HTTP را بررسی کنید؛ داخل سرور نیز نرخ درخواست، latency، خطا، saturation، CPU، memory pressure، Disk/inode، شبکه، process، دیتابیس و queue را نگه دارید. تازگی Backup و نتیجه Restore Test را مانیتور کنید و برای هر Alert، شدت، مسئول، Runbook و شرط پایان تعریف کنید.
Monitoring، Logging، Tracing و Alerting
Metric روند عددی مانند latency یا مصرف RAM است. Log رویداد و context می‌دهد. Trace مسیر یک درخواست را میان سرویس‌ها دنبال می‌کند. Alert از روی نشانه قابل اقدام به فرد مناسب خبر می‌دهد. هیچ‌کدام به‌تنهایی کامل نیست: نمودار خطا بدون request ID علت را نشان نمی‌دهد و log بدون alert ممکن است تا زمان شکایت کاربر خوانده نشود.
از دید کاربر شروع کنید
- آیا دامنه از resolver مستقل resolve می‌شود؟
- آیا TLS برای hostname معتبر است؟
- آیا صفحه عمومی پاسخ معتبر می‌دهد؟
- آیا یک endpoint dynamic کم‌خطر سالم است؟
- آیا journey حیاتی مثل login یا Checkout در حد امن قابل آزمون است؟
probe داخلی نمی‌تواند خرابی DNS، CDN یا firewall بیرونی را ببیند. probe بیرونی نیز وضعیت دیتابیس و queue را توضیح نمی‌دهد. هر دو دید لازم‌اند. آزمون synthetic نباید سفارش، ایمیل یا پرداخت واقعی تکراری بسازد؛ داده و حساب آزمایشی کنترل‌شده استفاده کنید.
چهار سیگنال پایه سرویس
Latency، traffic، error و saturation چارچوب خوبی برای شروع‌اند. latency را برای پاسخ موفق و ناموفق و مسیر cached/dynamic جدا کنید. traffic باید نرخ و نوع کار را نشان دهد. error فقط 500 نیست؛ timeout، پاسخ اشتباه و شکست dependency نیز مهم است. saturation نزدیک‌شدن به سقف worker، connection، queue یا Disk را آشکار می‌کند.
CPU و Load
CPU هر core، سهم user/system/iowait/steal و load نرمال‌شده را نگه دارید. spike کوتاه ممکن است طبیعی باشد؛ اشباع پایدار همراه backlog و latency قابل‌اقدام است. راهنمای تشخیص CPU بالای سرور نشان می‌دهد چرا load با درصد CPU یکی نیست.
Memory و OOM
available، swap activity، memory pressure، مصرف process/cgroup و OOM event مهم‌اند. درصد «used» بدون تفکیک page cache گمراه‌کننده است. نرخ رشد memory پس از deploy می‌تواند leak را زود نشان دهد. Alert باید پیش از kill شدن process فرصت اقدام بدهد.
Disk، Inode و نرخ رشد
بایت آزاد، درصد، inode، I/O latency و error storage را مانیتور کنید. هشدار در ۱۰۰٪ دیر است؛ زمان تخمینی تا exhaustion و نرخ رشد log/database ارزش بیشتری دارد. mountها جدا هستند و فضای root نماینده volume دیتابیس نیست. snapshot و backup نیز ظرفیت خود را مصرف می‌کنند.
شبکه
packet loss، latency، connection error، retransmission، bandwidth و تعداد connection را در context workload ببینید. ping سلامت HTTP را ثابت نمی‌کند و ممکن است بسته باشد. IPv4 و IPv6، مسیر CDN و origin را جدا بسنجید. جهش connection می‌تواند حمله، retry loop یا ترافیک واقعی باشد.
Process و Service Manager
وضعیت سرویس حیاتی، restart count، exit code، uptime و listener را نگه دارید. process running لزوماً ready نیست؛ health endpoint باید dependency ضروری و قابلیت پاسخ واقعی را با هزینه کم بسنجد. restart policy مکرر می‌تواند crash loop را از داشبورد availability پنهان کند.
Nginx و Reverse Proxy
نرخ 2xx/3xx/4xx/5xx، request time، upstream time/status، connection و body size را aggregate کنید. 404 ناشی از bot با شکست route release یکسان نیست. 499 یا قطع client باید در context timeout و latency تحلیل شود. log خام حاوی IP و query حساس نیازمند کنترل دسترسی و retention است.
PHP-FPM و Application Runtime
active/idle worker، queue، رسیدن به max children، slow request، memory و restart را ببینید. افزایش queue همراه CPU/RAM آزاد می‌تواند کمبود concurrency یا downstream کند باشد. status endpoint را عمومی نکنید. زمان اجرای برنامه را از انتظار proxy و دیتابیس جدا ثبت کنید.
دیتابیس
availability، connection استفاده‌شده/سقف، query latency، lock، replication lag، transaction و storage growth را پایش کنید. Query log دائمی و پرحجم ممکن است I/O و Disk را تحت فشار بگذارد؛ sampling و retention مناسب لازم است. میانگین latency، query بسیار کند p99 را پنهان می‌کند.
Queue، Cron و Job
طول صف، سن قدیمی‌ترین job، نرخ ورود/خروج، retry و dead-letter از CPU مهم‌ترند. queue ثابت بزرگ ممکن است backlog پایدار باشد؛ نرخ رشد و زمان پردازش را ببینید. موفق بودن scheduler ثابت نمی‌کند job نتیجه صحیح ساخته است. عملیات مالی باید idempotent و قابل reconciliation باشد.
Dependency بیرونی
DNS، ایمیل، درگاه پرداخت، storage و API شخص ثالث latency و error مستقل دارند. آن‌ها را از زمان برنامه جدا کنید تا مشکل provider به سرور نسبت داده نشود. credential expiry، quota و certificate dependency نیز Alert می‌خواهند. payload حساس را برای observability ذخیره نکنید.
TLS و DNS
expiry گواهی ارائه‌شده از اینترنت، chain، hostname و نتیجه renewal را مانیتور کنید. فقط فایل روی disk کافی نیست. authoritative DNS، resolve عمومی و تغییر رکوردهای حیاتی را زیر نظر بگیرید. Alert انقضا باید آن‌قدر زود باشد که challenge و reload قابل اصلاح باشد.
Backup و Restore
آخرین Backup موفق، حجم، مدت، checksum، upload خارج سرور و پوشش RPO را ثبت کنید. مهم‌تر، تاریخ آخرین Restore Test و زمان واقعی بازیابی است. راهنمای Backup سرور تفاوت موفقیت job با قابلیت بازیابی را توضیح می‌دهد.
Security Signals
login مدیریتی از مبدأ جدید، تغییر حساب/key، listener تازه، تغییر config حساس و افزایش غیرعادی خطا سرنخ‌اند. هر اسکن عمومی را paging نکنید. event امنیتی باید context و مسیر escalation داشته باشد. secret، token و داده شخصی نباید در log و label metric قرار گیرد.
Cardinality و هزینه
قرار دادن URL کامل، user ID یا request ID در label metric cardinality را انفجاری و سیستم مانیتورینگ را پرهزینه می‌کند. dimension محدود برای metric و context جزئی در log/trace مناسب‌تر است. retention داده خام و aggregate باید با نیاز incident و هزینه هماهنگ شود.
Alert قابل اقدام چیست؟
- اثر یا ریسک روشن دارد
- فرد دریافت‌کننده اختیار اقدام دارد
- Runbook و dashboard مرتبط پیوست است
- threshold و مدت از baseline آمده است
- شرط resolve و جلوگیری از flapping دارد
- severity با ساعت و کانال مناسب هماهنگ است
Alert «CPU بالاست» بدون host، مدت، latency و process بعدی، تشخیص را به گیرنده منتقل می‌کند. هشدار باید نشانه را با اثر سرویس نزدیک کند، بدون اینکه علت تأییدنشده اعلام کند.
هشدار ثابت یا مبتنی بر روند؟
threshold ثابت برای Disk و expiry ساده است، اما baseline روز/شب و فصل ممکن است فرق کند. anomaly detection نیز false positive دارد و جای حدهای ایمنی قطعی را نمی‌گیرد. ترکیب absolute limit، مدت، نرخ تغییر و اثر کاربر معمولاً نتیجه عملی‌تری می‌دهد.
Dashboard برای چه کسی؟
مدیر کسب‌وکار availability و journey را می‌خواهد؛ on-call نیازمند service map، error و saturation است؛ متخصص دیتابیس جزئیات query را می‌بیند. یک dashboard عظیم برای همه خوانا نیست. هر صفحه باید سؤال مشخصی را جواب دهد و لینک drill-down داشته باشد.
Runbook و Ownership
برای هر Alert بنویسید چگونه صحت آن سنجیده، چه اقدام کم‌ریسکی مجاز و چه زمانی escalation انجام شود. فرمان‌های خواندنی و مسیر rollback را درج کنید. Runbook پس از هر incident و تغییر معماری به‌روز شود. مالک سرویس و dependency ناشناس، زمان بازیابی را طولانی می‌کند.
آزمون خود Monitoring
قطع agent، شکست ارسال Alert و خرابی storage مانیتورینگ باید قابل تشخیص باشد. یک هشدار آزمایشی کنترل‌شده، زنجیره rule تا کانال و on-call را می‌سنجد. سیستم monitoring نباید فقط داخل همان سرور یا account خرابی باشد؛ حداقل check بیرونی مستقل لازم است.
شروع مرحله‌ای
- journey و SLO اولیه را تعریف کنید.
- check بیرونی DNS/TLS/HTTP بسازید.
- CPU، RAM، Disk، شبکه و service را جمع کنید.
- proxy، runtime، database و queue را اضافه کنید.
- Backup/TLS و dependency را پوشش دهید.
- Alertها را با owner و Runbook محدود کنید.
- در incident واقعی کیفیت سیگنال را بازبینی کنید.
اشتباه‌های رایج
- مانیتور فقط روی همان سرور
- تمرکز روی CPU و نادیده گرفتن کاربر
- Alert روی هر تغییر کوتاه
- نبود owner و Runbook
- ذخیره secret در log/label
- میانگین بدون percentile
- مانیتور Backup بدون Restore Test
- Dashboard زیاد بدون سؤال مشخص
چه زمانی کمک تخصصی لازم است؟
اگر قطعی را فقط از مشتری می‌فهمید یا Alertها زیاد اما بی‌اثرند، نیاز به طراحی دوباره سیگنال و Runbook دارید. مدیریت ماهانه سرور می‌تواند مانیتورینگ لایه کاربر تا دیتابیس، Alert قابل اقدام و روند پاسخ incident را پیاده کند.
پرسش‌های متداول
هر چند ثانیه سرور را مانیتور کنیم؟
به سرعت خرابی، هزینه probe و SLO بستگی دارد؛ همه metricها نیازمند فاصله یکسان نیستند.
آیا Ping برای مانیتورینگ کافی است؟
خیر؛ DNS، TLS، HTTP، برنامه و dependency می‌توانند خراب باشند در حالی که host ping می‌شود.
مهم‌ترین Alert چیست؟
اثری که journey حیاتی کاربر را تهدید می‌کند؛ سپس saturationهایی که پیش از آن فرصت اقدام می‌دهند.
لاگ را تا چه مدت نگه داریم؟
بر اساس نیاز incident، قانون، حساسیت داده و هزینه؛ retention عمومی واحدی برای همه logها وجود ندارد.