کالبدشکافی Prometheus و Grafana (بخش اول): چالش معماری چندپاره؛ «سندرم قطعات لگو» در مقیاس سازمانی

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

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

Prometheus: وظیفه جمع‌آوری متریک‌ها (Pull)، ذخیره‌سازی آن‌ها در TSDB محلی و ارزیابی قوانین هشدار را بر عهده دارد.

Grafana: به‌عنوان لایه نمایش و مصورسازی داده‌ها، امکان ایجاد داشبوردها و تحلیل بصری متریک‌های جمع‌آوری‌شده را فراهم می‌کند.

Alertmanager: مؤلفه‌ای مستقل برای دریافت هشدارهای Prometheus، گروه‌بندی، کنترل اعلان‌ها (Silencing و Inhibition) ارسال آن‌ها به مقصدهای مختلف است.

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

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

سناریوی عملیاتی: چالش توسعه زیرساخت و پایش تجهیزات جدید

برای درک بهتر، سناریویی متداول را در نظر بگیریم: اضافه شدن ۱۰ سوئیچ شبکه جدید و یک کلاسترPostgreSQL  به زیرساخت سازمان.

در یک معماری مبتنی بر Prometheus و Grafana، تیم مانیتورینگ برای اضافه کردن این تجهیزات باید مجموعه‌ای از مراحل را طی کند.

• استفاده از Exporterهای متناسب با منبع داده

سوئیچ‌های شبکه معمولاً داده‌های مدیریتی خود را از طریق SNMP ارائه می‌کنند. برای جمع‌آوری این داده‌ها در اکوسیستمPrometheus ، می‌توان از SNMP Exporter استفاده کرد.

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

برای PostgreSQL نیز می‌توان از Postgres Exporter یا ابزارهای مشابه استفاده کرد تا متریک‌های مورد نیاز پایگاه داده در اختیار Prometheus قرار گیرد.

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

• پیکربندی قوانین هشدار و مدیریت اعلان‌ها

قوانین هشدار Prometheus معمولاً به‌صورت Rule تعریف می‌شوند. پس از ایجاد Alert، مدیریت نحوه گروه‌بندی، مسیریابی و ارسال اعلان‌ها به تیم‌های مختلف توسط Alertmanager انجام می‌شود.

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

• اتصال به لایه نمایش و تحلیل

در مرحله بعد، داده‌های Prometheus به Grafana متصل شده و داشبوردهای مورد نیاز برای تیم‌های مختلف ایجاد می‌شوند.Grafana  انعطاف بسیار بالایی برای طراحی داشبورد دارد؛ اما در یک محیط سازمانی بزرگ، نگهداری Data Sourceها، داشبوردها، Variableها و وابستگی‌های میان آن‌ها نیز بخشی از فعالیت‌های عملیاتی تیم مانیتورینگ خواهد بود.

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

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

ناسازگاری مطلق وجود ندارد؛ چالش اصلی، پوشش تجهیزات سنتی است

Prometheus در اکوسیستم cloud-native و محیط‌هایی که سرویس‌ها و برنامه‌ها متریک‌های خود را از طریق HTTP و در قالب استاندارد Prometheus ارائه می‌کنند، عملکرد بسیار قدرتمندی دارد.

با این حال، زیرساخت‌های سازمانی معمولاً ترکیبی از فناوری‌های مدرن و تجهیزات سنتی هستند. سوئیچ‌ها، روترها، تجهیزات ذخیره‌سازی، تجهیزات امنیتی و بسیاری از سامانه‌های سخت‌افزاری ممکن است داده‌های مدیریتی خود را از طریق پروتکل‌هایی مانند SNMP یا رابط‌های اختصاصی ارائه کنند.

برای وارد کردن این داده‌ها به اکوسیستم Prometheus، معمولاً به Exporterها یا لایه‌های واسط نیاز است.

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

چالش مدیریت MIB و OIDها

در سناریوهای مبتنی بر SNMP، شناخت MIBها، OIDها، جدول‌های SNMP و نحوه نگاشت آن‌ها به metricهای Prometheus  اهمیت زیادی دارد.

SNMP Exporter با استفاده از Generator و پیکربندی مربوط به MIBها، امکان تولید  configurationمورد نیاز را فراهم می‌کند؛ اما مدیریت صحیح این فرآیند در محیط‌هایی با تعداد زیاد تجهیزات و Vendorهای مختلف، همچنان به دانش فنی و نگهداری مستمر نیاز دارد.

