مانیتورینگ سرورهای تولید بدون افراط

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

با پایه‌ها شروع کنید

چهار چیز بی‌صدا سرورها را می‌کشند:

• پر شدن دیسک — لاگ‌ها، jobهای شکست‌خورده، فایل‌های موقت.
• تمام شدن حافظه — نشت حافظه، workerهای زیادی.
• از کار افتادن سرویس — PHP-FPM، Nginx، Redis، پایگاه داده.
• انقضای گواهی — HTTPS می‌شکند، کاربران می‌روند.

قبل از خرید ابزار رصدپذیری، اول این‌ها را چک کنید.

ابزار ساده‌ای که جواب می‌دهد

# هشدار استفاده دیسک (کرون روزانه)
df -h / | awk 'NR==2 {if ($5+0 > 85) print "DISK WARNING: "$5" used"}'

# سلامت سرویس
systemctl is-active nginx php8.3-fpm redis-server postgresql

برای مانیتورینگ uptime، سرویس‌های بیرونی مثل UptimeRobot هر پنج دقیقه به سایت شما ping می‌زنند و وقتی قطع است هشدار می‌دهند — رده رایگان برای بیشتر پروژه‌ها کافی است.

بررسی‌های سلامت در سطح اپلیکیشن

یک endpoint به نام /health اضافه کنید که اتصال پایگاه داده و Redis را بررسی می‌کند:

Route::get('/health', function () {
    DB::connection()->getPdo();
    Redis::ping();
    return response('OK', 200);
});

این endpoint را مانیتور کنید، نه فقط صفحه اصلی را — سایت می‌تواند دارایی‌های ایستا را بارگذاری کند در حالی که پایگاه داده مرده است.

کِی ارتقا دهیم

وقتی لاگ‌گیری ساختاریافته، APM (مانیتورینگ کارایی اپلیکیشن) و داشبوردهای معیار را اضافه کنید که:

• چند سرویس دارید که با هم تعامل می‌کنند.
• دیباگ نیازمند همبسته کردن درخواست‌ها در سرتاسر اجزاست.
• دارید کارایی را بهینه می‌کنید و به داده تاریخی نیاز دارید.

پرومتئوس را به‌خاطر مد بودنش نصب نکنید. به‌خاطر حادثه‌ای نصب کنید که نتوانستید فقط با لاگ‌ها تشخیصش دهید.

اشتباهات رایج

• مانیتور کردن چیز اشتباه. uptime مساوی سلامت نیست. وابستگی‌ها را چک کنید، نه فقط HTTP 200 را.
• خستگی از هشدار. هشدارهای زیادی یعنی همه هشدارها نادیده گرفته می‌شوند. روی علائمی که کاربران حس می‌کنند هشدار بدهید.
• نبود runbook. یک هشدار ساعت سه نیمه‌شب بی‌فایده است اگر کسی نداند چه کند.

بهترین شیوه‌ها

• با دیسک، حافظه، uptime و سلامت اپ شروع کنید — وقتی درد طلب کرد گسترش دهید.
• برای هر هشدار یک runbook یک‌صفحه‌ای بنویسید: یعنی چه، چطور رفعش کنیم.
• هشدارها را ماهانه بازبینی کنید؛ آن‌هایی را که هرگز به عمل نمی‌انجامند حذف کنید.

جمع‌بندی

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