کالبدشکافی Prometheus و Grafana (بخش چهارم): چالش Event Correlation؛ محدودیت‌های تشخیص Root Cause در مقیاس سازمانی

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

در سه بخش قبلی این مجموعه، Prometheus و Grafana را از زوایای مختلف بررسی کردیم؛ از معماری چندپاره و وابستگی میان اجزای مختلف گرفته تا چالش پایش تجهیزات Multi-Vendor و در نهایت، مسئله Governance و مدیریت متمرکز در مقیاس سازمانی.اما حتی اگر تمام این چالش‌ها را به‌درستی مدیریت کنیم، هنوز یک سؤال اساسی باقی می‌ماند:

وقتی یک Incident در زیرساخت رخ می‌دهد، آیا سیستم مانیتورینگ می‌تواند تشخیص دهد واقعاً چه اتفاقی افتاده است؟

در نگاه اول، پاسخ ساده به نظر می‌رسد. اگر یک تجهیز یا سرویس دچار مشکل شود، Prometheus   آن را از طریق Metricها تشخیص می‌دهد و Alert ایجاد می‌شود. Grafana نیز می‌تواند این اطلاعات را در قالب Dashboard نمایش دهد.اما مشکل اصلی در زیرساخت‌های بزرگ معمولاً «تشخیص وجود مشکل» نیست؛ بلکه تشخیص رابطه میان مشکلات متعدد و پیدا کردن علت اصلی رخداد است.در یک زیرساخت سازمانی، یک خرابی واحد می‌تواند زنجیره‌ای از پیامدها ایجاد کند. از کار افتادن یک Core Switch ممکن است باعث قطع ارتباط چندین سرور شود؛ قطع ارتباط سرورها می‌تواند باعث اختلال در Database شود و اختلال Database نیز ممکن است در نهایت باعث افزایش خطا در Application و از دسترس خارج شدن یک سرویس کسب‌وکار شود.در چنین شرایطی، تیم عملیات ممکن است در مدت کوتاهی با ده‌ها یا حتی صدها Alert مواجه شود.اما این صد Alert الزاماً به معنای صد مشکل نیست.ممکن است تمام آن‌ها فقط نشانه‌های مختلف یک Root Cause  واحد باشند.

Alert با Incident یکسان نیست

یکی از مهم‌ترین مفاهیم در مدیریت مدرن زیرساخت، تفکیک میان Metric، Alert، Event و Incident است.Metric  یک داده قابل اندازه‌گیری است؛ مانند CPU، Memory، Packet Loss یا .Response Time Alert زمانی ایجاد می‌شود که یک شرط مشخص روی یک یا چند Metric برقرار شود؛ برای مثال زمانی که CPU یک سرور برای مدت مشخصی از یک آستانه عبور کند. اما Incident یک رخداد عملیاتی است که نیاز به بررسی و اقدام دارد.

این تفاوت در محیط‌های کوچک ممکن است چندان مهم به نظر نرسد، اما در محیط‌های بزرگ اهمیت آن چند برابر می‌شود.فرض کنیم یک Router اصلی دچار اختلال شده است. در نتیجه این اختلال، چندین Interface از دسترس خارج می‌شوند، تعدادی Server دیگر نمی‌توانند به Network دسترسی داشته باشند و سرویس‌های وابسته نیز شروع به تولید خطا می‌کنند.

در این حالت ممکن است سیستم ده‌ها Alert تولید کند، اما از دید تیم عملیات، یک Incident اصلی وجود دارد.

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

«چند Alert داریم؟»

بلکه این است:

«چند Incident واقعی داریم و Root Cause هرکدام چیست؟»

Alert Storm؛ وقتی مانیتورینگ بیش از حد هشدار می‌دهد

یکی از مشکلات شناخته‌شده در زیرساخت‌های بزرگ، پدیده‌ای است که معمولاً با عنوان Alert Storm شناخته می‌شود.

Alert Storm زمانی اتفاق می‌افتد که یک رخداد اصلی باعث فعال شدن تعداد زیادی Alert در اجزای مختلف زیرساخت شود. برای مثال، فرض کنید یک Storage مرکزی از دسترس خارج شود.

در نگاه اول، ممکن است Alert مربوط به Storage ایجاد شود. اما در ادامه، سرورهایی که به آن Storage وابسته هستند نیز ممکن است خطا دهند. Databaseهای مستقر روی این سرورها ممکن است Response Time بالاتری نشان دهند و Applicationهای وابسته نیز Error Rate بیشتری تولید کنند. در نهایت، تیم عملیات ممکن است با مجموعه‌ای از Alertها روبه‌رو شود که هرکدام از دید یک جزء زیرساخت کاملاً معتبر هستند.

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

Grouping با Correlation تفاوت دارد

در اینجا یکی از مهم‌ترین تفاوت‌های مفهومی باید روشن شود.Alert Grouping به معنای قرار دادن چند Alert مرتبط در یک گروه است. اما Event Correlation به دنبال کشف رابطه میان رخدادها و شناسایی الگوی مشترک آن‌هاست.برای مثال، اگر ده Alert در یک بازه زمانی مشخص از یک سرور ایجاد شوند، می‌توان آن‌ها را بر اساس Host یا زمان در یک گروه قرار داد.اما این الزاماً به این معنا نیست که سیستم علت اصلی را پیدا کرده است. ممکن است CPU، Memory، Network و Application همگی Alert داده باشند، اما Root Cause واقعی یک مشکل در Storage باشد.

بنابراین Correlation باید بتواند فراتر از شباهت ظاهری Alertها حرکت کند و روابط میان اجزای زیرساخت را نیز در نظر بگیرد.این همان نقطه‌ای است که مفهوم Dependency اهمیت پیدا می‌کند.

Dependency؛ چیزی که Metric به‌تنهایی نمی‌گوید

Metric معمولاً وضعیت یک جزء مشخص را توصیف می‌کند.اما Metric به‌تنهایی لزوماً نمی‌گوید این جزء به چه اجزای دیگری وابسته است.برای مثال، افزایش Latency یک Database می‌تواند دلایل مختلفی داشته باشد. ممکن است مشکل از خود Database باشد، یا از Storage، Network، Virtualization Layerیا حتی یک سرویس بالادستی ناشی شده باشد.

اگر سیستم فقط Metricها را به‌صورت مستقل مشاهده کند، تمام این احتمالات باید توسط مهندس عملیات بررسی شوند.اما اگر ارتباط میان اجزای زیرساخت نیز در اختیار سیستم باشد، تحلیل رخداد می‌تواند از سطح «چه چیزی خراب شده؟» به سطح «چه چیزی باعث خرابی شده؟» حرکت کند.به همین دلیل، Topology و Service Dependency در تحلیل رخداد اهمیت زیادی پیدا می‌کنند.

سناریوی عملیاتی؛ یک خرابی و ده‌ها Alert

فرض کنیم در یک دیتاسنتر سازمانی، یک Core Switch دچار خرابی شده است.در چند ثانیه، ارتباط تعدادی از Serverها با شبکه قطع می‌شود. Prometheus ممکن است Unreachable شدن این Serverها را تشخیص دهد. Applicationهای مستقر روی آن‌ها نیز ممکن است شروع به تولید Error کنند. Databaseهایی که روی این Serverها قرار دارند ممکن است Timeout ثبت کنند و در نهایت سرویس‌های کسب‌وکار نیز از دسترس خارج شوند.

اگر این رخداد را فقط از زاویه Alertها ببینیم، ممکن است با مجموعه‌ای از پیام‌ها مواجه شویم:

Server Down.

Database Timeout.

Application Error.

High Response Time.

Packet Loss.

Service Unavailable.

هرکدام از این Alertها ممکن است درست باشند.

اما Root Cause چیست؟

Core Switch.

این تفاوت بسیار مهم است.تیم عملیات به جای اینکه شش مشکل مستقل را بررسی کند، باید بتواند بفهمد این رخدادها به یک زنجیره وابسته‌اند و احتمالاً یک علت مشترک دارند.این همان ارزشی است که Event Correlation و  Root Cause Analysis باید ایجاد کنند.

Prometheus و Grafana؛ قدرتمند در مشاهده، اما Correlation یک مسئله بزرگ‌تر است

در اینجا باید منصفانه به معماری Prometheus و Grafana نگاه کنیم.Prometheus  یک موتور قدرتمند برای جمع‌آوری و پردازش Metricهای Time-Series است و امکان تعریف  Alert Ruleهای مختلف را فراهم می‌کند. Grafana نیز قابلیت‌های گسترده‌ای برای Query، Visualization و Alerting در اختیار تیم‌های فنی قرار می‌دهد.بنابراین مسئله این نیست که این ابزارها «نمی‌توانند Alert تولید کنند» یا «امکان Grouping ندارند.»مسئله این است که Alerting و Visualization با Event Correlation  و Root Cause Analysis یکسان نیستند.برای Correlation در سطح پیچیده‌تر، معمولاً باید اطلاعات بیشتری از جمله روابط میان اجزای زیرساخت، وابستگی سرویس‌ها، زمان رخدادها و Context عملیاتی در اختیار سیستم قرار گیرد.

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

مشکل Context؛ وقتی داده داریم اما تصویر نداریم

یکی از مهم‌ترین تفاوت‌های میان «داده» و «اطلاعات عملیاتی» همین‌جاست. ممکن است سازمان هزاران Metric داشته باشد و Dashboardهای بسیار دقیقی نیز در اختیار تیم عملیات قرار دهد.

اما در زمان Incident، مهندس عملیات معمولاً به دنبال پاسخ چند سؤال مشخص است:

چه چیزی خراب شده است؟

چه زمانی شروع شده است؟

علت اصلی چیست؟

چه سرویس‌هایی تحت تأثیر قرار گرفته‌اند؟

کدام تیم باید اقدام کند؟

آیا این رخداد جدید است یا پیامد یک رخداد قبلی؟

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

اثر مستقیم بر MTTR

هدف نهایی مانیتورینگ، صرفاً تولید Metric و Alert نیست. یکی از شاخص‌های مهم عملیات IT، Mean Time to Recovery یا MTTR است؛ یعنی مدت زمانی که برای بازگرداندن سرویس به وضعیت عادی صرف می‌شود.هر دقیقه‌ای که تیم عملیات صرف بررسی Alertهای مرتبط اما غیرضروری کند، می‌تواند زمان تشخیص و رفع مشکل را افزایش دهد.در Incidentهای ساده، این اختلاف ممکن است چندان مهم نباشد. اما در سرویس‌های حیاتی سازمانی، چند دقیقه تأخیر می‌تواند اهمیت زیادی داشته باشد. به همین دلیل، ارزش واقعی Event Correlation را باید در این دید که آیا می‌تواند حجم اطلاعاتی که مهندس باید به‌صورت دستی تحلیل کند کاهش دهد یا خیر.

Correlation در محیط Multi-Vendor پیچیده‌تر می‌شود

این مسئله در زیرساخت‌های سازمانی Multi-Vendor حتی پیچیده‌تر است.فرض کنید یک سازمان هم‌زمان از تجهیزات مختلف Network، Firewall، Storage، Server، Database و Application استفاده می‌کند. هرکدام از این حوزه‌ها ممکن است Metricها، Eventها، Severityها و روش‌های متفاوتی برای گزارش وضعیت داشته باشند.در چنین محیطی، Correlation فقط به معنای مقایسه چند Metric مشابه نیست.سیستم باید بتواند اطلاعات حاصل از فناوری‌ها و لایه‌های مختلف را در یک مدل مشترک قرار دهد.

برای مثال، Packet Loss در Network ممکن است با افزایش Latency در Database و افزایش Response Time در Application ارتباط داشته باشد.

اگر این رابطه در مدل عملیاتی سیستم قابل مشاهده باشد، تحلیل Incident بسیار سریع‌تر انجام می‌شود.اما اگر هر حوزه در یک Dashboard یا ابزار جداگانه قرار داشته باشد، برقراری این ارتباط ممکن است به عهده مهندس عملیات گذاشته شود.

از Monitoring به Event Management

اینجاست که تفاوت میان Monitoring و Event Management مشخص می‌شود.Monitoring  در ساده‌ترین تعریف به این سؤال پاسخ می‌دهد:

«وضعیت سیستم چگونه است؟»

Event Management سؤال دیگری را مطرح می‌کند:

«چه رخدادهایی در سیستم اتفاق افتاده و چگونه باید آن‌ها را مدیریت کنیم؟»

و در سطح پیشرفته‌تر، Root Cause Analysis می‌پرسد:

«چه رخداد یا مؤلفه‌ای عامل اصلی این زنجیره بوده است؟»

این سه مفهوم به یکدیگر مرتبط‌اند، اما یکسان نیستند.یک سازمان ممکن است Monitoring بسیار قدرتمندی داشته باشد و در عین حال برای مدیریت Incidentها نیازمند ابزارها و فرآیندهای دیگری باشد.بنابراین داشتن Metric بیشتر، لزوماً به معنای داشتن Visibility بهتر نیست.Visibility زمانی ارزشمند است که بتواند به تصمیم عملیاتی منجر شود.

آیا می‌توان Correlation را با Ruleهای بیشتر حل کرد؟

