مشاهده‌پذیری چندابری با استفاده از Fluent Bit چگونه است؟

نکات کلیدی

• Fluent Bit به ما اجازه می‌دهد ملاحظات مدیریت هزینه و الزامات انطباق (compliance) را که برای مشاهده‌پذیری چندابری حیاتی هستند پوشش دهیم.
• سازمان‌ها به‌ندرت فقط راهکارهای cloud-native را به‌تنهایی اجرا می‌کنند؛ پس هر ابزاری که می‌خواهد مشاهده‌پذیری را یکپارچه کند، مثل Fluent Bit، باید با طیف گسترده‌ای از فناوری‌ها و راهبردهای پیاده‌سازی به‌خوبی کار کند.
• Fluent Bit بی‌طرفی نسبت به ابر (cloud neutrality) و توانایی کار با سرویس‌های ارائه‌دهندگان ابر را ارائه می‌دهد؛ ویژگی‌هایی که برای ممکن‌کردن مشاهده‌پذیری چندابری مهم‌اند.
• Fluent Bit امکان پشتیبانی از تیم‌های مختلف با ابزارهای تخصصی مشاهده‌پذیری متفاوت را فراهم می‌کند تا ارزش عملیات چندابری سازمان به حداکثر برسد.
• فناوری‌ها و تکنیک‌های مانیتورینگ و مشاهده‌پذیری در دهه گذشته به‌طور چشمگیری بهتر شده‌اند. Fluent Bit قابلیت‌هایی فراهم می‌کند تا بتوانیم این تغییرات را بدون ایجاد اختلال جدی بپذیریم.

عملیات چندابری و IT ترکیبی چیز عجیبی نیستند. هرچند ابر-ابرشرکت‌ها ترجیح می‌دهند بارهای کاری‌تان را در ابر خودشان نگه دارید، اما این در عمل همیشه شدنی نیست. بالاخره هر ابر مزایا و معایب خودش را دارد. گاهی این تفاوتِ ویژگی‌ها نیست که انتخاب ابر را تعیین می‌کند. Fluent Bit بخشی از پروژه Fluent در CNCF است که قابلیت‌های جمع‌آوری داده‌های مشاهده‌پذیری را فراهم می‌کند (سه ستون کلاسیک: لاگ‌ها، تریس‌ها و متریک‌ها) و سپس این رویدادها را تبدیل، فیلتر و به ابزارهای مناسب مسیریابی می‌کند. پس قبل از اینکه نقش Fluent Bit را در سناریوی چندابری بررسی کنیم، یک قدم عقب برویم و محرک‌ها و چالش‌های چندابری را مرور کنیم.

واگرایی و خودمختاری

برای سازمان‌های بزرگ، رویکرد چندابری همیشه از برنامه‌ریزی استراتژیک و تلاش برای هم‌راستاکردن همه چیز با فروشندگان مشخص برای حداکثرکردن قدرت خرید نمی‌آید. ادغام‌ها و تملک‌ها (M&A) به‌طور سنتی (برای مثال در این مقاله از Thoughtworks) به‌عنوان یکی از محرک‌های چندابری مطرح شده‌اند. اما احتمالاً موقعیت‌های رایج‌تر از IT محلی یا «IT خاکستری» ناشی می‌شوند که انتخاب‌های محلی انجام می‌دهند، یا وقتی دپارتمان‌ها/واحدهای کسب‌وکار سطحی از خودمختاری دارند. خودمختاری برای چابکی خوب است، اما می‌تواند چالش ایجاد کند، مخصوصاً وقتی یک راه‌حل محلی محبوب می‌شود و در سازمان فراگیرتر می‌شود یا مشخص می‌شود که با تعهدات انطباقِ گسترده‌تر سازمان کاملاً هم‌سو نیست.

شکل ۱: چگونه یک راه‌حل محلی می‌تواند به‌تدریج نیازمند پشتیبانی سطح سازمانی شود

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

توزیع داده‌های مشاهده‌پذیری می‌تواند با ممکن‌کردن استفاده هر تیم از ابزار ترجیحی خودش، به حل چالش‌ها کمک کند. این ابزارها می‌توانند در ابرهای متفاوت مستقر شوند، و قابلیت‌های سراسری/متمرکز سازمان معمولاً روی پلتفرم‌های ابری استراتژیک میزبانی می‌شوند.

