در ادامه‌ی پست‌های قبلی تو این پست داریم می‌ریم ابزار Grafana Loki رو یکم بررسی کنیم و ببینیم چه کمکی به ما میکنه.
خب یه مروری کنیم پست‌های قبلی رو:
توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
گرافانا موقعی که میخواست لوکی رو بسازه یه شعار جالبی داشت، پرومتئوس ولی برای لاگ 🙂 لوکی یه ابزار مالتی تننت و high available و اسکیل پذیر هست برای مدیریت و جمع آوری لاگ که از پرومتئوس الهام گرفته. مثل پرومتئوس کاستش کمه و راحت اجرا میشه. لوکی لاگ هارو ایندکس نمیکنه ولی برای هر لاگی که میگیره یه سری لیبل هارو میزنه.
سرویس اصلی ای که لاگ هارو ذخیره میکنه و کوئری ها رو پردازش میکنه.
ایجنتی هست که وظیفه اش جمع کردن لاگ ها و فرستادن اونها به لوکی هست.
برای کوئری زدن و نشون دادن لاگ ها هم که گرافانا کارشو بلده 🙂
این کامپوننت ها در کنار هم میتونن یه استک فول فیچر برای لاگ رو بهمون بدن.
کامپوننتی که مسئول فشرده سازی لاگ ها و retention هست.
سرویسی که مسئولیت هندل کردن دیتای ورودی از سمت کلاینت رو بر عهده داره و اولین ایستگاه مسیر رایت هست برای دیتای لاگ. بعد از رسیدن لاگ صحت اون رو بررسی میکنه و اینکه لیمیت های تننت رو رعایت کرده باشه و بعد از اون چانک های پذیرفته شده تبدیل به batch ها میشن و به صورت موازی به سمت ingester ها فرستاده میشن. مهمه که یه لودبالانسر جلوی دیستریبیوتر ها باشه و لود رو بینشون پخش کنه. این کامپوننت stateless هست و مهم ترین کامپوننت مسیر نوشتن هست.
این سرویس مسئول نوشتن دیتا توی long-term storage هست توی مسیر نوشتن یا write path و همچنین مسئول برگردوندن دیتای کوئری های که پاسخشون توی مموری هست در مسیر خواندن یا read path.
سرویس اختیاری ای هست که همون api کوئرییر رو ارائه میده و میتونیم اونو بالا بیاریم تا سرعت read path مون رو بالاتر ببره. موقعیکه اونها رو به کلاستر اضافه میکنیم کوئری های ورودی باید اول به سمت اونها بیان تا وارد یک صف داخلی بشن و بعدش کوئرییر ها اونها رو از صف بردارن و اجرا کنن. این کامپوننت stateless هست و مفهوم مشابه‌ش رو توی میمیر هم داشتیم. به صورت کلی مسیر خواندن و نوشتن تو محصولات گرافانا به این صورت خواهد بود.
کامپوننتی که کوئری هارو با استفاده از زبان کوئری LogQL هندل میکنه و لاگ هارو از ingester و long-term storage میگیره و پردازش میکنه. کوئرییر به تمام ingester ها کوئری میزنه قبل از برگردوندن جواب تا مطمئن بشه duplicate توی دیتا نباشه که میتونید در موردش بیشتر بخونید.
اپلیکیشن واحد و جداگانه ای هست که با تولید کردن لاگ مصنوعی! و فرستادن اونها به کلاستر لوکی، با کلاستر ارتباط میگیره تا پرفورمنس کلاستر رو بررسی کنه.
لوکی هم مثل میمیر بعد از کامپایل یک فایل باینری میشه که با تغییر پارامتر target به شکل های مختلف دیپلوی میشه. بازم تاکید می کنم این مدل تو محصولات دیگر گرافانا هم برقرار هست.
ساده ترین مود دیپلوی کردن لوکی هست که مود دیفالت هم هست و با پارامتر target=all- اجرا میشه. توی این مود همه ی میکروسرویس های لوکی داخل یک پروسه سینگل ران میشه که از طریق باینری یا ایمیج داکر ایجاد شده. برای شروع سریع و استفاده های آزمایشی و حجم های در حدود صد گیگ در روز این مدل دیپلوی میتونه مناسب باشه.
اگر حجم لاگ شما از حدود صد گیگ در روز بیشتره یا اگه میخواین read و write رو جدا کنید این مدل دیپلوی میتونه بهتون کمک کنه و تا چند ترابایت لاگ در روز رو جواب بده. توی این مود کامپوننت های لوکی توی سه تا دسته تقسیم شدن که اونها رو با پارامترهای target=read- و target=write- و target=backend- میتونیم اجرا کنیم. در تصویر بالا سرویس های مرتبط به هر تارگت رو میتونید ببینید.
تارگت read فقط stateless هست و دوتا تارگت دیگه stateful هستن و در پیاده سازی روی کوبر اونها رو با statefulset پیاده سازی میکنن.
این مدل دیپلوی لوکی رو برای اسکیل های خیلی بزرگ میشه در نظر گرفت و هر کامپوننت به صورت مستقل پروسه اش بالا میاد تو این روش و میتونه اسکیل بشه. توی این روش انعطاف بیشتری رو برای اسکیل کردن داریم از طرفی میتونیم با مانیتور کردن تک تک کامپوننت ها Observability بهتری رو داشتیم در کنار اینکه پیچیدگی خودش رو هم نسبت به دو تا مود دیگه داره. این مود برای کلاستر های خیلی بزرگ پیشنهاد میشه و کوبرنتیز محیط مناسب دیپلوی به این روش هست و برای Jsonnet و Helm chart نصب هم وجود دارد.
حالا که داریم در مورد لاگ صحبت میکنیم یه معرفی کوتاه هم روی graylog داشته باشیم:
گری لاگ یک پلتفرم CLM یا centralized log management هست که به صورت یکپارچه لاگ ها رو جمع آوری و آنالیز میکنه. همونطور که میدونید توی دنیای IT لاگ ها نقش مهمی رو توی بررسی وضعیت و حفظ سلامتی و امنیت سیستم دارن و اینکه همه لاگ هارو توی یه جا داشته باشیم و بررسی کنیم، کار رو ساده تر میکنه.
گری لاگ سه تا کامپوننت اصلی داره که میشه اونها رو کنار هم بالا آورد اما برای استفاده های پروداکشنی توصیه میشه که الستیک رو جدا کنیم و روی سرور دیگه اونو بالا بیاریم.
معمولا توی محیط پروداکشن به این شکل عمل میکنیم که مثلا روی سه تا سرور یه کلاستر الستیک بالا میاریم و روی سه تا سرور دیگه هرکدوم یک رپلیکا از مونگو و یک رپلیکا از گری لاگ رو میذاریم و نهایتا این سرویس رو پشت یک لود بالانسر قرار میدیم که میتونه HA داشته باشه.
توی پست‌های بعدی بیشتر ابزارهای مانیتورینگ و Observability رو بررسی میکنیم و کنار هم یاد میگیرم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
