کالبدشکافی Prometheus و Grafana (بخش دوم): چالش Multi-Vendor؛ وقتی پایش تجهیزات ناهمگون به Exporter و Mapping وابسته می‌شود

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

در محیط‌های سازمانی، زیرساخت IT به‌ندرت از تجهیزات و محصولات یک Vendor واحد تشکیل شده است. یک سازمان بزرگ ممکن است هم‌زمان از تجهیزات شبکه Cisco، Huawei و Juniper، تجهیزات امنیتی Fortinet، تجهیزات ذخیره‌سازی از چند سازنده و سرورهای مختلف استفاده کند.

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

Prometheus در محیط‌های Cloud-Native و سرویس‌هایی که Metrics را مستقیماً در قالب استاندارد Prometheus ارائه می‌کنند، عملکرد بسیار قدرتمندی دارد. اما زمانی که دامنه مانیتورینگ از سرویس‌های نرم‌افزاری فراتر رفته و به تجهیزات سنتی زیرساخت مانند Switch، Router، Firewall و Storage می‌رسد، معمولاً به Exporterها و لایه‌های واسط نیاز پیدا می‌شود.

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

مسئله اصلی: تجهیزات مختلف، زبان داده متفاوت

تجهیزات مختلف برای ارائه اطلاعات مدیریتی از روش‌ها و ساختارهای متفاوتی استفاده می‌کنند.

برای مثال، تجهیزات شبکه ممکن است اطلاعات خود را از طریق SNMP ارائه کنند، در حالی که برخی تجهیزات و سامانه‌های جدیدتر ممکن است APIهای REST، مدل‌های NETCONF/YANG یا رابط‌های اختصاصی در اختیار قرار دهند.

حتی در صورت استفاده از یک پروتکل مشترک مانند SNMP نیز تفاوت میان Vendorها و مدل‌های مختلف کاملاً از بین نمی‌رود.

هر تجهیز می‌تواند:

• MIBهای متفاوت داشته باشد.
• OIDهای اختصاصی ارائه کند.
• Metricهای متفاوتی در اختیار قرار دهد.
• ساختار Tableهای متفاوتی داشته باشد.
• نام‌گذاری و نحوه نمایش برخی پارامترها متفاوت باشد.

بنابراین سیستم مانیتورینگ باید بتواند این داده‌های ناهمگون را به یک مدل قابل‌تحلیل تبدیل کند.

در معماری Prometheus، این وظیفه معمولاً از طریق Exporterها یا Collectorهای مناسب انجام می‌شود.

SNMP Exporter؛ پل میان تجهیزات شبکه وPrometheus

یکی از نمونه‌های شناخته‌شده این معماری، استفاده از SNMP Exporter برای پایش تجهیزات شبکه است.

در این مدل، Prometheus مستقیماً داده‌های SNMP را مانند یک Metric معمولی دریافت نمی‌کند.SNMP Exporter در میانه این ارتباط قرار می‌گیرد و با استفاده از پیکربندی مربوط به MIBها و OIDها، اطلاعات تجهیزات را دریافت کرده و در قالب Metrics در اختیار Prometheus قرار می‌دهد.

به‌صورت ساده می‌توان این فرآیند را چنین نمایش داد:

Network Device

↓

SNMP

↓

SNMP Exporter

↓

Prometheus Metrics

↓

Prometheus

↓

Grafana

در یک محیط کوچک، مدیریت این زنجیره معمولاً پیچیدگی زیادی ایجاد نمی‌کند.

اما وقتی تعداد تجهیزات افزایش پیدا کند و سازمان از Vendorها و مدل‌های مختلف استفاده کند، مدیریت MIBها، Moduleها و Mappingها به یک فعالیت مستمر تبدیل می‌شود.

Mapping؛ تبدیل زبان تجهیزات به مدل Metrics

یکی از مفاهیم کلیدی در این معماری، Mapping است. فرض کنیم دو Vendor مختلف اطلاعات CPU تجهیزات خود را از OIDهای متفاوت ارائه کنند.

برای مثال:

Vendor A

OID-A → CPU Usage

Vendor B

OID-B → CPU Usage

در لایه Monitoring باید این داده‌های متفاوت به Metricهایی تبدیل شوند که امکان مقایسه و تحلیل آن‌ها وجود داشته باشد.

به‌صورت مفهومی:

OID-A

↓

cpu_usage_percent

و:

OID-B

↓

cpu_usage_percent

در نتیجه، Prometheus می‌تواند بدون نیاز به شناخت جزئیات داخلی هر Vendor، Metricهای استانداردشده را Query کند.

