Memantau aplikasi klien Kafka

Dokumen ini menjelaskan cara memantau kondisi klien yang menghasilkan atau menggunakan data di cluster Managed Service for Apache Kafka Anda.

Penting untuk memantau aplikasi klien sebagai bagian dari strategi keandalan 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 yang sibuk), dan penyimpangan dalam operasi normal, seperti lonjakan latensi.

Throughput

Pantau metrik throughput berikut dan bandingkan dengan throughput yang Anda harapkan:

  • Tingkat pesan, per broker dan per topik.
  • Kecepatan byte, per broker dan per topik.
  • Rasio permintaan. Klien yang salah dikonfigurasi dapat membanjiri broker dengan permintaan kecil yang memiliki kecepatan tinggi (0-1000 byte per permintaan), sehingga mengurangi throughput.
  • Latensi permintaan. Lonjakan latensi permintaan produsen dapat 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 diagregasi 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 pembuatan 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 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 menurut topik, partisi, dan broker berguna untuk menentukan apakah jeda 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 performa klien.

SinyalKueri PromQL
Throughput: Kecepatan 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: Tingkat 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 kluster 
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}]
  )
)
Keterlambatan konsumen: 5 partisi teratas berdasarkan keterlambatan konsumen 
topk(5,
  max by (resource_container, location, cluster_id, broker_index, topic_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/consumer_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartition"
      }[${__interval}]
    )
  )
)

Metrik sisi klien

Terkadang, masalah klien tidak muncul dalam metrik server. Contoh:

  • Jika autentikasi atau jaringan salah dikonfigurasi, pesan dapat menumpuk di antrean internal klien. Saat waktu tunggu permintaan habis, pesan akan dimasukkan kembali ke dalam antrean dan dicoba lagi.

  • Jika kontrol alur salah dikonfigurasi, klien dapat menghasilkan lebih banyak pesan daripada jumlah thread yang dialokasikan dapat dikirim. 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 rasio 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 pengukuran 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 dapat terhubung ke port JMX di komputer yang menjalankan instance klien, Anda juga dapat membaca metrik ini secara interaktif.

Mitigasi

Jika Anda melihat masalah di aplikasi klien, pertimbangkan mitigasi berikut:

  • Cari beban yang tidak seimbang di seluruh broker (broker yang sibuk). Pastikan penyeimbangan ulang otomatis diaktifkan di cluster Anda.

  • Jika kecepatan permintaan tampak sangat tinggi, periksa apakah klien mengirimkan sejumlah besar permintaan kecil. Periksa konfigurasi max.request.size dan batch.size di produsen.

  • Periksa konfigurasi klien untuk autentikasi, jaringan, dan kontrol alur.

  • Lag yang berlebihan di semua topik atau partisi dalam cluster dapat menunjukkan bahwa cluster kelebihan beban dan harus di-scale up.

  • Lag yang berlebihan di semua topik atau partisi dalam broker dapat menunjukkan bahwa broker kelebihan beban. Coba tingkatkan distribusi kunci atau tetapkan ulang partisi ke broker yang berbeda.

Langkah berikutnya