کالبدشکافی ManageEngine (بخش سوم): نابینایی کانتینری؛ محدودیت‌های دید ManageEngine در دنیای Cloud-Native

پیش از ورود به بحث لازم است تأکید کنیم که هدف این مجموعه مقالات زیر سؤال بردن ارزش یا توانمندی ابزارهای مطرح مانیتورینگ زیرساخت فناوری اطلاعات نیست. بسیاری از این راهکارها سال‌هاست در سازمان‌های مختلف مورد استفاده قرار گرفته‌اند و نقش مهمی در پایش و مدیریت محیط‌های IT ایفا می‌کنند. آنچه در این مجموعه مقالات بررسی می‌شود، بیشتر نگاهی تحلیلی به برخی محدودیت‌ها و چالش‌هایی است که می‌توانند برای سازمان‌ها مسئله‌ساز شوند.

در زیرساخت‌های سنتی، مانیتورینگ یعنی مشاهده سرورها. هر سرویس روی یک ماشین مشخص اجرا می‌شود، آدرس‌ها ثابت‌اند و توپولوژی شبکه به‌ندرت تغییر می‌کند. بسیاری از ابزارهای مانیتورینگ کلاسیک، از جمله ManageEngine، دقیقاً برای چنین دنیایی طراحی شده‌اند.

اما زیرساخت‌های مدرن دیگر شبیه گذشته نیستند. با ظهور کانتینرها و پلتفرم‌هایی مانند Kubernetes، سرویس‌ها به موجوداتی پویا و موقتی تبدیل شده‌اند که دائماً ایجاد، جابه‌جا و نابود می‌شوند. در چنین محیطی، ابزارهایی که با ذهنیت «سرورمحور» طراحی شده‌اند، به‌تدریج دچار نوعی نابینایی عملیاتی می‌شوند.

مشکل اصلی ManageEngine این است که معماری آن همچنان بر همان فرض‌های قدیمی استوار است؛ فرض‌هایی که در دنیای کانتینرها دیگر برقرار نیستند.

فرض‌های قدیمی ManageEngine

• در زیرساخت‌های سنتی، هر سرویس معمولاً روی یک ماشین فیزیکی یا یک ماشین مجازی مشخص اجرا می‌شد؛ سیستمی با نام و IP ثابت که به‌ندرت تغییر می‌کرد. اما در دنیای کانتینرها این فرض دیگر برقرار نیست. پادها و کانتینرها ممکن است در عرض چند ثانیه ایجاد یا نابود شوند، IPها دائماً تغییر می‌کنند و دسترسی به سرویس‌ها اغلب از طریق مکانیزم‌هایی مانند Service Discovery و DNS داخلی انجام می‌شود. ManageEngine که بر مبنای مشاهده «نودهای ثابت» طراحی شده، در چنین محیط پویایی به‌سختی می‌تواند تصویر دقیقی از وضعیت سیستم ارائه دهد.
• در گذشته، توپولوژی شبکه نیز معمولاً ساختاری پایدار داشت. مدیر شبکه آن را یک‌بار طراحی می‌کرد و ابزارهای مانیتورینگ می‌توانستند همان ساختار را ترسیم و پایش کنند. اما در محیط‌های مبتنی بر Kubernetes ارتباطات میان سرویس‌ها دائماً در حال تغییر است. سرویسی که امروز روی یک Node اجرا می‌شود ممکن است فردا روی Node دیگری قرار گیرد. این پویایی باعث می‌شود ابزارهایی که بر اساس توپولوژی‌های ایستا طراحی شده‌اند، مانند ManageEngine، نتوانند نمای دقیقی از ارتباطات لحظه‌ای بین سرویس‌ها ارائه دهند.
• مشکل دیگر به مدل جمع‌آوری داده بازمی‌گردد. ManageEngine  همچنان تا حد زیادی به مدل agent محور متکی است؛ مدلی که در آن روی هر سرور یک عامل نرم‌افزاری نصب می‌شود تا متریک‌ها را گزارش کند. در محیط‌های کانتینری، که در آن هزاران پاد می‌توانند به‌صورت موقتی ایجاد و حذف شوند، نصب و مدیریت agent برای هر کانتینر عملاً غیرعملی است. به همین دلیل بسیاری از ابزارهای مدرن مانیتورینگ به سمت رویکردهایی مانند جمع‌آوری متمرکز متریک‌ها و telemetry مبتنی بر پلتفرم حرکت کرده‌اند.

