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

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

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

مانیتورینگ با داشبورد فرق دارد

بسیاری از سازمان‌ها ابزار مانیتورینگ نصب کرده‌اند: یک صفحه پر از نمودار سبز و قرمز که روی مانیتوری در اتاق IT باز است — و کسی نگاهش نمی‌کند. مانیتورینگ واقعی سه جزء دارد:

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

بدون جزء دوم، مانیتورینگ فقط ابزار تحلیل پس از حادثه است.

چه چیزی را پایش کنیم

لایه شبکه

• لینک‌های اینترنت و بین شعب: دسترس‌پذیری، تأخیر، لرزش و از دست رفتن بسته به مقصدهای بیرونی ثابت — نه فقط وضعیت پورت. لینکی که «بالا» است اما ۵٪ بسته از دست می‌دهد، برای تماس صوتی و نرم‌افزار تحت وب عملاً قطع است.
• پورت‌های سوئیچ و روتر: میزان استفاده، و مهم‌تر، خطاها — خطای CRC معمولاً نشانه کابل یا ماژول معیوب است و مدت‌ها پیش از قطعی کامل ظاهر می‌شود. شمارنده Discard نشانه اشباع است.
• فایروال: مصرف پردازنده و حافظه، تعداد نشست‌های هم‌زمان در برابر ظرفیت، وضعیت تونل‌های VPN، و وضعیت خوشه در صورت افزونگی.
• تجهیزات وایرلس: تعداد کاربر هر اکسس پوینت و میزان استفاده از کانال.

لایه سرور و مجازی‌سازی

• پردازنده، حافظه و به‌خصوص تأخیر دیسک — که معمولاً اولین علت کندی است.
• فضای دیسک با پیش‌بینی زمان پر شدن، نه فقط آستانه درصدی.
• سلامت سخت‌افزار از طریق پردازنده مدیریتی سرور (iLO، iDRAC) با SNMP یا رابط Redfish: وضعیت RAID، دیسک‌ها، منبع تغذیه، فن و دما.
• میزبان مجازی‌سازی: مصرف کلی، صف پردازنده، فضای مخزن ذخیره‌سازی و Snapshotهای قدیمی.

لایه سرویس

• بررسی مصنوعی (Synthetic Check): به‌جای «سرور به پینگ جواب می‌دهد»، «صفحه ورود نرم‌افزار در کمتر از دو ثانیه با کد ۲۰۰ باز می‌شود» یا «کوئری آزمایشی پایگاه داده جواب می‌دهد».
• سرویس‌های زیرساختی: DNS، سلامت تکثیر اکتیو دایرکتوری، همگام‌سازی زمان.
• گواهی‌های دیجیتال: روزهای باقی‌مانده تا انقضا.
• کارهای بکاپ: موفق، ناموفق، یا — خطرناک‌تر — اصلاً اجرا نشده. جزئیات در قانون ۳-۲-۱.
• مرکز تلفن: وضعیت ثبت ترانک‌ها و خطوط، تعداد تماس هم‌زمان.

لایه محیطی

• UPS: با کارت شبکه SNMP — وضعیت برق ورودی، بار، ظرفیت باتری و زمان پشتیبانی باقی‌مانده. هشدار «UPS روی باتری است» یکی از فوری‌ترین هشدارهاست. اگر UPS فعلی کارت شبکه ندارد، افزودنش ارزان‌ترین بخش مانیتورینگ است.
• دما و رطوبت اتاق سرور با حسگر تحت شبکه. خرابی کولر اتاق سرور در تعطیلات، سناریوی کلاسیک خرابی سخت‌افزار است.

سه چارچوب برای انتخاب متریک‌ها

روش USE برای منابع

برای هر منبع — پردازنده، حافظه، دیسک، کارت شبکه — سه چیز: Utilization (درصد زمان مشغول)، Saturation (کار در صف که منتظر منبع است) و Errors (خطاها). اشباع مهم‌ترین و فراموش‌شده‌ترین است: دیسکی با ۶۰٪ استفاده اما صف طولانی، گلوگاه است.

