کالبدشکافی AppDynamics (بخش اول): چالش Application-Centric Monitoring؛ وقتی Application نقطه شروع مانیتورینگ است

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

در یک سازمان بزرگ، تیم IT متوجه می‌شود که یکی از سامانه‌های حیاتی سازمان در ساعات پرترافیک با افزایش زمان پاسخ مواجه شده است. تیم Application Monitoring بررسی را از Business Transactionها و Serviceهای درگیر شروع می‌کند، مسیر اجرای درخواست‌ها را دنبال می‌کند و در نهایت به یک Database، یک Node یا حتی یک مؤلفه زیرساختی می‌رسد که می‌تواند در ایجاد مشکل نقش داشته باشد. این دقیقاً یکی از سناریوهایی است که ابزارهایی مانند AppDynamics برای آن طراحی شده‌اند: پیدا کردن ارتباط میان عملکرد Application، Transactionها، Serviceها و زیرساختی که  Application روی آن اجرا می‌شود.

اما در همین محیط یک سؤال دیگر نیز وجود دارد: اگر هنوز هیچ Applicationی دچار اختلال نشده باشد، تیم IT از کجا باید وضعیت زیرساخت را بررسی کند؟ اگر یکی ازServerها، Storageها، تجهیزات شبکه یا سایر اجزای زیرساخت در حال نزدیک شدن به یک وضعیت بحرانی باشد، آیا نقطه شروع تحلیل باید همچنان Application باشد یا خود  Infrastructure؟

این پرسش، به یکی از تفاوت‌های مهم میان Application-Centric Monitoring و Infrastructure-Centric یا  Unified Monitoring   برمی‌گردد. مسئله این نیست که AppDynamics نمی‌تواند Infrastructure را مانیتور کند؛ این محصول قابلیت‌های مشخصی برای Infrastructure Visibility دارد. مسئله اصلی، نقطه شروع مشاهده و مدل ارتباط میان اجزای  IT است؛ موضوعی که در محیط‌های سازمانی بزرگ می‌تواند تفاوت قابل‌توجهی در نحوه کار تیم‌های IT و NOC ایجاد کند.

Application-Centric Monitoring چیست و چرا Application در مرکز مدل مانیتورینگ قرار می‌گیرد؟

AppDynamics اساساً با تمرکز بر Application Performance طراحی شده است. در این رویکرد، Application، Business Transaction، Service، Node و اجزای وابسته به آن‌ها در مرکز تحلیل قرار می‌گیرند و هدف اصلی این است که مشخص شود یک Application یا سرویس از نظر Performance و Availability چه وضعیتی دارد و در صورت بروز مشکل، چه عواملی در ایجاد آن نقش داشته‌اند.

برای مثال، زمانی که زمان پاسخ یک Business Transaction افزایش پیدا می‌کند، تیم IT می‌تواند مسیر اجرای آن را دنبال کند، Serviceهای درگیر را بررسی کند و در ادامه به مؤلفه‌هایی مانند Database، Server یا سایر اجزای زیرساخت برسد. این مدل برای پاسخ به سؤالاتی مانند «چرا این Application کند شده است؟» یا «کدام Component باعث افت  Performance   این سرویس شده است؟» بسیار مناسب است.

بنابراین، Application-Centric بودن AppDynamics را نباید یک ضعف ذاتی یا به معنی ناتوانی در مانیتورینگ زیرساخت دانست. اتفاقاً این رویکرد یکی از نقاط قوت محصول برای سازمان‌هایی است که مسئله اصلی آن‌ها  Application Performance و Business Transaction Performance است. چالش از جایی آغاز می‌شود که مسئله سازمان از Application   فراتر می‌رود و تیم IT به دنبال یک دید مستقل و سراسری از وضعیت کل Infrastructure و IT Services است.

Infrastructure Visibility در AppDynamics؛ آیا Infrastructure خارج از Application قابل مشاهده است؟

