ابزارهای مانیتورینگ سرور وضعیت منابع و سرویس‌ها را اندازه می‌گیرند و می‌توانند دربارهٔ مشکل هشدار بدهند. مانیتورینگ به‌خودی‌خود مانع تمام قطعی‌ها نمی‌شود؛ ارزش آن در تشخیص به‌موقع و فراهم کردن اطلاعات برای پاسخ درست است.
از ابزارهای مانیتورینگ سرور چه می‌خواهیم؟
ابتدا خدمت مهم را مشخص کنید. روشن بودن ماشین الزاماً به معنی سالم بودن سایت نیست. ممکن است CPU آزاد باشد ولی دیتابیس پاسخ ندهد یا گواهی HTTPS منقضی شده باشد. معیارها باید هم زیرساخت و هم تجربهٔ استفاده از خدمت را پوشش دهند.
برای یک سایت، دسترس‌پذیری HTTP، زمان پاسخ، خطای برنامه، فضای دیسک و روند مصرف منابع نقطهٔ شروع هستند. پایش از بیرون سرور کمک می‌کند قطعی‌ای را ببینید که ابزار داخل همان ماشین دیگر قادر به گزارش آن نیست.
۱. Zabbix برای نظارت یکپارچه
Zabbix برای پایش سرور، شبکه و برنامه‌ها، جمع‌آوری داده و هشدار قابلیت‌های گسترده دارد. قالب‌ها و روش‌های جمع‌آوری مختلف به راه‌اندازی کمک می‌کنند، اما آستانه‌های آماده باید با محیط واقعی تنظیم شوند.
برای تیمی که داشبورد، موجودی میزبان‌ها و مدیریت هشدار در یک سامانه می‌خواهد، گزینه‌ای قابل بررسی است. ظرفیت پایگاه داده و مدت نگهداری تاریخچه را از ابتدا در نظر بگیرید.
۲. Prometheus برای معیارهای سری زمانی
Prometheus معیارها را معمولاً با مدل pull از HTTP جمع می‌کند و با PromQL امکان پرس‌وجو می‌دهد. exporterها و کشف سرویس به اتصال منابع مختلف کمک می‌کنند. مدیریت اعلان در معماری آن با Alertmanager انجام می‌شود.
برای برنامه‌ای که معیارهای مشخص منتشر می‌کند، این رویکرد انعطاف‌پذیر است. با این حال نام‌گذاری برچسب‌ها و حجم سری‌های زمانی باید طراحی شود؛ ثبت بی‌حساب مقدارهای منحصربه‌فرد هزینهٔ ذخیره‌سازی را بالا می‌برد.
۳. Nagios Core برای بررسی میزبان و سرویس
Nagios Core از افزونه‌های بررسی برای نظارت بر میزبان‌ها و سرویس‌ها استفاده می‌کند. مناسب بودن آن به تجربهٔ تیم و روش مدیریت پیکربندی بستگی دارد. امکانات Core را با محصول تجاری Nagios XI یکسان فرض نکنید.
۴. Monit برای نظارت و اقدام محلی
Monit ابزار سبک نظارت سیستم‌های یونیکسی است و می‌تواند اقدام‌های از پیش تعریف‌شده انجام دهد. راه‌اندازی دوبارهٔ یک سرویس با ریبوت کل سرور متفاوت است و باید دقیقاً مشخص شود چه کاری مجاز است.
اقدام خودکار را بدون محدودیت تکرار و بررسی وابستگی‌ها فعال نکنید. اگر علت اصلی حل نشده باشد، حلقهٔ راه‌اندازی مجدد ممکن است مشکل را پنهان یا شدیدتر کند.
۵. Munin برای مشاهدهٔ روند منابع
Munin برای جمع‌آوری شاخص‌ها و نمودار روند منابع کاربرد دارد و با افزونه‌ها گسترش پیدا می‌کند. برای فهم تغییر مصرف در طول زمان مفید است. تناوب نمونه‌برداری را با نیاز تشخیص قطعی مقایسه کنید؛ نمودار دوره‌ای با اعلان لحظه‌ای یکسان نیست.
هشدار باید قابل اقدام باشد
هر هشدار باید مسئول، شدت و دستور بررسی داشته باشد. برای جهش کوتاه CPU و پر شدن نزدیک دیسک، یک سیاست مشترک نسازید. هشدارهای تکراری و بدون اقدام، احتمال نادیده گرفتن مشکل واقعی را بیشتر می‌کنند.
ارسال و دریافت اعلان را عملاً آزمایش کنید. فقط سبز بودن داشبورد کافی نیست؛ قطع یک خدمت آزمایشی باید هشدار قابل فهم بدهد و بازگشت آن نیز ثبت شود.
انتخاب برای یک سرور یا مجموعهٔ بزرگ
برای یک ماشین ساده، ابزار سبک و پایش بیرونی ممکن است کافی باشد. برای چند محیط و تیم، مدیریت دسترسی، کشف منابع و نگهداری داده مهم‌تر می‌شود. هزینهٔ نیروی نگهداری و سرور مانیتورینگ را کنار رایگان بودن نرم‌افزار حساب کنید.
داشبورد مدیریتی و endpointهای معیار را عمومی رها نکنید. مانیتورینگ بخشی از زیرساخت است و خودش هم باید تحت نظارت و نگهداری باشد.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
