نظارت بر کافکا در تولید

Franz Kafka یک رمان نویس یهودی بوهمیایی آلمانی و نویسنده داستان کوتاه بود که به طور گسترده به عنوان یکی از شخصیت های اصلی ادبیات قرن بیستم شناخته می شد. از طرف دیگر Apache Kafka ، یک پلت فرم نرم افزاری پردازش جریان منبع باز است. با توجه به ادغام گسترده آن در زیرساخت های سطح سازمانی ، نظارت بر عملکرد کافکا در مقیاس به یک مسئله مهم فزاینده تبدیل شده است. در اینجا در Logz. io ، ما از Apache Kafka به عنوان بخشی از محصول اصلی خود استفاده می کنیم و می خواهیم برخی از بینش های خود را در مورد نظارت بر وضعیت و عملکرد آن با مجموعه ای از ابزارهای منبع باز به اشتراک بگذاریم.

Apache Kafka یک سیستم عالی است که کاملاً متناسب با نیازهای ما برای اطمینان از مصرف با توان بالا و اطمینان از پیام های ورود به سیستم است و به دلیل نقش مهمی که در معماری ما ایفا می کند ، به دست آوردن دید در عملکرد و عملکرد آن بسیار مهم است.

با این حال ، داده های تله متری ارائه شده توسط کافکا می تواند از نظر کمیت و تا حدودی مبهم و به راحتی در دسترس نباشد ، به خصوص در خوشه های تولید بزرگ. در نتیجه ، دستیابی به دید چالش برانگیز است. برای غلبه بر این چالش ها ، ما یک سیستم مانیتورینگ را برای جمع آوری ، جمع آوری ، تجسم و هشدار برای هر دو سیاهه و معیارها ابداع کرده ایم.

در Logz. io ، ما از Apache Kafka به عنوان اتوبوس اصلی ما برای پیام های ورود به سیستم استفاده می کنیم.

بار کار

فقط برای اینکه تصویری خشن از محیط ما به شما ارائه دهد ، در اینجا اطلاعاتی در مورد استقرار کافکا و بار کاری که از آن استفاده می کند آورده شده است:

• ده ها میلیارد پیام در روز (در هر خوشه)
• ده ها کارگزار (در هر خوشه)
• هزاران پارتیشن (اولیه)
• خوشه های تولید چندگانه در هر منطقه
• چند منطقه
• بدون تکثیر منطقه متقابل

تجمع سیاهههای مربوط به کافکا

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

معتقدین قوی در "خوردن غذای سگ خودمان" ، ما تمام سیاهههای مربوط به خودمان را جمع می کنیم ، برخی از طریق پیوستهای مستقیم و در موارد دیگر با استفاده از FileBeat.

مهمترین پرونده ورود به سیستم پرونده server. log است که در آن خطاها و اطلاعات مربوط به پارتیشن ها ، رهبری و سایر اطلاعات جالب وجود دارد.

ما ارسال ابرداده به همراه پیام های ورود به سیستم برای زمینه بهتر هنگام تجسم و هشدار بسیار مهم است ، بنابراین زمینه های زیر را به هر پیام ورود به سیستم اضافه می کنیم:

• محیط
• شناسه خوشه
• نمونه کارگزار (شناسه ، IP)

پیام های چند لایه در منبع توسط FileBeat انجام می شود و تجزیه و تحلیل توسط سرویس Logz. io انجام می شود. از همه مهمتر ، ما زمینه های ابرداده و همچنین کلاس Loglevel و Java را تجزیه می کنیم.

جمع آوری معیارهای کافکا

در مرحله بعد ، معیارها!

Apache Kafka با استفاده از JMX تعداد زیادی از معیارها را در معرض دید قرار می دهد. این معیارها برای درک عملکرد و ظرفیت خوشه ای شما بسیار ارزشمند هستند. ما معیارهای JMX و همچنین معیارهای میزبان را با استفاده از ابزارهای زیر جمع می کنیم:

• - عامل Jolokia با Kafka پر شده است و تمام معیارهای کارگزار JMX را با استفاده از API REST در معرض دید قرار می دهد.-ابزار منبع باز ما معیارهای در معرض Jolokia را جمع می کند و آنها را به گرافیت ارسال می کند.(2graphite) - این ابزار معیارهای میزبان را جمع می کند و آنها را به گرافیت ارسال می کند.

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

• منطقه/AZ
• شناسه خوشه
• شناسه کارگزار

نظارت بر تأخیر و تأخیر کافکا