اما ایجاد و نگهداری این Mappingها بخشی از هزینه عملیاتی معماری محسوب می‌شود.

چالش MIB و OID در محیط‌های Multi-Vendor

SNMP Exporter برای استخراج اطلاعات از تجهیزات SNMP به MIBها و تنظیمات مربوط به آن‌ها وابستگی دارد.

در محیطی که تنها یک یا دو مدل تجهیز وجود دارد، این فرآیند نسبتاً ساده است.

اما فرض کنیم یک سازمان دارای:

• ۵۰۰  Switch
• ۲۰۰  Router
• ۱۰۰  Firewall
• ۵۰  Load Balancer
• چندین مدل  Storage

از Vendorهای مختلف باشد.

در این شرایط ممکن است تیم Monitoring با مجموعه‌ای از MIBها، OIDها و ساختارهای متفاوت مواجه شود.

با اضافه شدن یک مدل جدید تجهیز، ممکن است نیاز باشد:

• MIB مربوطه بررسی شود.
• OIDهای مورد نیاز شناسایی شوند.
• Module مناسب ایجاد یا اصلاح شود.
• Metricهای مورد نیاز تعریف شوند.
• داده‌های حاصل Validation شوند.
• Dashboardها و Alertهای مربوطه بررسی شوند.

بنابراین اضافه کردن یک تجهیز جدید الزاماً به معنای «اضافه کردن یک IP» نیست؛ بلکه ممکن است نیازمند تغییر در بخشی از زنجیره جمع‌آوری و تحلیل داده باشد.

مشکل اصلی، تعداد تجهیزات نیست؛ تنوع آن‌هاست

در مانیتورینگ سازمانی، افزایش تعداد تجهیزات به‌تنهایی مسئله اصلی نیست.

مسئله زمانی جدی‌تر می‌شود که تعداد تجهیزات × تنوع Vendor × تنوع Model × تنوع Interface افزایش پیدا کند.

برای مثال، مدیریت ۱۰۰۰ تجهیز یکسان ممکن است ساده‌تر از مدیریت ۳۰۰ تجهیز از چندین Vendor و ده‌ها مدل مختلف باشد.

چرا؟

زیرا در حالت دوم، تیم مانیتورینگ باید تفاوت‌های موجود در:

• MIB
• OID
• Metric
• Interface
• Firmware
• قابلیت‌های SNMP
• ساختار Tableها

را نیز مدیریت کند.

به همین دلیل، در محیط‌های Multi-Vendor، مسئله اصلی فقط Scale نیست؛ بلکه Heterogeneity یا ناهمگونی زیرساخت است.

Exporterبه‌عنوان یک لایه عملیاتی جدید

Exporterها مزیت مهمی دارند: آن‌ها امکان وارد کردن داده منابع مختلف به اکوسیستم Prometheus را فراهم می‌کنند.

اما هر لایه جدید در معماری، نیازمند Lifecycle و مدیریت است.

تیم باید بداند:

• چهExporterهایی در حال استفاده هستند؟
• هر Exporter به چه منابعی متصل است؟
• Configuration آن کجا نگهداری می‌شود؟
• چه کسی مسئول به‌روزرسانی آن است؟
• در صورت تغییر Firmware تجهیز چه اتفاقی می‌افتد؟
• اگر Metric مورد انتظار تغییر کند، چه کسی باید Mapping را اصلاح کند؟
• اگر Exporter از دسترس خارج شود، چگونه باید تشخیص داده شود؟

در نتیجه، Exporter فقط یک Component فنی نیست؛ بلکه بخشی از زنجیره عملیاتی مانیتورینگ است.

 

مشکل Version و Firmware

یکی از چالش‌های کمتر دیده‌شده در محیط‌های Multi-Vendor، تغییرات Firmware است. فرض کنیم یک مدل Firewall در چندین سایت سازمان استفاده شده باشد.

پس از ارتقای Firmware ممکن است:

• برخی OIDها تغییر کنند.
• برخی Metricها دیگر در دسترس نباشند.
• رفتار یک Table تغییر کند.
• مقدار یک Counter با ساختار متفاوتی ارائه شود.

در این شرایط، Monitoring ممکن است بدون اینکه خود Prometheus دچار مشکل شده باشد، بخشی از Visibility خود را از دست بدهد.

بنابراین تیم باید تغییرات زیرساخت را با Configuration مربوط به مانیتورینگ هماهنگ کند.

این مسئله در سازمان‌هایی با چرخه‌های تغییر سریع، اهمیت بیشتری پیدا می‌کند.

