در مسیر Observability، لوکی (قسمت هشتم)

در ادامه‌ی پست‌های قبلی تو این پست داریم می‌ریم ابزار Grafana Loki رو یکم بررسی کنیم و ببینیم چه کمکی به ما می‌کنه.

خب یه مروری کنیم پست‌های قبلی رو:

• دواپس چیه و چرا لازمه؟  اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.

• چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.

• چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.

• خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.

• در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.

• در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.

• در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.

• تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.

• در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.

• در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.

• در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.

• در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.

• در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.

• در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.

• در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.

• در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.

• در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.

• در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.

• در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.

• در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم

• در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.

• آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.

• کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.

• کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.

• پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.

• ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.

• اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.

• نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.

• استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.

• پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.

• پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.

• اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.

• کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.

• دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.

• مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.

• هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.

• سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.

• نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.

• نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.

• نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

گرافانا Loki

• چیه و چه کمکی بهمون می‌کنه

گرافانا موقعی که میخواست لوکی رو بسازه یه شعار جالبی داشت، پرومتئوس ولی برای لاگ 🙂 لوکی یه ابزار مالتی تننت و high available و اسکیل پذیر هست برای مدیریت و جمع آوری لاگ که از پرومتئوس الهام گرفته. مثل پرومتئوس کاستش کمه و راحت اجرا میشه. لوکی لاگ هارو ایندکس نمیکنه ولی برای هر لاگی که میگیره یه سری لیبل هارو میزنه.

• کامپوننت‌های استک loki

• Loki

سرویس اصلی ای که لاگ هارو ذخیره میکنه و کوئری ها رو پردازش میکنه.

• Promtail

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

• Grafana

برای کوئری زدن و نشون دادن لاگ ها هم که گرافانا کارشو بلده 🙂

این کامپوننت ها در کنار هم میتونن یه استک فول فیچر برای لاگ رو بهمون بدن.

• دیزاین و کامپوننت‌هایی داخلی

• Compactor

کامپوننتی که مسئول فشرده سازی لاگ ها و retention هست.

• Distributor​

سرویسی که مسئولیت هندل کردن دیتای ورودی از سمت کلاینت رو بر عهده داره و اولین ایستگاه مسیر رایت هست برای دیتای لاگ. بعد از رسیدن لاگ صحت اون رو بررسی میکنه و اینکه لیمیت های تننت رو رعایت کرده باشه و بعد از اون چانک های پذیرفته شده تبدیل به batch ها میشن و به صورت موازی به سمت ingester ها فرستاده میشن. مهمه که یه لودبالانسر جلوی دیستریبیوتر ها باشه و لود رو بینشون پخش کنه. این کامپوننت stateless هست و مهم ترین کامپوننت مسیر نوشتن هست.

• Ingester​

این سرویس مسئول نوشتن دیتا توی long-term storage هست توی مسیر نوشتن یا write path و همچنین مسئول برگردوندن دیتای کوئری های که پاسخشون توی مموری هست در مسیر خواندن یا read path.

• Query frontend​

سرویس اختیاری ای هست که همون api کوئرییر رو ارائه میده و میتونیم اونو بالا بیاریم تا سرعت read path مون رو بالاتر ببره. موقعیکه اونها رو به کلاستر اضافه میکنیم کوئری های ورودی باید اول به سمت اونها بیان تا وارد یک صف داخلی بشن و بعدش کوئرییر ها اونها رو از صف بردارن و اجرا کنن. این کامپوننت stateless هست و مفهوم مشابه‌ش رو توی میمیر هم داشتیم. به صورت کلی مسیر خواندن و نوشتن تو محصولات گرافانا به این صورت خواهد بود.

• Querier​

کامپوننتی که کوئری هارو با استفاده از زبان کوئری LogQL هندل میکنه و لاگ هارو از ingester و long-term storage میگیره و پردازش میکنه. کوئرییر به تمام ingester ها کوئری میزنه قبل از برگردوندن جواب تا مطمئن بشه duplicate توی دیتا نباشه که میتونید در موردش بیشتر بخونید.