این مسئله به‌خصوص زمانی اهمیت پیدا می‌کند که سازمان به‌صورت هم‌زمان از تجهیزات چندین سازنده و مدل استفاده کند.

سربار معماری لایه واسط

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

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

بنابراین مسئله اصلی، کند بودن ذاتی Pull نیست؛ بلکه پیچیدگی و سربار عملیاتی ناشی از مدیریت لایه‌های متعدد جمع‌آوری داده است.

چالش ذخیره‌سازی بلندمدت داده‌ها (Long-term Storage)

Prometheus از TSDB محلی برای ذخیره‌سازی متریک‌ها استفاده می‌کند و مقدار Retention آن قابل تنظیم است. بنابراین نمی‌توان یک بازه زمانی ثابت مانند ۱۵ یا ۳۰ روز را به‌عنوان محدودیت ذاتی Prometheus در نظر گرفت.

چالش اصلی در محیط‌های سازمانی بزرگ، زمانی ظاهر می‌شود که حجم بالایی از متریک‌ها باید برای دوره‌های طولانی و با قابلیت مقیاس‌پذیری بالا نگهداری شوند.

با افزایش حجم داده، Cardinality و بازه زمانی مورد نیاز برای تحلیل، عواملی مانند مصرف منابع، حجم Storage، زمان اجرای Query و مدیریت نمونه‌های متعدد Prometheus اهمیت بیشتری پیدا می‌کنند.

در چنین شرایطی، سازمان‌ها می‌توانند از راهکارهای Long-term Storage و معماری‌های توزیع‌شده مانند Thanos، Cortex یا  Grafana Mimirاستفاده کنند.

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

بنابراین مسئله صرفاً «توانایی ذخیره‌سازی» نیست؛ بلکه هزینه عملیاتی و پیچیدگی معماری در مقیاس سازمانی اهمیت پیدا می‌کند.

فقدان کنترل دسترسی سازمانی در Prometheus خام

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

Prometheus به‌صورت مستقل و در حالت پایه، یک سیستم کامل RBAC و Multi-tenancy برای تفکیک دسترسی کاربران به داده‌ها ارائه نمی‌کند. در نتیجه، برای پیاده‌سازی نیازهای پیچیده کنترل دسترسی، معمولاً باید از لایه‌ها یا محصولات مکمل استفاده شود.

این قابلیت‌ها می‌توانند از طریق reverse proxyها، معماری‌های چندنمونه‌ای یا راهکارهای موجود در اکوسیستم Prometheus   پیاده‌سازی شوند.

این موضوع نیز مانند سایر چالش‌های مطرح‌شده، به معنای ناتوانی اکوسیستم Prometheus نیست؛ بلکه نشان می‌دهد برای رسیدن به یک معماری کاملاً سازمانی، ممکن است نیاز به ترکیب چند مؤلفه وجود داشته باشد.

نتیجه‌گیری

مقایسه Prometheus/Grafana با سامانه‌های یکپارچه مانیتورینگ، بیش از آنکه مقایسه دو ابزار منفرد باشد، مقایسه دو رویکرد معماری است.

اکوسیستم Prometheus/Grafana با تکیه بر استانداردهای باز، انعطاف‌پذیری بالا، جامعه کاربری گسترده و قابلیت توسعه، گزینه‌ای بسیار قدرتمند برای محیط‌هایی است که مانیتورینگ بخشی از جریان کاری  DevOpsو Cloud-Native محسوب می‌شود و تیم‌های فنی تخصص لازم برای طراحی و نگهداری این معماری را در اختیار دارند.

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

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

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

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

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

پرسش کلیدی برای مدیران زیرساخت این نیست که «کدام ابزار قدرتمندتر است؟»؛ بلکه این است که:

آیا سازمان ترجیح می‌دهد معماری مانیتورینگ خود را از مجموعه‌ای از ابزارهای تخصصی و مستقل تشکیل دهد و مسئولیت یکپارچه‌سازی و نگهداری آن‌ها را بر عهده بگیرد، یا ترجیح می‌دهد این پیچیدگی را در یک سامانه یکپارچه کاهش داده و تمرکز خود را بر تحلیل داده‌ها و مدیریت عملیات قرار دهد؟