مانیتورینگ سرور؛ از پایش سخت‌افزار تا هشدار قابل اقدام

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

پایش سرور دقیقاً چه چیزی را می‌سنجد؟

داده‌هایی که در پایش جمع می‌شوند سه دسته‌اند: شاخص‌های عددی مانند درصد مصرف پردازنده و حافظه، لاگ‌ها که رویدادها را ثبت می‌کنند، و بررسی‌های دسترس‌پذیری که از بیرون می‌سنجند سرویس پاسخ می‌دهد یا نه.

این دو نگاه مکمل یکدیگرند: پایش درونی بر پایهٔ داده‌های خود سیستم و پایش بیرونی که رفتار سرویس را از دید کاربر می‌آزماید. مقایسهٔ ساده‌اش مثل داشبورد خودرو است؛ عقربه‌ها وضعیت لحظه‌ای را نشان می‌دهند، چراغ هشدار وقتی چیزی از حد گذشت روشن می‌شود و تاریخچه روند را در اختیار می‌گذارد.

چهار معیار شناخته‌شده برای پایش سرویس

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

سه لایه‌ای که نباید از قلم بیفتند

• سخت‌افزار: دمای پردازنده و محیط، چرخش فن‌ها، وضعیت منابع تغذیه، سلامت دیسک و کنترلر RAID و خطاهای حافظه.
• سیستم‌عامل و منابع: مصرف پردازنده و بار سیستم، حافظه و Swap، فضای آزاد و ورودی/خروجی دیسک، ترافیک و خطای کارت شبکه.
• سرویس و کاربر: پاسخ و زمان پاسخ HTTP، وضعیت وب‌سرور و دیتابیس، اعتبار گواهی SSL و پاسخ‌گویی DNS.

اشتباه رایج این است که فقط لایهٔ دوم دیده شود. سروری که پردازنده‌اش آرام است ممکن است یک دیسک معیوب در آرایه داشته باشد یا گواهی SSL آن فردا منقضی شود.

شاخص‌های کلیدی و نشانه‌های خطر

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

ابزارهای سخت‌افزاری و درونی سرور

iLO و Redfish برای سلامت قطعات

در سرورهای HPE ProLiant، کنترلر iLO مستقل از سیستم‌عامل کار می‌کند و حتی وقتی سیستم‌عامل از دسترس بیرون است، وضعیت سخت‌افزار را گزارش می‌دهد. نسل‌های مختلف آن عبارت‌اند از iLO 4 روی Gen9، iLO 5 روی Gen10، iLO 6 روی Gen11 و iLO 7 روی Gen12. این کنترلر دما، فن، منبع تغذیه و ذخیره‌سازی را می‌پاید و می‌توان رویدادها را با SNMP، ایمیل یا Syslog به سامانهٔ پایش فرستاد.

smartmontools برای سلامت دیسک

بستهٔ متن‌باز smartmontools دو ابزار دارد: smartctl برای خواندن گزارش SMART دیسک‌های SATA، SAS و NVMe و smartd که به‌صورت سرویس دائمی اجرا می‌شود و در صورت دیدن نشانه‌های خرابی هشدار می‌فرستد. اگر دیسک‌ها پشت کنترلر RAID باشند، باید نوع کنترلر را به ابزار معرفی کنید.

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

ابزارهای نرم‌افزاری؛ از Zabbix تا Netdata

Zabbix؛ پلتفرم همه‌کارهٔ زیرساخت

Zabbix مجموعه‌ای کامل با سرور مرکزی، پایگاه‌داده، رابط وب و ایجنت است. نسخهٔ پیشنهادی محیط عملیاتی آن Zabbix 7.0 LTS است که چهارم ژوئن ۲۰۲۴ منتشر شد؛ طبق سیاست چرخهٔ عمر، پشتیبانی کامل آن تا ۳۰ ژوئن ۲۰۲۷ و پشتیبانی محدود تا ۳۰ ژوئن ۲۰۲۹ ادامه دارد. ایجنت نسل دوم آن به زبان Go نوشته شده و قالب‌ها، ماشه‌ها و اقدام‌ها امکان هشدار چندمرحله‌ای و پایش تجهیزات شبکه با SNMP را فراهم می‌کنند.

