پایش سرور: شاخص‌ها، آستانه هشدار و مانیتورینگ بیرونی

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

قبل از هر ابزاری، این چهار شاخص را بسنجید

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

• Load average نسبت به تعداد هسته. دستور uptime سه عدد می‌دهد: میانگین ۱، ۵ و ۱۵ دقیقه. عدد خام بی‌معنی است؛ باید تقسیم بر تعداد هسته شود. روی یک سرور ۴ هسته‌ای، لود ۴ یعنی اشباع کامل. لود ۸ یعنی صف انتظار دو برابر ظرفیت پردازش است. اگر لود بالا می‌رود ولی CPU بیکار است، مشکل I/O دیسک است نه پردازنده؛ راهنمای تشخیص علت لود بالای سرور همین حالت را گام‌به‌گام باز می‌کند.
• مصرف حافظه و swap. با free -m نگاه کنید، نه به ستون free بلکه به available. عدد available همان چیزی است که واقعاً می‌توانید به پروسه‌های جدید بدهید. اگر swap به‌طور مداوم در حال استفاده است، سرور زنده است ولی کند؛ این حالت بدتر از crash کامل است چون کسی متوجه نمی‌شود.
• فضای دیسک و inode. df -h فضای بلاک را نشان می‌دهد و df -i تعداد inode. این دومی را جدی بگیرید. سروری که ۲۰٪ فضا دارد ولی inode‌اش تمام شده، هیچ فایلی نمی‌تواند بسازد و خطای No space left on device می‌دهد در حالی که df فضای خالی نشان می‌دهد. معمولاً تقصیر session‌های PHP یا فایل‌های cache کوچک و بی‌شمار است.
• زمان پاسخ سرویس، نه فقط زنده بودنش. اینکه nginx با کد 200 جواب می‌دهد کافی نیست. اگر پاسخ ۸ ثانیه طول بکشد، از دید کاربر سایت down است.

آستانه هشدار را چطور تعیین کنیم که شبانه بیدارتان نکند

بزرگ‌ترین اشتباه در پایش سرور، انتخاب آستانه بر اساس حدس است. کسی می‌گوید «اگر CPU بالای ۸۰ رفت هشدار بده» و بعد هر روز ساعت ۳ صبح یک ایمیل می‌گیرد چون backup شبانه همان ساعت اجرا می‌شود. دو هفته بعد، آن ایمیل را فیلتر می‌کند و دیگر هیچ هشداری نمی‌بیند. این دقیقاً همان اتفاقی است که باعث می‌شود پایش داشته باشید و باز هم غافلگیر شوید.

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

ستون «مدت تداوم» مهم‌تر از ستون آستانه است. یک جهش لحظه‌ای CPU به ۹۵٪ برای دو ثانیه، خبر بدی نیست؛ همان کاری است که یک سرور باید بکند. هشدار باید روی تداوم باشد، نه روی قله. در Prometheus این را با for: 10m در بلوک rule می‌نویسید:

- alert: HighLoad
  expr: node_load1 > (count(node_cpu_seconds_total{mode="idle"}) * 1.5)
  for: 10m
  labels:
    severity: warning

خط for: 10m همان چیزی است که جلوی هشدارهای کاذب را می‌گیرد. بدون آن، هر بار که یک cron سنگین اجرا شود، تلفن‌تان زنگ می‌خورد.

پایش درونی کافی نیست؛ از بیرون هم نگاه کنید

اینجا جایی است که خیلی‌ها اشتباه می‌کنند. Netdata یا node_exporter را روی سرور نصب می‌کنند، داشبورد قشنگی می‌سازند و خیالشان راحت است. اما وقتی خود سرور از دسترس خارج شود، همان ابزار هم از دسترس خارج می‌شود. اگر سرور ریبوت شود، اگر کارت شبکه بمیرد، اگر دیتاسنتر مشکل برق داشته باشد، اگر فایروال اشتباهی بسته شود، شما هیچ هشداری نمی‌گیرید چون هشداردهنده روی همان ماشینی بود که مرده است.

پایش بیرونی یعنی یک نقطهٔ مستقل، خارج از سرور شما، هر ۶۰ ثانیه یک درخواست HTTP یا یک ping بفرستد و اگر جواب نیامد، به شما خبر بدهد. این سرویس می‌تواند یک VPS ارزان در جای دیگر باشد یا یکی از سرویس‌های uptime monitoring. نکتهٔ مهم این است که مسیر هشدار از مسیر خرابی جدا باشد.

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

چه چیزی را عمداً پایش نکنید