یکی از برداشت‌های نادرست درباره Application-Centric Monitoring این است که چون Application در مرکز مدل قرار دارد، بنابراین ابزار نمی‌تواند Infrastructure را به‌صورت مستقل مشاهده کند. در مورد AppDynamics چنین برداشتی دقیق نیست. این پلتفرم قابلیت Infrastructure Visibility را در اختیار تیم IT قرار می‌دهد و می‌تواند اطلاعات مربوط به زیرساخت و Network را برای تحلیل عملکرد Application مورد استفاده قرار دهد.

تفاوت اصلی در جایگاه این اطلاعات در مدل مانیتورینگ است. در یک سناریوی Application-Centric، Infrastructure معمولاً بخشی از زنجیره‌ای است که برای توضیح وضعیت Application مورد بررسی قرار می‌گیرد. به بیان ساده، سؤال می‌تواند از Application شروع شود و سپس به Infrastructure برسد: Application چه مشکلی دارد، کدام Service درگیر است، این Service روی کدام Node اجرا می‌شود و وضعیت زیرساخت آن Node چگونه است.

این در حالی است که در یک مدل Infrastructure-Centric، سؤال می‌تواند از جهت دیگری آغاز شود: وضعیت کل Serverها، Network، Storage، Virtualization، Database و سایر اجزای زیرساخت چگونه است؟ کدام Component در حال نزدیک شدن به وضعیت بحرانی است؟ آیا یک مشکل زیرساختی می‌تواند چند Application مختلف را تحت تأثیر قرار دهد؟ و اگر چنین اتفاقی رخ دهد، دامنه Impact آن روی سرویس‌های سازمان چیست؟

بنابراین تفاوت اصلی را باید در Monitoring Model جست‌وجو کرد، نه صرفاً در فهرست قابلیت‌های محصول.

چرا Infrastructure Monitoring نباید فقط از زاویه Application بررسی شود؟

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

فرض کنیم یک Storage در حال افزایش Latency است، اما هنوز هیچ Applicationی از نظر SLA دچار مشکل نشده است. یا ظرفیت یک فایل‌سیستم به نقطه بحرانی نزدیک شده، ولی هنوز Transactionی Fail نشده است. یا یک Interface شبکه با افزایش خطا و Packet Drop مواجه شده، اما اثر آن هنوز در Performance Applicationها قابل مشاهده نیست.

در این شرایط، تیم Infrastructure یا NOC الزاماً نمی‌پرسد «کدام Application مشکل دارد؟». سؤال آن‌ها می‌تواند این باشد که  کدام بخش از زیرساخت در حال ایجاد ریسک است و این وضعیت در صورت ادامه چه سرویس‌هایی را تحت تأثیر قرار خواهد داد؟

اینجاست که تفاوت میان Application-Centric Monitoring و Infrastructure-Centric Monitoring اهمیت پیدا می‌کند. در مدل اول، Application می‌تواند نقطه شروع تحلیل باشد و Infrastructure به توضیح وضعیت آن کمک کند؛ در مدل دوم، Infrastructure می‌تواند خودش نقطه شروع مشاهده باشد و ارتباط آن با Applicationها و سرویس‌ها در مرحله بعد بررسی شود.

Application-Centric Monitoring در برابر Infrastructure-Centric Monitoring؛ تفاوت دو نقطه شروع در مانیتورینگ

 تفاوت این دو رویکرد را می‌توان در مسیر حرکت اطلاعات و تحلیل مشاهده کرد. در Application-Centric Monitoring، مسیر معمول تحلیل می‌تواند چیزی شبیه به این باشد:

Business Transaction → Application → Service → Node → Infrastructure

یعنی تیم IT ابتدا با یک مسئله در Application یا Service مواجه می‌شود و سپس برای پیدا کردن علت یا عوامل مؤثر، به لایه‌های پایین‌تر حرکت می‌کند.

در مقابل، در Infrastructure-Centric یا Unified Monitoring می‌توان مسیر معکوس را نیز به همان اندازه مهم در نظر گرفت:

Infrastructure Event → Component → Dependency → Service → Application Impact

در این مدل، یک رویداد در Infrastructure می‌تواند نقطه شروع تحلیل باشد و سیستم مانیتورینگ مشخص کند این Component با چه اجزایی ارتباط دارد، چه سرویس‌هایی به آن وابسته هستند و در صورت ادامه یا تشدید مشکل، چه Applicationهایی تحت تأثیر قرار خواهند گرفت.

