نوشته های حامد نعیمایی

چگونه در پروژه های Large Scale نرم افزاری؛ فشار و استرس خود را کنترل کنیم؟

حامد نعیمایی — Mon, 04 Dec 2023 22:34:28 +0330

مدیریت استرس در بحران هاقطعی یا عدم ارایه سرویس در برخی پروژه های نرم افزاری حتی به اندازه ی چند ثانیه ضررهای مالی و غیرمالی زیادی را می تواند برای سازمان ها ایجاد کند. در چنین پروژه هایی میزان استرس ممکن است نسبت به پروژه های دیگر تا حد زیادی بالاتر باشد، مخصوصا در زمان Down Time.آیا شما آخرین قطعی سرویس جستجوی گوگل را به یاد می آوردید؟یا آخرین قطعی سرویس gmail را به یاد می آورید.البته گاها شاهد Down Time های مقطعی و منطقه ای در برخی از سرویس های مهم و بزرگ در سطح ایران و جهان بوده ایم. مثلا برخی از پیامرسان ها و شبکه های اجتماعی بوده اند که برای دقایقی و ساعاتی دچار قطعی و عدم سرویس دهی به کاربران شده اند.برای پروژه هایی با این سطح از گستردگی جغرافیای و زمانی قطعی سرویس برابر با نارضایتی کاربران و ضررهای مالی خواهد بود، با فرض اینکه مشکل در سطح تیم نرم افزاری باشد، تک تک دقایق از لحظه وقوع این اتفاق حیاتی بوده و مدیریت تیمی و فردی در چنین شرایطی از اهمیت بسزایی برخوردار است.از سوی مقابل در چنین شرایطی قطعا سطح استرس بالا بوده و مدیریت فردی اهمیت پیدا میکند. شاید یکی از تفاوت های یک مهندس سینیور و جونیور کنترل استرس در شرایط بحرانی باشد.من در این ویدیو که با همکاری مجموعه سون لرن تهیه شده است از تجربیاتم در این مورد گفته ام. خوشحال خواهم شد که شما هم از تجریبات و نظراتتون در این حوزه برام بنویسید. در ادامه هم میتونید با من همراه باشید تا با اثرات استرس و راهکارها کنترلش اطلاعات بیشتری کسب کنید. https://www.aparat.com/v/JO5iH قبل از اینکه راهکارها را بررسی کنیم باید استرس را تعریف کنیم و ببنیم چگونه رخ می دهد و چه اثراتی روی موجودات زنده دارد.در برابر شرایط استرس زا، ناگهانی و دشوار محیط اطراف، واکنش هایی در بدن جانداران تکامل یافته، که شانس بقا را افزایش دهد. گورخری زخمی که یک شیر او را تعقیب میکند، ترشح هورمون استرس مجموعه تغییراتی را بدن او ایجاد میکند. برای خون رسانی بهتر تپش قلب افزایش می یابد، فعالیت سیستم گوارشی، معده، و همچنین فرآیندهای طولانی مثل رشد متوقف میشود. سیستم ایمنی بدن نیز در حالت آماده باش است. اکسیژن و گلوکز بیشتری به مغز می رسد تا هوشیاری بالا باشد. برای سبک شدن هنگام فرار، تخلیه غیر ارادی مثانه و حتی روده بزرگ ممکن است اتفاق بیفتد. تولید گلوکز از چربی افزایش پیدا می کند و تولید انسولین قطع می شود. مغز به سلولهای چربی فرمان می دهد که انسولین را نادیده بگیرند. تمامی این واکنشها به بیشترین شدن شانس گورخر زخمی کمک می کند. تفاوت آدمی با حیوانات اینجاست که آدمی نه فقط برای بقا بلکه در اثر عوامل روانی و اجتماعی و حتی در نتیجه فکر کردن هم میتواند استرس را تجربه کند. فرایندی که میتواند مزمن و پرتکرار شود و به راحتی به تغییر تعادل بدن، اصطحلاک سیستم روانی و عصبی، به هم خوردن سیستم تنظیم چربی و قند خون و همچنین قلب و عروق، و بروز بیماریهایی که پیش زمینه آن وجود دارد منجر شود. وجود مستمر هورمون استرس، کورتیزول، سیستم کنترل قند خون و تعادل چربی/گلوکز را به هم میریزد و بسته به ژنتیک و خصوصیات فردی میتواند باعث چاقی یا لاغری شود.فرد ممکن است به انسولین مقاوم شود و بدن برای جبران انسولین بیشتری تولید کند و شانس ابتلا به دیابت را افزایش دهد. زخم معده ناشی از یک نوع باکتری است که بعد از ورود به سیستم گوارشی به تدریج در دیوارههای معده خراشهایی را ایجاد میکند که اسید معده وارد آن میشود.در بسیاری این باکتری منجر به بیماری نمی شود اما استرس یکی از عواملی است که تاثیر بزرگی در شروع زخم معده دارد.این نوشته از این لینک آمده که برگرفته از فصول اول کتاب Stress and Your Body است.بنابراین برای کسانی که در شرایط های استرس زا و بحرانی مشغول به کار هستند کنترل استرس امری بسیار ضروری است. چرا که استرس هم باعث افت کارایی افراد می شود و هم اثرات مخربی بر سلامت انسان خواهد داشت. به طور خاص در پروژه های نرم افزاری اثرات استرس می تواند منجر به مشکلات زیر شود: کاهش تمرکز و خلاقیتافزایش خطاها و اشتباهاتکاهش انگیزه و رضایت شغلیافزایش تعارضات و اختلافاتاختلال در ارتباط و همکاری درستافزایش بیماری‌ها و غیبت‌هاکاهش اعتماد و اعتبارافزایش هزینه‌ها و تاخیرهاو اگر شما با پروژه هایی با مشخصات زیر سر و کار دارید احتمالا در یک محیط استرس زا مشغول به کار هستید:پیچیدگی بالا و تعدد روابط بین اجزای نرم‌افزارنیازمندی‌های متغیر و نامشخصمحدودیت‌های زمانی و هزینه‌ایتعدد و تنوع ذی‌نفعان و انتظارات آن‌هانوآوری و ابتکار فنی و تکنولوژیکرقابت و فشار بازارتغییرات محیطی و قانونی هر فردی باید بررسی کند که کدام یک از مولفه های محیطی و فردی برای وی وجود دارد تا بتواند تا حدی آنها را کنترل کند، البته بخشی از آن به محیط بستگی دارد که سازمان ها و مدیران در آن نقش بیشتری دارند.در ادامه بطور کلی در مورد کنترل استرس در دو سطح سازمانی، مدیریتی و سطح فردی بحث خواهیم کرد.وظایف سازمانی و مدیریتیبرخی نکات در صورتیکه از قبل در سطح سازمان ها و تیم های نرم افزاری رعایت شوند امکان بروز شرایط استرس زا کاهش می یابد اما به صفر نخواهد رسید. وجود نقشه راه و پلن اجرایی برای پروژه ها در جهت تولید سیستم های با کیفیتایجاد فرایند هایی همچون Postmortemداشتن انواع مختلف تست و درصد پوشش مناسبداشتن روش های مدیریت پروژه و مدیریت تسک مدونکنترل سلامت تیم و دریافت فیدبک از اعضای تیمتعیین وظایف و انتظارات بصورت شفاف برای افرادتعیین Deadline واقعی و کارشناسی شدهایجاد فرهنگ سازمانی و تیمی مناسب برگزاری رویدادهایی مانند Team Building در جهت بهبود ارتباطات بین فردی و بین تیمیایجاد توازن بین کار و زندگی برای افراد سازمانایجاد فرهنگ قدردانی در تیم ها و سازمانپرهیز از ایجاد فضای کاری پر فشار تدوین برنامه ها و رویدادهای توسعه فردی در سازمانراهکار های فردیباید بدانیم بخشی از استرس شرایط بحرانی طبیعی بوده و ماهیت شرایط استرس زا اینگونه است در نتیجه حذف کامل هیجان در چنین شرایطی بسیار سخت بوده و هدف ما کنترل شرایط، کاهش استرس و رفع مشکل در سریع ترین حالت ممکن می باشد تمرکز و تسلط : دقیقه 90 فینال لیگ قهرمانان اروپاست و یک ضربه پنالتی برای تیم شما اعلام شده که اگر گل بشه برنده اید. شما اگر طرفدار پروپاقرص باشید کافی ست یک ساعت هوشمند به دست ببندید و ببینید استرس شما در آخرین نقطه اش قرار داره. حالا فرض کنید اون بازیکنی که پشت توپه تا پنالتی بزنه چقدر استرس داره. با توجه به مواردی که از بخش های قبل بهش اشاره کردیم داشتن استرس برای این بازیکن برابر با کاهش بسیار زیاد کارایی بوده که موجب بروز اشتباه در انجام کار می شود و نتیجه ی آن ضرر تیمی و فردی است. شاید در یک سیستم نرم افزاری بزرگ هم با چنین شرایط مشابهی مواجه شویم. وظیفه مدیران تمرکز و تسلط و کنترل تیم و وظیفه اعضا کنترل وضعیت با تمرکز و تسلط بالای روی سیستم می باشد. زمانی که شما تمرکز بالایی دارید می توانید برنامه ریزی کنید، تصمیم درست بگیرید و عمل کنید. پس همیشه به یاد داشته باشید یکی از تفاوت های افراد سینیور و جونیور کنترل شرایط و تمرکز در سخت ترین موقعیت ها می باشد، چرا که در موقعیت های ساده همه ی افراد می توانند تمرکز و تسلط داشته باشند. مهارت افراد در این مورد با تمرین و کسب تجربه افزایش می یابد.برنامه ریزی و تقسیم وظایف: با توجه به محدودیت زمانی ممکن است در چنین شرایطی هماهنگی های تیمی کاهش یابد و در نتیجه برنامه ریزی دشوار خواهد بود. و در صورت عدم برنامه ریزی صحیح ممکن است برخی افراد روی بخش های یکسانی کار کنند یا از ظرفیت همه افراد به درستی استفاده نشود. لازم است افراد سینیور تیم در کنار راهبر تیم کنترل شرایط را در دست گرفته و یک برنامه ریزی مناسب و سریع برای شرایط بحرانی داشته باشند و طبق برنامه ریزی انجام شده و وظایف مشخص به سمت حل مشکلات حرکت کنیم.استفاده از تکنیک های ایجاد آرامش: برای آرام کردن ذهن و بدن خود و کاهش اثرات منفی استرس می توانید از تکنیک آرام سازی یا تمرین ذهن آگاهی استفاده کنید. همانطور که در بخش های قبلی اشاره کردیم در شرایط استرس زا نوع فعالیت بدن برای مقابله با شرایط بحرانی تغییر پیدا می کند و معمولا ضربان قلب بالا می رود. تمریناتی مانند تمرینات تنفسی می تواند به شما کمک کند تا سیستم عصبی خود را آرام کرده و ضربان قلب و فشار خون خود را کاهش دهید. می توانید انواع مختلفی از تمرینات تنفسی مانند تنفس عمیق، تنفس شکمی یا تنفس متناوب از سوراخ بینی را امتحان کنید.فضای حمایتی در تیم: یکی از مواردی که تا حدودی باعث کاهش استرس موجودات زنده در شرایط استرس زا می شود حمایت شدن است. همیشه این جمله را از افراد بزرگ شنیده ایم که در سخت ترین شرایط برخی حامیان روحی موجب شده اند که آنها بتوانند مسیر خود را ادامه دهند. در صورتی که فضای تیم به معنای واقعی حمایتگرانه باشد، هم استرس اعضا کمتر خواهد بود و هم اعضا انرژی بیشتری خواهند داشت. پس سعی کنید یک Supportive team member باشید.کنترل اشتباهات: در شرایط بحرانی به علت عدم وجود تمرکز کافی، امکان رخداد اشتباهات بعدی بسیار محتمل است. پس سعی کنید حالت های محتمل هر راه حل احتمالی را یک بار بررسی نموده و مطمئن شوید این راه حل درست بوده و مشکلات جدیدی ایجاد نخواهد شد.به دنبال مقصر نگردید: یکی از مواردی که در شرایط آشفته و بحرانی اتفاق می افتد این است که افراد به جای تمرکز روی حل مسئله و رسیدن به یک شرایط پایدار به دنبال مقصر می گردند. پیدا کردن مقصر در چنین وضعیتی نه تنها مشکلی را حل نمی کند بلکه در بین اعضای تیم احساس عدم اطمینان و اعتماد به نفس ایجاد می نماید، پس اولویت اول و آخر باید حل مشکل با تمام قدرت باشد.از اتفاقات درس بگیریم: در صورتی که ما از یک اتفاق و اشتباه درس نگیریم آن اتفاق تبدیل به تجربه نخواهد شد، به عقیده بسیاری از روانشناسان، انسان ها معمولا از سخت ترین اتفاقات بزرگترین درس ها را می گیرند. در واقع بین کسب تجربه و سختی اتفاق ارتباط مستقیم وجود دارد، این گزاره بدین معنا نیست که ما سعی کنیم مرتکب اشتباهات بزرگ شویم اما حتما باید از این اشتباهات درس بگیریم و حتی آن را مستند کنیم تا در صورت وقوع اتفاقات مشابه بتوانیم از تجریبات مشابه استفاده نماییم.من در این مقاله سعی کردم تجربیات خود از شرایط استرس زا و بحرانی را با شما به اشتراک بگذارم. امیدوارم این مطلب برای شما مفید بوده باشد و دوست دارم شما هم مواردی که تجربه کرده اید را در بخش نظرات با من به اشتراک بگذارید.