یکپارچگی Metricها در محیط ناهمگون

یکی از اهداف اصلی مانیتورینگ سازمانی این است که بتواند وضعیت تجهیزات مختلف را در یک مدل مشترک نمایش دهد.

برای مثال، مدیر شبکه ممکن است بخواهد در یک Dashboard واحد موارد زیر را مشاهده کند:

• CPU
• Memory
• Interface Utilization
• Packet Loss
• Errors
• Availability

برای تجهیزات مختلف.

اما اگر Metricهای تولیدشده برای Vendorهای مختلف Naming و Labelهای متفاوتی داشته باشند، ساخت Dashboardهای عمومی و قابل استفاده مجدد دشوارتر می‌شود.

در اینجا تیم باید علاوه بر جمع‌آوری داده، به Metric Standardization نیز فکر کند.

یعنی مشخص کند:

برای یک مفهوم مشترک مانند CPU Usage، چه نام Metric، چه Labelها و چه واحدی باید در کل سازمان استفاده شود؟

هرچه تعداد تجهیزات و تیم‌ها افزایش پیدا کند، Governance این استانداردها اهمیت بیشتری پیدا می‌کند.

هزینه پنهان Dashboardها

مشکل تنها در لایه Collection باقی نمی‌ماند. فرض کنیم سازمان برای هر Vendor و Model، Dashboardهای اختصاصی ایجاد کرده باشد.

با افزایش تعداد Vendorها، ممکن است مجموعه‌ای مانند این شکل بگیرد:

Cisco Dashboard

Huawei Dashboard

Juniper Dashboard

Fortinet Dashboard

Storage Dashboard

و...

در این شرایط، تغییر یک نیاز عملیاتی ممکن است مستلزم اصلاح چند Dashboard مختلف باشد.

اگر سازمان بخواهد یک KPI جدید را در همه تجهیزات نمایش دهد، ابتدا باید مشخص شود آیا Metric مربوطه در تمام Vendorها وجود دارد، آیا نام آن یکسان است و آیا داده آن با یک استاندارد مشترک قابل نمایش است یا خیر.

بنابراین، تنوع تجهیزات می‌تواند به Dashboard Sprawl نیز منجر شود.

Alerting در محیط  Multi-Vendor

همین مسئله در Alerting نیز وجود دارد.

فرض کنیم هدف این باشد:

اگر CPU یک تجهیز از ۸۰ درصد عبور کرد، هشدار ایجاد شود.

در ظاهر Rule ساده است.

اما در محیط Multi-Vendor باید مطمئن شویم:

• Metric  مربوطه در تمام تجهیزات وجود دارد.
• Naming Convention  یکسان است.
• Unit یکسان است.
• Labelها قابل اتکا هستند.
• رفتار Counterها و Gaugeها درست تفسیر شده است.

اگر این استانداردسازی انجام نشده باشد، ممکن است یک Rule برای یک گروه از تجهیزات درست کار کند اما برای گروه دیگری نیازمند تغییر باشد.

در نتیجه، Monitoring Policy باید از Metric Collection جدا نباشد و طراحی این دو بخش با یکدیگر هماهنگ شود.

آیا Prometheus در محیط Multi-Vendor نامناسب است؟

خیر.

Prometheus می‌تواند با استفاده از Exporterها، Collectorها و ابزارهای مکمل، طیف بسیار گسترده‌ای از منابع را تحت پایش قرار دهد.

مشکل اصلی «عدم امکان مانیتورینگ» نیست.

مسئله این است که:

هرچه تنوع زیرساخت بیشتر شود، میزان Configuration، Mapping، Standardization و Governance مورد نیاز نیز افزایش پیدا می‌کند.

در یک محیط Cloud-Native که سرویس‌ها Metricهای استاندارد ارائه می‌کنند، این فرآیند می‌تواند بسیار ساده‌تر باشد.

اما در یک دیتاسنتر سازمانی که مجموعه‌ای از تجهیزات Legacy، Network، Security، Storage و Server از Vendorهای مختلف وجود دارد، لایه‌های بیشتری برای تبدیل و استانداردسازی داده مورد نیاز خواهد بود.

مقایسه دو رویکرد معماری

در یک معماری مبتنی بر Prometheus، مسیر کلی ممکن است چنین باشد:

تجهیزات مختلف

↓

Protocol / API / SNMP

↓

Exporter / Collector

↓

Metric Mapping

↓

Prometheus

↓

Alerting / Rules

↓

Grafana