بهره‌وری‌های هزینه‌ای

صرف‌نظر از اینکه یک سازمان چگونه به وضعیت چندابری رسیده، لازم است درک سرتاسری از IT خود داشته باشد تا تشخیص دهد چه زمانی مشکلی رخ داده و چه چیزی علت و چه چیزی معلول است.

تیم‌های IT مرکزی اغلب به‌عنوان سربار دیده می‌شوند، پس همیشه فشار وجود دارد که «بیشتر با کمتر» انجام دهند؛ از فرآیندهای عملیاتی تا امنیت. بنابراین هر بهبودی که کار را سریع‌تر و ساده‌تر کند مثبت است: از یکپارچه‌سازی ابزارها و داشبوردهای مشترک مشاهده‌پذیری تا تشخیص سریع‌تر مشکلات یا تشخیص زمان اعمال اقدامات پیشگیرانه. Fluent Bit، همان‌طور که خواهیم دید، می‌تواند به ساده‌کردن این چالش‌ها کمک کند. اما صرفاً یکپارچه‌کردن همه داده‌های مشاهده‌پذیری از چند ابر می‌تواند گران باشد؛ لاگ‌ها و تریس‌ها حجیم هستند و متریک‌ها هم غالباً با فرکانس بالا تولید می‌شوند. همه این‌ها هزینه شبکه ایجاد می‌کند، به‌خصوص هزینه خروج داده، و حتی اگر صحبت از سنت در ساعت برای هر سرویس باشد، خیلی سریع جمع می‌شود. پس باید یک راهبرد مؤثر پیدا کنیم، که این هم یکی از حوزه‌هایی است که Fluent Bit می‌تواند کمک کند.

Fluent Bit

ارزش دارد پس‌زمینه Fluent Bit را بررسی کنیم تا بفهمیم چگونه می‌تواند کمک کند، چون این کار دیدی نسبت به برخی ویژگی‌های مهمش می‌دهد. Fluent Bit از همان پروژه CNCF می‌آید که Fluentd هم از آن است، و در سال‌های اولیه Fluentd و به‌عنوان بخشی از چشم‌انداز CNCF، تا حد زیادی «برادر کوچک‌تر» محسوب می‌شد. Fluent Bit برای کاربردهای اینترنت اشیا (IoT) با ردپای بسیار کوچک ایده‌آل بود. می‌توانست لاگ‌ها را جمع کند و برای پردازش به جلو بفرستد، اغلب از طریق همان برادرش. اما Fluent Bit در چند سال اخیر از سایه برادرش بیرون آمده است. این تغییر با تمرکز cloud-native روی اجرایی‌های کوچک‌تر و کارآمدتر هدایت شده است. Fluent Bit با C ساخته شده و با C، Go و WASM قابل توسعه است؛ هم باینری‌های native تولید می‌کند و هم با LuaJIT قابل سفارشی‌سازی است.

علاوه بر توسعه‌پذیری Fluent Bit، رویکرد حمایت از استانداردهای رایج هم اثرگذار بوده است. در نتیجه، علاوه بر اینکه با OpenTelemetry Protocol سازگار است و می‌تواند نقش یک OpenTelemetry Collector را ایفا کند، می‌تواند به‌صورت روان با استقرارهای موجود Fluentd هم کار کند و هم پلاگین‌های «کامپایل‌شده داخلی» دارد که اجازه می‌دهند داده از انواع منبع‌ها دریافت و به انواع مقصدها ارسال شود؛ از فایل‌های لاگ Log4J، Apache و Nginx تا خروجی به Kafka، TensorFlow و کانال‌های اعلان اجتماعی.

