پیش از ورود به بحث لازم است تأکید کنیم که هدف این مجموعه مقالات زیر سؤال بردن ارزش یا توانمندی ابزارهای مطرح مانیتورینگ زیرساخت فناوری اطلاعات نیست. بسیاری از این راهکارها سالهاست در سازمانهای مختلف مورد استفاده قرار گرفتهاند و نقش مهمی در پایش و مدیریت محیطهای IT ایفا میکنند. آنچه در این مجموعه مقالات بررسی میشود، بیشتر نگاهی تحلیلی به برخی محدودیتها و چالشهایی است که میتوانند برای سازمانها مسئلهساز شوند. ازاینرو، اگر قصد خرید نرمافزار AppDynamics را دارید، پیشنهاد میکنیم پیش از تصمیمگیری، مجموعه مقالات کالبدشکافی AppDynamics را نیز مطالعه کنید.
در یک سازمان بزرگ، معمولاً یک Application روی یک فناوری واحد اجرا نمیشود. ممکن است یک سامانه از چند Application Server، چند Database، سرویسهای مختلف Middleware، ماشینهای مجازی، Serverهای فیزیکی، تجهیزات Network، Storage و سرویسهای Cloud تشکیل شده باشد و در هر لایه نیز از محصولات و فناوریهای متفاوتی استفاده شود. حتی در یک محیط مشابه، ممکن است بخشی از Applicationها روی Java و بخشی دیگر روی .NET اجرا شوند، Databaseها از محصولات مختلف استفاده کنند و زیرساخت نیز ترکیبی از Virtualization، Bare Metal و Cloud باشد.
در چنین محیطی، مانیتورینگ فقط به این معنا نیست که یک Agent روی Application نصب شود و چند Metric جمعآوری شود. مسئله اصلی این است که چگونه میتوان Visibility را از یک فناوری به فناوری دیگر گسترش داد و اطلاعات بهدستآمده از این منابع مختلف را در یک مدل قابل تحلیل کنار یکدیگر قرار داد.
AppDynamics برای پوشش طیف متنوعی از Applicationها و فناوریهای زیرساختی، قابلیتهای مختلفی در اختیار سازمان قرار میدهد و از Agentها، Integrationها و Extensionها برای گسترش دامنه مانیتورینگ استفاده میکند. بنابراین مسئله، نبود قابلیت برای مانیتور کردن فناوریهای مختلف نیست؛ بلکه این است که هرچه محیط IT ناهمگونتر میشود، معماری Integration و نحوه مدیریت این نقاط اتصال اهمیت بیشتری پیدا میکند.