هر متریکی که اضافه می‌کنید، هزینهٔ ذخیره‌سازی و هزینهٔ توجه دارد. چند چیز را آگاهانه کنار بگذارید:

• متریک‌های سطح پروسه برای سرویس‌هایی که خودشان restart می‌شوند. اگر systemd ظرف ۵ ثانیه سرویس را بالا می‌آورد، هشدار دادن روی آن فقط نویز است.
• نرخ خطای ۴۰۴. این عدد در سایت‌های عمومی همیشه بالا است و تقریباً هیچ‌وقت نشانهٔ خرابی نیست.
• دمای CPU روی سرورهای مجازی. سنسوری وجود ندارد و عددی که می‌بینید ساختگی است.

راه‌اندازی عملی در نیم ساعت

اگر می‌خواهید همین امروز شروع کنید، این ترتیب را برویم:

1. روی سرور، node_exporter را نصب و با systemd فعال کنید. پورت پیش‌فرضش ۹۱۰۰ است و باید فقط از IP سرور مانیتورینگ قابل دسترس باشد، نه از اینترنت. فهرست پورت‌هایی که نباید باز باشند را در مرجع پورت سرویس‌های پرکاربرد ببینید.
2. یک Prometheus روی یک ماشین جدا بالا بیاورید و در prometheus.yml هدف را اضافه کنید. اگر ماشین جدا ندارید، یک سرور ابری کوچک برای همین کار کافی است.
3. چهار هشدار جدول بالا را بنویسید. Alertmanager را به یک کانال واقعی وصل کنید؛ ایمیلی که روی گوشی notification نمی‌دهد، هشدار نیست.
4. یک بررسی بیرونی HTTP روی صفحهٔ اصلی سایت تنظیم کنید، با تایم‌اوت ۱۰ ثانیه.
5. یک هفته بگذارید کار کند و بعد آستانه‌ها را بر اساس دادهٔ واقعی تنظیم کنید.

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

این‌جا اشتباه می‌کنند

رایج‌ترین اشتباهی که دیده‌ام این است: کسی Alertmanager را تنظیم می‌کند، ولی مسیر ارسال هشدار از همان سرور می‌گذرد. یعنی هشدار با SMTP محلی ارسال می‌شود. سرور دیسکش پر می‌شود، postfix نمی‌تواند صف را بنویسد، و هیچ ایمیلی بیرون نمی‌رود. علامتش هم این است: در داشبورد می‌بینید که هشدار trigger شده، ولی در inbox هیچ خبری نیست. همیشه از یک relay بیرونی برای ارسال هشدار استفاده کنید.

اشتباه دوم، هشدار روی «سرویس بالاست» به‌جای «سرویس درست کار می‌کند» است. nginx با کد 502 هم بالاست. بررسی سلامت باید یک endpoint واقعی را صدا بزند که به دیتابیس هم دست بزند، نه فقط پورت ۸۰ را باز ببیند.

پرسش‌های پرتکرار

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

برای شروع سریع، Netdata کمترین زحمت را دارد و در چند دقیقه داشبورد زنده می‌دهد. اگر می‌خواهید هشدارهای دقیق و تاریخچهٔ بلندمدت داشته باشید، ترکیب Prometheus و node_exporter و Alertmanager انتخاب بهتری است، به قیمت اینکه باید چند فایل YAML بنویسید. برای یک سرور تنها، Netdata کافی است؛ از سه سرور به بالا، Prometheus ارزش وقتش را دارد.

آستانه هشدار CPU را روی چند بگذارم؟

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

چرا با اینکه مانیتورینگ دارم، خرابی را دیر فهمیدم؟

تقریباً همیشه یکی از دو دلیل است: یا هشدار روی متریک اشتباهی تنظیم شده بود، یا مسیر ارسال هشدار از همان سروری می‌گذشت که خراب شده بود. دلیل سوم هم کم نیست: هشدارهای کاذب آن‌قدر زیاد بوده که کاربر آن‌ها را فیلتر کرده. اگر هشدارهایتان را نادیده می‌گیرید، مشکل پایش نیست، مشکل تنظیم آستانه است.

پایش بیرونی و درونی را همزمان لازم دارم؟

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

همین امروز یک بررسی بیرونی روی صفحهٔ اصلی سایتتان تنظیم کنید. یک درخواست HTTP هر ۶۰ ثانیه، با تایم‌اوت ۱۰ ثانیه و هشداری که به گوشی‌تان می‌رسد. این نیم ساعت کار، بیشتر از هر داشبورد زیبایی ارزش دارد.