توی قسمت سوم مسیر Observability کامپوننت هایی که از استک الک مونده بود رو بررسی میکنم، یه مقایسه بین fluentd و fluentbit انجام میدیم و نهایتا یه توضیح مختصر در مورد Opensearch و Elastic Cloud.
خب یه مروری کنیم پست‌های قبلی رو:
توصیه میکنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
خب بریم که بقیه موارد استک الک رو با هم بررسی کنیم:
Kibana:
یه اینترفیس browser-based که میتونه برای سرچ آنالیز و مهم تر از همه visualize کردن دیتای ذخیره شده توی الستیک سرچ استفاده بشه. کیبانا اوپن سورس هست و با بقیه دیتابیس ها هم سازگار نیست. کیبانا میتونه بهمون توی منیج کردن دیتا و مانیتور کردن وضعیت کلاستر الستیک و کنترل کردن اینکه چه یوزرهایی به چه قابلیت هایی دسترسی دارن کمک کنه. تو آنالیز دیتا کیبانا کمک میکنه تا با استفاده از چارت ها و نقشه ها و گراف هایی که از ترکیب دیتا می‌کشیم بتونیم درک بهتری رو از طریق داشبورد کیبانا بدست بیاریم. کیبانا حتی توی آنالیز لاگ ها برای پیدا کردن آسیب‌پذیری‌های امنیتی هم بهمون کمک میکنه و یه جورایی درگاه دسترسی ما به این قابلیت‌ها هست. ما با استفاده از kibana میتونیم هم استک خودمون رو کانفیگ کنیم و هم به خوبی query بزنیم و مواردی که داریم رو مشاهده کنیم.
Beats:
بهشون اصطلاحا میگن log shipper، کامپوننت‌های سبکی که به زبان گولنگ توسعه یافتن تا به عنوان ایجنت توی محیط‌های مختلف بتونن با مصرف کم منابع و بدون دیپندنسی نصب بشن تا لاگ ها و متریک ها رو جمع آوری کنند. البته دیگه فقط لاگ نیست که میتونه متریک‌ها و موارد دیگه رو هم برای ما به سمت استک ELK که راه‌اندازی کردیم ارسال کنه. در ادامه لیستی از انواع Beats رو براتون میذارم و یه توضیح مختصر که هر کدومش چه دیتایی رو جمع آوری میکنه :
بنابراین Beats اولین راهی هست که استک ELK برای فرستادن دیتا سمت انجین اصلی استک داره و بسته به اینکه چه دیتایی رو میخوایم جمع کنیم باید تعدادی Beats رو نصب کنیم رو هاست‌مون که شاید اگر تمام موارد رو نیاز داشته باشیم بهینه نباشه. برای همین کانسپت دیگه‌ای به اسم elastic agent وجود داره که این موضوع رو خیلی بهینه‌تر هندل میکنه و به زبان ساده راه حل این مشکل هست.
Elastic Agent:
راه دوم و جدیدتر استک ELK برای فرستادن دیتا سمت الستیک استفاده از الستیک ایجنت هست که برای لاگ، متریک و دیتای سکیوریتی و … ازش استفاده میکنیم. الستیک ایجنت رو میتونیم به دو روش دیپلوی کنیم. روش اول standalone mode هست که همه‌ی پالیسی هامون رو به صورت دستی در قالب یک فایل yaml قرار میدیم، که این روش یه مقدار پیچیده تر هست و برای جاهایی که agent ما در محیط ایزوله‌ای قرار داره و بهش دسترسی نیست توصیه میشه. یه جورایی داریم کانفیگ هر agent رو داخل خودش انجام میدیم.
اما روش دوم دیپلوی الستیک ایجنت فلیت هست. ایجنت پالیسی‌ها و لایف سایکل میتونه به صورت مرکزی با استفاده از اپ فلیت توی کیبانا منیج بشه که این روشی هست که برای اکثر کاربران توصیه میشه. این روش خیلی بهینه است و به محضی که تغییری در کانفیگ‌‌ها و پالیسی‌های agent ایجاد کنیم به صورت مرکزی روی تمام agentها اعمال میشه و خیلی خیلی بهینه است. می‌تونم بگم قدرت روش جدید توی همین fleet هست که میتونیم agentهای خودمون رو به صورت مرکزی مدیریت و کانفیگ کنیم.
Fleet Server:
کامپوننتی که ایجنت های الستیک رو به فلیت متصل میکنه، فلیت سرور هست و همزمان به چندین ایجنت وصل میشه و به عنوان یه کنترل پلین پالیسی‌های اونها رو آپدیت میکنه و دیتای وضعیت اونها رو جمع آوری میکنه. همچنین قابلیت یک ساختار اسکیل‌پذیر رو بهمون میده و با اضافه شده تعداد و سایز ایجنت‌های الستیک میتونیم فلیت سرورها رو هم بیشتر کنیم تا بتونیم لود بیشتر رو هم هندل کنیم. از اونجا که فلیت سرور stateless هست و اصلا کلا توی استک ELK فقط elasticserach هست که stateful هست، میتونیم روی فلیت سرورها لود بالانس انجام بدیم و به صورت افقی آنها را زیاد کنیم.
در ادامه دو تا ابزار دیگه بهتون معرفی میکنم که تو این استک نیستن ولی اونقدر کنار اینها تعریف می‌شن و جایگزین‌های محبوبی هستند که گاها به جای ELK ما از EFK استفاده میکنیم که fluentd رو با logstash جایگزین میکنیم. بریم ببینیم چی هست و چه کاری برای ما انجام می‌دهند.
Fluentd:
ابزار اوپن سورسی برای جمع آوری لاگ از منابع مختلف و فرستادن اونها به مقصدها مختلف که توی سال ۲۰۱۱ Treasure Data اون رو توسعه داد. بالای هزار تا پلاگین مختلف داره که میتونه از سورس‌ها و دستینیشن‌های مختلف پشتیبانی کنه که همین انعطاف‌پذیری هم نقطه قوت این ابزار هست. فلوئنت‌دی به زبان سطح بالای روبی توسعه یافته تا بتونه کامیونیتی بیشتری رو برای مشارکت داشته باشه. با مکانیزم بافرینگی که داره میتونه حتی موقع تولید لاگ سنگین هم بدون دیتا لاس کار کنه که این ویژگی اون رو قابل اتکاتر میکنه. این پایداری که فلوئنت‌دی ارائه میده باعث شده تا کمپانی‌های زیادی بهش اعتماد کنن و کلا استک EFK رو داریم که جای لاگ استش از فلوئنت‌دی استفاده میشه برای فیلتر و بافر و روتیت کردن لاگ.
Fluent bit:
ابزار دیگه ای که توسط تیم Treasure Data توسعه یافته به زبان C برای جمع آوری لاگ. سبک بودن و استفاده بهینه از منابع ویژگی اصلی این ابزار هست و با بیش از ۱۰۰ پلاگینی که داره میتونه با ساختار های متنوعی ادغام بشه. در ادامه یه مقایسه بین این دوتا ابزار رو براتون میذارم:
یک ابزار نسبتاً بزرگ‌تر و پیچیده‌تر است. این ابزار از Ruby و C نوشته شده و پلاگین‌های زیادی دارد که آن را به یک راه‌حل جامع برای جمع‌آوری و پردازش لاگ‌ها تبدیل می‌کند. Fluentd بیشتر برای محیط‌هایی با نیازهای پیشرفته و پیچیده مانند تجمیع داده‌های لاگ در مقیاس بالا استفاده می‌شود.
سبک‌تر و کم‌حجم‌تر است و به طور کامل به زبان C نوشته شده است. هدف اصلی آن ارائه یک راه‌حل کارآمد برای جمع‌آوری و ارسال لاگ‌ها با حداقل مصرف منابع است. Fluent Bit برای جمع‌آوری لاگ‌ها در دستگاه‌های IoT، edge و محیط‌های با منابع محدود ایده‌آل است.
به دلیل معماری پیچیده‌تر و قابلیت‌های گسترده، معمولاً حافظه و منابع CPU بیشتری نسبت به Fluent Bit مصرف می‌کند. این ابزار برای محیط‌هایی مناسب است که منابع کافی برای پردازش حجم زیادی از داده‌ها دارند.
به عنوان یک ابزار سبک، طراحی شده تا مصرف منابع بسیار کمی داشته باشد. بنابراین، برای محیط‌هایی که مصرف کم حافظه و CPU اولویت دارد، انتخاب بهتری است.
با داشتن یک اکوسیستم گسترده از پلاگین‌ها، Fluentd قادر است تقریباً هر نوع داده‌ای را پردازش کند و به هر مقصدی ارسال کند. این ویژگی آن را به یک ابزار بسیار منعطف برای سناریوهای پیچیده لاگ تبدیل کرده است.
اگرچه Fluent Bit نیز از پلاگین‌های متنوعی پشتیبانی می‌کند، اما تعداد پلاگین‌ها و قابلیت‌های آن کمتر از Fluentd است. با این حال، پلاگین‌های اصلی برای جمع‌آوری و ارسال لاگ‌ها در آن وجود دارند و می‌تواند نیازهای اصلی را برآورده کند.
به دلیل قابلیت‌های پیشرفته و انعطاف‌پذیری بالا، برای تجمیع و پردازش لاگ‌ها در محیط‌های کلاسترهای بزرگ، سرورهای متعدد و سیستم‌های پیچیده مناسب است. از آن برای مدیریت لاگ‌ها در سیستم‌هایی مثل Kubernetes و محیط‌های ابری استفاده می‌شود.
بیشتر برای جمع‌آوری لاگ‌ها در edge devices، دستگاه‌های IoT و محیط‌هایی که نیاز به حداقل مصرف منابع دارند، استفاده می‌شود. همچنین به عنوان یک جمع‌آورنده لاگ در مقیاس کوچک‌تر یا به عنوان یک عامل جمع کردن لاگ در کنار Fluentd نیز به کار می‌رود.
با توجه به قابلیت‌های متعدد، پیکربندی Fluentd پیچیده‌تر است و نیاز به دانش بیشتری در مورد سیستم دارد. مدیریت و نگهداری این ابزار نیز به دلیل امکانات گسترده‌تر، ممکن است دشوارتر باشد.
پیکربندی ساده‌تری دارد و راه‌اندازی آن سریع‌تر و راحت‌تر است. این ویژگی باعث می‌شود برای کسانی که نیاز به راه‌حل‌های ساده و سریع دارند، مناسب باشد.
Sharding and Replication:
توی کلاستر اگه از یک دیتا تعداد بیشتری نگهداری کنم در واقع رپلیکا اونو بردیم بالاتر و اگه یک دیتایی که دارم رو به تعداد قسمت‌های کوچیک‌تر بشکنم در واقع شارد دیتا رو بردیم بالاتر. دو تا مفهوم خیلی مهم و حساس تو دیتابیس‌ها که برخی از آنها فقط Replication رو پشتیبانی می‌کنند. از شاردینگ میتونیم برای scale کردن کلاستر موقعیکه تعداد ایندکس دیتا بالا میره کمک بگیریم و تعداد درست شارد اهمیت بالایی توی پرفورمنس ما داره. وقتیکه کوئری‌ها روی شاردهای مختلف ران بشن و به صورت موازی پاسخ برگرده، سرعت بالاتری رو نسبت به حالتیکه دیتا توی یک شارد هست تجربه میکنیم اما به شرطی که شاردهای مختلف‌مون توی نودهای مختلف باشن و تعداد کافی نود توی کلاسترمون داشته باشیم.
موقعیکه یک ایندکس ایجاد میشه میتونیم تعداد شارد و رپلیکا اون رو مشخص کنیم و بهترم هست همون موقع فقط این مقادیر رو ست کنیم چون تغییر مقدار شارد بعدا توی کلاستر باعث ایجاد مساله reindexing میشه که لود بالایی رو روی کلاستر میندازه و اصلا توصیه نمی‌شه. معمولا توصیه میشه هر شارد حجمی بین ۳۰ تا ۵۰ گیگ داشته باشه مثلا اگه دیتای شما ۳۰۰ گیگ هست شارد رو روی ۱۰ بذارید. انتخاب اینکه چند تا شارد و یا چند تا رپلیکا داشته باشیم خیلی مهمه و باید در ابتدای ایجاد ایندکس یه استیمیتی از میزان دیتای آن داشته باشیم.
با رپلیکیشن ما میتونیم دیتامون رو در برابر مشکلات احتمالی که ممکنه پیش بیاد محافظت کنیم البته به شرطی‌که نود کافی رو توی کلاسترمون داشته باشیم و هر رپلیکارو بذاریم روی یک نود. هر رپلیکایی که از یک شارد میگیریم باید توی نود متفاوتی ذخیره بشه تا زمانی‌که نود قبلی fail میکنه ما یک نسخه کپی از دیتا رو داشته باشیم. رپلیکاها به جز جلوگیری از downtime و محافظت از دیتا توی سرعت هم با ایجاد امکان پاسخ به صورت موازی به کوئری ها، کمک کننده هستن.
Backup and restore (Snapshot):
به نوعی اسنپ شات یک بک‌آپ از کلاستر توی اون لحظه هست. چندتا از استفاده های اسنپ شات و مواردی که که میتونه بهمون کمک کنه رو در ادامه براتون میارم.
Elasticsearch clustering:
وقتی ما تعدادی نود elasticsearch رو کنار هم قرار می‌دهیم می‌توانیم یک کلاستر مالتی نود الستیک سرچ ایجاد کنیم. کلاستری که به ما امکان این رو میده که دیتاها رو ذخیره کنیم در کنار اینکه قدرت و سرعت خوبی برای سرچ و ایندکس به ما می‌دهد. ما با کلاسترینگ میتونیم High availability و Load Balancing به همراه Fault tolerance داشته باشیم مواردی که در استک‌های بزرگ به تمام آنها نیاز داریم و همواره باید طوری کار کنیم که SPOF نداشته باشیم.
برای ایجاد کلاسترینگ ما می‌توانیم نودهای خود را با نقش‌های (Role) مختلفی راه‌اندازی کنیم. نقش‌هایی که هر کدومشون برای ایجاد کلاسترینگ لازم است و نیاز است که یه نفر آن را برعهده بگیرد. برخی از نقش‌ها رو تو پست قبلی که در مورد نود تایپ‌ها صحبت کردیم بهش اشاره کردم. مثلا master یا data یا coordinator یا ingest node و … که هر کدومشون کاری رو تو کلاستر پیش می‌برند و انجام می‌دهند. نقش هر نود رو داخل کانفیگ آن میتونیم مشخص کنیم. موضوع دیگه‌ای که مهمه اینه که باید لیست نودهایی که داخل کلاستر هستند رو تو کانفیگ تمام نودهایی کلاستر قرار بدیم. این کار رو با کانفیگ discovery.seed_hosts انجام میدیم که به نوعی لیست تمام هاست‌های داخل کلاستر هست. موضوع بعدی مشخص کردن نودهایی است که برای bootstrap کردن کلاستر باید نقش ایفا کنند که کانفیگ cluster.initial_master_nodes برای این موضوع است. موارد متعدد دیگه‌ای برای کانفیگ کلاستر وجود داره ولی این چند تا نکته که گفتم از الزامات کلاسترینگ هست.
یکی از موارد مهمی که تو کلاسترینگ مطرحه اینه که داریم اون رو برای چه کاری و با چه هدفی ایجاد و کانفیگ میکنیم. این موضوع که باید در موردش تصمیم بگیریم در ایجاد و نوع پیاده‌سازی کلاستر ما خیلی مهمه و تاثیر گذاره. در ادامه به برخی از آن موارد اشاره میکنم:
کلاستر برای تیم توسعه و آزمایشی: تو این نوع پیاده‌سازی تنها فانکشنالیتی خود کلاستر اهمیت دارد و نه دیتا مهمه و نه پایدار بودن آن برای همین برای مدیریت راحت تر و صرفه‌جویی تو هزینه‌ها کلاستر رو به صورت یک نود راه‌اندازی میکنیم و ازش استفاده میکنیم. دقت کنید دیتایی که آنجا داره ذخیره میشه برامون مهم نیست و برای همین به تک نود اکتفا کردیم.
کلاستر برای پروداکشن: تو این موارد دیتا برای ما مهمه و خیلی اهمیت داره که کلاستر حتما همیشه در دسترس باشه برای همین باید به HA و LB و FT دقت کنیم و نوع پیاده‌سازی از سخت‌افزار مورد استفاده تا نحوه‌ی قرارگیری نودها در سرورها رو بررسی و بهترین جایگیری آنها رو داشته باشیم. چیزی که اینجا مهمه اینه که در زمان بروز خطا و خرابی کمترین آسیب به دیتا برسه و فانکشن اصلی سرویس ما قطع نشه.
ایجاد کلاستر برای استفاده خاص: در برخی از موارد نوع دیتا و مدل آن ساختار کلاستر رو عوض می‌کند مثلا اگر نیازه که دیتا به صورت مادام العمر نگهداری بشه میتونیم براش چرخه‌ی عمر داشته باشیم که بتوانیم از Hot و Warm و …. استفاده کنیم. پس با توجه به نوع استفاده کلاستر میتونیم دیزاین اون رو طراحی و بعد پیاده‌سازی کنیم.
OpenSearch:
اول یه کم تاریخچه‌ی الستیک رو با هم بررسی کنیم:
آقای Shay banon در سال ۲۰۰۴ نسخه اولیه‌ای از Elasticsearch به نام Compass را ایجاد کرد. برای ایجاد یک راه‌حل جستجوی مقیاس‌پذیر، توی نسخه سوم بخش‌های زیادی از Compass دوباره نوشته شد تا ساختاری که از پایه برای توزیع پذیری آماده شده شکل بگیره و از یک اینترفیس متداول یعنی Json over HTTP استفاده کرد که مناسب زبان‌های برنامه‌نویسی غیر از Java نیز باشد. اولین نسخه از Elasticsearch را در فوریه ۲۰۱۰ منتشر شد. شرکت Elastic NV در سال ۲۰۱۲ تأسیس شد تا خدمات و محصولات تجاری مرتبط با Elasticsearch و نرم‌افزارهای مربوطه را ارائه دهد. تا سال ۲۰۱۴ تونستن حدود صد میلیون دلار سرمایه جذب کردن، تنها ۱۸ ماه پس از تاسیس شرکت! در مارس ۲۰۱۵، شرکت Elasticsearch نام خود را به Elastic تغییر داد. در ژوئن ۲۰۱۸، Elastic برای عرضه اولیه عمومی با ارزیابی تخمینی بین ۱.۵ تا ۳ میلیارد دلار اقدام کرد. در ۵ اکتبر ۲۰۱۸، Elastic در بورس اوراق بهادار نیویورک فهرست شد. در ژانویه ۲۰۲۱، Elastic اعلام کرد که از نسخه 7.11 به بعد، کدهای تحت مجوز Apache 2.0 در Elasticsearch و Kibana را به دو مجوز Server Side Public License و Elastic License تغییر می‌دهد که هیچ‌یک از آنها به عنوان مجوز متن‌باز شناخته نمی‌شود. Elastic این تغییر را به AWS نسبت داد و اعتراض کرد که AWS Elasticsearch و Kibana را به‌طور مستقیم به مصرف‌کنندگان ارائه می‌دهد و مدعی شد که AWS با Elastic همکاری نمی‌کند. نتیجه اش این شد که AWS و چنتا شرکت دیگه نیاز به اینکه Elastic به صورت متن باز توسعه بدن رو احساس کردن و فورک جدیدی از پروژه رو توی همون نسخه‌ها ایجاد کردن که بعدا اسمش رو هم گذاشتن OpenSearch. پس اپن‌سرچ جزو خانواده ابزارهای سرچ هست که از سال ۲۰۲۱ فورک شده از پروژه‌های Elasticsearch و Kibana و توسط Amazon Web Services داره توسعه داده میشه.
و حالا آمازون اپن‌سرچ رو اینطوری معرفی میکنه:
اپن‌سرچ یک ابزار کامیونیتی محور و ۱۰۰ درصد اپن‌سورس تخت Apache 2.0-license هست که برای سرچ و آنالیز دسته بزرگی از یوزکیس‌ها مثل real-time application monitoring, log analytics, website search کارایی داره. کاملا اسکیل‌پذیر هست و میتونه دسترسی سریعی به دیتای حجیم از طریق داشبوردهاش و ابزارهای visualization بده که کار رو برای بررسی و آنالیز دیتا آسون میکنه و ازونجایی که از لایبرری‌های سرچ Apache Lucene استفاده میکنه میتونه قابلیت‌های زیادی مثل k-nearest neighbors (KNN) search, SQL, Anomaly Detection, Machine Learning Commons, Trace Analytics, full-text search رو فراهم کنه.
به صورت کلی تغییر لایسنسی که دادن و داستان‌هایی که ایجاد کردن باعث شد تا مسیر جدیدی ایجاد بشه و به صورت متن باز مسیر ادامه پیدا کنه. اخیرا شبیه همین داستان برای terraform هم اتفاق افتاد که تغییری تو نوع استفاده از کلادش انجام داد که خیلی‌ها شاکی شدن و مسیر جدیدی به نام OpenTofu رو ایجاد کردن و پروژه‌ی دیگه‌ای شکل گرفت و پیش رفت. به صورت کلی جامعه‌ی متن باز اگر موضوع براش خوشایند نباشه مسیر جدیدی رو ایجاد می‌کنند که در خیلی از موارد حتی از مسیر قبلی بهتر و پر شور تر هم پیش میره.
خیلی از مواردی که تو Elastic Stack مورد نیاز است نیاز به لایسنس داره مثلا آلرتینگ کلا نیاز به لایسنس داره. فکر کن کل سامانه رو پیاده‌سازی کردی حالا که می‌خواد بهت آلرت بده مشکل لایسنس می‌خوری و نمی‌تونی ازش استفاده کنید. دیدم که تو ایران بیشتر این استک رو کرک می‌کنند و از تمام قابلیت‌های که داره استفاده می‌کنند. من زیاد فاز این کار رو ندارم. بیشتر دوست دارم که از ابزارهای متن‌باز استفاده کنم تا اینکه یه محصولی رو کرک کنم و ازش استفاده کنم.
Elastic Cloud:
یه موضوع دیگه که خیلی برای ما داخل ایران شاید مسیر ولیدی نباشه استفاده از Cloud خود الستیک هست که امکانات زیاد رو روی کلاد خودش در اختیار ما قرار میده و ما میتونیم به صورت کامل از تمام قابلیت‌هایی که در اختیارمون میذاره، استفاده کنیم. استفاده از کلاد الستیک به ما این امکان رو میده که بدون اینکه درگیر پیاده‌سازی زیرساخت و خود ابزارها باشیم بتونیم از امکانات آنها نهایت استفاده رو کنیم. موضوع دیگه اینکه معمولا پیاده‌سازی و نگهداری این ابزارها نیاز به دانش زیادی داره و این دانش مستقل از دانش استفاده از خود ابزار هست. وقتی ما از کلاد استفاده میکنیم دیگه نیازی به دانش پیاده‌سازی و نگهداری اون ابزار مثلا elastic نداریم و تنها با دانش استفاده از اون ابزار میتونیم ازش بهره ببریم.
از مزایای استفاده از elastic cloud به موارد زیر میتونیم اشاره کنیم:
معمولا این مواردی که بهش اشاره میکنیم برای تمامی ابزارهایی که کلاد دارند مثلا Grafana و …. هم صادق است.
این میشه یه جمع بندی از استک الک امیدوارم در آینده فرصت بشه که برگردیم و با عمق بیشتر بررسی‌ش کنیم و کنار هم یاد بگیریم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
