مقاله 04 / مانیتورینگ
مانیتورینگ سرور با Prometheus و Grafana؛ از نمودار تا هشدار قابل اقدام
مشخصات پیشنهادی انتشار
- عنوان سئو
- مانیتورینگ سرور با Prometheus و Grafana | نگهبان وب
- توضیح متا
- برای مانیتورینگ سرور چه شاخص‌هایی لازم است؟ پایش تجربه کاربر، منابع، صف و دیتابیس را به هشدار قابل اقدام و مسیر رسیدگی مشخص متصل کنید.
- مسیر پیشنهادی
- /blog/server-monitoring-alerting
- عبارت اصلی
- مانیتورینگ سرور
- تصویر
- server-monitoring-alerting.webp
- یادداشت انتشار
- تصویر را در CMS بارگذاری و تاریخ واقعی انتشار و URL تصویر را ثبت کنید.
مانیتورینگ سرور زمانی مفید است که قبل از تبدیل شدن یک مشکل به اختلال گسترده، به تصمیم درست کمک کند. یک داشبورد زیبا یا نمایش درصد CPU به‌تنهایی کافی نیست. باید معلوم باشد کدام مسیر کاربر آسیب دیده، چه کسی هشدار را می‌گیرد و اولین اقدام تشخیصی چیست.
Prometheus برای جمع‌آوری و پرس‌وجوی متریک‌ها و Grafana برای نمایش و تحلیل آن‌ها کاربرد دارند. هشدارها نیز باید با قواعد، مسیر ارسال و مسئول پاسخ روشن طراحی شوند. کیفیت نتیجه بیشتر به انتخاب شاخص و فرایند رسیدگی وابسته است تا تعداد نمودارهای نصب‌شده.
کاربر فروشگاه به ثبت سفارش اهمیت می‌دهد، نه فقط روشن بودن ماشین. بنابراین پایش بیرونی یک مسیر عمومی سالم را کنار شاخص‌های داخلی قرار دهید. endpoint سلامت هم باید معنای مشخص داشته باشد: زنده بودن فرایند با آماده بودن آن برای دریافت ترافیک یکسان نیست.
برای یک محصول، چهار گروه شاخص نقطه شروع خوبی‌اند: زمان پاسخ، حجم ترافیک، نرخ خطا و نزدیک شدن منابع به حد ظرفیت. این چارچوب در کتاب SRE گوگل توضیح داده شده است. در عمل، انتخاب زیرشاخص‌ها باید با رفتار برنامه خودتان هماهنگ باشد.
حداقل داشبورد کاربردی چه چیزهایی دارد؟
| لایه | شاخص پیشنهادی | پرسشی که پاسخ می‌دهد |
|---|---|---|
| تجربه کاربر | موفقیت درخواست و زمان پاسخ مسیرهای مهم | آیا خدمت واقعاً قابل استفاده است؟ |
| برنامه | نرخ خطا، تعداد درخواست و زمان پردازش | افت کیفیت از چه زمانی شروع شده؟ |
| صف | طول صف و سن قدیمی‌ترین کار | کارها در حال عقب افتادن‌اند؟ |
| دیتابیس | اتصال‌ها، زمان query و انتظار قفل | آیا برنامه پشت دیتابیس منتظر مانده؟ |
| میزبان | حافظه، CPU، فضای دیسک و inode | کدام منبع به محدودیت نزدیک است؟ |
نمایش فقط میانگین زمان پاسخ می‌تواند کندی بخشی از کاربران را پنهان کند. صدک‌ها، حجم نمونه و تفکیک مسیرها دید دقیق‌تری می‌دهند. با این حال، از ساختن برچسب‌های بی‌نهایت مانند شناسه هر کاربر یا هر درخواست در متریک‌ها پرهیز کنید؛ جزئیات تک‌درخواست معمولاً جای دیگری مثل لاگ یا trace قرار می‌گیرند.
هشدار خوب چه مشخصاتی دارد؟
هر هشدار باید نام خدمت، شدت، زمان شروع، نشانه اختلال و لینک راهنمای اقدام داشته باشد. متن «سرور مشکل دارد» کمکی به تشخیص نمی‌کند. متن «نرخ خطای مسیر سفارش افزایش یافته؛ لاگ برنامه و اتصال دیتابیس بررسی شود» مسیر مشخص‌تری می‌دهد.
قواعد را براساس نوسان طبیعی و اثر واقعی تنظیم کنید. یک جهش کوتاه CPU الزاماً نیاز به بیدار کردن فرد ندارد. در مقابل، شکست پیوسته ثبت سفارش می‌تواند با مصرف منابع عادی رخ دهد. مثال‌های آستانه باید روی خط پایه واقعی آزمایش شوند؛ عدد ثابت برای همه سرورها مناسب نیست.
برای هشدارها سه مسیر بسازید
هشدار فوری برای اختلال جاری و مهم، تیکت برای مشکلی که زمان رسیدگی دارد و گزارش برای روندی که نیازمند برنامه‌ریزی است. این تقسیم باید با ساعات پوشش قرارداد هماهنگ باشد. اگر کسی خارج از ساعت کاری پاسخ نمی‌دهد، ارسال پیام فوری به‌تنهایی پوشش شبانه‌روزی ایجاد نمی‌کند.
هشدارهای وابسته را گروه‌بندی کنید. قطع یک ماشین نباید ده‌ها پیام جدا برای همه کانتینرهای همان ماشین ایجاد کند. در زمان نگهداری برنامه‌ریزی‌شده هم سکوت موقت، محدود و ثبت‌شده تعریف کنید تا تیم به نادیده گرفتن کلی هشدارها عادت نکند.
مسیر ارسال هشدار را هم آزمایش کنید
یک رخداد آزمایشی کنترل‌شده بسازید و ببینید پیام به گیرنده درست می‌رسد یا نه. دریافت پیام، تأیید آن، ارجاع و بسته شدن رخداد باید قابل پیگیری باشد. خرابی سرویس پیام‌رسان یا انقضای توکن ارسال نباید ماه‌ها پنهان بماند.
بهتر است پایش حداقلی بیرونی به همان ماشین اصلی وابسته نباشد. اگر ابزار مانیتورینگ همراه برنامه از دسترس خارج شود، تیم ممکن است هیچ هشداری نگیرد. نحوه این استقلال به اندازه و بودجه زیرساخت بستگی دارد و می‌تواند ساده و مرحله‌ای باشد.
خروجی ماهانه را به تصمیم تبدیل کنید
به‌جای گزارش چند ده نمودار، سه موضوع را بنویسید: مهم‌ترین اختلال‌ها، خطرهای ظرفیت و اقدام‌های ماه آینده. مثلاً اگر فضای دیسک پیوسته رشد کرده، زمان تقریبی رسیدن به حد بحرانی را با فرض روند فعلی محاسبه کنید؛ این برآورد را پیش‌بینی قطعی تلقی نکنید.
در خدمات مانیتورینگ نگهبان وب، دامنه پایش و روش رسیدگی باید متناسب با سرویس‌های توافق‌شده تعریف شود. هدف عملی این است که هر نمودار یا هشدار به سؤال مشخصی پاسخ دهد.
پرسش‌های رایج
آیا برای یک سرور هم مانیتورینگ لازم است؟
اگر توقف آن روی کار شما اثر دارد، پایش پایه ارزش دارد. اندازه سامانه مانیتورینگ باید با نیاز متناسب باشد.
آیا داشتن Grafana یعنی مانیتورینگ کامل داریم؟
خیر. جمع‌آوری داده، قواعد هشدار، گیرنده مسئول و آزمون مسیر ارسال باید جدا بررسی شوند.
برای شروع، درخواست طراحی مانیتورینگ را با فهرست سرویس‌ها و مهم‌ترین مسیرهای کاربر ثبت کنید.