Multi-Technology Monitoring به توانایی یک پلتفرم مانیتورینگ برای مشاهده و تحلیل طیف متنوعی از فناوریها، محصولات و لایههای IT اشاره دارد؛ از Application و Database گرفته تا Operating System، Virtualization، Network، Storage، Middleware و سرویسهای Cloud.
در یک محیط ساده، ممکن است تعداد فناوریهای مورد نیاز محدود باشد و یک Agent یا Integration مشخص بخش بزرگی از نیاز مانیتورینگ را پوشش دهد. اما در سازمانهای بزرگ، وضعیت کاملاً متفاوت است. فناوریها معمولاً در طول زمان افزایش پیدا میکنند، محصولات مختلف از Vendorهای گوناگون وارد زیرساخت میشوند و در کنار فناوریهای جدید، سیستمهای Legacy نیز برای سالها باقی میمانند.
در نتیجه، پلتفرم مانیتورینگ باید بتواند با یک محیط واقعاً Heterogeneous کار کند؛ محیطی که در آن نمیتوان فرض کرد همه اجزا از یک Protocol، یک Vendor، یک Operating System یا یک Application Architecture استفاده میکنند.
این موضوع یکی از نقاطی است که تفاوت میان یک پلتفرم مانیتورینگ و یک مجموعه ابزارهای تخصصی آشکار میشود. هرچه تعداد فناوریها بیشتر شود، مسئله فقط جمعآوری Metric نیست؛ نحوه اتصال، نگهداری، Normalization و قرار دادن اطلاعات در Context مشترک اهمیت پیدا میکند.
AppDynamics برای مانیتورینگ فناوریهای مختلف از یک مدل یکسان برای همه Componentها استفاده نمیکند. Application Agentها برای فناوریهای Application مورد استفاده قرار میگیرند و برای دسترسی به برخی فناوریها و سیستمهای دیگر نیز از Integrationها، Extensionها و مکانیزمهای مختلف استفاده میشود.
این مدل کاملاً منطقی است؛ زیرا هر فناوری روش دسترسی، Metricها، APIها و ساختار داده مخصوص خود را دارد. برای مثال، نحوه دریافت اطلاعات از یک Application با نحوه دریافت Metricهای یک Database، Network Platform یا یک سیستم زیرساختی یکسان نیست.
بنابراین در AppDynamics نیز برای گسترش Visibility به لایهها و فناوریهای مختلف، بسته به نوع فناوری ممکن است به Agent، Extension یا Integration مناسب نیاز باشد.
این موضوع به خودی خود یک ضعف محسوب نمیشود. تقریباً هر پلتفرم Enterprise Monitoring برای دسترسی به فناوریهای مختلف به مکانیزمهای Integration نیاز دارد. چالش زمانی ایجاد میشود که تعداد فناوریها، Integrationها و Componentهای مورد نیاز به اندازهای افزایش پیدا کند که مدیریت این اکوسیستم Integration به یک موضوع عملیاتی مستقل تبدیل شود.
در محیطهای Application، Agent معمولاً بهعنوان نقطهای برای Instrumentation و جمعآوری اطلاعات Performance عمل میکند. Agent میتواند اطلاعات مربوط به Application، Transaction، Call و Componentهای درگیر را جمعآوری کند و Context مورد نیاز برای تحلیل Application Performance را فراهم کند.
اما وقتی دامنه مانیتورینگ از Application فراتر میرود، همه فناوریها الزاماً از یک مدل Agent-based پیروی نمیکنند. بعضی فناوریها از طریق API، برخی از طریق SNMP یا Protocolهای استاندارد، بعضی از طریق Extension و برخی نیز با استفاده از Integration اختصاصی قابل مشاهده هستند.
در نتیجه، هرچه محیط ناهمگونتر شود، معماری مانیتورینگ نیز به مجموعهای از روشهای مختلف Collection و Integration نیاز پیدا میکند.
از دید فنی، این انعطافپذیری یک مزیت است؛ زیرا به پلتفرم اجازه میدهد فناوریهای بیشتری را پوشش دهد. اما از دید عملیاتی، همین انعطافپذیری میتواند یک چالش ایجاد کند: تیم IT باید بداند برای هر فناوری از چه روش Collection استفاده شده، چه Componentی مسئول جمعآوری اطلاعات است، چه Versionی از آن مورد استفاده قرار گرفته و در صورت تغییر فناوری یا Upgrade محصول، چه بخشهایی باید بهروزرسانی شوند.
اگر در یک سازمان فقط تعداد Integrationها را بشماریم، بخش مهمی از مسئله را از دست دادهایم. مسئله اصلی زمانی ایجاد میشود که اطلاعات جمعآوریشده از فناوریهای مختلف باید در کنار یکدیگر قرار بگیرند و یک تصویر مشترک از وضعیت IT ایجاد کنند.
فرض کنیم سازمانی از چند نوع Database، چند Virtualization Platform، چند Operating System و چند Application Technology استفاده میکند. هر Integration میتواند اطلاعات ارزشمندی از فناوری مربوط به خود ارائه دهد، اما تیم IT در نهایت به یک سؤال بزرگتر نیاز دارد:
برای مثال، اگر یک Database Metric نشان دهد که Latency افزایش پیدا کرده، آیا سیستم مانیتورینگ میتواند این وضعیت را در Context سرویسهایی که به Database وابستهاند قرار دهد؟ اگر یک Virtual Machine دچار Resource Contention شود، آیا میتوان Impact آن را روی Application و IT Service مشاهده کرد؟ اگر یک Network Component دچار اختلال شود، آیا ارتباط آن با Applicationهایی که از مسیر آن استفاده میکنند قابل مشاهده است؟
در اینجا تفاوت میان Technology Coverage و Unified Context مشخص میشود.
داشتن Integration برای یک فناوری به این معنا نیست که اطلاعات آن فناوری الزاماً در یک مدل یکپارچه از کل IT Environment قرار گرفته است.
در محیطهای Enterprise معمولاً مسئله فقط تعداد فناوریها نیست؛ بلکه تفاوت معماری آنها نیز اهمیت دارد. ممکن است یک سازمان همزمان از فناوریهای On-Premises، Virtualized، Cloud و Containerized استفاده کند و در کنار آن Applicationهای Legacy نیز داشته باشد.
در چنین محیطی، یک پلتفرم مانیتورینگ باید با طیف گستردهای از روشهای Deployment و Data Collection کنار بیاید. برخی Componentها Agent-based هستند، برخی Agentless، برخی API-based و برخی به Integration اختصاصی نیاز دارند.
این ناهمگونی باعث میشود یک مدل مانیتورینگ در مقیاس کوچک، با همان مدل در مقیاس Enterprise تفاوت زیادی داشته باشد. در محیط کوچک، اضافه کردن یک Integration جدید ممکن است یک فعالیت ساده باشد؛ اما در سازمانی با صدها یا هزاران Component، مسئله Deployment، Configuration، Version Compatibility، Security، Credential Management و Lifecycle آن Integrationها نیز مطرح میشود.
به همین دلیل، Multi-Technology Monitoring در مقیاس سازمانی فقط یک مسئله Technical Coverage نیست؛ یک مسئله Operational Architecture نیز هست.
اینجا باید بین دو موضوع تفاوت قائل شد.
از یک طرف، استفاده از Agent و Integration یک روش استاندارد برای دسترسی عمیق به فناوریهای مختلف است و حتی میتواند باعث شود اطلاعات تخصصیتر و دقیقتری از یک Component جمعآوری شود. بنابراین نمیتوان صرفاً به دلیل استفاده از Agent یا Integration، یک پلتفرم را ضعیف دانست.
از طرف دیگر، هرچه تعداد فناوریهای تحت مانیتورینگ بیشتر شود، تعداد نقاط Integration نیز میتواند افزایش پیدا کند و این موضوع هزینه عملیاتی سیستم مانیتورینگ را بالا ببرد. این هزینه لزوماً مالی نیست؛ ممکن است به شکل زمان Deployment، نگهداری Configuration، بررسی Compatibility، Troubleshooting و مدیریت تغییرات خود را نشان دهد.
در نتیجه، سؤال درست این نیست که «آیا AppDynamics Agent یا Integration دارد؟»؛ بلکه باید پرسید:
در محیط واقعی سازمان، برای پوشش فناوریهای مورد نیاز چه تعداد Agent، Extension و Integration لازم است و مدیریت Lifecycle آنها تا چه اندازه پیچیدگی ایجاد میکند؟
این سؤال، ارزیابی را از سطح Feature به سطح Operational Scalability منتقل میکند.
یکی از چالشهای اصلی در محیطهای Multi-Technology این است که هر فناوری با زبان خودش اطلاعات تولید میکند. یک Database از Connection، Query و Latency صحبت میکند، یک Server از CPU، Memory و Disk، یک Network Device از Interface، Packet و Error و یک Application از Transaction، Service و Response Time .
اگر این اطلاعات فقط در Integrationهای جداگانه جمعآوری شوند، تیم IT در نهایت با مجموعهای از Metricها مواجه خواهد بود؛ اما برای Troubleshooting واقعی، Metric بهتنهایی کافی نیست.
ارزش اصلی زمانی ایجاد میشود که این اطلاعات در Context قرار بگیرند و ارتباط میان آنها مشخص باشد. یعنی تیم IT بتواند بفهمد افزایش Latency در یک Database چه سرویسهایی را تحت تأثیر قرار داده، افت Performance یک Server به کدام Applicationها مرتبط است و یک Event در Network چه اثری بر Serviceهای بالادستی دارد.
بنابراین یک پلتفرم Multi-Technology Monitoring موفق فقط نباید بگوید «این فناوری را هم پشتیبانی میکنم»؛ بلکه باید بتواند اطلاعات فناوریهای مختلف را در یک مدل قابل استفاده برای Correlation، Dependency Analysis و Root Cause Analysis قرار دهد.
در یک محیط Enterprise، فناوریها ثابت نمیمانند. یک سازمان ممکن است یک Database جدید اضافه کند، نسخه یک Application را تغییر دهد، یک Platform را Upgrade کند، بخشی از Infrastructure را به Cloud منتقل کند یا یک Vendor جدید وارد معماری خود کند.
هر تغییر میتواند مانیتورینگ را نیز تحت تأثیر قرار دهد. ممکن است Agent جدید نیاز باشد، Extension باید Upgrade شود، یک Integration با Version جدید سازگار نباشد یا Configuration مربوط به Credential و Endpoint تغییر کند.
در چنین شرایطی، پلتفرم مانیتورینگ بخشی از چرخه تغییرات IT میشود و هرچه تعداد Technology و Integration بیشتر باشد، مدیریت این چرخه نیز اهمیت بیشتری پیدا میکند.
اینجاست که Technology Coverage و Operational Manageability باید در کنار یکدیگر بررسی شوند. یک محصول ممکن است از فناوریهای بسیار زیادی پشتیبانی کند، اما سؤال مهم این است که این پوشش در محیط واقعی سازمان با چه میزان پیچیدگی عملیاتی به دست میآید.
این موضوع خصوصاً برای سازمانهایی اهمیت دارد که تیم مانیتورینگ یا NOC باید یک پلتفرم مشترک را برای تعداد زیادی Technology و Vendor مدیریت کند.
Multi-Technology Monitoring و Unified Monitoring دو مفهوم نزدیک اما یکسان نیستند.
Multi-Technology Monitoring در وهله اول به این سؤال پاسخ میدهد که:
اما Unified Monitoring سؤال گستردهتری مطرح میکند:
ممکن است یک پلتفرم از صدها Technology پشتیبانی کند، اما هر Technology در یک Integration مستقل قرار داشته باشد و اطلاعات آن بدون Context مشترک در اختیار تیم قرار گیرد. در مقابل، یک Unified Monitoring Platform تلاش میکند اطلاعات مختلف را در یک مدل واحد از Infrastructure، Application و Service قرار دهد.
بنابراین Technology Coverage یک شرط لازم برای مانیتورینگ در محیطهای بزرگ است، اما الزاماً شرط کافی برای ایجاد Visibility یکپارچه نیست.
AppDynamics برای پوشش فناوریهای مختلف، مجموعهای از Agentها، Integrationها و Extensionها را در اختیار سازمان قرار میدهد و نمیتوان ادعا کرد که این پلتفرم صرفاً برای یک فناوری یا یک نوع Application طراحی شده است. اتفاقاً انعطافپذیری در Integration یکی از عواملی است که امکان گسترش Visibility به محیطهای مختلف را فراهم میکند.
اما در محیطهای Enterprise، مسئله از جایی جدیتر میشود که تعداد فناوریها، Vendorها و Integrationها افزایش پیدا میکند. در این مرحله، علاوه بر Technology Coverage باید به نحوه Deployment، مدیریت Configuration، Version Compatibility، Security، Lifecycle و ارتباط اطلاعات جمعآوریشده با سایر لایههای IT نیز توجه کرد.
در نتیجه، چالش اصلی Multi-Technology Monitoring در AppDynamics را نباید «عدم پشتیبانی از فناوریهای مختلف» دانست. مسئله دقیقتر این است که گسترش مانیتورینگ به فناوریهای ناهمگون میتواند نیازمند مجموعهای از Agentها، Integrationها و Extensionها باشد و در مقیاس سازمانی، مدیریت این اکوسیستم به بخشی از پیچیدگی عملیاتی مانیتورینگ تبدیل شود.
در یک Unified Monitoring Platform مانند پلتفرم معین، هدف صرفاً افزایش تعداد Technologyهای قابل مانیتور نیست؛ بلکه ایجاد یک مدل مشترک از Computing Infrastructure، Application Infrastructure و Business Applications & Services است تا اطلاعات فناوریهای مختلف در کنار یکدیگر و در قالب Dependency و Context مشترک قابل مشاهده باشند.
بنابراین در ارزیابی یک پلتفرم مانیتورینگ Enterprise، صرفاً نباید پرسید «چند فناوری را پشتیبانی میکند؟»؛ سؤال مهمتر این است که این فناوریها چگونه به سیستم مانیتورینگ متصل میشوند، چگونه مدیریت میشوند و مهمتر از همه، اطلاعات آنها چگونه در یک مدل یکپارچه برای تحلیل وضعیت، Dependency و Impact قرار میگیرد.