در مسیر Observability، استک پرومتئوس (قسمت چهارم)

 

استک Prometheus:

چیه و چرا لازمش داریم

پرومتئوس یک ابزار متن باز مانیتورینگ و آلرتینگ هست که توسط کمپانی soundcloud معرفی شد. از شروعش توی سال ۲۰۱۲ کمپانی ها و سازمان‌های زیادی پروژه هاشون رو بردن سمت پرومتئوس و باعث شد که کامیونیتی قوی و بزرگی برای این ابزار شکل بگیره و توی سال ۲۰۱۶ پرومتئوس به عنوان دومین ابزار بعد از کوبرنتیز وارد CNCF شد. پرومتئوس ابزاری هست که متریک هارو به صورت دیتای time series جمع آوری و ذخیره میکنه.

برخی از ویژگی های پرومتئوس:

• A multi-dimensional data model with time series data identified by metric name and key/value pairs
• PromQL, a flexible query language to leverage this dimensionality
• No reliance on distributed storage; single server nodes are autonomous
• Time series collection happens via a pull model over HTTP
• Pushing time series is supported via an intermediary gateway
• Targets are discovered via service discovery or static configuration
• Multiple modes of graphing and dashboarding support

متریک چیه؟

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

حالا time series چیه؟

دیتای تایم‌سریز یا “Time Series Data” به داده‌هایی اشاره دارد که به طور مداوم در طول زمان جمع‌آوری می‌شوند و هر نقطه داده مربوط به زمان خاصی است. این داده‌ها به طور معمول در زمان‌های منظم گردآوری می‌شوند و معمولاً برای مانیتورینگ، تحلیل و پیش‌بینی‌های زمانی استفاده می‌شوند.

مثال‌هایی از داده‌های تایم سریز شامل اطلاعات سنسورها (مانند دما، فشار، رطوبت)، داده‌های مالی (قیمت‌های سهام، نرخ ارز)، داده‌های شبکه (ترافیک شبکه) و داده‌های زیرساخت (مانند بار CPU و حافظه) می‌شوند.

بسته به دیتایی که داریم ممکنه میانگین، جمع، مینیمم، ماکسیمم یا تعداد اون دیتا بهمون اطلاعاتی رو بده که بتونیم ازش توی Observability استفاده کنیم.

به طور کلی دو تا روش برای جمع آوری دیتای مانیتورینگ هست روش push و pull که در روش push کامپوننت کالکتور که دیتا رو جمع میکنه اون رو میفرسته سمت سرویس مانیتورینگ و در روش pull خود سرویس مانیتورینگ میره و دیتا رو از کالکتور میگیره که هرکدوم مزیت خودشون رو دارن که در جدول پایین میتونید ببینید:

 

توضیح کامپوننت‌ها:

 

• Exporter

اکسپورتر کامپوننتی هست که روی هاست‌مون اون رو بالا میاریم و متریک‌ها رو استخراج میکنه و اونها رو آماده میکنه برای پرومتئوس مثلا node-exporter به صورت دیفالت روی پورت ۹۱۰۰ بالا میاد و متریک هارو برای ما expose می‌کنه و ازونجا که پرومتئوس از روش pull استفاده میکنه، بنابراین پرومتئوس تلاش می‌کنه که از تارگت‌های خودش دیتا رو جمع‌آوری کنه. اصطلاحا pull بیس هستش.

 

• Prometheus

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

• Pushgateway

برخی ابزارها هستن که متریک هاشون رو push میکنن، اگه بخوایم با استک پرومتئوس اونها رو مانیتور کنیم از کامپوننت pushgateway استفاده می‌کنیم تا اول متریک‌هارو توی اون پوش کنن و بعد پرومتئوس بتونه از pushgateway دیتا رو pull کنه. مثلا فکر کنید شما تو یه Private zone هستید که از بیرون به شما دسترسی نیست ولی شما امکانش رو دارید و به بیرون اکسس دارید. به نوعی اکسس یه طرفه دارید اینجا می‌تونید خودتون متریک‌ها رو پوش کنید و از این ابزار برای آن استفاده کنید.

 

• Alert manager