• Loki Canary​

اپلیکیشن واحد و جداگانه ای هست که با تولید کردن لاگ مصنوعی! و فرستادن اونها به کلاستر لوکی، با کلاستر ارتباط میگیره تا پرفورمنس کلاستر رو بررسی کنه.

• Loki deployment modes​

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

• Monolithic mode

ساده ترین مود دیپلوی کردن لوکی هست که مود دیفالت هم هست و با پارامتر target=all- اجرا میشه. توی این مود همه ی میکروسرویس های لوکی داخل یک پروسه سینگل ران میشه که از طریق باینری یا ایمیج داکر ایجاد شده. برای شروع سریع و استفاده های آزمایشی و حجم های در حدود صد گیگ در روز این مدل دیپلوی میتونه مناسب باشه.

• Simple Scalable

اگر حجم لاگ شما از حدود صد گیگ در روز بیشتره یا اگه میخواین read و write رو جدا کنید این مدل دیپلوی میتونه بهتون کمک کنه و تا چند ترابایت لاگ در روز رو جواب بده. توی این مود کامپوننت های لوکی توی سه تا دسته تقسیم شدن که اونها رو با پارامترهای target=read- و target=write- و target=backend- میتونیم اجرا کنیم. در تصویر بالا سرویس های مرتبط به هر تارگت رو میتونید ببینید.

تارگت read فقط stateless هست و دوتا تارگت دیگه stateful هستن و در پیاده سازی روی کوبر اونها رو با statefulset پیاده سازی میکنن.

این مدل دیپلوی لوکی رو برای اسکیل های خیلی بزرگ میشه در نظر گرفت و هر کامپوننت به صورت مستقل پروسه اش بالا میاد تو این روش و میتونه اسکیل بشه. توی این روش انعطاف بیشتری رو برای اسکیل کردن داریم از طرفی میتونیم با مانیتور کردن تک تک کامپوننت ها Observability بهتری رو داشتیم در کنار اینکه پیچیدگی خودش رو هم نسبت به دو تا مود دیگه داره. این مود برای کلاستر های خیلی بزرگ پیشنهاد میشه و کوبرنتیز محیط مناسب دیپلوی به این روش هست و برای Jsonnet و Helm chart نصب هم وجود دارد.

حالا که داریم در مورد لاگ صحبت میکنیم یه معرفی کوتاه هم روی graylog داشته باشیم:

• چیه و چه کمکی بهمون می‌کنه

گری لاگ یک پلتفرم CLM یا centralized log management هست که به صورت یکپارچه لاگ ها رو جمع آوری و آنالیز میکنه. همونطور که میدونید توی دنیای IT لاگ ها نقش مهمی رو توی بررسی وضعیت و حفظ سلامتی و امنیت سیستم دارن و اینکه همه لاگ هارو توی یه جا داشته باشیم و بررسی کنیم، کار رو ساده تر میکنه.

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

• کامپوننت‌ها

  • Graylog

  • Mongodb

  • Elasticsearch

• دیزاین و استفاده best practice

معمولا توی محیط پروداکشن به این شکل عمل میکنیم که مثلا روی سه تا سرور یه کلاستر الستیک بالا میاریم و روی سه تا سرور دیگه هرکدوم یک رپلیکا از مونگو و یک رپلیکا از گری لاگ رو میذاریم و نهایتا این سرویس رو پشت یک لود بالانسر قرار میدیم که میتونه HA داشته باشه.

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

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

خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.

🫀 Follow DockerMe 🫀

🔔 Follow YouTube 🔔

📣 Follow Instagram 📣

🖇 Follow LinkedIn DockerMe🖇

🔎 Follow Linkedin Ahmad Rafiee 🔎

🕊 Follow Twitter 🕊