مانیتورینگ سرویس با Prometheus و Grafana - بخش 2

حامد نعیمایی — Wed, 05 Jan 2022 16:10:00 +0330

نحوه ارسال اطلاعات متریک ها به Prometheusدر بخش اول کلیات Prometheus را بررسی کردیم و در این بخش نحوه ارسال متریک ها بررسی خواهد شد و سپس تا حدودی با زبان PromQL آشنا میشیم.نمونه داشبورد وضعیت سرویس هاما یک سرویس با ASP.NET Core نوشتیم (شما میتونید از زبانها یا فریمورک های دیگه استفاده کنید) و از پکیج App-Metrics برای تولید متریک ها استفاده کردیم. این پکیج در زمینه جمع آوری متریک ها و ارتباط با Prometheus و InfluxDB ابزار خوبی هستش، علاوه بر این یک سری متریک در مورد مصرف منابع سرویس هم ثبت میکنه. با توجه به اینکه ساده ترین بخش کار تولید متریک ها در سرویس هستش شما میتونید از هر زبان یا تکنولوژی دیگه ای هم برای تولید متریک ها استفاده کنید و من اصلا اینجا به این مبحث نمی پردازم ولی اگر با ASP.NET Core کار کردید کد های مربوط به ارسال متریک ها به Prometheus رو ببینید. نکته دیگه هم اینکه تا جایی که میتونید ثبت متریک ها رو بصورت Fire and forget بنویسید.ما در ادامه ی مقاله بیشتر به مباحث اصلی Prometheus و Grafana می پردازم. یک نکته ی مهم که باید بهش اشاره کنم اینه که در طراحی سیستم سعی کنید تعداد حالات Label های متریک خیلی زیاد نشه و حالت های اصلی رو نگهداری کنید. مثلا برای نگهداری HTTP Response ها حالت های مهم رو نگهداری کنید. حالا علتش چیه؟فرض کنید برای یک متریک 4 تا Label (Response Code, Endpoint, External Service, Client) قراره ذخیره بشه و هر کدوم از این 4 تا 3 حالت دارن. مثلا برای Response Code ها مقادیر 500، 400 و 200 رو نگهداری میکنیم.برای Endpoint مقادیر صفحه سرچ، صفحه لیست محصولات و صفحه ثبت سفارش رو داریم.برای External Service ها فرضا فروشنده 1 ، فروشنده 2 و فروشنده 3 را خواهیم داشت.برای کلاینت هم، اپلیکیشن موبایل، وب سایت و API را خواهیم داشت. در نتیجه تعداد ماکزیمم حالتی (ترکیب Label ها) که دیتا برای این متریک ذخیره میشه 81 حالت که خوبه، ولی فرض کنید یک Label جدید اضافه میکنیم با 6 حالت ، که در نتیجه افزودن همین یک Label تعداد ماکزیمم حالات ما میشه 480 حالت که رشد زیادی خواهد داشت. در نتیجه باید روی این مسئله دقت کافی داشته باشیم.همونطور که در پاراگرافهای قبل اشاره کردیم برای ثبت متریک ها در Prometheus از یکی از روش های Push و Pull میتونیم استفاده کنیم و اینکه هر کدوم چه مکانیزمی دارن رو اونجا توضیح دادم. روش Pull بار کمتری به سرویس ما وارد میکنه و البته ممکنه چالش هایی در خوندن و نوشتن در فایل متریک به وجود بیاد و همچنین نکته های دیگه هم داره که بحث رو طولانی میکنه و شاید در بخش های بعد بهش بپردازیم.اگه به تصویر معماری Prometheus در بخش اول مراجعه کنید در سمت چپ تصویر میتونید نحوه ورود متریک ها به Prometheus رو ببینید. کد های نحوه ارسال متریک ها که خیلی هم ساده هستن رو اینجا میتونید ببینیددر ادامه در قالب یه مثال کار رو ادامه خواهیم داد. قبلش حتما پروژه رو از گیتهاب Clone کنید و از پوشه Prometheus دستور زیر رو اجرا کنید تا Image ها دریافت و سرویس ها بالا بیاد:docker-compose -f "Prometheus\docker-compose.yml" up -d --build با توجه به اینکه نیازه Image ها دانلود بشن بهتره اینکارو انجام بدید تا وقتی که میرسیم به بخش کوئری ها همه چی آماده باشه، بعد از اجرای کامل که یکم طول میکشه چندتا سرویس براتون میاد بالا:سرویس های بک اند (1 و 2) که قراره متریک های شبه واقعی تولید کنه تا ما براشون نمودار و داشبورد بسازیم. دو نمونه از سرویس روی داکر Run خواهد شد.سرویس Prometheus که دیگه تقریبا باهاش آشنا شدیمسرویس Grafana که برای تولید داشبورد و نمودار ازش استفاده می کنیم. username: admin password: foobarسرویس Alert Manager که برای ارسال هشدارها ازش استفاده میکنیم و یک هشدار ایمیل براش کانفیگ میکنیم و نحوه کانفیگ هشدار پیامکی رو هم توضیح خواهم داد.سرویس Google cAdvisor یک سری متریک برای مانیتورینگ کانتینر ها تولید میکنه که داشبورد و نمودارهای آماده براش زیاد وجود داره و میشه اونها رو در گرافانا Import کرد.کار با Prometheus و زبان PromQLبعد از بالا اومدن سرویس ها از این آدرس وارد رابط کاربری سرویس Prometheus بشید تا با بخش های مختلف و اصلی ش آشنا بشیم:صفحه اصلی Prometheus ، صفحه اجرای کوئری هاصفحه اصلی اجرای کوئری در Prometheusدر این صفحه میتونیم کوئری های مورد نظرمونو بنویسیم و نتیجه اون رو بصورت گراف( Graph Tab) یا ساده (Table Tab) مشاهده کنیم، زمانیکه شما اسم یک متریک رو وارد میکنید تمامی مقادیر اون در لحظه جاری (یا زمانی که مدنظرتون هست) برای شما نمایش داده میشه.صفحه Target، مشاهده وضعیت Target هاصفحه Target ها در Prometheusدر این صفحه Up و Down بودن وضعیت سرویس هایی که Prometheus ازشون دیتا میگیره قابل مشاهده هستش و اگر سرویسی Down باشه علتش اینجا مشخص میشه. نحوه کانفیگ ساده ی یک Target هم طبق این فرمت در فایل Prometheus.yml هستش: https://gist.github.com/naeemaei/8c28c171acc3bbdaae8561fe3b827436 صفحات مربوط به سیستم ارسال هشدار : بخش Alert ها : اینجا لیست هشدار های کانفیگ شده به همراه وضعیت آن ها قابل مشاهده است، هر Alert چند وضعیت دارد که در بخش مربوط به Alerting باهاشون کامل آشنا خواهیم شد.بخش Rule ها : در این قسمت هم شروطی که برای ارسال هشدار کانفیگ شده است و به همراه وضعیت آن ها قابل مشاهده است.زبان PromQLزبان کوئری نویسی در Prometheus اسمش PromQL هستش، فکر میکنم قبلا برای دیتابیس های دیگه کوئری نوشته باشید ولی کوئری نویسی در دیتابیس های Time Serie کمی متفاوت خواهد بود چون ساختار و مدل ذخیره سازی دیتا در این دیتابیس ها متفاوته و اینجا همه چی روی محور زمان میچرخه و چون زمان همیشه در حال حرکت هستش اجرای یک کوئری ثابت در هر لحظه ممکنه نتیجه ی متفاوتی بده. در ادامه با نحوه کار و برخی کوئری ها و توابع مهمش آشنا خواهیم شد. شما هم میتونید هر کدوم از کوئری ها رو در پنل اجرای کوئری بنویسید و نتیجه رو ببینید.توجه: من روی برخی متون لینک گذاشتم که با کلیک بر روی لینک ها میتونید مستقیم کوئری های هر بخش رو ببینید. البته در صورتی که سرویس هایی که گفتیم روی داکر ران شده باشه که اگه نشده برای ران شدن سرویس کار زیادی نیاز نیست انجام بدید و فقط کافیه فایل Docker-compose رو با توضیحاتی که ابتدای همین بخش دادم Up کنید :خروجی کوئری ها: خروجی کوئری ها چند حالت دارد:1- خروجی یک مقدار است مثلا یک عدد: برای نمونه وقتی از توابع Aggregation مانند Sum یا Increase استفاده میکنیم خروجی میتواند یک عدد باشد. مثال آن هم مجموع تعداد درخواست ها یا مجموع زمان پاسخ درخواست ها می باشد. برای مشاهده اجرای کوئری کلیک کنیدخروجی تک مقداری2- خروجی یک بردار یا مجموعه است: نمونه ای از این خروجی را در زمانهایی که مقدار کلی متریک ها را با لیبل های مختلف یا بر اساس یک گروه بندی خاص میگیریم میتوانیم مشاهده کنیم، مثلا: تعداد درخواست بر اساس نوع پاسخ سرور (تعداد موفق، تعداد ناموفق، تعداد دارای خطا و...). برای مشاهده اجرای کوئری کلیک کنیدخروجی چند مقداریکوئری ساده: ما میتونیم اسم متریک رو مستقیم در پنل کوئری یا در گرافانا وارد کنیم که در این صورت بر اساس نوع متریک خروجی به ما نمایش داده خواهد شد. ما در این پروژه دو متریک اصلی داشتیم (application_request_duration و application_request_counter)ما میتونیم با وارد کردن اسم متریک در باکس کوئری ببینیم آخرین مقدار application_request_duration چقدر بوده و یا تعداد رخداد application_request_counter چند تا بوده. البته این مدل کوئری خیلی به کار نمیاد و خروجی که میده مفید نخواهد بود ولی لازم بود که بدونیم.application_request_counterاعمال شرط روی کوئری: برای اعمال شرط روی کوئری باید بعد از اسم متریک توی یک {} شروط رو بنویسیم:application_request_counter{instance="ex1-web-api:80",service="Shopping1"} شرطهایی مثل not یا in هم خیلی شبیه همین شرط هاست، این یک مثال از not هستشapplication_request_counter{instance!="ex1-web-api:80",service!="Shopping1"}یا برای اعمال شرط چندتایی (in, not in)روی یک Label این مثال رو ببینید:application_request_counter{endpoint=~"product-detail-page|register-order",responsecode!~"400|401|403"} برای اینکه بیشتر با این نوع کوئری ها آشنا بشید میتونید اینجا رو ببینید.اعمال بازه زمانی روی کوئری: گاهی اوقات نیاز داریم که نتیجه یک کوئری را در n دقیقه (ثانیه یا ...) اخیر بدست بیاوریم، برای مثال مجموع تعداد درخواست ها در 5 دقیقه اخیر، یا میانگین زمان پاسخ در 30 ثانیه اخیر:ceil(sum(increase(application_request_counter[5m])))اعمال Offset زمانی روی کوئری: گاهی هم نیاز داریم نتیجه یک کوئری را در زمان های غیر از زمان جاری ببینیم، مثلا تعداد درخواست ها روز گذشته و همین ساعت و دقیقه تا 5 دقیقه قبلش را بدست بیاوریم.ceil(sum(increase(application_request_counter[5m] offset 1d)))این مدل کوئری ها در زمانهایی که نیاز داریم وضعیت سیستم را نسبت به زمان مشابه در روز گذشته، هفته گذشته، ساعت گذشته یا ماه گذشته را مقایسه کنیم خیلی بدرد بخور خواهد بود، برای مثال کوئری زیر نشون میده که درصد افزایش یا کاهش تعداد درخواست در 5 دقیقه اخیر نسبت که زمان مشابه در یک ساعت اخیر چقدر بوده (مثلا مقایسه تعداد درخواست از ساعت 11:02 الی 11:07 با ساعت 10:02 الی 10:07) و ما میتونیم بجای یک ساعت از یک روز استفاده کنیم و همیشه وضعیت سیستم رو نسبت به زمان مشابه روز گذشته، هفته ی گذشته و حتی ماه گذشته و بیشتر هم بسنجیم.( ceil(sum(increase(application_request_counter[5m]))) - ceil(sum(increase(application_request_counter[5m] offset 1h))) ) / ceil(sum(increase(application_request_counter[5m]))) * 100اعمال گروه بندی روی کوئری: گاهی لازمه مجموع یا میانگین یک متریک رو بر اساس یک Label خاص بسنجیم، برای نمونه تعداد درخواست ها در کلاینت های مختلف (تعداد درخواست های Mobile Application و وبسایت بصورت جداگانه)ceil(sum by (application)(increase(application_request_counter[5m])))برخی توابع به درد بخور مثل sum، increase، rate، grouping و... داریم که در بخش بعدی که داشبورد طراحی میکنیم با برخی از اینها سر و کار خواهیم داشت و باهاشون آشنا خواهیم شد.در قسمت های بعد موارد زیر را بررسی میکنیم:1. طراحی داشبورد در گرافانا برای متریک ها و دیتای تولید شده2. کار با AlertManager و ارسال هشدار از طریق ایمیل و اس ام اس

