توی قسمت چهارم مسیر Observability میریم به سراغ حضرت پرومتئوس!
خب یه مروری کنیم پست‌های قبلی رو:
توصیه میکنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
چیه و چرا لازمش داریم
پرومتئوس یک ابزار متن باز مانیتورینگ و آلرتینگ هست که توسط کمپانی soundcloud معرفی شد. از شروعش توی سال ۲۰۱۲ کمپانی ها و سازمان‌های زیادی پروژه هاشون رو بردن سمت پرومتئوس و باعث شد که کامیونیتی قوی و بزرگی برای این ابزار شکل بگیره و توی سال ۲۰۱۶ پرومتئوس به عنوان دومین ابزار بعد از کوبرنتیز وارد CNCF شد. پرومتئوس ابزاری هست که متریک هارو به صورت دیتای time series جمع آوری و ذخیره میکنه.
برخی از ویژگی های پرومتئوس:
متریک‌ها اندازه‌گیری‌هایی هستن که ما میخوایم توی سیستم مون انجام بدیم و اونها رو به صورت عددی بیان کنیم. اینکه متریک دقیقا چیه میتونه توی اپلیکیشن‌های مختلف متفاوت باشه مثلا توی یه وب سرور ممکنه زمان ریکوئست‌ها متریک باشه یا توی یک دیتابیس تعداد کانکشن‌ها یا تعداد کوئری‌ها میتونه متریک باشه. متریک نقش مهمی توی فهمیدن عملکرد اپلیکیشن دارن.
دیتای تایم‌سریز یا "Time Series Data" به داده‌هایی اشاره دارد که به طور مداوم در طول زمان جمع‌آوری می‌شوند و هر نقطه داده مربوط به زمان خاصی است. این داده‌ها به طور معمول در زمان‌های منظم گردآوری می‌شوند و معمولاً برای مانیتورینگ، تحلیل و پیش‌بینی‌های زمانی استفاده می‌شوند.
مثال‌هایی از داده‌های تایم سریز شامل اطلاعات سنسورها (مانند دما، فشار، رطوبت)، داده‌های مالی (قیمت‌های سهام، نرخ ارز)، داده‌های شبکه (ترافیک شبکه) و داده‌های زیرساخت (مانند بار CPU و حافظه) می‌شوند.
بسته به دیتایی که داریم ممکنه میانگین، جمع، مینیمم، ماکسیمم یا تعداد اون دیتا بهمون اطلاعاتی رو بده که بتونیم ازش توی Observability استفاده کنیم.
به طور کلی دو تا روش برای جمع آوری دیتای مانیتورینگ هست روش push و pull که در روش push کامپوننت کالکتور که دیتا رو جمع میکنه اون رو میفرسته سمت سرویس مانیتورینگ و در روش pull خود سرویس مانیتورینگ میره و دیتا رو از کالکتور میگیره که هرکدوم مزیت خودشون رو دارن که در جدول پایین میتونید ببینید:
اکسپورتر کامپوننتی هست که روی هاست‌مون اون رو بالا میاریم و متریک‌ها رو استخراج میکنه و اونها رو آماده میکنه برای پرومتئوس مثلا node-exporter به صورت دیفالت روی پورت ۹۱۰۰ بالا میاد و متریک هارو برای ما expose میکنه و ازونجا که پرومتئوس از روش pull استفاده میکنه، بنابراین پرومتئوس تلاش میکنه که از تارگت‌های خودش دیتا رو جمع‌آوری کنه. اصطلاحا pull بیس هستش.
قسمت اصلی این استک که سه تا کار مهم رو برای ما انجام می‌دهد. یکی نگهداری دیتا داخل TSDB داخل خودش و دومین موضوع هم گرفتن و پول کردن متریک‌ها طبق اینتروال مشخصی که براش تعیین میکنیم. و سومین موضوع هم رول‌ها به همراه اینترفیسی که در اختیار ما قرار میده.
برخی ابزارها هستن که متریک هاشون رو push میکنن، اگه بخوایم با استک پرومتئوس اونها رو مانیتور کنیم از کامپوننت pushgateway استفاده میکنیم تا اول متریک‌هارو توی اون پوش کنن و بعد پرومتئوس بتونه از pushgateway دیتا رو pull کنه. مثلا فکر کنید شما تو یه Private zone هستید که از بیرون به شما دسترسی نیست ولی شما امکانش رو دارید و به بیرون اکسس دارید. به نوعی اکسس یه طرفه دارید اینجا میتونید خودتون متریک‌ها رو پوش کنید و از این ابزار برای آن استفاده کنید.
این کامپوننت در کنار پرومتئوس و ترکیبش با آن به ما امکان آلرتینگ می‌دن. تو این استک داخل پرومتئوس رول‌های آلرت نوشته میشه. مثلا اینکه رم یه سرور از ۸۰ درصد بیشتر داره استفاده میشه یا اینکه دیسک ۸۰ درصد از ظرفیتش پر شده. پس داخل خود پرومتئوس ما میایم آلرت رول تعریف میکنیم که بر اساس اون رول‌ها آلرت‌ها فایر می‌شوند و بعدش آلرت‌های فایر شده دست آلرت منیجر می‌رسه که وظیفه‌ی اطلاع دادن آلرت‌ها یا اصطلاحا نوتیف کردن آنها بر عهده‌ی آلرت منیجر می‌باشد. آلرت منیجز با استفاده از کانفیگ‌هایی که داره آلرت‌ها رو بر اساس اولیوت و گروهی که دارند برای جایی که باید ارسال میکنه.
Grafana
ابزار قدرتمندی هست که توی استک پرومتئوس معمولا برای نمایش دیتا ازش استفاده میکنیم و کلی ابزار جانبی دیگه هم داره که در ادامه توی پست‌های بعدی معرفی شون میکنم.
پرومتئوس رو خیلی ساده با یه کانتینر داکر از ایمیج prom/prometheus میاریم بالا و مسیر prometheus/ رو که دیتا توی اون قرار داره و مسیر etc/prometheus/ که توی اون فایل yaml کانفیگ پرومتئوس قرار میگیره رو توی والیوم میذاریم و پورت ۹۰۹۰ که پورت دیفالت پرومتئوس هست رو پابلیش میکنیم.
فایل کانفیگ پرومتئوس سه تا قسمت اصلی داره:
توی قسمت گلوبال کانفیگ های کلی پرومتئوس مثل interval بین زمان هایی که دیتای اکسپورتر رو بگیره یا اینتروال بین زمان هایی که rule ها رو چک کنه، مینویسیم.
توی این قسمت آدرس فایل‌هایی که میخوایم پرومتئوس از اونها rule ها رو بخونه، مینویسیم.
توی این قسمت برای پرومتئوس ریسورس‌هایی رو که میخوایم پرومتئوس مانیتور کنه وارد میکنیم، هر منبعی که ازش دیتارو میگیره رو به عنوان یک جاب بهش معرفی میکنیم و پرومتئوس حتی میتونه وضعیت خودش رو هم مانیتور کنه. پرومتئوس به صورت دیفالت در مسیر metrics/ از آدرسی که بهش دادیم دیتا رو میگیره. البته این مسیر پیش‌فرض هست و میتونه تو مسیرهای دیگه باشه که تو کانفیگ میتونید آدرس‌دهی کنید. اگر چیزی اینجا قرار ندید به صورت پیش فرض مسیر metrics/ رو قرار میده.
کتابخانه های پرومتئوس چهار نوع اصلی دیتا رو معرفی میکنن که از اینها بیشتر سمت کلاینت و برای API ها و wire protocol استفاده میشه و با دیتا داخل پرومتئوس سرور به صورت دیتای بدون تایپ و time series رفتار میشه.
یک نوع دیتای تجمعی رو نشون میده که مقدار اون فقط میتونه افزایش پیدا کنه یا در صورت ریست شدن، برگرده به عدد صفر. برای مثال از این تایپ میتونیم برای تعداد درخواست‌هایی که پاسخ داده شده یا تعداد تسک هایی که کامل شده یا تعداد ارورها استفاده کنیم. از کانترها برای دیتایی که مقدارش میتونه کاهش پیدا کنه استفاده نکنید چون این کار رو نمی‌تونه برای شما انجام بده.
گِیج نوعی از دیتا هست که به صورت مقدار عددی که میتونه بالا یا پایین بره ذخیره میشه. معمولا از گِیج برای دما، میزان مصرف مموری و همچنین کانت‌هایی که میتونن کم هم بشن مثل تعداد ریکوئست های در لحظه، استفاده میشه.
معمولا برای متریک‌هایی مثل زمان پاسخ به ریکوئست یا اندازه ریسپانس ازین نوع استفاده میکنیم با هیستوگرام میتونیم دیتا رو به صورت جمع مقادیر در بازه های زمانی مشخص داشته باشیم.
شبیه هیستوگرام هست و موارد مثل مجموع کل یا مثلا مشخص کردن نمونه ای که بیش از پنجاه درصد مواقع تکرار شده و موارد مشابه رو هم ارائه میده.
به هر سورسی که پرومتئوس اون رو scrape میکنه یک اینستنس میگیم و مجموعه ای از اینستنس‌ها با هدف مشابه رو بهش میگیم یک جاب.
پروتکل remote write طراحی شده تا امکان انتقال سمپل‌های دیتا رو از یک فرستنده به گیرنده به صورت real time و بدون دیتا لاس بهمون بده. با استفاده از اون میتونیم پرومتئوس رو هم که تنها کامپوننت stateful استک پرومتئوس هست stateless کنیم. ابزارهای مثل M3 و Mimir و Thanos و Victoria Metrics و … میتونن به عنوان گیرنده ریموت رایت پرومتئوس قرار بگیرن.
رول‌ها رو معمولا توی فایل yaml مینویسیم و آدرس اون رو توی قسمت rule_file فایل کانفیگ پرومتئوس قرار میدیم. برای چک کردن سینکس فایل rule مون هم میتونیم آدرس فایل رو به دستور promtool check rules بدیم. به طور کلی دو نوع rule توی پرومتئوس داریم:
میتونیم با این نوع رول‌ها روی دیتایی که داریم یک سری محاسبات رو از قبل انجام بدیم و دیتای جدید به وجود اومده رو به عنوان یه دیتای time series داشته باشیم.
با استفاده از این رول‌ها شرایطی رو که میخوایم بر اساس اون پرومتئوس سیستم آلرتینگ مارو تریگر کنه، مشخص میکنیم. مثلا میگیم از توی ده دقیقه اخیر میانگین زمان پاسخگویی سیستم‌مون از نیم ثانیه بیشتر بوده بهمون خبر بده.
پرومتئوس از یک functional query language به اسم PromQL یا Prometheus Query Language پشتیبانی میکنه که به یوزر این امکان رو میده که به صورت real time دیتایی که میخواد رو انتخاب کنه یا با هم ترکیب کنه و نتیجه عملیاتی که انجام میده رو به صورت گراف یا جدول دیتا توی browser پرومتئوس یا یک سیستم بیرونی به وسیله API ببینه.
برای اینکه بدونیم چقدر دیسک برای اسکیل ما نیاز هست، لازم داریم که ابتدای کار یه تخمینی بزنیم از میزان دیسکی که میخوایم برای پرومتئوس. برای بدست آوردن این تخمین میتونیم از فرمول پیشنهادی خود پرومتئوس استفاده کنیم که از ضرب کردن سه تا مقدار در هم بدست میاد. مقدار اول ریتنشن تایم هست که یعنی دیتای چند ثانیه اخیر رو میخوایم نگهداری کنیم. مقدار دوم تعداد سمپل هایی که در ثانیه میگیرم هست و مقدار حجم هر سمپل هست که با واحد بایت اون رو میگیم. مثلا اگه دیتای یک ماه اخیر رو میخوایم و هر ثانیه ۲۰۰۰۰ سمپل میگریم که حجم هر سمپل ۲ بایت هست محاسبه به شکل زیر میشه :
needed_disk_size=(30*24*3600)*(20000)*(2)~= 104 GB
که طبق این محاسبه در حدود ۱۰۰ گیگ دیسک نیاز دارم. پرومتئوس از استورج های ریموت هم پشتیبانی میکنه.
کانسپت فدریشن کلا تو هر ابزاری یعنی اون ابزار با یک ابزار دیگه از نوع خودش دست میده، مثلا توی پرومتئوس میریم متریک های یک پرومتئوس دیگه‌ای رو میاریم یا متریک هامون رو در اختیار پرومتئوس‌های دیگه‌ای هم میذاریم. کاربرد فدریشن جایی هست که مثلا ما یک پرومتئوس توی کلاستر کوبرنتیز آوردیم بالا و برای اینکه دیزاین بهتری داشته باشیم و در زمانیکه کلاسترمون داون میشه هم بتونیم Observability داشته باشیم، میایم یک پرومتئوس خارجی دیگه هم میاریم بالا و اصطلاحا با اون دیتای پرومتئوس داخلی رو فدریت میکنیم. حالا دیزاین های مختلفی برای پرومتئوس هست که میتونید بیشتر در موردش بخونید.
Prometheus service discovery:
سرویس دیسکاوری کانسپت مهمی هست که جاهایی مثل کوبرنتیز و داکر اهمیت پیدا میکنه جاهایی که تعداد سرویس‌ها زیاد هست و در طول زمان مدام زیاد و کم میشه. نمیتونیم خودمون یه لیست از قبل آماده داشته باشیم از مواردی که میخوایم اونها رو مانیتور کنیم.
توی پرومتئوس میتونیم دو مدل سرویس دیسکاوری داشته باشیم اولی بر پایه فایل هست و دومی بر اساس HTTP . توی فایل بیس میگیم این فایل رو بررسی کن و تغییراتش رو توی مواردی که بررسی میکنه اعمال کن و توی مدل دوم هم یک رنج آی پی میدیم میگیم اینارو بررسی کن هرکدوم که روی فلان پورت و فلان مسیر متریک داد اون رو مانیتور کن.
درضمن بگم که سرویسی با نام watcher توی استک ELK هست برای بحث آلرتینگ ولی چون پولی هست زیاد در موردش نگفتیم. چنتا کانسپت مهم توی آلرت منیجر هست که در ادامه بررسی شون میکنم. یه سری آلرت داریم که زیادی میان، مثلا فرض کنید یه اتفاقی افتاده که یکی از سرور های من کلا down شده … قبول دارید اگه سرور کلا از دسترس خارج شده باشه سرویس ها و vm های روی اون هم دیگه در دسترس نیستن ؟ پس اگه آلرت down شدن سرور رو دریافت کنیم کافیه و نیاز نیست که دیگه برای تک تک سرویس‌های روش هم آلرت دریافت کنیم. اینجا مفهوم گروپ رو توی آلرت‌ها داریم که یه جورایی یه سری از آلرت‌ها از یک آلرت دیگه ارث ببرن و اگه آلرت بالاتر اتفاق افتاد دیگه پایینی‌هاش رو بهمون نگه. یا مثلا میخوایم یه تغییری رو توی سیستم بدیم که میدونیم منجر میشه به یه سری از آلرت‌هامون، بنابراین قبل از انجام تغییرمون میریم اون آلرت هارو سایلنت میکنیم. کارهای این چنینی رو انجام میدیم تا آلرت ها برامون تبدیل به یک چیزی عادی نشن و نسبت به اونها بی تفاوت نشیم.
آلرت‌ها میتونن توی استیت‌های مختلفی باشن:
مثلا میگیم اگه پنج دقیقه CPU سرورم بالای ۹۰ درصد زیر لود بود بهم آلرت بده، تا قبل از پنج دقیقه مثلا سه دقیقه هست که این اتفاق افتاده … توی این مدت آلرت در استیت پندینگ هست.
بعد از اینکه شرایطی که برای آلرت گذاشتیم اتفاق افتاد، آرتمون میره توی استیت فایر و انجام میشه.
بعد از اینکه اون مشکل برطرف شد و شرایط به حالت عادی برگشت، آلرت توی این استیت میره و اینکه مشکل حل شده رو هم بهمون اطلاع میده.
توی پست‌های بعدی بیشتر ابزارهای مانیتورینگ و Observability رو بررسی میکنیم و کنار هم یاد میگیرم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