این فناوری‌ها بخشی از دلایلی هستند که پذیرش اولیه Fluent Bit حول سناریوهای IoT شکل گرفت، چون کد می‌توانست برای سخت‌افزار تخصصی با یک ردپای کوچک و کارآمد کامپایل شود. وقتی cloud-native و Kubernetes به سمت باینری‌های کوچک‌تر و کارآمدتر در مقیاس حرکت کردند (۲۲ مگابایت روی ویندوز در مقایسه با ۱۰۰ مگابایت Fluentd)، این مزیت‌های عملکردی باعث صرفه‌جویی هزینه شد (خصوصاً در مقیاس‌های بسیار بزرگ). با این حال، ابر همچنین برای AI/ML یک توانمندساز عالی بوده، چون می‌توانیم ناوگان‌های بزرگ GPUهای متراکم را «زمان‌-اشتراکی» کنیم و از Fluent Bit برای مانیتورینگ استفاده کنیم.

Fluent Bit می‌تواند به‌عنوان یک عامل Prometheus و یک کالکتور OpenTelemetry برای همه انواع سیگنال‌ها عمل کند. به‌راحتی در اکوسیستم Kubernetes جا می‌گیرد، محیط‌های سنتی را پشتیبانی می‌کند و همان‌جایی وصل می‌شود که شاید قبلاً از Fluentd استفاده می‌کردیم.

Fluent Bit یک جایگزین تک-عامل (single-agent) بسیار سازگار ارائه می‌دهد که می‌تواند ابزارهایی را که برای پرس‌وجو و مصورسازی آنچه رخ می‌دهد لازم داریم پشتیبانی کند. این یعنی می‌توانیم نیازهای استقرار عامل‌ها را خیلی ساده کنیم: استقرار Fluent Bit نیاز به استقرار Prometheus Agent، عامل‌های جمع‌آوری لاگ سطح سیستم‌عامل، OpenTelemetry collector و غیره را از بین می‌برد.

قابلیت‌های Fluent Bit به ما اجازه می‌دهد رویدادها را در حال عبور تبدیل کنیم تا از روی لاگ‌ها متریک استخراج کنیم (مثلاً تعداد خطا در دقیقه در یک جریان لاگ) و نمایش لاگ را به متریک یا تریس استاندارد صنعتی تبدیل کنیم. این تواناییِ انجام تبدیل، به تیم‌ها اجازه می‌دهد ابزارها و تکنیک‌های جدید مشاهده‌پذیری را بدون ایجاد اختلال جدی وارد کنند. برای مثال، اگر تیم‌های توسعه در زمان build از auto instrumentation استفاده می‌کنند یا با service meshهایی مثل Istio داده تریس تولید می‌کنند، اما ابزارهای عملیاتی اصلی هنوز آماده پردازش داده تریس نیستند، می‌توانیم تریس‌ها و متریک‌ها را به لاگ تبدیل کنیم. برعکس، اپلیکیشن‌های قدیمی که هیچ‌کس دلش نمی‌خواهد تغییرشان دهد، می‌توانند تریس و متریک را از روی لاگ‌هایشان «به‌دست بیاورند»، و بینش بیشتری از یک پشته مشاهده‌پذیری به دست دهند که از چنین داده‌هایی پشتیبانی می‌کند.

مهم‌تر از همه، چون Fluent Bit با فایل‌های پیکربندی هدایت می‌شود، اعمال تغییرات به‌صورت ساده و تکرارشونده آسان می‌شود؛ یعنی می‌توانیم هم‌زمان با تکامل رویه‌ها و فناوری‌ها، تغییرات را بدون نیاز به تغییرات مخرب (disruptive) منتشر کنیم.

Fluent Bit در یک محیط چندابری

همان‌طور که دیدیم، Fluent Bit قابلیت‌های زیادی برای ترکیب و پشتیبانی از چند ابزار و ابزارهای فنی یا عملیاتی هم‌پوشان دارد. می‌توانیم از رویکردهای جدیدتر و بالغ‌تر مانیتورینگ و مشاهده‌پذیری پشتیبانی کنیم و حتی چندین عامل جمع‌آوری داده را جایگزین کنیم. همچنین با ردپایی کوچک و کارآمد کار می‌کنیم.

این‌ها همه دلایل خوبی برای Fluent Bit هستند، اما چه چیزی آن را برای استفاده‌های چندابری منحصربه‌فرد می‌کند؟ فناوری‌های به‌کاررفته در Fluent Bit (و اینکه یک راه‌حل متن‌باز است) یعنی می‌تواند تقریباً هرجایی اجرا شود، از جمله در چند ابر مختلف.

