کالبدشکافی Prometheus و Grafana (بخش پنجم): چالش Long-Term Monitoring؛ محدودیت‌های نگهداری و تحلیل بلندمدت داده‌های مانیتورینگ در مقیاس سازمانی

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

در یک زیرساخت کوچک، معمولاً بررسی وضعیت فعلی سیستم‌ها و رخدادهای اخیر برای تیم IT کافی است. اگر یک سرور دچار مشکل شود، تیم عملیات می‌تواند وضعیت CPU، Memory، Disk یا Network آن را در ساعات و روزهای گذشته بررسی کند و برای پیدا کردن علت مشکل، داده‌های مربوط به همان بازه زمانی را مورد استفاده قرار دهد. اما با بزرگ‌تر شدن زیرساخت، نیاز سازمان به داده‌های مانیتورینگ دیگر محدود به چند ساعت یا چند روز گذشته نیست.

در محیط‌های Enterprise، داده‌های مانیتورینگ به یک منبع مهم برای تحلیل وضعیت زیرساخت تبدیل می‌شوند. سازمان ممکن است بخواهد بداند مصرف CPU یک سرور در شش ماه گذشته چگونه تغییر کرده، ظرفیت Storage چه روندی داشته، Latency یک سرویس در طول یک سال چه تغییری کرده یا پیش از وقوع یک Incident مهم، چه تغییراتی در وضعیت زیرساخت رخ داده است.

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

اما مسئله از جایی پیچیده می‌شود که حجم داده‌های مانیتورینگ افزایش پیدا می‌کند. در این مرحله، نگهداری داده‌ها دیگر فقط یک موضوع ساده در Configuration سیستم مانیتورینگ نیست و به یک مسئله معماری در حوزه Storage، Scalability، Availability و Data Management تبدیل می‌شود.

Long-Term Monitoring چیست؟

Long-Term Monitoring را می‌توان ادامه طبیعی مانیتورینگ در مقیاس سازمانی دانست. در مانیتورینگ روزمره، تمرکز اصلی روی وضعیت فعلی سیستم و رخدادهای نزدیک است؛ اما در Long-Term Monitoring، داده‌های جمع‌آوری‌شده در طول زمان به یک مجموعه تاریخی تبدیل می‌شوند که می‌توان از آن برای شناخت رفتار زیرساخت استفاده کرد.

فرض کنید سازمانی صدها سرور، تجهیزات شبکه، سرویس نرم‌افزاری و Application دارد. برای هرکدام از این اجزا ممکن است Metricهای مختلفی مانند CPU Utilization، Memory Usage، Disk Usage، Network Traffic، Latency و Error Rate جمع‌آوری شود.

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

برای مثال، ممکن است مصرف CPU یک Application Server در یک روز کاملاً عادی به نظر برسد، اما بررسی داده‌های یک‌ساله نشان دهد که مصرف CPU به‌صورت تدریجی از ۴۵ درصد به ۷۰ درصد رسیده است. این تغییر می‌تواند نشانه افزایش بار کاری، رشد تعداد کاربران یا نزدیک شدن سرویس به محدودیت ظرفیت باشد.

بنابراین ارزش Long-Term Monitoring فقط در نگهداری داده‌های قدیمی نیست؛ ارزش اصلی آن در تبدیل داده‌های تاریخی به اطلاعات قابل استفاده برای تصمیم‌گیری است.

مسئله از کجا شروع می‌شود؟

در نگاه اول، راهکار ساده به نظر می‌رسد: اگر داده‌های بیشتری لازم داریم، کافی است Retention را افزایش دهیم. اما در یک محیط Enterprise، افزایش Retention می‌تواند اثر مستقیمی بر Storage و Performance داشته باشد.

هرچه تعداد Targetها افزایش پیدا کند، تعداد Metricها نیز بیشتر می‌شود. از طرف دیگر، هرچه Scrape Interval کوتاه‌تر باشد، Sampleهای بیشتری تولید می‌شوند. حال اگر همین داده‌ها برای ماه‌ها یا سال‌ها نگهداری شوند، حجم Storage به‌سرعت افزایش پیدا می‌کند.

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

برای یک سازمان کوچک، این افزایش حجم ممکن است مشکلی ایجاد نکند؛ اما در محیطی با هزاران Target و میلیون‌ها Time-Series، Storage به یکی از اجزای مهم معماری مانیتورینگ تبدیل می‌شود.

در این نقطه، سازمان دیگر فقط نمی‌پرسد «چقدر داده نگه داریم؟» بلکه باید بپرسد «این داده‌ها را کجا، با چه معماری و با چه سطحی از دسترس‌پذیری نگهداری کنیم؟»

محدودیت Retention در مقیاس Enterprise