البته این دو مسیر الزاماً رقیب یکدیگر نیستند. یک پلتفرم قدرتمند می‌تواند هر دو مسیر را پشتیبانی کند. نکته اصلی این است که آیا مدل مانیتورینگ سازمان اجازه می‌دهد تحلیل از هر دو سمت انجام شود یا خیر.

این موضوع به‌خصوص در محیط‌هایی اهمیت دارد که یک زیرساخت مشترک، میزبان تعداد زیادی Application و IT Service است. در چنین محیطی، وابستگی Infrastructure به Application یک رابطه یک‌به‌یک نیست و ممکن است یک Component زیرساختی، وابستگی‌های متعددی در لایه سرویس و Application داشته باشد.

تأثیر Application-Centric Monitoring بر دید تیم NOC و Infrastructure

برای تیم Application، معمولاً مهم‌ترین سؤال این است که چرا یک Application یا Business Transaction دچار افت   Performance شده است. در مقابل، تیم NOC یا Infrastructure ممکن است سؤالات متفاوتی داشته باشد: وضعیت کلی  Infrastructure چگونه است؟ چه Componentهایی در وضعیت غیرعادی قرار گرفته‌اند؟ کدام رویدادها ممکن است به Incident تبدیل شوند؟ چه تجهیز یا سرویسی در چند سامانه مشترک است و در صورت اختلال، چه دامنه‌ای از سرویس‌های سازمان را تحت تأثیر قرار می‌دهد؟

AppDynamics برای سناریوهای Application Performance بسیار قدرتمند است و قابلیت‌هایی مانند  Infrastructure Visibility کمک می‌کنند تیم Application درک بهتری از عوامل زیرساختی مؤثر بر Performance داشته باشد. اما زمانی که نیاز اصلی سازمان، مدیریت متمرکز و سراسری وضعیت کل IT Infrastructure باشد، دیگر صرفاً داشتن Infrastructure Metrics کافی نیست؛ نحوه سازمان‌دهی این اطلاعات، ارتباط آن‌ها با سایر اجزا و امکان مشاهده Impact نیز اهمیت پیدا می‌کند.

به همین دلیل، تفاوت اصلی برای یک NOC ممکن است نه در این باشد که آیا ابزار Metric مربوط به CPU یا Memory را نمایش می‌دهد، بلکه در این باشد که آیا می‌تواند از یک وضعیت زیرساختی به Dependencyهای آن و سپس به Service و Application Impact برسد و برعکس، از یک Application مشکل‌دار به تمام اجزای زیرساختی وابسته حرکت کند.

Dependency Mapping در AppDynamics؛ مسئله فقط نمایش ارتباط Application و Infrastructure نیست

Dependency Mapping یکی از بخش‌های مهم هر پلتفرم مدرن مانیتورینگ است، اما صرف داشتن یک نقشه وابستگی به معنی یکسان بودن مدل Dependency در همه محصولات نیست.

در یک رویکرد Application-Centric، Dependencyها عمدتاً حول Application، Service، Node، Database و سایر مؤلفه‌های مرتبط با اجرای Application معنا پیدا می‌کنند. این مدل برای تحلیل Application Performance بسیار ارزشمند است، زیرا به تیم IT کمک می‌کند مسیر اجرای یک درخواست و ارتباط Componentهای درگیر را بهتر درک کند.

اما در یک Unified Monitoring Platform، دامنه Dependency می‌تواند گسترده‌تر تعریف شود و شامل روابط میان Network، Server، Virtualization، Storage، Database، Middleware، Application و IT Service باشد. در چنین مدلی، هدف صرفاً پیدا کردن علت کندی یک Application نیست؛ بلکه ساختن یک مدل یکپارچه از روابط میان اجزای IT است.

بنابراین سؤال مهم‌تر این نیست که «آیا AppDynamics Dependency Mapping دارد؟»؛ بلکه باید پرسید:

Dependency Model محصول تا چه سطحی از Infrastructure و IT Services را پوشش می‌دهد و آیا این مدل می‌تواند برای تحلیل دوطرفه Impact و Root Cause در کل محیط IT مورد استفاده قرار گیرد؟

این تفکیک، مقایسه را از یک مقایسه ساده قابلیت‌ها خارج کرده و به سطح معماری Monitoring Model می‌رساند.

محدودیت‌های Application-Centric Monitoring در محیط‌های سازمانی بزرگ

Application-Centric Monitoring در جایگاه خود یک رویکرد قدرتمند است، اما در سازمان‌های بزرگ می‌تواند با چند چالش مواجه شود. اولین چالش زمانی ایجاد می‌شود که تعداد Applicationها، Serviceها و Dependencyها به‌شدت افزایش پیدا می‌کند و در کنار آن، Infrastructure سازمان نیز شامل تعداد زیادی Server، Network Device، Storage، Virtualization Platform، Database و Middleware است. در چنین محیطی، داشتن Visibility روی Applicationها به‌تنهایی برای ایجاد یک تصویر جامع از وضعیت IT کافی نیست.

چالش دوم به Shared Infrastructure مربوط می‌شود. یک Component زیرساختی ممکن است به چند Application و Service مختلف سرویس دهد. بنابراین لازم است تیم IT بتواند نه‌تنها وضعیت Application را مشاهده کند، بلکه Impact یک Component زیرساختی را روی تمام Dependencyهای آن نیز درک کند.

چالش سوم، تفاوت نیاز تیم‌های مختلف IT است. تیم Application، تیم Infrastructure، تیم Network و NOC ممکن است از یک محیط واحد سؤالات کاملاً متفاوتی داشته باشند. اگر مدل مانیتورینگ بیش از حد حول Application سازمان‌دهی شود، ممکن است برای تیم Application بسیار مناسب باشد، اما تیم Infrastructure برای مشاهده مستقل و مدیریت کل محیط نیاز به Context و Viewهای متفاوتی داشته باشد.

در نتیجه، مسئله اصلی کمبود Metric یا Dashboard نیست؛ مسئله این است که آیا اطلاعات مختلف IT در یک مدل مشترک و قابل تحلیل کنار یکدیگر قرار گرفته‌اند یا خیر.

Full-Stack Monitoring در AppDynamics؛ آیا Full-Stack بودن به معنی Unified Monitoring است؟

 AppDynamics را نمی‌توان صرفاً یک Application Monitoring Tool ساده در نظر گرفت. این پلتفرم طیف گسترده‌ای از قابلیت‌های Application Performance، Infrastructure Visibility و Integrationها را ارائه می‌کند و از منظر مفهومی می‌تواند در یک معماری Full-Stack Monitoring مورد استفاده قرار گیرد.

اما Full-Stack Monitoring لزوماً به معنی Unified Monitoring نیست.

Full-Stack به این معناست که لایه‌های مختلف Stack قابل مشاهده و تحلیل باشند؛ در حالی که  Unified Monitoring علاوه بر پوشش لایه‌های مختلف، بر ایجاد یک مدل مشترک از Infrastructure، Applicationو IT Services و ارتباط میان آن‌ها تأکید دارد.

به همین دلیل، هنگام مقایسه این دو رویکرد نباید پرسید «آیا AppDynamics Full-Stack است یا خیر؟»؛ سؤال دقیق‌تر این است که:

Full-Stack در AppDynamics با چه نقطه شروعی، چه مدل Dependency و در چه دامنه‌ای از IT Infrastructure پیاده‌سازی می‌شود و این مدل تا چه حد با نیاز سازمان برای Unified IT Monitoring هم‌راستا است؟

این تمایز به‌خصوص در سازمان‌هایی اهمیت دارد که Monitoring فقط برای تیم Application نیست و قرار است یک پلتفرم مشترک برای تیم‌های NOC، Network، Infrastructure، Database و Application فراهم شود.

Application-Centric Monitoring برای چه سازمان‌هایی مناسب است؟