دستکاری و فیلترکردن داده‌ها برای چندابر مهم است؛ مشاهده‌پذیری پرحجم است (خصوصاً تریس‌ها و لاگ‌ها) و پهنای باند زیادی مصرف می‌کند و در نتیجه هزینه ایجاد می‌کند. هزینه‌های دقیق خروج داده می‌تواند پیچیده باشد، چون به عوامل مختلفی وابسته است:

• فقط Oracle در میان چهار فروشنده بزرگ ابر، هزینه‌ها را بر اساس regionهای ابری متفاوت نمی‌کند (وقتی تفاوت وجود دارد، regionهای آمریکا و اروپا معمولاً ارزان‌ترند و آسیا-اقیانوسیه و آمریکای لاتین گران‌تر).

• لایه‌بندی قیمت (tiering): فروشنده‌ها قیمت را بر اساس حجم، میزان تعهد مصرف و غیره پلکانی می‌کنند.

• بیشتر فروشنده‌ها بابت جریان داده بین regionهای ابری خودشان هزینه می‌گیرند.

• کاربردها: در برخی کاربردها، مثل مهاجرت سرویس‌ها یا انتقال آفلاین داده، هزینه خروج داده ممکن است کاهش یابد یا رایگان باشد.

ما نرخ‌هایی تا ۰.۱۶ دلار به ازای هر گیگابایت دیده‌ایم. با این قیمت، یک سرور که در تمام ساعات شبانه‌روز، هر ساعت یک گیگابایت لاگ، تریس و متریک تولید کند، ماهانه ۱۱۵ دلار هزینه خواهد داشت. اما چه کسی یک راه‌حل تک‌سروری اجرا می‌کند؟ پس اگر بتوانیم راهبردی بچینیم که حتی ۱۰٪ از این هزینه را بدون لطمه‌زدن به کارایی عملیاتی تیم پشتیبانی کاهش دهد، صرفه‌جویی قابل توجهی خواهیم داشت.

توانایی Fluent Bit در فیلتر کردن و تعامل با ابزارهای مختلف یعنی به‌راحتی می‌توان آن را طوری پیکربندی کرد که لاگ‌های پر سر و صدا را فیلتر کند و موقتاً در ذخیره‌سازی محلی کم‌کارایی‌تر (و کم‌هزینه‌تر) روی سرورها نگه دارد. نتیجه این می‌شود که اگر لازم شد لاگ‌ها قابل بازیابی‌اند، اما امیدواریم ۹۹.۹۹٪ مواقع اصلاً به آن‌ها نیاز نباشد. برای مثال، یک اپلیکیشن ممکن است مرتب گزارش دهد که «زنده‌ام و خوبم». به‌جای فرستادن تک‌تک این رویدادها از طریق شبکه، تنظیم Fluent Bit برای حذف چنین رویدادهایی ساده است، یا بهتر از آن، فقط این واقعیت را از یک ابر به مکان مرکزی بفرستیم که مثلاً «در هر ۵ دقیقه، x عدد از این لاگ‌ها دیده شده‌اند» تا نبودِ اطلاعات خودش مسئله‌ساز نشود. بنابراین معماری‌ای شبیه نمودار زیر می‌گیریم:

شکل ۲: معماری ساده سطح بالا برای کمک به هزینه‌های داده

این ایده جدید نیست؛ اغلب آن را به‌عنوان حالتی از عملیات «لبه ابر» می‌بینیم. می‌تواند هوشمندتر هم بشود اگر تیم‌های عملیات متمرکز از چند ابزار استفاده کنند. داده مشاهده‌پذیریِ موردنیاز همه اپلیکیشن‌ها هم‌پوشانی خواهد داشت، پس با مسیریابی محلی به زیرساخت عملیات، ترافیک تکراری را محدود می‌کنیم.

مشاهده نمونه‌های اپلیکیشن با توزیع جغرافیایی

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

این رویکرد تازه نیست؛ راهکارهای managed service اغلب همین را انجام می‌دهند: ابر مرکزی با همه داشبوردهای مشاهده‌پذیری عملیاتی و راهنمای دانش روی یک ابر، اما ورود به ابرهای دوردست برای اجرای remediation.