Prometheus و Grafana؛ محبوب دنیای کانتینر

Prometheus ابزار متن‌باز پایش و هشدار است که سال ۲۰۱۲ در SoundCloud ساخته و در ۲۰۱۶ به‌عنوان دومین پروژه به بنیاد CNCF پیوست. داده را به شکل سری زمانی با برچسب ذخیره می‌کند، آن را با مدل کشیدن و روی HTTP جمع می‌آورد و زبان پرس‌وجوی PromQL دارد. برای سرور لینوکسی، node_exporter معیارها را تأمین می‌کند، Alertmanager هشدارها را مسیریابی می‌کند و Grafana داشبورد می‌سازد.

Netdata؛ دید لحظه‌ای روی هر سرور

Netdata معیارها را با دقت ثانیه‌ای جمع می‌کند، سرویس‌های رایج را بدون پیکربندی اولیه می‌شناسد و با مدل یادگیری ماشین روی همان سرور، رفتار غیرعادی را علامت می‌زند. ایجنت آن با مجوز GPLv3+ منتشر می‌شود و برای عیب‌یابی سریع بسیار کاربردی است.

Uptime Kuma؛ نگاه از بیرون

ابزارهای درونی اگر خود سرور یا شبکه قطع شود ممکن است هشداری نفرستند. Uptime Kuma متن‌باز و خودمیزبان است، انواع بررسی HTTP، TCP، Ping و DNS را انجام می‌دهد و با بیش از ۹۰ سرویس اعلان یکپارچه می‌شود. آن را روی سروری جدا و ترجیحاً در شبکه‌ای دیگر نصب کنید.

مقایسهٔ Zabbix، Prometheus و Netdata

هشدار؛ حلقهٔ نهایی زنجیرهٔ پایش

بهترین داشبورد هم اگر کسی نگاهش نکند بی‌فایده است؛ هشدار باید به دست فرد درست برسد. کانال‌های رایج ایمیل، پیامک و Webhook هستند و می‌توان به پیام‌رسان‌هایی مثل Telegram و Slack وصل شد.

دو نکتهٔ عملی: هشدار «اطلاع» را از «بحرانی» جدا کنید تا فقط موارد فوری شما را در نیمه‌شب بیدار کنند، و برای جهش‌های کوتاه هشدار ندهید و شرط را برای چند دقیقهٔ پیوسته تعریف کنید. روی سرورهای داخل ایران، پیش از اتکا به هر کانال، ارسال آزمایشی بگیرید و دست‌کم دو کانال مستقل نگه دارید.

هشدار باید نشانه‌ای فوری و قابل اقدام را برساند؛ هشدارهای زیاد و بی‌اثر، هشدار واقعی را پنهان می‌کنند.

شروع عملی و خطاهای رایج

• برای یک یا دو سرور و نیاز به دید سریع: Netdata به‌همراه Uptime Kuma.
• برای چند سرور، سوئیچ، UPS و تجهیزات متنوع: Zabbix با قالب‌های آماده و SNMP.
• برای کانتینر، Kubernetes و معیار سفارشی: Prometheus، Alertmanager و Grafana.

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

آستانهٔ پیش‌فرض برای همهٔ سرورها مناسب نیست؛ یک تا دو هفته داده جمع کنید تا رفتار عادی روشن شود و سپس هشدارها را تنظیم کنید.

جمع‌بندی

مانیتورینگ سرور وقتی ارزش دارد که هر سه لایهٔ سخت‌افزار، سیستم‌عامل و سرویس را ببیند و هشدارهایش به دست فرد درست برسد. iLO و smartmontools سلامت قطعات را گزارش می‌دهند، Zabbix برای زیرساخت متنوع، Prometheus و Grafana برای محیط‌های کانتینری و Netdata برای دید لحظه‌ای مناسب‌اند و Uptime Kuma از بیرون مراقب در دسترس بودن سرویس است.

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