یکی از واکنش‌های طبیعی در برابر این مسئله، اضافه کردن Ruleهای بیشتر است.اگر دو Alert با هم مرتبط‌اند، می‌توان Rule دیگری برای آن‌ها تعریف کرد. اگر رابطه پیچیده‌تر باشد، Ruleهای بیشتری ایجاد می‌شوند.اما در زیرساخت‌های بزرگ، این رویکرد می‌تواند به افزایش پیچیدگی منجر شود.زیرا با رشد تعداد تجهیزات و سرویس‌ها، تعداد روابط احتمالی نیز افزایش پیدا می‌کند.در نتیجه، اگر برای هر سناریو Rule مستقلی ایجاد شود، خود سیستم Correlation ممکن است به مجموعه بزرگی از قواعد تبدیل شود که نگهداری آن نیازمند دانش و زمان قابل‌توجهی است.به همین دلیل، مسئله Correlation در مقیاس سازمانی صرفاً «داشتن Rule» نیست؛ بلکه داشتن مدل مناسبی از ارتباط میان اجزای زیرساخت نیز اهمیت دارد.

جایگاه Topology در تشخیص Root Cause

Topology می‌تواند یکی از مهم‌ترین منابع Context برای تحلیل رخداد باشد. وقتی سیستم بداند یک Server از طریق کدام Switch به شبکه متصل است، یک Database روی کدام Server قرار دارد و یک Application به کدام Database وابسته است، می‌تواند رخدادها را در بستر ارتباط واقعی میان اجزا تحلیل کند.در این مدل، اگر یک Core Switch از کار بیفتد، سیستم می‌تواند Alertهای مربوط به تجهیزات و سرویس‌های وابسته را در یک زنجیره منطقی مشاهده کند.در نتیجه، تیم عملیات به جای مشاهده مجموعه‌ای از Alertهای مستقل، یک تصویر وابسته از Incident در اختیار خواهد داشت.این همان نقطه‌ای است که Topology از یک نقشه گرافیکی ساده به یک منبع Context عملیاتی تبدیل می‌شود.

نقش پلتفرم یکپارچه در مدیریت رخداد

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

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

جایگاه پلتفرم معین؛ از مشاهده رخداد تا تحلیل یکپارچه

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

در یک سازمان، ممکن است یک رخداد از لایه Network آغاز شود، اما اثر آن در Server، Database و Application مشاهده شود. ارزش یک سامانه مانیتورینگ سازمانی زمانی بیشتر مشخص می‌شود که بتواند این لایه‌ها را در یک تصویر عملیاتی مشترک قرار دهد.

در چنین رویکردی، هدف نهایی فقط این نیست که سیستم بگوید «چه چیزی Alert شده است» بلکه باید به تیم عملیات کمک کند بفهمد «چه اتفاقی افتاده، دامنه تأثیر آن چیست و از کجا باید بررسی را آغاز کرد.»این تفاوت میان یک ابزار جمع‌آوری و نمایش Metric و یک پلتفرم مدیریت مانیتورینگ در سطح سازمان است.

نتیجه‌گیری؛ از حجم داده به ارزش داده

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

اما در محیط‌های سازمانی، مسئله اصلی صرفاً افزایش تعداد Metricها یا Dashboardها نیست.هرچه زیرساخت بزرگ‌تر و پیچیده‌تر شود، تعداد رخدادهای هم‌زمان نیز افزایش پیدا می‌کند و تشخیص اینکه کدام Alertها مستقل هستند و کدام‌یک پیامد یک Root Cause مشترک‌اند، اهمیت بیشتری پیدا می‌کند.در این مرحله، تفاوت میان Alerting، Alert Grouping، Event Correlation و  Root Cause Analysis اهمیت خود را نشان می‌دهد.

Alert می‌تواند بگوید یک مؤلفه وضعیت غیرعادی دارد.Correlation  می‌تواند به شناسایی رابطه میان چند رخداد کمک کند و Root Cause Analysis باید به تیم عملیات کمک کند تا علت اصلی را از میان مجموعه‌ای از علائم و پیامدها پیدا کند.بنابراین سؤال مهم برای مدیران زیرساخت دیگر این نیست که:

«سیستم مانیتورینگ ما چند Metric را می‌تواند جمع‌آوری کند؟»

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

«وقتی یک Incident واقعی رخ می‌دهد، چه مقدار از زمان تیم عملیات صرف پیدا کردن علت اصلی می‌شود و چه مقدار صرف جست‌وجو میان Alertها و داده‌های پراکنده؟»

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