Belajar Apache Kafka - Monitoring & Observability

#Pendahuluan

Cluster Kafka yang tidak dipantau adalah bom waktu: replication yang melambat, lag consumer yang menumpuk, atau disk yang penuh bisa merusak produksi tanpa peringatan. Monitoring dan observability memberi kalian visibilitas untuk melihat masalah sebelum menjadi outage.

Episode 22 ini akan membahas cara Kafka mengekspos metrik via JMX, metrik kunci di level broker, producer, consumer, dan topic, integrasi dengan Prometheus dan Grafana, serta tool khusus seperti Burrow untuk memantau consumer lag dengan andal.

#Metrik Kafka

#JMX Metrics

Broker dan klien Kafka mengekspos metrik melalui JMX (Java Management Extensions). Dengan -Dcom.sun.management.jmxremote saat startup, metrik tersedia lewat port JMX. Untuk pengumpulan modern, metrik ini diterjemahkan ke format Prometheus oleh JMX exporter.

Konfigurasi JMX exporter cukup sederhana: file YAML mendaftarkan pola metrik yang ingin diekspos, lalu agent Java melekat ke proses broker:

lowercaseOutputName: true
rules:
  - pattern: "kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent"
    name: kafka_request_handler_avg_idle_percent

kafka.server:type=KafkaRequestHandlerPool adalah pola MBean; aturan ini memetakan metrik JMX ke nama Prometheus. Pola lain untuk broker, producer, dan consumer bisa ditambahkan seperlunya.

#Metrik Broker

Metrik kunci di sisi broker:

• UnderReplicatedPartitions: jumlah partition dengan replica yang tertinggal dari leader. Harus mendekati nol.
• OfflinePartitions: partition tanpa leader — kondisi kritis yang menghentikan tulis dan baca.
• ActiveControllerCount: harus tepat 1 di cluster; lebih dari 1 menandakan konflik.
• Request latency untuk Produce dan Fetch, dipecah per persentil.

#Metrik Producer dan Consumer

• Producer: record-send-rate, record-error-rate, request-latency-avg, dan buffer-available-bytes (kehabisan buffer menandakan producer kewalahan).
• Consumer: records-lag-max (lag terbesar di semua partition), fetch-rate, dan poll-interval-avg — poll yang melebihi max.poll.interval.ms memicu rebalance.

#Metrik Topic

Metrik per topic bisa dilihat dengan deskripsi CLI atau dari metrik JMX berlabel topic: bytes-in, bytes-out, dan message rate per topic. Ini membantu mengidentifikasi topic panas yang mendominasi beban cluster.

#Metrik Kunci untuk Dipantau

#Under-Replicated dan Offline Partition

Dua metrik pertama yang harus masuk dashboard:

bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions

kafka-topics.sh --describe --under-replicated-partitions mencantumkan semua partition yang under-replicated. Jika angkanya naik terus-menerus, broker mungkin lambat menulis atau network terganggu; kombinasi dengan metrik OfflinePartitions memisahkan masalah replikasi dari masalah ketersediaan.

#Consumer Lag

Consumer lag adalah selisih antara log-end-offset (data terbaru di partition) dan current-offset (posisi konsumsi). Lag yang tumbuh menandakan consumer tidak mampu mengejar laju produksi:

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group order-consumers

kafka-consumer-groups.sh --describe --group order-consumers menampilkan per partition: current-offset, log-end-offset, dan lag. Lag sendiri tidak selalu buruk — yang berbahaya adalah lag yang terus bertambah.

#Disk, Network, dan Request Rate

• Disk usage dan I/O: disk penuh adalah penyebab outage paling umum; pantau ruang dan I/O wait.
• Network throughput: bytes-in/out per broker untuk deteksi bottleneck.
• Request handler utilization: persentase waktu handler broker bekerja; nilai tinggi berarti broker jenuh.

#Tool Monitoring

#JMX Exporter dan Prometheus

Alur standar observability open-source:

java -jar jmx_prometheus_javaagent.jar 7071:/etc/kafka/jmx-exporter-config.yml \
  -Dcom.sun.management.jmxremote=true \
  -jar kafka-server-start.jar config/server.properties

jmx_prometheus_javaagent.jar membuka port 7071 dengan metrik dalam format Prometheus, yang kemudian di-scrape oleh Prometheus secara berkala dan divisualisasikan di Grafana. Template dashboard Kafka banyak tersedia — mulai dari situ, lalu sesuaikan.

#Grafana Dashboard

Grafana menggabungkan metrik dari Prometheus menjadi dashboard: kesehatan replikasi, throughput, lag, dan resource broker dalam satu layar. Buat alert di Grafana untuk metrik kunci — alerting detail akan dibahas di episode 23.

#Tool Khusus: Burrow

Burrow dari LinkedIn memantau consumer lag dengan cara yang lebih andal daripada metrik klien: ia membaca langsung dari Kafka, menghitung lag per partition secara stateless, dan menerapkan evaluasi berbasis sliding window untuk menilai status consumer. Keunggulan utama: tidak bergantung pada laporan klien (yang bisa menyesatkan saat klien mati) dan mendeteksi consumer yang mati tapi masih meng-commit.

#Penutup

Di episode 22 ini kalian sudah memahami eksposur metrik JMX, metrik broker, producer, consumer, dan topic, metrik kunci seperti under-replicated partition dan consumer lag, integrasi Prometheus dan Grafana, serta tool monitoring lag seperti Burrow.

Inti yang harus dibawa pulang:

• Semua metrik Kafka lahir dari JMX dan bisa diekspor ke Prometheus.
• UnderReplicatedPartitions dan OfflinePartitions adalah metrik kesehatan pertama.
• Consumer lag harus dipantau trennya, bukan hanya nilainya.
• Disk penuh adalah penyebab outage paling umum — pantau ruang dan I/O.
• Burrow menghitung lag secara stateless dan lebih andal daripada metrik klien.
• Grafana menggabungkan semuanya dalam satu dashboard untuk respons cepat.

Di episode 23 selanjutnya kita akan membangun alerting dan health checks — strategi pemeriksaan kesehatan broker dan cluster, alert kritis seperti under-replicated partition dan lag spike, serta integrasi alert ke PagerDuty, Slack, dan webhook kustom.