Prometheus از یک Time-Series Database داخلی برای ذخیره داده‌های Metric استفاده می‌کند. این معماری برای بسیاری از سناریوهای Monitoring بسیار مناسب است و باعث می‌شود راه‌اندازی یک Prometheus Server نسبتاً ساده باشد.

اما در یک محیط Enterprise، مسئله فقط ذخیره داده‌های یک Prometheus Server نیست.

فرض کنید یک سازمان چندین دیتاسنتر یا چند محیط مختلف دارد و در هر محیط چند Prometheus Server برای جمع‌آوری Metricها فعالیت می‌کنند. در این حالت، داده‌ها در چند محل مختلف توزیع شده‌اند.

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

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

وقتی Prometheus دیگر به‌تنهایی کافی نیست

اکوسیستم Prometheus برای پاسخ به نیازهای مقیاس بزرگ، ابزارها و معماری‌های مکمل مختلفی دارد. Thanos، Cortex، Grafana Mimir و VictoriaMetrics از جمله راهکارهایی هستند که می‌توانند قابلیت‌هایی مانند Long-Term Storage، Global Query، High Availability و Scalability را به معماری مانیتورینگ اضافه کنند.

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

در یک معماری ساده ممکن است مسیر داده تقریباً به این شکل باشد:

Exporter → Prometheus → Grafana

اما در یک معماری Enterprise، ممکن است یک لایه Long-Term Storage، Object Storage و Query Layer نیز در این مسیر قرار بگیرد.

در نتیجه، سازمان برای رسیدن به قابلیت Long-Term Monitoring باید اجزای بیشتری را طراحی، پیکربندی، مانیتور و نگهداری کند.

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

Thanos؛ گسترش Prometheus برای داده‌های بلندمدت

Thanos یکی از شناخته‌شده‌ترین راهکارها برای گسترش معماری Prometheus است. این پروژه می‌تواند قابلیت‌هایی مانند Long-Term Storage و Global Query را در اختیار معماری‌های مبتنی بر Prometheus قرار دهد.

در یک سناریوی معمول، Prometheus همچنان وظیفه جمع‌آوری Metricها و نگهداری داده‌های محلی را بر عهده دارد و Thanos می‌تواند داده‌ها را برای نگهداری بلندمدت به Object Storage منتقل کند.

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

اما در کنار این قابلیت‌ها، یک واقعیت عملیاتی نیز وجود دارد. سازمان اکنون علاوه بر Prometheusو Grafana، باید اجزای مرتبط با Thanos و Storage را نیز مدیریت کند.

بنابراین مسئله فقط اضافه کردن یک ابزار نیست؛ بلکه ایجاد یک معماری جدید برای مدیریت داده‌های مانیتورینگ است.

Grafana Mimir و معماری مقیاس‌پذیر

Grafana Mimir نیز یکی دیگر از راهکارهای مهم در این حوزه است که برای ذخیره‌سازی و Query کردن حجم بالای Prometheus-compatible Metrics طراحی شده است.

Mimir می‌تواند در معماری‌های بزرگ قابلیت‌هایی مانند Horizontal Scalability، High Availability، Multi-Tenancyو Long-Term Storage را فراهم کند.

اما استفاده از چنین معماری‌ای نیز نیازمند طراحی و مدیریت مجموعه‌ای از اجزای زیرساختی است. تیم IT باید Storage، Scalability، Availability، Monitoring و نگهداری این لایه را در نظر بگیرد.

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

Long-Term Storage فقط مسئله فضای دیسک نیست

یکی از برداشت‌های اشتباه درباره Long-Term Monitoring این است که مشکل اصلی فقط کمبود فضای Storage است. در حالی که در مقیاس Enterprise، Storage تنها یکی از بخش‌های مسئله است.

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

بنابراین Long-Term Monitoring با موضوعاتی مانند High Availability، Backup، Disaster Recovery و Query Performance ارتباط مستقیم پیدا می‌کند.

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

هزینه پنهان داده‌های مانیتورینگ

هر Metric به‌تنهایی حجم زیادی ندارد، اما در مقیاس سازمانی، تعداد Metricها می‌تواند بسیار زیاد باشد.

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

در این شرایط، سازمان باید درباره Cost مربوط به Observability نیز تصمیم‌گیری کند.

آیا تمام Metricها باید برای چند سال نگهداری شوند؟ آیا داده‌های کم‌اهمیت باید با همان Resolution داده‌های حیاتی ذخیره شوند؟ آیا برای داده‌های قدیمی همچنان به همان سطح جزئیات نیاز است؟

این پرسش‌ها نشان می‌دهند که Retention Policy باید بر اساس نیاز عملیاتی و ارزش داده تعیین شود، نه صرفاً بر اساس اینکه Storage موجود چه مقدار ظرفیت دارد.