مانیتورینگ سرویس با Prometheus و Grafana - بخش 1

حامد نعیمایی — Wed, 01 Sep 2021 09:33:38 +0430

امروزه پایش لحظه ای سرویسهای نرم افزاری و اعلام سریع مشکلات به وجود اومده به گروه هدف (یه چیزی شبیه سیستم های اعلان خطر) جز بخش بسیار مهم سرویس های نرم افزاری هستش چرا که تشخیص سریع مشکل باعث صرفه جویی در وقت و هزینه مالکان و ذینفعان سرویس خواهد شد. البته سیستم های مانیتورینگ مزایای خیلی بیشتری هم دارند که در ادامه باهاشون روبرو خواهیم شد.نمونه داشبوردی که قراره بسازیم کارهایی که در طی این مقاله انجام میدیم اینطوریه که قراره چند تا instance از یه Web API بیاریم بالا و یه سری Metric شبه واقعی برای مانیتورینگ سرویسمون تعریف کنیم، بعدش اونها رو بفرستیم روی Prometheus (در واقع Prometheus اونها رو از ما بگیره و ذخیره کنه) و به کمک Grafana یه سری داشبورد مانیتورینگ برای سرویس(ها) بسازیم. برای اینکه شما درگیر راه اندازی سرویس ها نشید و بعد از مباحث ابتدایی بریم سراغ کوئری و داشبوردهای Prometheus کافیه فایل docker-compose رو بالا بیارید و اتفاقاتی که افتاده رو ببینید، البته سورس کل کارها و توضیحات مراحل کار هم اینجا نوشته میشه که برای درک بهتر کارهای انجام شده میتونه کمک کنه.همه چیزهایی که گفتم توی گیتهاب این مقاله گذاشتم و میتونید ببینید و اگر براتون مفید بود بهش ستاره بدید.git clone https://github.com/naeemaei/MonitoringExampleبعد از دریافت سورس از گیت با این دستور از روت پروژه، سرویس ها pull و run خواهند شد. اگه مشکلی با docker-compose داشتید این لینک رو ببینیدdocker-compose -f "Prometheus\docker-compose.yml" up -d --buildبه چه ابزارهایی نیاز داریم؟1- VS Code2- Dockerدر طی این مجموعه مقالات با موارد زیر آشنا خواهیم شد:آشنایی با Time Serie Databases با محوریت Prometheusنحوه ارسال اطلاعات متریک ها به Prometheusکار با Prometheus و تا حدودی زبان Promqlکار با Alerting و ارسال هشدار به سرویس های ثانویهکار با Grafana و ساختن داشبورد روی یک مسئله شبه واقعی نزدیک به دنیای واقعیآشنایی با Time Serie Databasesمن راجع به دیتابیس های Time Serie مثل Prometheus و InfluxDB و شبیه اینها زیاد نمینویسم چون راجع بهشون مقاله زیاد نوشته شده ولی به یک سری مسائل اصلی در موردشون اشاره میکنم، البته با محوریت Prometheusبرای چه کارهایی و چه نوع دیتاهایی ازشون استفاده میکنیم؟قبل از اینکه یکم بحث رو فنی کنیم لطفا به این دو تا مثال توجه کنید:به ساعت هوشمندی که دارین دقت کنید، اونها ضربان قلب شما رو در هر لحظه نشون میدن، حالا اگر بخوایم مقادیر ضربان رو در بازه زمانی طولانی مدت ذخیره کنیم (مثلا یک ماه)، باید در چه ساختاری ذخیره کنیم؟ یک بُعد اصلی به نام زمان داریم (Key) و یک مقدار داریم به نام تعداد ضربان (Value). در واقع در یک زمان مشخص یک مقدار برای تعداد ضربان وجود داره. احتمالا شما رو به یاد یکی از ساختارهای نگهداری داده میندازهعلاوه بر این شاید بخوایم یک سری اطلاعات دیگه رو در کنارش نگهداری کنیم، مثلا شهری که الان توش هستیم، و اینکه در چه حالی هستم (خواب، بیداری، پیاده روی، ورزش)و در پایان هم میخوایم گزارش تهیه کنیم یا ماینتور کنیم:1. میانگین ضربان قلب اون فرد در یک شهر ساحلی یا در یک شهر کوهستانی چقدر هستن.2. نرخ کاهش یا افزایش ضربان قلب در ساعات شروع خواب، عمق خواب و پایانی خواب به چه صورت هستن.3. نرخ ضربان قلب در یک ساعت اخیر چقدر بوده است.امروزه ساعت های هوشمند و حتی گوشی ها قدم های شما را هم ثبت می کنند و به شما گزارش می دهند در طول یک روز چند قدم برداشتید.به چه روشی این دیتا ها رو ذخیره کنیم که بتونیم هم روی این اطلاعات مانیتورینگ انجام بدیم و هم گزارشاتی مانند مواردی که بالا گفتم رو تهیه کنیمآیا RDBMS های مثل MySQL و MSSQL برای نگهداری و گزارش گیری این نوع اطلاعات مناسب هستند؟ در واقع Time Serie Database ها برای چنین استفاده هایی طراحی و بهینه سازی شده اند و Prometheus یکی از اونهاست.دقیقا چه اطلاعاتی در Prometheus ذخیره میشود؟ 1 - نام متریک مثلا ضربان قلب2 - زمان ذخیره سازی مثلا 17:45:46.125 2021/07/143 - چه اطلاعات اضافه ای در کنارش ذخیره می شود؟ مثلا شهر، وضعیت فرد (خواب، بیدار و...). به مواردی که در کنار متریک ذخیره می شوند Label یا Tag میگیم.4 - مقدار متریک، مثلا 103بطور خلاصه میشه گفت برای یک Value علاوه بر زمان یک سری Tag یا label هم میشه ذخیره کرد.2021/07/14 14:17:25.1000 => heart_rate{city=”shiraz",state=”sleep”} 103Metric Name: heart_rate (ضربان قلب)Timestamp: 2021/07/14 14:17:25.1000 (زمان ثبت مقدار متریک)Tags: city, stateValue: 103ضربان قلب در تاریخ 2021/07/14 14:17:25.1000 در شهر شیراز و وضعیت خواب 103 ثبت شده است.در کل باید گفت در Time Serie Databases محور اصلی و کلید زمان هستش، به این تصویر توجه کنید:نمونه ای از دیتای ذخیره شدههمونطور که در این تصویر میبینید، ما یه سری نقطه زمانی داریم از t0 تا t6 که در هر کدوم از این زمان ها اطلاعات متریک ها ذخیره میشه، مثلا تعداد درخواستهای سرچی که تا لحظه t3 وارد اپلیکیشن اندروید شده (سطر اول از پایین) 18 تا هستش که تا زمان t5 این عدد به 22 میرسه یعنی در (t5 - t3) ثانیه 5 تا درخواست سرچ جدید روی سرویس اندروید اومده. یه نکته هم که اهمیت داره بدونید اینه که در Prometheus یه مفهومی داریم به اسم Scrape که با کانفیگ کردن اون مشخص میکنیم اطلاعات متریک ها هر چند ثانیه از Exporter ها گرفته بشه و ذخیره بشه. حالا باید ببینیم Exporter ها چیا هستن؟ اما قبلش معماری کلی رو ببینیم:معماری Prometheusسرویس Prometheus به دو روش دیتای متریک ها رو جمع آوری و ذخیره مکینهروش Pull: در این روش هر سرویسی که قراره اطلاعات متریک هاشو در اختیار Prometheus قرار بده به عنوان یک Exporter معرفی میشه و مقادیر متریک ها رو در یک قالب مشخص ایجاد میکنه و Prometheus در بازه های مشخصی اطلاعاتشو میخونه (Scrape) و ذخیره میکنه. روش Push: در این روش هر سرویس مقادیر متریک هاشو برای Pushgateway میفرسته و Prometheus با Pushgateway هم مثل یک Exporter برخورد میکنه و اطلاعات رو در بازه زمانی مشخص ازش میخونه. البته ما در این پروژه از روش Pull استفاده خواهیم کرد.نکته جذاب تر اینه که کتابخانه های جانبی زیادی وجود دارند که برای انواع مختلف سرویس ها Exporter ارائه میکنند. مثلا شما اگر بخواین از بخشی اطلاعات موجود در MSSQL در Prometheus استفاده کنید میتونید سرچ کنید و Exporter مناسب رو پیدا کنید، یا اگر بخواین سیستم عامل ویندوز رو مانیتور کنید میتونید از Windows Exporter استفاده کنید. تقریبا برای اکثر سرویس های مهمی که میشناسید Exporter وجود داره و میشه به سادگی به Prometheus متصلش کرد.یکی از بخش های دیگه Alertmanager هستش که وظیفه ی ارسال هشدار ها از طریق ایمیل، اسلک، اس ام اس و... رو داره.پرومتئوس از Service Discovery برای شناسایی Target ها و بررسی up یا down بودن اونها استفاده میکنه که امکان Integrate شدنش با Kubernetes، Consul وجود داره.از ابزارهایی مثل Grafana هم برای نمایش اطلاعات روی نمودار و داشبورد استفاده میشه. Prometheus یه HTTP Server هم داره که از طریق اون کوئریها رو دریافت میکنه و خروجی مورد نیاز رو به گرافانا یا هر API دیگه ای ارائه میده، این کوئری ها به زبان PromQL هستن که در ادامه باهاش آشنا میشیممتریک ها چند نوع هستن: Counter، Gauge، Histogram و Summariesیک. Counter یک شمارنده ست که مقدارش در گذر زمان افزایش پیدا میکنه، برای مثال تعداد درخواستها وارد شده به سرویس به ازای هر درخواست جدید که وارد سرویس میشه یک واحد افزایش پیدا میکنه. مقادیر یه شمارنده همیشه افزایشی است: 1-2-3-4-5-6-7-8-9-10..... # TYPE application_request_counter gauge application_request_counter{endpoint="product-detail-page",responsecode="200"} 532مثال بالا به این معناست که برای Endpoint جزئیات محصول با پاسخ 200 تا این لحظه 532 تا درخواست وارد سیستم شده و زمانی که درخواست جدیدی بیاد میشه 533دو. Gauge برای نگهداری مقادیر عددی متغیر استفاده میشه، مثل مصرف CPU در یک زمان خاص یا مدت زمانی که صرف اجرای یک درخواست میشه: 450-320-470-1250-125-400# TYPE application_request_duration gauge application_request_duration{endpoint="product-list-page"} 845مثال بالا هم به این معناست که مدت زمان اجرای یک درخواست نمایش محصولات 845 میلی ثانیه است.سه و چهار. Summary و Histogram متریک های ترکیبی هستند، یعنی اگر بخوایم مقدار یک متریک رو بسنجیم هم تعدادش (count) رو ثبت میکنه و هم مجموع رخداد (sum) این متریک ثبت میشه. که داشتن این دو مقدار به ما برای رسیدن به میانگین اون متریک کمک میکنه، فرض کنید ما تعداد درخواستها رو داریم و در کنارش مجموع Response Time درخواست ها هم هست و با کمک این دوتا مقدار میتونیم به میانگین زمان پاسخ درخواست ها برسیم. حالا تفاوت کجاست.در Histogram میتونیم در کنار موارد بالا، مجموع تعداد درخواست در دسته های مختلف را هم داشته باشیم، مثلا تعداد درخواستهایی که زمان پاسخ کمتر از 50 میلی ثانیه بوده، تعداد درخواستهایی که زمان پاسخ کمتر از 180 میلی ثانیه و...# TYPE application_request histogram application_request_bucket{le="50"} 502 application_request_bucket{le="100"} 954 application_request_bucket{le="180"} 1166 application_request_bucket{le="250"} 1296 application_request_bucket{le="400"} 1383 application_request_bucket{le="800"} 1424 application_request_bucket{le="2000"} 1429 application_request_bucket{le="+Inf"} 1429 application_request_sum 25465 application_request_count 1429در Summary هم مجموع و تعداد رو داریم اما در کنارش یه دسته بندی کمی (quantile) هم داریم که با عددی بین صفر و یک نشون میدیم که تا هر دهک درصدی میانگین زمان پاسخ سرویس چقدره، یکم تعریفش گنگ بود با یک مثال فهمش راحت تره. یک نمونه از Summary برای میانگین زمان پاسخ به این شکل هستش که مثلا ثبت میکنیم میانگین زمان پاسخِ 50 درصد درخواستها حدود 114 میلی ثانیه هستش و میانگین زمان پاسخِ 95 درصد درخواست ها 146 میلی ثانیه.# TYPE application_request_duration summary application_request_duration_sum{app="MonitoringExample.Api"} 95743 application_request_duration_count{app="MonitoringExample.Api"} 1429 application_request_duration{app="MonitoringExample.Api",quantile="0.5"} 114 application_request_duration{app="MonitoringExample.Api",quantile="0.75"} 132 application_request_duration{app="MonitoringExample.Api",quantile="0.95"} 146 application_request_duration{app="MonitoringExample.Api",quantile="0.99"} 152توضیحات تکمیلی و مثالهایی از این متریک ها را در قسمتهای بعد سعی میکنم اضافه کنم.شما بعد از اجرا شدن دستور docker-compose میتونید سرویس ها رو در مرورگر ببینید. اینجا لینک هر سرویس و اطلاعات جانبی برای ورود رو گذاشتم که برای مشاهده داشبورد اولیه لازمه وارد پنل گرافانا بشید. وقتی وارد پنل گرافانا شدید در داشبورد my api dshboard میتونید نمودارهایی که قراره بسازیم رو ببینید تا در قسمت های بعد نحوه ساختن هر کدوم رو توضیح بدیم.در قسمت های بعد موارد زیر را بررسی میکنیم: نحوه ارسال متریک ها به Prometheusبررسی سرویس هایی که قراره بیاریم بالاکار با Prometheus و زبان PromQLطراحی داشبورد برای متریک ها و دیتای تولید شدهکار با AlertManager و ارسال هشدار از طریق ایمیل و اس ام اسبخش دوم : نحوه کار Prometheus و کوئری نویسی در آن

الگوی Circuit Breaker در طراحی نرم افزار

حامد نعیمایی — Fri, 03 Apr 2020 00:51:50 +0430

Circuit Breaker در دنیای الکترونیکمقدمهاز سالهای گذشته استفاده از معماری مایکروسرویس به علت مزایایی که برای سیستم های بزرگ دارد در حال افزایش است، یکی از مسائلی که بیشتر در این معماری و معماری های توزیع شده حائز اهمیت است ارتباط بین سرویس ها می باشد.در معماری Monolith با توجه به اینکه کل سرویس روی یک ماشین اجرا می شود، ارتباط بین بخش های مختلف سرویس بصورت In-Memory Call می باشد و یا همیشه کل سرویس در دسترس است یه بالعکس. اما زمانی که معماری متفاوت باشد سرویس ها روی ماشین های مختلف شبکه قرار دارند و ارتباط بصورت Remote Call می باشد که تعامل بین سرویس ها در سطح ارتباطات شبکه ای انجام می شود. تفاوت مهم این دو نوع ارتباط این است که ارتباطات Remote می توانند Fail شوند یا اینکه در زمان مشخص شده پاسخی دریافت نشوددر معماری مایکرو سرویس یک سرویس ممکن است دچار مشکل شده باشد و در دسترس نباشد (Unavailable) یا مشکلی در سطح شبکه ی آن سرویس باشد، در نتیجه سرویس به درخواست ها پاسخی نمی دهد.در صورت بروز هر یک از این اتفاقات سرویسی(مثلا A) که منتظر دریافت پاسخ است و درخواست های زیادی را ارسال کرده است که منتظر پاسخ هستند و لحظه به لحظه به تعداد این درخواست ها افزوده می شود، در نتیجه میزان استفاده از منابع به علت تلنبار شدن درخواست های زیاد منتظر پاسخ، بالا می رود و اگر این اتفاقات بصورت زنجیره ای رخ دهد و سرویس(های) دیگری مثل B و C منتظر پاسخ سرویس A باشند، همه سیستم های این زنجیره ممکن است که دچار مشکل منابع شوند. مثال : فرض کنید شما در یک فروشگاه پس از صدور فاکتور توسط فروشنده از طریق دستگاه کارتخوان اقدام به پرداخت صورتحساب می کنید. پس از اینکه کارت می کشید سرویس کارتخوان(A) سعی می کند درخواست را برای Provider خود (سرویس B) ارسال کند و Provider هم پس از دریافت درخواست آن را برای سرویس پرداخت نهایی (سرویس C) ارسال خواهد کرد و منتظر پاسخ می ماند، حال فرض کنید سرویس پرداخت نهایی Down می باشد یا به هر علتی هیچ پاسخی به درخواست ها نمی دهد.چه اتفاقی رخ خواهد داد ؟کاملاً مشخص است که پرداخت شما Failed می شود. اما اتفاق مهم تری که رخ می دهد این است که درخواست های زیادی که از کارتخوان های مختلف سطح کشور به سرویس B آمده اند، از سرویس B به سرویس C ارسال می شوند بدون اینکه پاسخی از سرویس C دریافت کنند و پس از طی مدت زمان مشخصی Timeout می شوند، البته با استفاده از الگوهایی مانند Retry Pattern می توان برای دفعات دیگری درخواست را ارسال کرد تا نتیجه حاصل شود، اما اگر سرویس C بعلت رخداد مشکل پیش بینی نشده ای برای مدتی نامشخص در دسترس نباشد چه اتفاقی خواهد افتاد؟ درخواست های زیادی در سرویس B در صف می مانند که مثلا موجب باز ماندن کانکشن های زیاد به دیتابیس(در صورت عدم مدیریت)، ایجاد Thread های زیاد و در نتیجه مصرف منابع سرویس B شروع به بالا رفتن می کند و در نتیجه امکان Down شدن سرویس B محتمل تر خواهد بود و ما بخش دیگری از سیستم را از دست خواهیم داد.مفهوم Cascading Failure چیست؟
زمانی است که قسمتی از سیستم (یکی از سرویس ها) از کار می افتد و این Failure به مرور زمان موجب ایجاد خطا و Failure در سیستم های دیگر خواهد شد. این مسئله ممکن است در هر سیستمی رخ دهد و مختص سیستم های نرم افزاری نمی باشد حتی در بدن انسان اگر یک عضو دچار عدم کارکرد یا نارسایی شود ممکن است باعث از کار افتادن سایر بخش ها شود.منبع : https://en.wikipedia.org/wiki/Cascading_failureدنیای نرم افزار برای رخداد چنین مشکلی حتما باید یک راه حل داشته باشد، به همین دلیل مهندسین کامپیوتر مشابه راه حل موجود در دنیای واقعی را در دنیای نرم افزار پیاده سازی کردند.راه حل چیست؟الگوی طراحی Circuit Breaker راه حل این مشکل است، اما چگونه؟قطع کننده های مدار و دستگاههای محافظ برق لوازم الکتریکی را به یاد بیاروید، وقتی که جریان برق دچار نوسان می شود جریان برق به لوازم الکتریکی را قطع می کنند و تا زمانی که ولتاژ به وضعیت استاندارد نرسد جریان را وصل نمی کند. حتی زمانی که جریان به وضعیت استاندارد رسید، دستگاه محافظ بعد از چند دقیقه تست، اعلام وضعیت نرمال کرده و اتصال دستگاه به جریان برق را برقرار میکنند. عملکرد Circuit Breaker چیزی مشابه سناریوی فوق می باشد.دستگاه محافظ برقزمانی که در Failure های متوالی از یک سرویس دریافت می شوند و این Failure ها از یک Threshold عبور می کند Breaker وارد عمل می شود. اما Breaker چه کارهایی انجام می دهد.بعد از عبور تعداد خطا ها از آستانه تعیین شده، تمامی درخواستهایی که به سرویس دارای خطا ارسال می شوند بلافاصله با یک خطا یا یک نتیجه عمومی پاسخ داده می شود و جریان ارسال درخواست به سرویس مشکل دار موقتا قطع می شود. ( Breaker در وضیعت Open قرار می گیرد)این قطع ارتباط تا چه زمانی ادامه دارد؟ تا زمانی که سرویس به وضعیت Stable باز گردد.زمانی که سرویس به وضعیت مناسب برگردد Breaker به حالت Half-Open می رود و شروع به تست سرویس می کند که آیا مشکل سرویس همچنان پا برجاست یا برطرف شده است؟ زمانیکه همه چیز به حالت نرمال برگشته باشد Breaker به حالت Closed می رود و تمامی Request ها اجازه می یابند به سرویس ارسال شوند و این چرخه ادامه خواهد یافت.https://martinfowler.com/bliki/CircuitBreaker.htmlاستفاده از این الگو باعث می شود که زمانی که یک قسمت یه سیستم دچار مشکل شده است یا موقتا Down شده است بقیه قسمت های سیستم بکار خود ادامه دهند و مشکل Cascading Failure رخ ندهد.پیاده سازی Circuit Breaker را می توان بصورت Central در سطح Gateway یا برای هر سرویس پیاده سازی کرد، که بنا بر استفاده و نیاز هر سازمان مزایا و معایبی دارد که می توان به موارد زیر اشاره کرد:اگر بصورت متمرکز پیاده شود، نیاز نیست هر تیم بصورت جداگانه روی پروژه های خود پیاده کند. اگر بصورت متمرکز پیاده شود، نیاز نیست اعضای هر تیم دانشی برای پیاده سازی آن داشته باشند.اگر بصورت متمرکز پیاده شود، و سرویس مرکزی از کار بیفتد کل سیستم به فنا می رود.اگر جداگانه پیاده شود، و اگر تیم ها و سرویس ها با تکنولوژی های مختلفی پیاده سازی شده باشند، پیچیدگی کار، Learning Curve ایجاد شده برای Developer های هر سرویس قطعا بیشتر خواهد بود.برای آشنایی بیشتر می توانید لینک های زیر را مشاهده کنید:https://github.com/Netflix/Hystrix https://github.com/afex/hystrix-go/https://github.com/sony/gobreakerhttps://github.com/Travix-International/Hystrix.Dotnethttps://github.com/danielfm/pybreakerhttps://github.com/yammer/circuit-breaker-jshttps://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/implement-circuit-breaker-pattern