هرچه تعداد و تنوع تجهیزات افزایش پیدا کند، مدیریت این زنجیره نیز پیچیده‌تر می‌شود.

در مقابل، در یک پلتفرم یکپارچه مانیتورینگ، هدف این است که تفاوت‌های مربوط به Vendor و Protocol در لایه داخلی پلتفرم مدیریت شود و تیم عملیات تا حد امکان با یک مدل مدیریتی مشترک کار کند.

در چنین معماری‌ای، اضافه شدن یک تجهیز جدید می‌تواند بیشتر به یک فرآیند Discovery و Configuration تبدیل شود تا یک پروژه جدید برای ساخت زنجیره Collection و Mapping.

جایگاه پلتفرم مانیتورینگ معین در محیط‌های Multi-Vendor

یکی از چالش‌های اصلی سازمان‌های بزرگ، مدیریت هم‌زمان فناوری‌های مختلف است.

یک پلتفرم مانیتورینگ سازمانی باید بتواند بدون ایجاد زنجیره‌ای طولانی از ابزارهای مکمل، اطلاعات تجهیزات مختلف را در یک مدل عملیاتی مشترک جمع‌آوری و نمایش دهد.

پلتفرم مانیتورینگ معین با تمرکز بر مانیتورینگ زیرساخت‌های سازمانی، تلاش می‌کند تجهیزات و سامانه‌های مختلف شبکه، امنیت، سرور، پایگاه داده، ذخیره‌سازی و سایر اجزای زیرساخت را در یک پلتفرم یکپارچه مدیریت کند.

مزیت چنین رویکردی الزاماً این نیست که Exporter وجود ندارد؛ بلکه مسئله مهم‌تر، انتقال پیچیدگی مربوط به تفاوت Vendorها و Protocolها از تیم عملیات به لایه داخلی پلتفرم است.

در نتیجه، تیم مانیتورینگ می‌تواند به‌جای تمرکز بر جزئیات MIB، OID و Mapping، بیشتر روی وضعیت واقعی زیرساخت، رخدادها، Performance و تحلیل عملیاتی تمرکز کند.

جمع‌بندی

Prometheus و Grafana از نظر انعطاف‌پذیری و قابلیت توسعه، ابزارهایی بسیار قدرتمند هستند و می‌توانند در کنار Exporterها و ابزارهای مکمل، طیف گسترده‌ای از منابع را تحت پایش قرار دهند.

اما در محیط‌های سازمانی Multi-Vendor، چالش اصلی تنها جمع‌آوری Metric نیست.

تفاوت MIBها، OIDها، مدل‌های تجهیزات، Firmwareها، Naming Conventionها و ساختار داده می‌تواند باعث شود تیم Monitoring علاوه بر خود تجهیزات، بخش قابل‌توجهی از زمان خود را صرف مدیریت لایه‌های تبدیل و استانداردسازی داده کند.

در مقیاس کوچک، این پیچیدگی معمولاً قابل مدیریت است.

اما با افزایش تعداد تجهیزات و به‌خصوص افزایش تنوع Vendor و Model، هزینه عملیاتی آن نیز افزایش پیدا می‌کند.

در چنین شرایطی، Exporterها و Mappingها یک راهکار فنی مؤثر هستند؛ اما خودشان نیز به Configuration، Lifecycle Management، Governance و دانش تخصصی نیاز دارند.

بنابراین سؤال اصلی این نیست که:

آیا Prometheus می‌تواند تجهیزات Multi-Vendor را مانیتور کند؟

پاسخ این سؤال در بسیاری از سناریوها مثبت است.

سؤال مهم‌تر این است:

برای تبدیل هزاران تجهیز ناهمگون به یک مدل مانیتورینگ استاندارد، چه مقدار Configuration، Integration و دانش تخصصی باید در اختیار تیم قرار گیرد؟

در نهایت، تفاوت میان معماری ماژولار و یکپارچه را می‌توان در یک جمله خلاصه کرد:

در معماری ماژولار، انعطاف‌پذیری بیشتری در اختیار تیم قرار می‌گیرد؛ اما بخشی از مسئولیت یکپارچه‌سازی نیز به همان تیم منتقل می‌شود.

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

به همین دلیل، انتخاب میان این دو رویکرد نباید صرفاً بر اساس متن‌باز بودن، تعداد قابلیت‌ها یا محبوبیت ابزار انجام شود؛ بلکه باید تنوع زیرساخت، تعداد Vendorها، تخصص تیم، هزینه نگهداری و میزان پیچیدگی قابل‌قبول سازمان نیز در نظر گرفته شود.