این کامپوننت در کنار پرومتئوس و ترکیبش با آن به ما امکان آلرتینگ می‌دن. تو این استک داخل پرومتئوس رول‌های آلرت نوشته می‌شه. مثلا اینکه رم یه سرور از ۸۰ درصد بیشتر داره استفاده می‌شه یا اینکه دیسک ۸۰ درصد از ظرفیتش پر شده. پس داخل خود پرومتئوس ما میایم آلرت رول تعریف می‌کنیم که بر اساس اون رول‌ها آلرت‌ها فایر می‌شوند و بعدش آلرت‌های فایر شده دست آلرت منیجر می‌رسه که وظیفه‌ی اطلاع دادن آلرت‌ها یا اصطلاحا نوتیف کردن آنها بر عهده‌ی آلرت منیجر می‌باشد. آلرت منیجز با استفاده از کانفیگ‌هایی که داره آلرت‌ها رو بر اساس اولیوت و گروهی که دارند برای جایی که باید ارسال می‌کنه.

 

Grafana

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

 

توضیح اجمالی نصب و کانفیگ Prometheus

پرومتئوس رو خیلی ساده با یه کانتینر داکر از ایمیج prom/prometheus میاریم بالا و مسیر prometheus/ رو که دیتا توی اون قرار داره و مسیر etc/prometheus/ که توی اون فایل yaml کانفیگ پرومتئوس قرار میگیره رو توی والیوم میذاریم و پورت ۹۰۹۰ که پورت دیفالت پرومتئوس هست رو پابلیش می‌کنیم.

فایل کانفیگ پرومتئوس سه تا قسمت اصلی داره:

• global

توی قسمت گلوبال کانفیگ های کلی پرومتئوس مثل interval بین زمان هایی که دیتای اکسپورتر رو بگیره یا اینتروال بین زمان هایی که rule ها رو چک کنه، مینویسیم.

• rule_files

توی این قسمت آدرس فایل‌هایی که میخوایم پرومتئوس از اونها rule ها رو بخونه، مینویسیم.

• scrape_configs

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

انواع Prometheus data type

 

کتابخانه های پرومتئوس چهار نوع اصلی دیتا رو معرفی میکنن که از اینها بیشتر سمت کلاینت و برای API ها و wire protocol استفاده میشه و با دیتا داخل پرومتئوس سرور به صورت دیتای بدون تایپ و time series رفتار میشه.

• Data type: Counter

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

• Data type: Gauge

گِیج نوعی از دیتا هست که به صورت مقدار عددی که میتونه بالا یا پایین بره ذخیره میشه. معمولا از گِیج برای دما، میزان مصرف مموری و همچنین کانت‌هایی که میتونن کم هم بشن مثل تعداد ریکوئست های در لحظه، استفاده میشه.

• Data type: Histogram

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

• Data type: Summary

شبیه هیستوگرام هست و موارد مثل مجموع کل یا مثلا مشخص کردن نمونه ای که بیش از پنجاه درصد مواقع تکرار شده و موارد مشابه رو هم ارائه میده.

توضیح چنتا مفهوم:

• Jobs and instances

به هر سورسی که پرومتئوس اون رو scrape میکنه یک اینستنس میگیم و مجموعه ای از اینستنس‌ها با هدف مشابه رو بهش میگیم یک جاب.

• Prometheus remote write

پروتکل remote write طراحی شده تا امکان انتقال سمپل‌های دیتا رو از یک فرستنده به گیرنده به صورت real time و بدون دیتا لاس بهمون بده. با استفاده از اون میتونیم پرومتئوس رو هم که تنها کامپوننت stateful استک پرومتئوس هست stateless کنیم. ابزارهای مثل M3 و Mimir و Thanos و Victoria Metrics و … میتونن به عنوان گیرنده ریموت رایت پرومتئوس قرار بگیرن.

• Prometheus rule types

رول‌ها رو معمولا توی فایل yaml مینویسیم و آدرس اون رو توی قسمت rule_file فایل کانفیگ پرومتئوس قرار میدیم. برای چک کردن سینکس فایل rule مون هم میتونیم آدرس فایل رو به دستور promtool check rules بدیم. به طور کلی دو نوع rule توی پرومتئوس داریم:

• Recording rules

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

• Alerting rules

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

توضیح promql به صورت مختصر

پرومتئوس از یک functional query language به اسم PromQL یا Prometheus Query Language پشتیبانی میکنه که به یوزر این امکان رو میده که به صورت real time دیتایی که میخواد رو انتخاب کنه یا با هم ترکیب کنه و نتیجه عملیاتی که انجام میده رو به صورت گراف یا جدول دیتا توی browser پرومتئوس یا یک سیستم بیرونی به وسیله API ببینه.

 

توضیح capacity planning

برای اینکه بدونیم چقدر دیسک برای اسکیل ما نیاز هست، لازم داریم که ابتدای کار یه تخمینی بزنیم از میزان دیسکی که میخوایم برای پرومتئوس. برای بدست آوردن این تخمین میتونیم از فرمول پیشنهادی خود پرومتئوس استفاده کنیم که از ضرب کردن سه تا مقدار در هم بدست میاد. مقدار اول ریتنشن تایم هست که یعنی دیتای چند ثانیه اخیر رو میخوایم نگهداری کنیم. مقدار دوم تعداد سمپل هایی که در ثانیه میگیرم هست و مقدار حجم هر سمپل هست که با واحد بایت اون رو میگیم. مثلا اگه دیتای یک ماه اخیر رو میخوایم و هر ثانیه ۲۰۰۰۰ سمپل میگریم که حجم هر سمپل ۲ بایت هست محاسبه به شکل زیر میشه :

needed_disk_size=(30*24*3600)*(۲۰۰۰۰)*(۲)~= 104 GB

که طبق این محاسبه در حدود ۱۰۰ گیگ دیسک نیاز دارم. پرومتئوس از استورج های ریموت هم پشتیبانی میکنه.

توضیح Prometheus federation

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

 

Prometheus service discovery:

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

توی پرومتئوس میتونیم دو مدل سرویس دیسکاوری داشته باشیم اولی بر پایه فایل هست و دومی بر اساس HTTP . توی فایل بیس میگیم این فایل رو بررسی کن و تغییراتش رو توی مواردی که بررسی میکنه اعمال کن و توی مدل دوم هم یک رنج آی پی میدیم میگیم اینارو بررسی کن هرکدوم که روی فلان پورت و فلان مسیر متریک داد اون رو مانیتور کن.

توضیح آلرت منیجر و گروپ کردن آلرت‌ها و ارتباطات آنها

درضمن بگم که سرویسی با نام watcher توی استک ELK هست برای بحث آلرتینگ ولی چون پولی هست زیاد در موردش نگفتیم. چنتا کانسپت مهم توی آلرت منیجر هست که در ادامه بررسی شون میکنم. یه سری آلرت داریم که زیادی میان، مثلا فرض کنید یه اتفاقی افتاده که یکی از سرور های من کلا down شده … قبول دارید اگه سرور کلا از دسترس خارج شده باشه سرویس ها و vm های روی اون هم دیگه در دسترس نیستن ؟ پس اگه آلرت down شدن سرور رو دریافت کنیم کافیه و نیاز نیست که دیگه برای تک تک سرویس‌های روش هم آلرت دریافت کنیم. اینجا مفهوم گروپ رو توی آلرت‌ها داریم که یه جورایی یه سری از آلرت‌ها از یک آلرت دیگه ارث ببرن و اگه آلرت بالاتر اتفاق افتاد دیگه پایینی‌هاش رو بهمون نگه. یا مثلا میخوایم یه تغییری رو توی سیستم بدیم که میدونیم منجر میشه به یه سری از آلرت‌هامون، بنابراین قبل از انجام تغییرمون میریم اون آلرت هارو سایلنت میکنیم. کارهای این چنینی رو انجام میدیم تا آلرت ها برامون تبدیل به یک چیزی عادی نشن و نسبت به اونها بی تفاوت نشیم.

آلرت‌ها میتونن توی استیت‌های مختلفی باشن:

• Pending

مثلا میگیم اگه پنج دقیقه CPU سرورم بالای ۹۰ درصد زیر لود بود بهم آلرت بده، تا قبل از پنج دقیقه مثلا سه دقیقه هست که این اتفاق افتاده … توی این مدت آلرت در استیت پندینگ هست.

• Firing

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

• Resolved

بعد از اینکه اون مشکل برطرف شد و شرایط به حالت عادی برگشت، آلرت توی این استیت میره و اینکه مشکل حل شده رو هم بهمون اطلاع میده.

توی پست‌های بعدی بیشتر ابزارهای مانیتورینگ و Observability رو بررسی می‌کنیم و کنار هم یاد میگیرم.

مراقب خودتون باشید.