پیاده‌سازی SLA در Zabbix؛ از مانیتورینگ سرویس تا محاسبه Availability
وقتی صحبت از مانیتورینگ میشه، معمولاً اولین چیزی که به ذهنمون میرسه اینه که بفهمیم یک سرور یا سرویس Up هست یا Down. اما در محیط واقعی فقط دونستن وضعیت فعلی سرویس کافی نیست.
مثلاً ممکنه بخوایم بدونیم یک سرویس در طول یک ماه چند درصد در دسترس بوده؟ چقدر قطعی داشته؟ آیا SLA تعریف‌شده برای اون سرویس رعایت شده یا نه؟
اینجاست که قابلیت SLA در Zabbix کاربردی میشه.
در ویدیویی که در این صفحه قرار دادم، سعی کردم با یک سناریوی ساده و عملی، نحوه‌ی پیاده‌سازی SLA در Zabbix رو از ابتدا بررسی کنم.
SLA دقیقاً چیه؟
SLA یا Service Level Agreement به زبان ساده مشخص می‌کنه که انتظار داریم یک سرویس در یک بازه‌ی زمانی مشخص چه میزان در دسترس باشه.
مثلاً اگر برای یک سرویس SLA برابر با 99.9% تعریف کنیم، یعنی انتظار داریم این سرویس در طول بازه‌ی موردنظر حداقل 99.9 درصد در دسترس باشه.
این عدد وقتی معنی بیشتری پیدا می‌کنه که بدونیم حتی اختلاف کوچیک بین 99%، 99.9% و 99.99% می‌تونه مقدار Downtime مجاز رو به شکل قابل توجهی تغییر بده.
سناریویی که در ویدیو پیاده‌سازی کردیم
برای اینکه موضوع فقط در حد تعریف و تئوری باقی نمونه، یک سناریوی آزمایشگاهی ساختم.
روی یک سرور چند TCP Port مختلف بالا آوردم و هر کدوم رو به عنوان یک سرویس در نظر گرفتم.
بعد در Zabbix برای این پورت‌ها Item ساختم تا وضعیتشون مانیتور بشه. در مرحله‌ی بعد برای هر کدوم Trigger تعریف کردم تا اگر پورت از دسترس خارج شد، Zabbix بتونه اون رو به عنوان یک Problem تشخیص بده.
تا اینجا تقریباً با ساختار معمول مانیتورینگ در Zabbix طرف هستیم:
TCP Port → Item → Trigger → Problem
اما برای پیاده‌سازی SLA باید یک مرحله جلوتر بریم.
تعریف Service در Zabbix
در مرحله‌ی بعد از قابلیت Services در Zabbix استفاده کردم.
Service در واقع کمک می‌کنه وضعیت فنی‌ای که توسط Triggerها تشخیص داده میشه رو به یک سرویس قابل فهم‌تر تبدیل کنیم.
مثلاً به جای اینکه فقط بگیم:
TCP Port 8080 is down
می‌تونیم این Problem رو به سرویسی مثل:
Web Application Service
مرتبط کنیم.
این موضوع مخصوصاً وقتی تعداد زیادی Host، Item و Trigger داریم خیلی کاربردیه، چون می‌تونیم از دید سرویس به زیرساخت نگاه کنیم، نه صرفاً از دید تجهیزات و Triggerها.
اتصال Service به SLA
بعد از اینکه Service ساخته شد، SLA موردنظر رو تعریف می‌کنیم و Service رو به اون متصل می‌کنیم.
از اینجا به بعد Zabbix می‌تونه Availability سرویس رو در بازه‌های زمانی مختلف محاسبه کنه و مشخص کنه که SLA موردنظر رعایت شده یا نه.
در نتیجه مسیر کلی سناریویی که در ویدیو پیاده کردیم به این شکل میشه:
TCP Service → Item → Trigger → Problem → Service → SLA
به نظرم درک همین زنجیره یکی از مهم‌ترین قسمت‌های یادگیری SLA در Zabbix هست. چون وقتی ارتباط بین Trigger، Service و SLA مشخص بشه، پیاده‌سازی سناریوهای بزرگ‌تر هم خیلی راحت‌تر میشه.
این قابلیت کجا به درد می‌خوره؟
فرض کنید چند سرویس مهم مثل وب‌سایت، API، دیتابیس یا سرویس‌های داخلی سازمان دارید.
صرفاً اینکه Zabbix هنگام قطعی براتون Alert ارسال کنه خوبه، ولی بعد از چند ماه احتمالاً سوال‌های مهم‌تری مطرح میشه:
این سرویس واقعاً چقدر در دسترس بوده؟
ماه قبل چند ساعت Downtime داشتیم؟
آیا Availability سرویس به 99.9% رسیده؟
کدوم سرویس بیشتر از SLA تعیین‌شده قطعی داشته؟
اینجاست که SLA از یک قابلیت جانبی تبدیل به یک ابزار کاربردی برای گزارش‌گیری و بررسی کیفیت سرویس‌ها میشه.
در ویدیوی این صفحه کل این سناریو رو مرحله‌به‌مرحله داخل Zabbix پیاده‌سازی کردم؛ از ساخت Item و Trigger برای TCP Portها گرفته تا تعریف Service و در نهایت محاسبه SLA.
ادامه این قسمت در ویدیو زیر میتوانید مشاهده کنید:
