Memantau keandalan cluster Kafka

Dokumen ini menjelaskan cara memantau cluster Managed Service untuk Apache Kafka untuk memastikan keandalan workload Kafka Anda.

Ringkasan

Keandalan adalah kemampuan sistem untuk berfungsi dengan benar dan konsisten dari waktu ke waktu. Untuk beban kerja berbasis Kafka, keandalan mencakup baik klaster Kafka itu sendiri, maupun aplikasi klien yang menghasilkan dan mengonsumsi pesan.

Managed Service untuk Apache Kafka dirancang untuk mentoleransi dan memulihkan diri dari banyak kegagalan umum. Misalnya, layanan menempatkan replika di zona yang berbeda untuk toleransi kesalahan, dan otomatis memulai ulang broker yang gagal. Namun, faktor lain yang memengaruhi keandalan berada di luar kontrol langsung layanan, seperti:

  • Konfigurasi klien
  • Beban pada cluster, termasuk beban rata-rata dan lonjakan
  • Jumlah partisi dan replika
  • Konfigurasi topik, seperti retensi pesan

Untuk mencapai operasi yang andal, penting untuk memantau cluster untuk parameter operasional ini dan menjaganya dalam rentang yang direkomendasikan. Bagian berikut menjelaskan beberapa metrik utama yang penting untuk keandalan.

Memantau kapasitas cluster

Untuk menghindari kelebihan beban pada cluster, pantau sinyal berikut. Buat pemberitahuan untuk memberi tahu Anda jika detak jantung berada di luar rentang yang direkomendasikan untuk jangka waktu yang lama.

  • Penggunaan CPU. Usahakan pemakaian CPU di semua broker tidak lebih dari 80%.

  • Penggunaan disk broker: Pastikan penggunaan disk broker tetap di bawah 80%.

  • Ukuran disk. Sebagai titik awal yang aman, sebaiknya miliki setidaknya 2*(segment.bytes) per partisi per broker. Dalam praktiknya, persyaratan disk sebenarnya sering kali jauh lebih rendah.

    Secara default, file segmen ditutup dan dipindahkan ke penyimpanan jarak jauh setelah 7 hari. Umumnya, sebagian besar partisi menerima kurang dari segment.bytes data selama periode tersebut, yang berarti sebagian besar partisi menggunakan kurang dari segment.bytes ruang disk. Sebelum menambah ukuran disk, pantau penggunaan disk saat Anda membuat lebih banyak partisi di cluster.

  • Jumlah partisi. Usahakan untuk mempertahankan kurang dari 4000 partisi per broker, dan kurang dari 100.000 partisi per klaster.

Jika kapasitas cluster Anda rendah, pertimbangkan mitigasi berikut:

Tabel berikut menunjukkan kueri Prometheus Query Language (PromQL) untuk metrik ini yang dapat Anda tambahkan ke dasbor Cloud Monitoring kustom.

SinyalKueri PromQL
Pemakaian CPU 
rate(
  {
    "managedkafka.googleapis.com/cpu/core_usage_time",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/cpu/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Penggunaan disk broker 
max_over_time(
  {
    "managedkafka.googleapis.com/disk/used_bytes",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Ukuran segmen per partisi 
# Assumes that segment files are 225 MiB. Check your cluster configuration.
2*225*(1024*1024) * max_over_time(
  {
    "managedkafka.googleapis.com/partitions",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Partisi per broker 
max by (resource_container, location, cluster_id, broker_index) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Partisi per cluster 
max by (resource_container, location, cluster_id) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)

Memantau keseimbangan partisi di seluruh broker

Beban yang tidak merata dapat mencegah cluster Kafka melayani permintaan klien dengan benar. Jumlah partisi yang ditetapkan ke satu broker harus tetap dalam sekitar 10% dari jumlah partisi rata-rata per broker. Cari anomali dalam metrik ini.

Untuk mempertahankan partisi yang seimbang, pertimbangkan untuk mengaktifkan penyeimbangan ulang otomatis saat penskalaan di cluster Anda.

Tabel berikut menunjukkan kueri PromQL yang dapat Anda gunakan untuk memantau ketidakseimbangan partisi.

SinyalKueri PromQL
Jumlah partisi per broker 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Ketidakseimbangan partisi 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
/ on (resource_container, location, cluster_id)
  group_left avg by (resource_container, location, cluster_id) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
) - 1

Memantau replikasi partisi

Replikasi data sangat penting untuk memastikan bahwa workload Anda fault-tolerant. Dalam klaster yang sehat, setiap partisi dalam suatu topik memiliki jumlah replika penuh, berdasarkan faktor replikasi yang dikonfigurasi pada topik tersebut.

Gunakan sinyal berikut untuk memantau replikasi partisi:

  • Di bawah replika dalam sinkronisasi (ISR) minimum. Jika partisi memiliki ISR sinkron yang lebih sedikit daripada minimum yang dikonfigurasi (min.insync.replicas), ada risiko serius kehilangan data dan ketersediaan. Biasanya, situasi ini disebabkan oleh kapasitas yang tidak memadai pada satu atau beberapa broker, atau oleh kegagalan infrastruktur.

  • Partisi yang kurang direplikasi. Partisi kurang direplikasi jika jumlah replika yang sinkron kurang dari faktor replikasi. Jika partisi tetap kurang direplikasi selama 10 menit, mungkin ada masalah dengan broker, kapasitas penyimpanan, atau hal lain.

    Selama memulai ulang bertahap, broker menjadi tidak tersedia saat dimulai ulang, sehingga menyebabkan kurangnya replikasi sementara. Situasi ini sudah diperkirakan dan tidak memerlukan intervensi.

Tabel berikut menunjukkan kueri PromQL yang dapat Anda gunakan untuk memantau replikasi.

SinyalKueri PromQL
Di bawah ISR minimum 
max by (
  resource_container,
  location,
  cluster_id
) (
  max_over_time(
    {
      "managedkafka.googleapis.com/broker/under_min_isr_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Dalam replikasi 
max by (
  resource_container,
  location,
  cluster_id
) (
  min_over_time(
    {
      "managedkafka.googleapis.com/broker/under_replicated_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[10m:${__interval}]
  )
)

Langkah berikutnya