Fluent Bit می‌تواند این را ممکن کند؛ با فیلترکردن یا استخراج رویدادهای مرتبط در استقرارهای جغرافیایی و ارسال آن‌ها به یک سرویس مرکزی، در حالی که هر مقدار حساس ماسک یا حذف شده باشد. همچنین وقتی داده را جلو می‌فرستیم، سرویس‌های مرکزی باید منشأ رویدادها را بدانند، مثلاً اینکه رویداد از کدام کلاستر Kubernetes آمده است؛ این اطلاعات می‌تواند با پلاگین‌ها به رویدادهای مشاهده‌پذیری تزریق شود، برای مثال پلاگین Kubernetes.

جمع‌آوری داده استاندارد شده، مصورسازی محلی

آخرین مورد استفاده‌ای که Fluent Bit می‌تواند در آن بدرخشد، زمانی است که راه‌حل باید مستقل از فروشنده (vendor agnostic) باشد، اغلب با پذیرش یک پشته فناوری مبتنی بر CNCF. داده مشاهده‌پذیری جمع‌آوری‌شده سپس از طریق یک نود مرکزی به دامنه ابری هدایت می‌شود. این یعنی یک نود Fluent Bit باید یکپارچگی اختصاصی محصول مشاهده‌پذیری محلی را پشتیبانی کند. در فروشندگان بزرگ، این ممکن است از طریق تعریف‌های استاندارد صنعتی مثل OTLP در OpenTelemetry در دسترس باشد که Fluent Bit با آن سازگار است.

سپس تیم مصورسازی مانیتورینگ را طوری تنظیم می‌کند که از ابزارهای محلی همان ابر استفاده کند. حتی ممکن است خوراک داده Fluent Bit را با نقاط مانیتورینگ اختصاصی ابر مثل CloudWatch ترکیب کنند (که اغلب رایگان ارائه می‌شود، پس هزینه محاسباتی برای Fluent Bit ایجاد نمی‌شود). این «چندابر» به معنای استفاده هم‌زمان از چند ابر توسط یک فروشنده مشترک یا در یک زمان مشخص نیست. این برای فروشندگان نرم‌افزار خیلی منطقی است، چون مانیتورینگ اپلیکیشن را طوری استخراج می‌کنند که مشتری نیازی به دخالت یا فهم پیکربندی‌ها نداشته باشد. وقتی در محیطی شبیه Kubernetes کار می‌کنید، فقط کافی است به خوراک Fluent Bit وصل شوید و از داده Fluent Bit که در همه استقرارها یکسان است استفاده کنید تا از طریق یک ابزار کنترل یا حتی فقط Kubernetes Operatorها چیزها را کنترل کنید.

نتیجه‌گیری

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

جریان داده میان ابرها یا regionهای ابری اغلب به معنی عبور از مرزهای قانونی است. اگر داده ما شامل اطلاعات حساس مثل PII باشد، علاوه بر هزینه با محدودیت‌ها و تعهدات قانونی هم مواجه می‌شویم (مثلاً حاکمیت داده یا data sovereignty).

ردپای کوچک و کارآمد Fluent Bit که تقریباً هرجا قابل استقرار است، این را ممکن می‌کند. می‌توانیم «به‌اندازه کافی» داده را تجمیع کنیم، در صورت نیاز خلاصه‌های تجمیعی بسازیم، اما همچنین داده مشاهده‌پذیری را در مکان‌هایی نگه داریم که اگر لازم شد بتوانیم به‌سادگی سراغش برویم.

می‌توانیم داده درست را به ابزارهای مختلف برای کارهای مرتبطِ مختلف مشاهده‌پذیری برسانیم، از امنیت تا نماهای عملیاتی تخصصی اپلیکیشن، و تیم‌ها را به شکلی پشتیبانی کنیم که تا حد ممکن مؤثر باشند.

و چون Fluent Bit می‌تواند رویدادها را تقریباً در زمان نزدیک به واقعی جمع‌آوری کند، می‌توانیم از «تشخیص مشکل بعد از شروع» به سمت «شناسایی نشانه‌های هشدار هنگام جمع‌آوری رویدادها» حرکت کنیم و فرصت‌های پیش‌دستانه ایجاد کنیم.