مانیتورینگ - قسمت اول

به نام خدا

در این نوشته به بررسی فصل Monitoring Distributed Systems می‌پردازیم.

کلا این فصل درمورد تعاریف و best practiceهای مانیتورینگ بحث می‌کنه و کمک میکنه که رصد بهتری از سیستم‌مون داشته باشیم و نهایتا باعث بشه که سرویس‌مون قابل اعتماد بشود.

اول از همه یک سری تعاریف مطرح میشود:

• مانیتورینگ: به طور کلی به جمع‌آوری، پردازش و دسته‌بندی اطالاعات یک سیستم مثل تعداد کوئری‌ها و درخواست‌ها و مدت‌زمان طول کشیدن اون‌ها و ... مانیتورینگ می‌گوییم.
• مانیتورینگ white-box: این قسمت شامل اطلاعاتی کلی از داخل سیستم میشود. مانند: لاگ‌ها و مصرف منابع (cpu, ram, ...) و مسائلی که برای کاربر نهایی قابل لمس نیستند.
• مانیتورینگ black-box: این قسمت شامل داده‌های مربوط به رفتار خارجی سرویس که توسط کاربر نهایی قابل لمس است، می‌شود. مانند: ارورها، لیتنسی درخواست‌ها و...
• داشبورد: یک وب اپلیکیشن که اطلاعات مانتیورینگ ما در آن به صورتی که می‌خواهیم، قابل مشاهده است. و داده‌های روزهای قبل نیز دردسترس است. مثلا grafana یک مثالی از این داشبورد‌ها است.

پ-ن: قبلا در نوشته‌ای این که چگونه یک داشبورد گرافانا برای خودمان راه بندازیم را توضیح داده‌ام.

• آلرت (Alert): یک اعلانی است که از قبل تعیین شده است و حتما توسط یک فرد خاص مورد توجه قرار می‌گیرد.
• دلیل ریشه‌ای (Root cause): یک عیبی در سیستم است که اگر درست شود، سیستم دیگر از آن‌جا خراب نمی‌شود.

حالا یک سوال اساسی مطرح می‌شود.

چرا باید مانیتورینگ داشته باشیم؟

دلایل بسیاری بر ضرورت وجود مانیتورینگ وجود دارد که به برخی اشاره می‌کنیم:

• تحلیل و مقایسه روندهای بلندمدت: یعنی این که بدانیم در طی یک زمان خاص مثلا چقدر رشد کاربر داشته‌ایم؟ سرعت پاسخ‌دادن به درخواست‌هایمان چگونه بوده است؟ آیا بهبود داشته‌ایم یا بدتر شده‌ایم؟ و سوالاتی از این قبیل با داشتن یک مانیتورینگ خوب، قابل پاسخ‌دادن است.
• سیستم هشدار (Alerting): واضح است که با وجود مانیتورینگ ما می‌توانیم از اتفاقات بد سیستم در لحظه باخبر شویم و اقدامات لازم را انجام دهیم.
• دیباگ‌کردن سیستم: وقتی مشکلی پیش می‌آید، مانیتورینگ معمولا جزو اولین جاهایی است که به آن رجوع می‌شود. مثلا تاخیر در ریکوئست‌ها زیاده شده است. آیا مصرف رم بالا رفته است؟ cpu چطور؟ ارور داریم یا نه؟ و سوالاتی از این قبیل که از مانیتورینگ به دست‌ می‌آیند، باعث پیدا شدن دلیل ریشه‌ای می‌شوند.

انتظارات معقولی از مانیتورینگ داشته باشیم. :دی

نباید انتظار داشته باشیم که یک سیستم مانیتورینگ تمام مشکلات ما را حل خواهد کرد.

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

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

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

علامت‌ها درمقابل دلیل‌ها

یک سیستم مانیتورینگ باید به دو سوال جوابی داشته باشد: چه چیزی خراب شده است و چرا؟

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

در زیر چند نمونه از علامت‌ها و دلیل‌ها برای یک خرابی داریم:

علامت: تعداد درخواست‌های با جواب‌های 500 یا 404 زیاد شده است.

دلیل: دیتابیس درخواست‌ها را رد می‌کند.

علامت: پاسخ‌ها کند شده‌اند.

دلیل: لود cpu بالا رفته است.

- تفاوت دلیل و علامت در نوشتن یک سیستم مانیتورینگ خوب خیلی ماثر است.

مانیتورینگ Black-Box در مقابل White-Box:

تفاوت عمده این دو مورد، در علامت‌گرا بودن black-box و در حالی که white-box هم می‌تواند علامت‌گرا و هم علت‌گرا باشد. از این جهت که در یک سیستم چندلایه، علامت مشکل یک سرویس ممکن است دلیل مشکل یک سرویس وابسته به آن باشد.

نهایتا white-box وابسته به قدرت پایش اطلاعات داخل سیستم، مثلا لاگ‌ها و ... است. و باعث فهمیدن مشکلات قریب‌الوقوع و حتی مشکلاتی که با ریترای کردن پنهان شده‌اند، می‌شود.

میزان مراجعه white-box بیشتر است. و این جواب را معمولا به ما می‌دهد که چرا مشکل داریم و از این سمت black-box جواب چه چیزی خراب است را به ما می‌دهد.

چهار سیگنال طلایی مانیتورینگ:

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

• Latency:

مدت زمانی که طول می‌کشد که سرویس یک درخواست را پردازش کرده و به آن جواب بدهد. یک نکته مهم در این جا وجود دارد و آن جدا کردن latency درخواست‌ها موفق و ناموفق است. چرا؟ چون که درخواست‌های ناموفق مانند 404 طولی نمی‌کشند و سریع هستند و باعث تاثیر در سایر داده‌ها شده و منجر به برداشت اشتباه از این قسمت می‌شوند.

• Traffic:

این که در لحظه چقدر درخواست برای یک سرویس وجود دارد و مقدار هر کدام از درخواست‌ها در صورت وجود، چقدر است؟

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

• Errors:

سرعت درخواست‌هایی که با خطا مواجه می‌شوند. توجه داشته باشید که این خطاها لزوما شامل مثلا خطاهای 500 نمی‌شوند و بلکه یک پاسخ 200 هم ممکن است خطا تلقی شود. وقتی که دارای محتوای اشتباهی باشد و وقتی مثلا یک قانونی (این که باید یک ثانیه طول بکشد و یک و نیم ثانیه طول کشیده است.) را بشکند.

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

حالا مانیتور کردن همه این موارد شاید یکسان نباشد. مثلا فهمیدن پاسخ‌های 500 می‌تواند در مثلا load balancer به راحتی انجام شود. اما فهمیدن درخواست‌های با محتوای اشتباه به این سادگی نیست و در تست‌های end-to-end به دست‌ می‌آیند.

• Saturation:

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

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

*** یک نکته مهم ***:

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

فرض کنید ما یک وب‌سرویسی داشته باشیم که در هر ثانیه ۱۰۰۰ درخواست را جواب می‌دهد و میانگین latency برابر ۱۰۰ میلی‌ثانیه است. ظاهرا همه چیز خوب است ولی اگر کمی دقت کنیم متوجه می‌شویم که در همین سناریو ممکن است ۱ درصد درخواست‌هایمان بالای ۵ ثانیه طول کشیده باشند!!!
مواردی از قبیل مصرف CPU، میزان مشغول بودن Database و ... مقدار مصرف‌شان به صورت نرمال توزیع نشده است و کاملا ممکن است غیرمتعادل باشند.

برای این که اینگونه به اشتباه نیوفتیم، می‌توانیم برای مثال همین latency را بر اساس مقدارهای مناسب تقسیم بندی کنیم. مثلا این‌گونه اندازه‌گیری کنیم که چه مقدار از درخواست‌های ما زیر ۱۰ میلی‌ثانیه و چه مقدار بین ۱۰ تا ۳۰ و چقدر بین ۳۰ تا ۱۰۰ و نهایتا چقدر بالای صد داریم. در این حالت نمود واقعی‌تری را از وضعیت سیستم موجود می‌بینیم.

وضوح اندازه‌گیری مهم است:

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

در مشاهده بار پردازنده در بازه زمانی یک دقیقه، احتمالا spikeهایی که باعث افزایش latency می‌شوند برایمان نمایان نشوند. و برعکس برای سیستمی که SLO آن ۹۹٫۹ درصد دردسترس بودن در یک سال است، چک کردن میزان پر بودن هارد هر یک دقیقه یک بار، فرکانسی نیست که لازم باشد.

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

این قسمت تا اینجا کافی است و در ادامه به بررسی سیستم هشدار و استانداردهای آن می‌پردازیم.
اگر نظری هم دارید مانند همیشه مشتاق به شنیدنش هستم. :دی