Dokumen ini menjelaskan cara memantau kondisi klien yang memproduksi atau menggunakan data di cluster Managed Service untuk Apache Kafka Anda.
Penting untuk memantau aplikasi klien sebagai bagian dari strategi keandalan Anda secara keseluruhan. Metrik seperti throughput, tingkat error, dan jeda konsumen dapat memberi tahu Anda apakah aplikasi klien mengalami masalah keandalan. Masalah mungkin disebabkan oleh konfigurasi klien, distribusi kunci yang tidak merata di seluruh partisi, atau masalah cluster yang hanya memengaruhi partisi tertentu.
Metrik sisi server
Meskipun berguna untuk memantau perilaku klien secara langsung, metrik sisi server tidak memerlukan instrumentasi tambahan, dan dapat membantu Anda mendeteksi masalah sisi klien yang memengaruhi keandalan.
Metrik sisi server sangat berguna untuk mendeteksi ketidakseimbangan beban di seluruh broker (broker panas), dan penyimpangan dalam operasi normal, seperti lonjakan latensi.
Throughput
Pantau metrik throughput berikut dan bandingkan dengan throughput yang Anda harapkan:
- Message rate, per broker dan per topik.
- Kecepatan byte, per broker dan per topik.
- Rasio permintaan. Klien yang salah dikonfigurasi mungkin membanjiri broker dengan tingkat permintaan kecil yang tinggi (0-1.000 byte per permintaan), sehingga mengurangi throughput.
- Latensi permintaan. Lonjakan latensi permintaan produsen mungkin menandakan beban yang tidak seimbang atau masalah pada konfigurasi klien.
Kafka menawarkan metrik throughput per topik dan untuk cluster. Metrik ini tidak selalu memiliki nilai yang sama saat digabungkan untuk semua topik. Gunakan metrik gabungan untuk pemantauan dan pemberitahuan tingkat tinggi, serta lihat metrik per topik saat Anda memecahkan masalah throughput. Mengisolasi masalah apa pun ke broker tertentu.
Tingkat error permintaan
Metrik topic_error_count
melacak jumlah permintaan pengambilan dan produksi yang gagal di sisi
server. Namun, beberapa jenis error tidak tercermin dalam metrik ini. Misalnya:
Setelan otorisasi yang salah dikonfigurasi dapat mencegah klien memproduksi ke topik, tanpa error yang muncul dalam metrik ini.
Kegagalan cluster dapat mencegah broker merespons permintaan sama sekali.
Oleh karena itu, Anda juga harus memantau error di sisi klien, termasuk error waktu tunggu permintaan.
Jeda konsumen
Keterlambatan konsumen mengukur seberapa jauh klien konsumen tertinggal dari offset tertentu. Menggabungkan metrik ini berdasarkan topik, partisi, dan broker berguna untuk menentukan apakah keterlambatan disebabkan oleh broker atau partisi tertentu.
Pertimbangkan untuk membuat pemberitahuan berdasarkan jeda maksimum di seluruh subset topik yang penting untuk workload Anda.
Kueri dasbor kustom
Sebaiknya buat dasbor dan pemberitahuan kustom untuk memantau sinyal ini. Tabel berikut menunjukkan kueri Prometheus Query Language (PromQL) yang dapat Anda gunakan untuk memantau kondisi klien.
| Sinyal | Kueri PromQL |
|---|---|
| Throughput: Rasio pesan per broker | sum by (resource_container, location, cluster_id, broker_index) ( rate( { "managedkafka.googleapis.com/message_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| Throughput: Rasio pesan per broker per topik, untuk 5 topik terbesar | topk(5, sum by (resource_container, location, cluster_id, broker_index, topic_id) ( rate( { "managedkafka.googleapis.com/message_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) ) |
| Throughput: Bandwidth per topik dan broker | sum by (resource_container, location, cluster_id, broker_index, topic_id) ( rate( { "managedkafka.googleapis.com/byte_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| Rasio permintaan | sum by (resource_container, location, cluster_id, request) ( rate( { "managedkafka.googleapis.com/request_count", monitored_resource="managedkafka.googleapis.com/Cluster", "request"="Produce" }[${__interval}] ) ) |
| Rasio permintaan, total cluster | sum by (resource_container, location, cluster_id, request) ( rate( { "managedkafka.googleapis.com/topic_request_count", monitored_resource="managedkafka.googleapis.com/Topic", "request"="Produce" }[${__interval}] ) ) |
| Latensi permintaan | sum by (resource_container, location, cluster_id, broker_index, request) ( avg_over_time( { "managedkafka.googleapis.com/request_latencies", monitored_resource="managedkafka.googleapis.com/Cluster", "percentile"="95", "request"="Produce" }[${__interval}] ) ) |
| Jumlah error permintaan | sum by (resource_container, location, cluster_id, broker_index, request) ( rate( { "managedkafka.googleapis.com/topic_error_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| Jeda konsumen: 5 partisi teratas berdasarkan jeda offset | topk(5, max by (resource_container, location, cluster_id, topic_id, partition_index) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
| Jeda konsumen: 5 grup konsumen teratas berdasarkan jeda offset | topk(5, max by (resource_container, location, cluster_id, consumer_group_id) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
Metrik sisi klien
Terkadang masalah klien tidak muncul di metrik server. Contoh:
Jika autentikasi atau jaringan salah dikonfigurasi, pesan mungkin akan menumpuk di antrean internal klien. Saat waktu tunggu permintaan habis, pesan akan dimasukkan kembali ke antrean dan dicoba lagi.
Jika kontrol alur salah dikonfigurasi, klien mungkin menghasilkan lebih banyak pesan daripada yang dapat dikirim oleh jumlah thread yang dialokasikan. Meskipun throughput mungkin konsisten, backlog permintaan yang terus bertambah akan berakhir sebelum dapat dikirim.
Jika klien Anda berjalan di Compute Engine, Google Kubernetes Engine, atau Cloud Run, Anda dapat menggunakan metrik berbasis log di Cloud Monitoring untuk mendeteksi tingkat error yang tinggi dalam log. Namun, beberapa klien Kafka menyembunyikan pengecualian yang menyebabkan percobaan ulang yang berkepanjangan, kecuali jika Anda mengonfigurasi tingkat log yang lebih tinggi. Oleh karena itu, Anda juga harus memantau peningkatan latensi permintaan.
Klien Java mengekspos banyak metrik melalui Java Management Extensions (JMX). Untuk mengetahui informasi selengkapnya, lihat Monitoring dalam dokumentasi Apache Kafka. Jika memungkinkan, prioritaskan instrumentasi klien Anda untuk melaporkan metrik berikut:
- Tingkat error permintaan
(
kafka.producer:type=producer-metrics,client-id="{client-id}") - Latensi rata-rata permintaan
(
kafka.producer:type=producer-metrics,client-id="{client-id}")
Kirim metrik ini ke solusi pemantauan jika memungkinkan. Jika Anda dapat terhubung ke port JMX di mesin yang menjalankan instance klien, Anda juga dapat membaca metrik ini secara interaktif.
Mitigasi
Jika Anda melihat masalah dalam aplikasi klien, pertimbangkan mitigasi berikut:
Cari beban yang tidak seimbang di seluruh broker (hot broker). Pastikan penyeimbangan ulang otomatis diaktifkan di cluster Anda.
Jika rasio permintaan tampak sangat tinggi, periksa apakah klien mengirimkan banyak permintaan kecil. Periksa konfigurasi
max.request.sizedanbatch.sizepada produsen.Periksa konfigurasi klien untuk autentikasi, jaringan, dan kontrol alur.
Lag yang berlebihan di semua topik atau partisi dalam cluster mungkin menunjukkan bahwa cluster kelebihan beban dan harus ditingkatkan skalanya.
Keterlambatan yang berlebihan di semua topik atau partisi dalam broker mungkin menunjukkan bahwa broker kelebihan beban. Coba tingkatkan distribusi kunci atau tetapkan ulang partisi ke broker yang berbeda.