البته باید توجه داشت که برخی محصولات خانواده  ManageEngine، مانند Applications Manager یا سرویس ابری Site24x7، قابلیت‌هایی برای مشاهده محیط‌های Kubernetes و Docker ارائه می‌دهند. اما مسئله اصلی در اینجا «وجود قابلیت» نیست، بلکه نوع معماری پشت آن است.

در بسیاری از ابزارهای مانیتورینگ سنتی، پشتیبانی از کانتینرها به‌صورت افزونه یا قابلیت اضافه‌شده در سال‌های اخیر ارائه شده است. در حالی که معماری پایه این ابزارها همچنان بر مدل‌های سنتی مانند Polling و مانیتورینگ مبتنی بر نود استوار است. در مقابل، بسیاری از ابزارهای مدرن مانیتورینگ از ابتدا با فرض پویایی زیرساخت‌های کانتینری طراحی شده‌اند و بر مبنای جریان مداوم Telemetry و معماری‌های Event-driven عمل می‌کنند.

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

دردسرهای عدم مانیتورینگ کانتینرها

از اهمیت مانیتورینگ کانتینرها می‌توان به این نکته اشاره کرد که امروز «قابلیت مانیتورینگ کوبرنتیز» به یکی از معیارهای اصلی ارزیابی ابزارهای مانیتورینگ تبدیل شده است. در واقع، هر محصولی که خود را مدرن بداند، باید بتواند سلامت و رفتار workloadهای کانتینری را ردیابی کند. اما نبود این قابلیت، در ابزارهایی که دید عمیقی نسبت به لایه‌های کانتینری ندارند — از جمله برخی پیاده‌سازی‌های ManageEngine — این مسئله می‌تواند پیامدهای عملی و پرهزینه‌ای ایجاد کند.

در یک محیط کانتینری، سرویس‌ها به‌صورت پویا و لحظه‌ای جابه‌جا می‌شوند. اگر ابزار مانیتورینگ نتواند ساخت و نابودی این پادها را تشخیص دهد، مجموعه‌ای از blind spot‌ها شکل می‌گیرد؛ بخش‌هایی از زیرساخت که هیچ داده‌ای از آن‌ها جمع‌آوری نمی‌شود. نتیجه؟

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

مشکل به همین‌جا ختم نمی‌شود. در معماری‌های مبتنی بر میکروسرویس، هر کانتینر ممکن است وابسته به چند سرویس دیگر باشد. فقدان مانیتورینگ عمیق باعث می‌شود ابزار نتواند زنجیره وابستگی یا تأثیر دومینووار خطاها را ردیابی کند. یعنی اگر یک سرویس پایه دچار مشکل شود، تشخیص اینکه کدام سرویس‌های دیگر آسیب می‌بینند تقریباً غیرممکن می‌شود. بخش قابل توجهی از مانیتورینگ در ابزارهایی مانند ManageEngine بیشتر در سطح «Node Down» یا «CPU Usage High» باقی می‌ماند، نه در سطح «کدام سرویس به‌دلیل اختلال در پاد X دچار degradation شده است».

در نتیجه نه تنها مانیتورینگ ناقص است، بلکه کل مدل تشخیص و واکنش سریع (Incident Response) فلج می‌شود.

در مقیاس بالا این ضعف خودش را بیشتر نشان می‌دهد. وقتی صدها یا هزاران پاد به‌طور مداوم در حال چرخش هستند، ابزارهایی که نتوانند با telemetry دنیای کانتینرها همگام شوند، به‌سرعت در میان متخصصان SRE و DevOps کنار گذاشته می‌شوند. به همین دلیل است که در چند سال اخیر، مانیتورینگ Kubernetes به یکی از پیشران‌های اصلی تحول بازار ابزارهای مانیتورینگ تبدیل شده است و ابزارهایی مانند پلتفرم مانیتورینگ معین به‌خوبی این موج را درک کرده‌اند.

تا زمانی که از معماری «سرورمحور» به معماری «سرویس‌محور و Telemetryمحور» مهاجرت نکنند، شکاف میان دنیای آن‌ها و دنیای واقعی زیرساخت‌های مدرن هر روز بزرگ‌تر خواهد شد.