کالبدشکافی ManageEngine (بخش دوم): توهمِ مانیتورینگ یکپارچه؛ تفاوت «داشبوردهای بههمچسبیده» با «یکپارچگی در هسته»
پیش از ورود به بحث لازم است تأکید کنیم که هدف این مجموعه مقالات زیر سؤال بردن ارزش یا توانمندی ابزارهای مطرح مانیتورینگ زیرساخت فناوری اطلاعات نیست. بسیاری از این راهکارها سالهاست در سازمانهای مختلف مورد استفاده قرار گرفتهاند و نقش مهمی در پایش و مدیریت محیطهای IT ایفا میکنند. آنچه در این مجموعه مقالات بررسی میشود، بیشتر نگاهی تحلیلی به برخی محدودیتها و چالشهایی است که میتوانند برای سازمانها مسئلهساز شوند.
در معماری نرمافزار به سیستمهایی که از کنار هم قرار دادن چند محصول مستقل ساخته میشوند، «معماری فرانکشتاین» گفته میشود. این معماری شاید در دموهای فروش جذاب به نظر برسد، اما در زمان بروز بحرانهای زیرساختی، تیمهای عملیات را با مشکلات جدی مواجه میکند.
ManageEngine یکی از نمونههایی است که بسیاری از محصولات مانیتورینگ خود را بهصورت مجموعهای از ابزارهای مستقل ارائه میکند. در این مقاله میخواهیم به معایب این معماری و دردسرهایی که در زمینه عملیات ایجاد میکند، بپردازیم.
یکی از مفاهیم محبوب در دنیای مانیتورینگ زیرساخت، ایدهی “Single Pane of Glass” یا «پنجره واحد» برای مشاهده کل وضعیت سیستمهاست. ManageEngine سالهاست که با وعده ارائه چنین پلتفرمی، محصولات خود را عرضه میکند. اما وقتی از لایه رنگارنگ داشبوردها عبور میکنیم و به معماری زیرین سیستم نگاه میاندازیم، با واقعیت دیگری روبهرو میشویم: آنچه به عنوان مانیتورینگ یکپارچه فروخته میشود، در واقع مجموعهای از نرمافزارهای جداگانه است که صرفاً در یک رابط کاربری (UI) به هم چسبانده شدهاند.
داشبوردهای بههمچسبیده: وقتی ماژولهای ManageEngine زبان یکدیگر را نمیفهمند
در پلتفرم ManageEngine، شما معمولاً برای مانیتورینگ شبکه از OpManager، برای سرویسها و نرمافزارها از Applications Manager و برای تحلیل ترافیک از NetFlow Analyzer استفاده میکنید. هرچند ممکن است تبهای همه اینها را در یک پرتال وب ببینید، اما در هسته سیستم:
- هر کدام از این ابزارها موتور پردازشی (Engine) کاملاً مستقل خود را دارند.
- هر ماژول دیتابیس جداگانهای برای ذخیره اطلاعات دارد.
- منطق جمعآوری داده و سیستم هشداردهی (Alerting) آنها مجزا از یکدیگر عمل میکند.
نتیجه این معماری، «توهم یکپارچگی» است. در چنین معماریای، همبستگی واقعی دادهها در سطح سیستم وجود ندارد؛ هر ماژول تنها دادههای خودش را تحلیل میکند و تصویر کلی زیرساخت باید بهصورت ذهنی توسط اپراتور ساخته شود. به بیان دیگر، کاری که یک پلتفرم مانیتورینگ باید انجام دهد، عملاً به عهده انسان گذاشته میشود.
دردسرهای عملیاتی معماری فرانکنشتاین در زمان بحران
وقتی یک سرویس حیاتی در سازمان دچار اختلال میشود، زمان برای یافتن علت ریشهای (Root Cause Analysis) حیاتی است. در معماری ManageEngine، تیمهای عملیات با این دردسرها مواجه میشوند:
- فقدان بستر مشترک و بمباران هشدارها: اگر سرور دیتابیس دچار مشکل شود، Applications Manager یک هشدار میدهد و OpManager همزمان افت ترافیک شبکه را گزارش میکند. سیستم توانایی درک این موضوع را ندارد که این دو اتفاق به هم مرتبط هستند؛ در نتیجه، ادمین به جای دریافت یک هشدار تحلیلی و ریشهای، با طوفانی از هشدارهای نامرتبط روبهرو میشود. در چنین شرایطی، زمان تشخیص علت اصلی مشکل ممکن است از چند دقیقه به دهها دقیقه یا حتی ساعتها افزایش پیدا کند؛ موضوعی که در سرویسهای حیاتی میتواند به معنی اختلال گسترده یا نارضایتی کاربران باشد.
- سربار شدید منابع (Resource Overhead): اجرای چندین موتور مجزای مبتنی بر جاوا (Java) و نگهداری چندین دیتابیس در کنار هم، به شدت منابع سرور (CPU و RAM) را میبلعد و خود ابزار مانیتورینگ را به یک بارِ پردازشی سنگین برای زیرساخت تبدیل میکند.
- کابوس بهروزرسانی و یکپارچهسازی: ارتقای یک ماژول (مثلاً آپدیت OpManager) میتواند باعث از کار افتادن ارتباط با ماژولهای دیگر شود، زیرا این محصولات از پایه به عنوان یک سیستم واحد طراحی نشدهاند.
«یکپارچگی در هسته» واقعا مزیت است؟
از نظر معماری نرم افزار، یک سیستم واقعاً یکپارچه تنها در سطح رابط کاربری به هم متصل نیست؛ بلکه در هسته معماری خود اشتراک دارد. در چنین سیستمی:
- دادههای شبکه، زیرساخت و سرویسها در یک مدل داده مشترک ذخیره میشوند.
- همه رویدادها از یک موتور پردازش رویداد واحد عبور میکنند.
- سیستم هشداردهی، تحلیل و همبستگی دادهها بر پایه همان پایگاه داده مشترک عمل میکند.
این تفاوت ظاهراً کوچک، در عمل اثر بزرگی ایجاد میکند. در پلتفرمهایی که از ابتدا با معماری هستهای یکپارچه طراحی شدهاند — مانند پلتفرم مانیتورینگ معین — وقتی یک اختلال در زیرساخت رخ میدهد، سیستم میتواند ارتباط بین رویدادها را درک کند. افت عملکرد دیتابیس، کندی سرویسهای وابسته و کاهش ترافیک کاربران، همگی به عنوان نشانههایی از یک مشکل مشترک تحلیل میشوند و به جای دهها هشدار پراکنده، یک تصویر منسجم از مشکل ارائه میشود.
اما در معماریهایی مانند ManageEngine که تنها در سطح رابط کاربری یکپارچه شدهاند، هر ماژول همچنان جهان مستقل خود را دارد. در چنین شرایطی، کار همبستگی رویدادها عملاً از سیستم به انسان منتقل میشود. این یعنی به جای اینکه ابزار مانیتورینگ پیچیدگی زیرساخت را ساده کند، خود به لایهای جدید از پیچیدگی تبدیل میشود؛ لایهای که در زمان بحران، سرعت تشخیص و واکنش تیم عملیات را به شکل محسوسی کاهش میدهد.