روش RED برای سرویس‌ها

برای هر سرویس: Rate (تعداد درخواست در ثانیه)، Errors (درخواست‌های ناموفق) و Duration (زمان پاسخ). این سه، تجربه کاربر را مستقیم نشان می‌دهند.

چهار سیگنال طلایی

کتاب مهندسی قابلیت اطمینان سایت (SRE) گوگل، چهار سیگنال را برای هر سرویس کاربرمحور معرفی می‌کند: تأخیر، ترافیک، خطا و اشباع. نکته ظریفش: تأخیر درخواست‌های موفق و ناموفق را جدا بسنجید، چون خطای سریع می‌تواند میانگین تأخیر را گمراه‌کننده «خوب» نشان دهد.

پروتکل‌ها و روش جمع‌آوری

ابزارها

ابزارهای متن‌باز بالغ، برای بیشتر سازمان‌ها کافی‌اند:

• Zabbix: همه‌کاره، با الگوهای آماده برای بسیاری از تجهیزات، کشف خودکار، و هشدار چندسطحی. انتخاب رایج برای زیرساخت‌های سنتی شبکه و سرور.
• Prometheus و Grafana: Prometheus متریک‌ها را به‌صورت سری زمانی جمع می‌کند (با Exporterهایی مثل node_exporter برای سرور و snmp_exporter برای تجهیزات)، Alertmanager هشدارها را مدیریت می‌کند و Grafana داشبورد می‌سازد. انتخاب رایج برای محیط‌های کانتینری و برنامه‌های مدرن.
• LibreNMS: متمرکز بر شبکه، با کشف خودکار تجهیزات و نمودار پورت‌ها.

ابزار مهم است، اما کمتر از طراحی. بدترین حالت، نصب ابزار با همه الگوهای پیش‌فرض است که در هفته اول صدها هشدار بی‌اهمیت تولید می‌کند.

طراحی هشدار: مهم‌ترین بخش

بزرگ‌ترین شکست مانیتورینگ، خستگی از هشدار (Alert Fatigue) است: وقتی روزانه ده‌ها هشدار می‌آید که بیشترشان نیازی به اقدام ندارند، تیم یاد می‌گیرد نادیده‌شان بگیرد — و روزی که هشدار واقعی می‌آید، آن هم نادیده گرفته می‌شود. قواعد طراحی:

1. هر هشدار باید قابل اقدام باشد. اگر پاسخ درست به هشداری «کاری نکن» است، آن هشدار نیست؛ یک متریک در داشبورد است.
2. روی علامت هشدار دهید، نه علت. «زمان پاسخ نرم‌افزار مالی بالای ۵ ثانیه است» مهم‌تر از «پردازنده سرور ۹۰٪ است» — پردازنده ۹۰٪ که روی کاربر اثری ندارد، ممکن است کاملاً عادی باشد.
3. مدت زمان در شرط. «پردازنده بالای ۹۰٪ برای ۱۵ دقیقه»، نه «یک لحظه بالای ۹۰٪». در Prometheus این با بند for و در Zabbix با توابعی روی بازه زمانی تعریف می‌شود.
4. هشدار پیش‌بینانه. «دیسک در ۴۸ ساعت آینده با روند فعلی پر می‌شود» بسیار مفیدتر از «دیسک ۸۵٪ است». در Prometheus تابع predict_linear دقیقاً برای این است.
5. سطح‌بندی: بحرانی (فوری، حتی نیمه‌شب — پیامک یا تماس)، هشدار (در ساعت کاری رسیدگی شود — ایمیل یا پیام‌رسان)، اطلاعات (فقط در داشبورد).
6. وابستگی‌ها: اگر روتر شعبه قطع است، ده هشدار برای ده دستگاه پشت آن نفرستید؛ یک هشدار برای روتر.
7. مسیر ارجاع: اگر هشدار بحرانی در مدت مشخص تأیید نشد، به نفر بعدی برود.

SLO و بودجه خطا

برای سرویس‌های مهم، هدف دسترس‌پذیری را صریح تعریف کنید. هر «۹» اضافه، زمان مجاز توقف را ده برابر کم می‌کند:

این اعداد برای تعهد واقع‌بینانه در قرارداد پشتیبانی هم کاربرد دارند — ارتباطش را در SLA و زمان پاسخ آورده‌ایم. تفاوت مهم: SLA تعهد قراردادی به مشتری است؛ SLO هدف داخلی سخت‌گیرانه‌تری است که با مانیتورینگ سنجیده می‌شود تا SLA هرگز نقض نشود. مقداری که از توقف مجاز باقی مانده، بودجه خطا است: اگر در نیمه ماه بیشترش مصرف شده، تغییرات پرریسک تا ماه بعد عقب می‌افتند.

مانیتورِ مانیتورینگ

اگر سرور مانیتورینگ خودش از کار بیفتد، سکوت کامل است — که دقیقاً شبیه «همه چیز سالم است» به نظر می‌رسد. دو اقدام:

• هشدار نگهبان (Watchdog): یک هشدار که همیشه فعال است و به یک سرویس بیرونی ارسال می‌شود؛ اگر قطع شد، یعنی خود سیستم مانیتورینگ مشکل دارد.
• محل استقرار: سرور مانیتورینگ نباید در همان حوزه خرابی باشد که پایش می‌کند. اگر روی همان میزبان مجازی‌سازی است، با خرابی میزبان، هیچ هشداری نمی‌آید. کانال هشدار بحرانی — مثلاً پیامک — هم نباید فقط به همان اینترنتی وابسته باشد که ممکن است قطع شود.

از کجا شروع کنیم: چهار مرحله

1. هفته اول — حیاتی‌ها: دسترس‌پذیری لینک اینترنت، فایروال، سرورهای اصلی، UPS روی باتری، وضعیت RAID، شکست بکاپ، فضای دیسک. فقط هشدارهای بحرانی.
2. ماه اول — عمق: خطای پورت‌ها، تأخیر دیسک، بررسی مصنوعی سرویس‌های اصلی، گواهی‌ها، دمای اتاق سرور.
3. ماه دوم — تنظیم: بازبینی همه هشدارهای ماه اول. هر هشداری که اقدامی در پی نداشت، حذف یا به داشبورد منتقل شود. آستانه‌ها بر اساس خط مبنای واقعی تنظیم شوند.
4. مداوم — روند: گزارش ماهانه ظرفیت و دسترس‌پذیری، و افزودن پایش برای هر حادثه‌ای که مانیتورینگ پیش از کاربر تشخیصش نداد.

قاعده مرحله آخر مهم است: هر حادثه باید یک سؤال داشته باشد — «چرا مانیتورینگ این را زودتر ندید؟» — و جوابش به پایش یا هشدار جدید تبدیل شود. بررسی‌های دوره‌ای که مکمل مانیتورینگ خودکارند را در سرویس دوره‌ای سرور و نگهداری پیشگیرانه شبکه آورده‌ایم.

پرسش‌های متداول

مانیتورینگ برای شرکت کوچک هم لازم است؟

بله، و حتی مهم‌تر، چون شرکت کوچک معمولاً کسی را ندارد که هر روز سرورها را نگاه کند. مجموعه کوچکی از هشدارهای حیاتی — لینک، UPS، RAID، بکاپ، فضای دیسک — بیشتر خرابی‌های پرهزینه را پیش از وقوع نشان می‌دهد.

مانیتورینگ ابری بهتر است یا داخلی؟

برای پایش دسترس‌پذیری از دید بیرون — سایت و سرویس‌های اینترنتی — بررسی از بیرون شبکه لازم است. برای تجهیزات داخلی، سرور مانیتورینگ داخلی رایج‌تر است. ترکیب هر دو، مسئله «مانیتورِ مانیتورینگ» را هم حل می‌کند.

راه‌اندازی مانیتورینگ چقدر طول می‌کشد؟

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

قدم بعدی

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

مشاهده خدمات DevOps و مانیتورینگ زیرساخت · تلفن: 021-74903