Application-Centric بودن لزوماً یک ایراد نیست و حتی در بسیاری از سناریوها یک مزیت جدی محسوب می‌شود. سازمانی که مسئله اصلی آن Performance Application، Business Transaction، Distributed Application، Microservices، Database Calls  یا تجربه کاربر است، می‌تواند از این رویکرد ارزش زیادی دریافت کند؛ زیرا ابزار از همان نقطه‌ای شروع می‌کند که مسئله اصلی سازمان در آن قرار دارد.

چالش زمانی مطرح می‌شود که نیاز سازمان صرفاً به Performance Application محدود نباشد و تیم IT بخواهد کل محیط را به‌عنوان یک سیستم به‌هم‌پیوسته مشاهده کند؛ یعنی Infrastructure، Application و IT Services همگی در یک مدل مشترک قرار بگیرند و تحلیل بتواند هم از Application به Infrastructure و هم از Infrastructure به Application حرکت کند.

بنابراین، انتخاب میان Application-Centric Monitoring و Unified Monitoring نباید بر اساس این تصور باشد که یکی «خوب» و دیگری «ضعیف» است. انتخاب صحیح به این بستگی دارد که سازمان در وهله اول می‌خواهد چه مسئله‌ای را حل کند و مرکز ثقل  Monitoring Model آن کجاست.

جمع‌بندی؛ آیا Application-Centric Monitoring برای همه سازمان‌ها کافی است؟

AppDynamics را نمی‌توان به‌سادگی به‌عنوان ابزاری معرفی کرد که فقط Application را می‌بیند و Infrastructure را نادیده می‌گیرد. این محصول قابلیت‌های گسترده‌ای برای Application Performance Monitoring و Infrastructure Visibility دارد و یکی از نقاط قوت آن، توانایی ایجاد ارتباط میان Performance Application و عوامل مؤثر در زیرساخت است.

اما در سازمان‌هایی که نیاز آن‌ها از Application Performance فراتر می‌رود، تفاوت در Monitoring Model اهمیت بیشتری پیدا می‌کند. Application-Centric Monitoring معمولاً Application را نقطه شروع مشاهده قرار می‌دهد و Infrastructure را در ارتباط با عملکرد Application تحلیل می‌کند؛ در حالی که یک Unified Monitoring Platform می‌تواند Infrastructure، Application و IT Services را به‌عنوان اجزای یک مدل یکپارچه در نظر بگیرد و اجازه دهد تحلیل از هر یک از این لایه‌ها آغاز شود.

در چنین شرایطی، مسئله دیگر این نیست که «آیا ابزار می‌تواند Server یا Network را مانیتور کند؟» بلکه سؤال این است که آیا می‌توان کل محیط IT را در یک مدل مشترک مشاهده، ارتباطات میان اجزا را تحلیل و Impact یک رویداد را از Infrastructure   تا Service و Application دنبال کرد؟

در پلتفرم مانیتورینگ معین، رویکرد از ابتدا صرفاً بر Application Monitoring متمرکز نشده است. مدل مانیتورینگ آن در سه سطح  Computing Infrastructure، Application Infrastructure و Business Applications & Services تعریف شده و هدف، ایجاد یک دید یکپارچه از زیرساخت و سرویس‌های IT است. در این مدل، Application یکی از لایه‌های Monitoring   است، نه تنها نقطه شروع آن؛ به همین دلیل ارتباط میان اجزای زیرساخت، Application و  Serviceمی‌تواند در یک مدل واحد مورد بررسی قرار گیرد.

در نتیجه، تفاوت اصلی را نباید در یک Feature یا Metric خاص جست‌وجو کرد.AppDynamics  در  Application-Centric Monitoring  و تحلیل Performance Application نقطه قوت مشخصی دارد؛ در مقابل، رویکرد Unified Monitoring بر این تمرکز دارد که کل IT Environment، از Infrastructure تا Application و  Service، در یک مدل یکپارچه قابل مشاهده و تحلیل باشد. این همان نقطه‌ای است که هنگام انتخاب یک پلتفرم مانیتورینگ سازمانی، باید فراتر از فهرست قابلیت‌ها به معماری و مدل مشاهده محصول توجه کرد.