آیا همه داده‌ها باید با یک Resolution نگهداری شوند؟

فرض کنید یک Metric هر ۱۵ ثانیه جمع‌آوری می‌شود. برای بررسی یک Incident که همین امروز اتفاق افتاده، این سطح از جزئیات می‌تواند بسیار مفید باشد.

اما آیا برای بررسی روند مصرف CPU در سه سال گذشته نیز به داده‌هایی با همین Resolution نیاز داریم؟

در بسیاری از سناریوها، پاسخ منفی است.

برای داده‌های جدید می‌توان Resolution بالاتری حفظ کرد تا تحلیل دقیق رخدادها امکان‌پذیر باشد، در حالی که برای داده‌های قدیمی‌تر می‌توان از داده‌های خلاصه‌شده یا Downsampled استفاده کرد.

این روش می‌تواند مصرف Storage را کاهش دهد، اما در مقابل به یک سیاست مشخص برای Data Lifecycle و Retention         نیاز دارد.

بنابراین Long-Term Monitoring فقط درباره مدت زمان نگهداری داده نیست؛ بلکه درباره این است که چه داده‌ای، با چه Resolution و برای چه مدت نگهداری شود.

ارزش واقعی داده‌های تاریخی

اگر داده‌های تاریخی فقط ذخیره شوند اما امکان تحلیل مؤثر آن‌ها وجود نداشته باشد، بخش مهمی از ارزش Long-Term Monitoring از بین می‌رود.

یکی از مهم‌ترین کاربردهای این داده‌ها Trend Analysis است. سازمان می‌تواند روند مصرف منابع را در طول زمان بررسی کند و تغییرات تدریجی را شناسایی کند.

کاربرد دیگر Capacity Planning است. اگر مصرف Storage یک سازمان در طول ماه‌های گذشته روند مشخصی داشته باشد، می‌توان بر اساس آن برای افزایش ظرفیت برنامه‌ریزی کرد.

داده‌های تاریخی همچنین در Incident Analysis اهمیت زیادی دارند. گاهی یک مشکل چند ماه بعد از وقوع آن مورد بررسی قرار می‌گیرد. اگر داده‌های مربوط به آن زمان هنوز در دسترس باشند، تیم IT می‌تواند وضعیت زیرساخت را در زمان وقوع رخداد بازسازی کند.

این قابلیت در محیط‌های Enterprise اهمیت زیادی دارد؛ زیرا بسیاری از تصمیم‌های زیرساختی بر اساس رفتار گذشته سیستم‌ها گرفته می‌شوند.

نقش Grafana در Long-Term Monitoring

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

Grafana عمدتاً به‌عنوان یک لایه Visualization و Dashboarding عمل می‌کند و داده‌ها را از Data Sourceهای مختلف دریافت و نمایش می‌دهد.

بنابراین اگر سازمان قصد داشته باشد داده‌های مانیتورینگ را برای چند سال نگهداری کند، صرفاً استفاده از Grafana مسئله Long-Term Storage را حل نمی‌کند.

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

در نتیجه، Grafana بخش قابل مشاهده معماری است، اما مسئله Long-Term Monitoring در لایه Storage و Data Management نیز ادامه پیدا می‌کند.

Hidden Complexity؛ پیچیدگی‌ای که با رشد سیستم ظاهر می‌شود

یکی از نکات مهم در بررسی معماری Prometheus و Grafana این است که بسیاری از قابلیت‌ها به‌صورت مستقل بسیار قدرتمند هستند.

Prometheus یک ابزار قدرتمند برای Metrics Monitoring است. Grafana قابلیت‌های گسترده‌ای برای  Visualization ارائه می‌دهد.  Thanos می‌تواند قابلیت Long-Term Storage و Global Query را اضافه کند و Mimir نیز برای سناریوهای بزرگ و توزیع‌شده طراحی شده است.

اما زمانی که این ابزارها در کنار یکدیگر قرار می‌گیرند، سازمان باید کل زنجیره را مدیریت کند.

این همان جایی است که Hidden Complexity خود را نشان می‌دهد.

ممکن است هر ابزار به‌تنهایی پیچیدگی زیادی نداشته باشد، اما مدیریت ارتباط میان آن‌ها، طراحی Storage، تعریف Retention Policy، تأمین High Availability، Backup، Monitoring و رفع خطاهای احتمالی، مجموعاً یک بار عملیاتی قابل توجه ایجاد می‌کند.

در یک محیط Enterprise، این پیچیدگی باید به‌عنوان بخشی از Total Cost of Ownership معماری در نظر گرفته شود.

