در این مقاله نکاتی ظریف و ملاحظاتی برای نظارت بر اپلیکیشن‌های بلادرنگ کافکا و شرایط هشدار، متر و معیار و مدخل‌های آن آورده شده است.
معرفی
آپاچی کافکا® یک پلتفرم جریان توزیع شده و مقاوم در برابر خطا است. از کافکا می‌توان برای پردازش جریان‌های داده بلادرنگ استفاده کرد. من آموخته‌های حاصل از تجربیاتم در زمینه استفاده از روت برنامه پخش جریانی کافکا را در این مقاله بیان کرده‌ام. نظارت (monitoring) به مشاهده سیستم و کشف مسائل و مشکلات، قبل از بروز آن‌ها کمک می‌کند. در زمان هشدار، آلارم‌ها را برای دریافت alert و پارامترهای بحرانی سیستم افزایش دهید.هنگامی که نظارت و هشدار، هر دو به صورت آگاهانه استفاده شوند، می‌توانند میزان زوال سلامت هر اپلیکیشن با داده‌های گسترده را تعیین کنند.
مشکل پارامترها و متر و معیارهای موجود
در چنین سیستمی، مشکل اصلی تعداد پارامترها و مترومعیارهای موجود است. به عنوان مثال، بیش از 250 متر و معیار JMX از واسط کافکا، مصرف‌کننده، زوکیپر، تکثیرکننده و غیره وجود دارد. اگر همه آن‌ها برای نظارت و هشدار استفاده شوند، اوضاع آشفته می‌شود. برای این کار، نیاز به یک استراتژی برای تعیین معیارهای خاص برای مشاهده‌پذیری و نظارت و همچنین آستانه‌ای برای هشدارهای آگاهانه وجود دارد. هشدارها همچنین باید تجمیع را درنظر بگیرند و آمار مثبت (پوزتیو) کاذب را کاهش دهند.
در این مقاله، معیارهایی را که عمدتاً در یکی از اپلیکیشن‌های جریان داده بزرگ کافکا استفاده کرده بودیم، فهرست می‌کنم.
هشدار و نظارت بر اپلیکیشن(های) جریانی کافکا
راه حل نظارت و هشدار هوشمند چیست؟
این‌ها سؤالاتی هستند که در هنگام طراحی استراتژی هشدار و نظارت کافکا باید پرسیده شوند:
- معیارهای نظارت و هشدار چیست؟
- سیگنال‌های طلایی در نظارت چیست؟
- معیارهای کلیدی برای نظارت در برنامه‌های جریانی کافکا، واسط‌های کافکا، زوکیپر و تکثیرکننده کافکا کدامند؟
- نظارت بر عملکرد برنامه جریانی کافکا چیست؟
- چگونه مشکلات فعلی و احتمالی را شناسایی کنیم؟
- تجمیع هشدارها و منطق پشت آن چیست؟
سیگنال‌های طلایی چیست؟
مهندسان قابل اطمینان سایت گوگل (SREs) چهار معیار کلیدی برای نظارت تعریف کرده‌اند. آن‌ها این چهار معیار را «چهار سیگنال طلایی» می‌نامند: تأخیر، ترافیک، خطاها و اشباع شدگی.
تأخیر: زمانی که برای سرویس‌دهی به یک درخواست طول می‌کشد. زمانی که برای رسیدن رکورد از منبع به سینک صرف می‌شود.
ترافیک: تعداد درخواست‌های دریافت شده در هر ثانیه / تعداد رکوردهای پردازش شده در خط لوله داده.
خطاها: میزان درخواست‌هایی که با شکست مواجه می‌شود. شکست‌ها می‌توانند آشکار باشند.
اشباع شدگی: بازده خدمات با نزدیک شدن به حد اشباع شدگی، کاهش می‌یابد. مثلاً نشانگر CPU، حافظه، فضای هارددیسک و غیره.
بیایید نگاهی به معیارهای اجزای مختلف کافکا بیندازیم. نمودار زیر معیارهای مختلف موجود در یک برنامه ساده پخش کافکا را نشان می‌دهد. امیدواریم این به تصور شما از مراحلی که معیارها باید مورد نظارت قرار بگیرند، کمک کند. این مقاله فهرستی از معیارهای انتخابی را ارائه می‌دهد که می‌توانید آن‌ها را به نمودار زیر ارتباط دهید.
برنامه پخش جریانی
لطفا قبل از بررسی متر و معیارها و مدخل‌ها، اسناد برنامه پخش جریانی کافکا را مرور کنید.
https://kafka.apache.org/31/documentation/streams/architecture
کُندی مصرف‌کننده
تأخیر مصرف‌کننده را می‌توان با استفاده از ابزار خط فرمان گروه‌های مصرف کننده کافکا یا با استفاده از معیار JMX مصرف‌کننده کنترل کرد. افزایش کندی (lag) به این معنی است که برنامه‌ها عملکرد کندتری دارند و تأخیر در حال افزایش است.
MBean
kafka.consumer:type=consumer-fetch-manager-metrics,client-id={client-id}
Attribute: records-lag-max.
توان عملیاتی
میانگین تعداد رکوردهای ارسال شده در هر ثانیه برای یک موضوع را توان عملیاتی می‌گویند. اگر توان عملیاتی کمتر باشد، تأخیر بیشتر می‌شود. برای یک سیستم پایدار، توان عملیاتی باید حداقل 1.5 برابر حد بحرانی واقعی باشد.
به‌عنوان مثال، اگر سیستم شما به 75 پیام در ثانیه نیاز دارد، و یکی پردازش سیستم را با 115 پیام در ثانیه انجام بدهد، حد هشدار در 90 پیام بر ثانیه و حد هشدار بحرانی در کمتر از 75 پیام بر ثانیه است. این مثال سعی می‌کند نشان دهد که چگونه می‌توان هشدارهای هوشمند را برای جلوگیری از مثبت کاذب تنظیم کرد و برای تعیین سلامت و اقدامات اصلاحی زمان گذاشت. آستانه بسیار بالاتر مستلزم مهندسی بیش از حد است و آستانه پایین‌تر زمان کمتری برای انجام اقدامات اصلاحی لازم دارد.
MBeankafka.producer:type=producer-topic-metrics,client-id=([-.w]+),topic=([-.w]+)Atttribute: record-send-rate
تأخیر فرآیند
]میانگین/حداکثر[ زمان اجرا بر حسب نانوثانیه، برای عملیات مربوط به این وظیفه.
MBean:kafka.streams:type=stream-metrics,client-id=([-.\w]+)Attribute: process-latency-avg | max
نرخ عضویت در گروه مصرف‌کننده
تعدد عضویت در گروه بر حسب ثانیه.
MBean:kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.w]+)Atttribute: join-rate
معیارهای کلیدی واسط کافکا
آیا می‌دانید واسط تا چه میزان بارگذاری شده است؟
معیارهای مهم واسط عملیاتی که در صورت لزوم در سرتاسر خوشه، در هر واسط یا هر تاپیک جمع‌آوری شده‌است را دنبال کنید.
- تجمیع نرخ ورودی پیام
kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec
- نرخ بایت ورودی توسط کلاینت ها
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
- نرخ درخواست
kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower}
- میزان نرخ بایت خروجی توسط کلاینت ها
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec
- RequestQueueSize : اندازه صف درخواست. یک صف در خواست متراکم قادر به پردازش درخواست‌های ورودی یا خروجی نخواهد بود.
kafka.network:type=RequestChannel,name=RequestQueueSize
- آیا بررسی کرده‌اید که زمان درخواست در کجا صرف می‌شود؟
کل زمانی که در هر میکروثانیه صرف درخواست خاصی می‌شود.
kafka.network:type=RequestMetrics,name=TotalTimeMs,request={Produce|FetchConsumer|FetchFollower}
مدخل و متر و معیارهای بحرانی
تعداد کنترلرهای فعال کافکا
- شرح:
کنترلر مسئول حفظ فهرست لیدرهای پارتیشن و هماهنگی انتقال رهبری است.
- اگر ActiveControllerCount کوچک‌تر از 1 باشد: تولید کنندگان/مصرف‌کنندگان دیگر نمی‌توانند رهبری پارتیشن را دریافت کنند.
- اگر ActiveControllerCount بزرگتر از 1 باشد: مشکل دوپارگی ذهن رخ می‌دهد، و این واقعاً بد است!
- متر و معیار:
معیار JMX را جمع کنید
kafka.controller:type=KafkaController,name=ActiveControllerCount across the cluster.
پارتیشن‌های آفلاین کافکا
- شرح:
پارتیشن آفلاین پارتیشنی بدون لیدر فعال است و از این رو قابل نوشتن یا خواندن نیست. وجود پارتیشن‌های آفلاین، قابلیت دسترسی به داده‌های خوشه را به خطر می‌اندازد.
- متر و معیار:
JMX را جمع کنید
kafka.controller:type=KafkaController,name=OfflinePartitionsCount across the cluster
المثنی (Replica)
تحت پارتیشن‌های تکراری
- شرح:
در یک خوشه سالم، تعداد کپی‌های همگام‌سازی (ISR) باید دقیقاً برابر با تعداد کل کپی‌ها باشد. به عبارت دیگر، متر و معیار اطمینان حاصل می‌کند که پارتیشن‌ها به پیکربندی فاکتور تکرار موضوع اعتبار قائل باشند. پارتیشن‌های تحت تکثیر می‌توانند زمانی کارشان را انجام دهند که یک واسط از کار افتاده باشد یا نتواند با سرعت کافی از لیدر کپی‌برداری کند. (تأخیر واکشی المثنی)
- متر و معیار:
مجموع JMX
kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions across the cluster
تحت Min In Sync Replicas
- شرح:
هنگامی که کافکا برای دوام بالاتر پیکربندی شده است، تولیدکنندگان با acks=all پیکربندی می‌شوند. همچنین تاپیک‌ها باید با min.insync.replicas پیکربندی شوند. اگر پارتیشن‌ها کمتر از min.insync.replicas داشته باشند، کلاینت‌ها به خاطر استثنای NotEnoughReplicas نمی‌توانند تولید کنند. و بسته به پیکربندی سازنده ممکن است دوباره تلاش کنند. به طور خلاصه، وقتی پارتیشنی تحت حداقل ISR دارید، تولید داده مسدود می‌شود.
- متر و معیار:
مجموع JMX
kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount across the cluster
شبکه واسط و I/O
فعالیت IO واسط
- شرح:
یک گره کارگزار داخلی برای خواندن پیامی از صف درخواست از ترد I/O استفاده می‌کند، آن را در حافظه پنهان صفحه سیستم عامل می‌نویسد و در Purgatory قرار می‌دهد. جایی که استراتژی تکرار شما اجرا می‌شود. زمان بیکاری (idle) ترد، سطحی از میزان استفاده را در I/O واسط فراهم می‌کند:
- When idle==1: واسط غیرفعال است.
- When idle==0: واسط همیشه در حال پردازش است.
میزان این درصد بین 0 تا 1 است. 1 به معنای بیکاری 100 درصد و 0.4 به معنای بیکاری 40 درصدی است.
- متر و معیار:
JMX MBean
kafka.network:type=SocketServer,name=RequestHandlerAvgIdlePercent (monitored per broker)
فعالیت شبکه واسط کافکا
- شرح:
همانند بالا، یک گره واسط از ترد شبکه برای خواندن پیامی از شبکه استفاده می‌کند و آن را در صف درخواست قرار می‌دهد.
- When idle==1: کارگزار ترافیک ورودی ندارد.
- When idle==0: کارگزار دائماً در حال دریافت پیام است.
میزان این درصد بین 0 تا 1 است. 1 به معنای بیکاری 100 درصد و 0.4 به معنای بیکاری 40 درصدی است.
- متر و معیار:
JMX MBean
kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent (monitored per broker)
ZooKeeper
متوسط تأخیر زوکیپر کافکا
Metric: JMX AvgRequestLatency
کانکشن‌های زوکیپر
Metric: JMX NumAliveConnections
دیسکانکشن‌های زوکیپر واسط
Metric: JMX
kafka.server:type=SessionExpireListener,name=ZooKeeperDisconnectsPerSec
مدخل‌های متر و معیار سخت‌افزاری
- 1- 60 درصد استفاده از دیسک برای دیسک‌هایی که لاگ کافکا را ذخیره می‌کنند. (پیکربندی شده از طریق dirs)
- 2- 60 درصد استفاده از IO دیسک
- 3- 60 درصد استفاده از IO شبکه
- 4- 60 درصد استفاده از فایل هندل
Confluent Replicator به شما امکان می‌دهد به راحتی و با اطمینان تاپیک‌ها را از یک خوشه کافکا به خوشه دیگر تکرار کنید. Replicator علاوه بر کپی کردن پیام‌ها، تاپیک‌های مورد نیاز را با حفظ پیکربندی تاپیک در خوشه منبع ایجاد می‌کند.
متغیر محیطی JMX_PORT را تنظیم کنید
در صورتی که برنامه در چند منطقه قرار گرفته باشد، می‌توان از متر و معیارهای مشابه و لیست مدخل زیر استفاده کرد.
متر و معیارهای تکرارکننده MBean:
confluent.replicator:type=confluent-replicator-task-metrics,confluent-replicator-task=([-.w]+),confluent-replicator-task-topic-partition=([-.w]+)
عملیات StateFul
برای اپلیکیشن StateFul، نویسنده نظارت را با استفاده از معیارهای زیر پیشنهاد می‌کند. بر اساس بحرانی بودن برنامه و الزامات غیرعملکردی، مدخل‌ها را می‌توان تنظیم کرد.
متر و معیارهای Streams — State Store
- put-latency-max
حداکثر زمان اجرای put (قراردهی) بر حسب نانوثانیه.
kafka.streams:type=stream-[store-scope]-metrics,client-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
- put-if-absent-latency-max
حداکثر زمان اجرای put-if-absent بر حسب نانوثانیه.
kafka.streams:type=stream-[store-scope]-metrics,client-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
- get-latency-max
حداکثر زمان اجرای get (دریافت) برحسب نانوثانیه.
kafka.streams:type=stream-[store-scope]-metrics,client-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
- delete-latency-max
حداکثر زمان اجرای delete (حذف) برحسب نانوثانیه.
لورم ایپسوم متن ساختگی با تولید سادگی نامفهوم از صنعت چاپ و با استفاده از طراحان گرافیک است چاپگرها و متون بلکه روزنامه و مجله در ستون و سطرآنچنان که لازم است.
kafka.streams:type=stream-[store-scope]-metrics,client-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
- restore-latency-max
حداکثر زمان اجرای restore (بازیابی) بر حسب نانوثانیه.
kafka.streams:type=stream-[store-scope]-metrics,client-id=([-.\w]+),task-id=([-.\w]+),[store-scope]-id=([-.\w]+)
متر و معیارهای Streams — Record Cache
- hitRatio-avg
میانگین نسبت بازدید حافظه کش به عنوان نسبت بازدیدهای حافظه کش به کل درخواست‌های خواندن حافظه کش.
kafka.streams:type=stream-record-cache-metrics,client-id=([-.\w]+),task-id=([-.\w]+),record-cache-id=([-.\w]+)
معیارهای RocksDb
- number-file-errors-total
تعداد کل خطاهای فایل که رخ داده است.
- memtable-hit-ratio
نسبت بازدیدهای memtable، نسبت به همه جستجوها به memtable.
- block-cache-filter-hit-ratio
نسبت تعداد بازدیدهای ککش بلوک برای بلوک‌های فیلتر، نسبت به تمام جستجوهای بلوک‌های فیلتر به حافظه کش بلوک.
ابزارها
زمانی که صحبت از نظارت بر برنامه پخش جریانی کافکا می‌شود، ابزارهای زیادی در بازار وجود دارد. فهرست ابزارهای برجسته‌ای که می‌توان از آن‌ها برا هشدار و نظارت بر کافکا استفاده کرد، به شرح زیر است:
- Confluent Control Centre
- Yahoo Kafka Manager
- LinkedIn Burrow
- KafDrop
- Kafka Tool
- AppDynamics
- Prometheus and Grafana
- Datadoghq
هر یک از پیوندهای فوق، جزئیات چگونگی نصب و استفاده از این ابزارهای موجود را ارائه می‌دهد. پیشنهاد می‌کنم آن‌ها را بررسی کنید.
نویسنده: یاشوانت دشموک، معمار گوگل کلود (دارای گواهینامه)، مهندس ارشد داده، متخصص DevOps، توسعه دهنده Full Stack با منطق قابل استدلال
منبع: مدیوم
Leave feedback about this