توی قسمت چهارم مسیر Observability میریم به سراغ حضرت پرومتئوس!
خب یه مروری کنیم پستهای قبلی رو:
- دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
- مسیر شغلی دواپس اینجا در مورد مسیر شغلی دواپس و موارد پیرامون آن صحبت کردم.
- چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور میتونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
- چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
- خودکارش کن، مشکلاتت حل میشه 🙂 در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما میکنه صحبت کردم.
- در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
- در مسیر دواپس به داکر رسیدم. (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
- در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
- در مسیر دواپس اینبار: والیوم و نتورک داکر (قسمت سوم) توی این پست در مورد شبکه توی داکر و اینکه چطوری دیتای کانتینر رو میتونیم نگه داریم توضیح دادیم.
- در مسیر دواپس اینبار: داکر فایل ( قسمت چهارم ) توی این پست در مورد اینکه چطور با استفاده از داکر اپلیکیشن مون رو بیلد کنیم و ایمیج بسازیم توضیح دادیم.
- در مسیر دواپس اینبار: کامپوز فایل و داکر کامپوز (قسمت پنجم) توی این پست در مورد اینکه چطور روند دیپلوی کردن سرویسهامون و کانفیگ اونها رو به صورت کد داشته باشیم توضیح دادیم.
- در مسیر دواپس: اینبار داکر سوآرم (قسمت ششم) توی این پست در مورد داکر سوآرم و اینکه چطوری به کمک داکر چنتا سرور رو کلاستر کنیم، توضیح دادیم.
- در مسیر دواپس اینبار: دور و بری های داکر (قسمت هفتم) توی این پست در مورد ابزارهای جانبی که بهمون توی کار با داکر کمک میکنن توضیح دادیم.
- در مسیر دواپس: جمع بندی داکر (قسمت هشتم) توی این پست در مورد امنیت داکر توضیح دادیم و در آخر هم یه سری از بست پرکتیسها و تجربیات خودم رو گفتم.
- تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیتلب و جنکینز داشتیم.
- در مسیر CI/CD گیت رو بررسی میکنیم (قسمت دوم) توی این پست قبل ورود به گیتلب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
- در مسیر CI/CD شناخت گیتلب (قسمت سوم) توی این پست اجزای گیتلب رو بررسی کردیم و با کامپوننتهای مختلفی که داره بیشتر آشنا شدیم.
- در مسیر CI/CD پایپلاین و رانر گیتلب (قسمت چهارم) توی این پست پایپلاین و رانر گیتلب رو بررسی کردیم.
- در مسیر CI/CD وریبل، گیتآپس و جمعبندی (قسمت پنجم) توی این پست وریبلهای گیتلب رو بررسی کردیم و یه معرفی کوتاه از گیتآپس و آتودواپس کردیم و در انتها یه مقدار تجربههای خودم رو در گیتلب باهاتون به اشتراک گذاشتم.
- مسیر Observability (قسمت اول) توی این پست معرفی observability رو داشتیم و مقایسه اش با مانیتورینگ و یه توضیح مختصر هم در مورد اپنتلهمتری دادیم.
- در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
- در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننتهای استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
توصیه میکنم که حتما این پستها رو هم مطالعه کنید. بریم که ادامه بدیم.
استک 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 رو بررسی میکنیم و کنار هم یاد میگیرم.
مراقب خودتون باشید. 🌹🐳🌹