آیا این موضوع به معنی ضعف Prometheus است؟

خیر. چنین برداشتی دقیق نیست.

Prometheus یکی از موفق‌ترین راهکارهای Open Source برای Metrics Monitoring است و انعطاف‌پذیری آن یکی از دلایل اصلی محبوبیتش محسوب می‌شود.

مسئله زمانی مطرح می‌شود که سازمان از یک Prometheus-centric Stack انتظار داشته باشد تمام نیازهای Enterprise Monitoring، از جمع‌آوری Metric تا Long-Term Storage، تحلیل تاریخی، High Availability و مدیریت داده را در ساده‌ترین شکل ممکن پوشش دهد.

در چنین شرایطی، معمولاً باید اجزای مکمل وارد معماری شوند.

بنابراین نقد اصلی این نیست که Prometheus نمی‌تواند Long-Term Monitoring انجام دهد. بلکه مسئله دقیق‌تر این است که در مقیاس سازمانی، Long-Term Monitoring می‌تواند نیازمند طراحی یک معماری مکمل در اطراف Prometheus باشد.

این تفاوت، برای ارزیابی واقعی یک راهکار Monitoring اهمیت زیادی دارد.

مقایسه با یک پلتفرم یکپارچه  مانیتورینگ

در یک پلتفرم یکپارچه Enterprise Monitoring، انتظار می‌رود بخش قابل توجهی از چرخه مانیتورینگ در یک محیط واحد مدیریت شود؛ از جمع‌آوری داده و ذخیره‌سازی گرفته تا Dashboard، Historical Data، گزارش‌گیری، Alerting و تحلیل روند.

در این مدل، تیم IT الزاماً برای هر قابلیت جدید مجبور به اضافه کردن یک سرویس یا محصول مستقل به معماری نیست.

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

 تفاوت اصلی در اینجا لزوماً به معنای «بهتر بودن یک ابزار و ضعیف بودن ابزار دیگر» نیست؛ بلکه به تفاوت در مدل معماری بازمی‌گردد.

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

سؤال اصلی برای سازمان‌های Enterprise

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

سؤال مهم‌تر این است که سازمان برای نگهداری و استفاده از داده‌های Monitoring در طول چند سال، چه معماری‌ای را باید طراحی و عملیاتی کند.

اگر معماری مبتنی بر Prometheus انتخاب شود، موضوعاتی مانند Retention، Storage Architecture، Long-Term Storage، Object Storage، High Availability، Backup، Disaster Recovery، Global Query، Data Resolutionو Downsampling  باید از ابتدا مورد توجه قرار گیرند.

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

جمع‌بندی

Prometheus و Grafana ترکیب قدرتمندی برای Monitoring و Visualization هستند، اما در محیط‌های Enterprise، نیاز سازمان به Monitoring معمولاً با مشاهده وضعیت لحظه‌ای زیرساخت پایان نمی‌یابد.

داده‌های تاریخی می‌توانند برای Trend Analysis، Capacity Planning، بررسی Incidentهای گذشته و تصمیم‌گیری‌های زیرساختی ارزش زیادی داشته باشند. به همین دلیل، Long-Term Monitoring یکی از نیازهای مهم سازمان‌هایی است که می‌خواهند از داده‌های Monitoring خود در یک بازه زمانی طولانی استفاده کنند.

اما هرچه حجم داده و مدت Retention افزایش پیدا کند، مسئله از یک Configuration ساده فراتر می‌رود و به موضوعاتی مانند Storage، Scalability، High Availability، Backup، Disaster Recovery و Query Performance گره می‌خورد.

Prometheus می‌تواند در چنین معماری‌هایی با استفاده از راهکارهایی مانند Thanos، Mimir، Cortex یا  VictoriaMetrics توسعه پیدا کند، اما این توسعه در بسیاری از موارد به معنای اضافه شدن اجزای بیشتر به Stack و در نتیجه افزایش مسئولیت عملیاتی تیم IT است.

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

بنابراین چالش اصلی Long-Term Monitoring را می‌توان این‌گونه خلاصه کرد:

«هرچه سازمان به داده‌های تاریخی بیشتری نیاز داشته باشد، مسئله Monitoring بیشتر به یک مسئله Data Management   و معماری Storage تبدیل می‌شود.»

و در مقیاس  Enterprise، تصمیم اصلی فقط این نیست که چه ابزاری برای جمع‌آوری Metric انتخاب شود؛ بلکه باید مشخص شود سازمان می‌خواهد در سال‌های آینده، چه معماری‌ای را برای ذخیره‌سازی، مدیریت و تحلیل این حجم از داده‌های Monitoring اداره کند.

مجموعه مقالات کالبدشکافی Prometheus و Grafana