البته ، برخی از مشاغل یا معیارهایی که کاربردی دارند وجود دارد که نمی توانیم هنگام سنجش عملکرد کافکا از آنها غافل شویم. ما به طور کلی باید بدانیم که چه نوع تاخیرها در لوله مصرف ما وجود دارد. این امر بیشتر به عنوان "تاخیر" گفته می شود.

ما تاخیر کافکا را از دو طریق اندازه گیری می کنیم.

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

با این حال ، این یک نشانگر مستقیم یک مسئله نیست ، زیرا این امر به دانش میزان مصرف نیز نیاز دارد. برای این منظور ، ما از Zipkin برای اندازه گیری زمان واقعی زمان بین مصرف و مصرف استفاده می کنیم ، که یک معیار بسیار دقیق تر و مستقیم برای سنجش تجربه کاربر است.

الگوهای گرافانا

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

به عنوان یک نکته جانبی ، شایان ذکر است که Logz. io همچنین از افزودن Logz. io به عنوان منبع داده برای تجزیه و تحلیل معیارها در گرافانا پشتیبانی می کند.

تجسم داده های کافکا

نحوه تجسم داده های خود می تواند تأثیر بسزایی در درک داده های اساسی داشته باشد. در صورت لزوم ، و به خصوص هنگامی که همه چیز اشتباه پیش می رود ، می خواهید بتوانید صف های بصری درستی را بدست آورید که شما را با سرعت و دقیق تر به منبع چیزها سوق می دهد.

در اینجا نمونه ای از گزارش های Kafka توسط Logz. io جمع آوری شده و در صفحه کشف Kibana نمایش داده می شود:

از این نظر ، خوب است که توجه داشته باشید که داده های مشابه را می توان به روش های مختلف مشاهده کرد ، هر کدام چیز دیگری را برجسته می کنند.

به عنوان مثال ، به دو تجسم زیر نگاهی بیندازید که مجموعه داده های بایت/ثانیه ورودی را به صورت هر موضوعی تجسم می کنند:

این دو تجسم همان سری داده ها را نشان می دهد ، اما یکی پیکربندی شده است تا این سریال را به عنوان همپوشانی نشان دهد ، در حالی که دیگری روی پشته تنظیم شده است. اولین مورد برای تشخیص سنبله ها در موضوعات خاص بهتر است ، در حالی که دوم به وضوح تأثیر کلی را در تمام موضوعات نشان می دهد.

علاوه بر این ، ما دریافتیم که با توجه به تعداد زیادی از سری داده ها برای هر وکتور (میزبان ، موضوع ، خوشه و غیره) ، با کپی کردن برخی از تجسم ها دستاوردهای بصری وجود دارد ، اما فقط "10 نفر برتر" را فیلتر می کنددر هر یک و این سری داده ها نیز می توانند به روش های مختلفی نشان داده شوند.

با استفاده از عملکرد بالاترین جریان ، سریال برای نمایش در اینجا انتخاب می شود زیرا در حال حاضر بالاترین بایت/ثانیه را دارند.

با استفاده از عملکرد HighestMax ، سری داده های نشان داده شده آنهایی هستند که در پنجره View بالاترین اوج را دارند.

با استفاده از بالاترین عملکرد متوسط می توانیم یک فیلتر را برای این سریال که به طور متوسط بیش از پنجره View بود ، بدست آوریم.

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

معیارهای کلیدی کافکا برای نظارت

از دیدگاه ما ، مباحث زیر را پیدا کرده ایم که در نظارت بر کافکا بسیار مفید است:

• پیام های داخل/خارج
• زمان بیکار بودن شبکه
• درخواست زمان بیکار
• پارتیشن های زیر تکرار شده
• انتخابات رهبر
• زمان بیکار CPU
• شبکه میزبان داخل/خارج

برای مرجع ، این همان چیزی است که ما در گرافیت لیست می کنیم تا آن را باتلاق نکنیم:

خلاصه آن

کافکا نقش مهمی در معماری ما دارد و ثابت شده است که هم پایدار و هم قابل اعتماد است. با این حال ، این بدون کار و محافظت های اضافی نیست. ظرفیت باید به خوبی برنامه ریزی شود و یک سیستم نظارت دقیق باید در جای خود قرار بگیرد.

برای پایان دادن به این قطعه ، در اینجا برخی از توصیه های نهایی برای کسانی که مایل به اجرای کافکا به عنوان یک کارگزار پیام با حجم بالا هستند ، آورده شده است: