Belajar Apache Kafka - Alerting & Health Checks

#Pendahuluan

Monitoring memberi kalian data; alerting yang mengubah data menjadi tindakan. Tanpa alert yang baik, metrik hanya menumpuk di dashboard — masalah nyata baru terdeteksi ketika pengguna melaporkan. Episode 23 ini membahas cara membangun sistem alerting yang efektif untuk Kafka: health checks, alert kritis, dan integrasi ke kanal notifikasi.

Kunci alerting yang baik bukan kuantitas, melainkan selektivitas. Alert harus menandakan sesuatu yang benar-benar membutuhkan tindakan, menghindari alert fatigue, dan menyediakan konteks yang cukup untuk respons cepat.

#Strategi Health Check

#Broker Liveness

Pemeriksaan dasar: apakah broker merespons? Gunakan CLI untuk menguji koneksi dan API:

bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092 --version-check

kafka-broker-api-versions.sh --version-check memastikan broker merespons versi API. Untuk pemeriksaan berkala, jalankan perintah ini secara cron dan beri tahu jika gagal — ini memverifikasi koneksi TCP, protokol, dan handler sekaligus.

#Cluster Health Metrics

Selain liveness per broker, pantau kesehatan agregat:

• ActiveControllerCount = 1: lebih dari satu atau nol menandakan masalah.
• UnderReplicatedPartitions = 0: setiap nilai lebih dari nol perlu investigasi.
• OfflinePartitions = 0: partition tanpa leader adalah kondisi kritis.
• Ketersediaan tulis: coba produksi record uji dan verifikasi sampai tersimpan.

#Topic Availability dan Consumer Health

• Topic availability: pastikan topic kritis memiliki semua partition dengan leader. Pantau juga min.insync.replicas agar acks=all tidak gagal.
• Consumer health: consumer group yang hilang dari deskripsi atau lag yang tumbuh menandakan consumer bermasalah. Pantau status group dan kecepatan konsumsi.

#Alert Kritis

#Under-Replicated dan Offline Partition

Threshold yang disarankan:

• UnderReplicatedPartitions > 0 selama lebih dari beberapa menit: peringatan (warning); replikasi belum sembuh.
• OfflinePartitions > 0: kritis (critical); data tidak tersedia.
• ActiveControllerCount != 1: kritis.

Aturan Prometheus yang umum:

- alert: KafkaUnderReplicatedPartitions
  expr: kafka_server_replicamanager_underreplicatedpartitions > 0
  for: 5m
 
- alert: KafkaOfflinePartitions
  expr: kafka_controller_kafkacontroller_offlinepartitionscount > 0
  for: 1m

for: 5m memberi toleransi transisi agar alert tidak membanjiri saat rebalance normal. Aturan ini hanya memicu ketika kondisi bertahan melewati durasi.

#Controller Flapping dan Lag Spike

• Controller flapping: ActiveControllerCount berubah-ubah cepat menandakan broker tidak stabil — alert kritis karena setiap pergantian controller menunda operasi cluster.
• Consumer lag spike: lag melonjak mendadak, biasanya karena consumer crash atau rebalance. Alert dengan threshold relatif terhadap baseline: misalnya lag melebihi 2x rata-rata atau melewati ambang absolut untuk topic kritis.
• Disk space: ruang tersisa di bawah 20 persen — warning; di bawah 10 persen — kritis.
• Network partition: deteksi melalui metrik request error antar broker atau ketidakkonsistenan ISR.

#Integrasi Alert

#PagerDuty dan OpsGenie

Untuk kejadian kritis, integrasi on-call: Prometheus Alertmanager mengirim alert ke PagerDuty atau OpsGenie, yang melakukan eskalasi ke tim yang berjaga. Buat severity yang jelas: critical (halaman on-call) versus warning (email/Slack), sehingga hanya masalah nyata yang membangunkan orang.

#Slack Notifications

Kanal non-kritis atau notifikasi gabungan dikirim ke Slack:

receivers:
  - name: "slack-ops"
    slack_configs:
      - channel: "#kafka-alerts"
        send_resolved: true

slack_configs mengarahkan notifikasi ke kanal tertentu dengan send_resolved: true agar tim tahu masalah sudah selesai. Sertakan konteks alert — broker mana, metrik apa, sejak kapan — dalam pesan.

#Custom Webhooks dan Remediation

Untuk kebutuhan khusus, Alertmanager bisa memanggil webhook kustom. Ini membuka otomatisasi remediasi: webhook memicu script yang menyelidiki broker bermasalah, mengumpulkan thread dump, atau mengeksekusi aksi perbaikan standar. Mulai dari investigasi otomatis yang aman, lalu perluas ke remediasi setelah aksi terbukti andal.

#Penutup

Di episode 23 ini kalian sudah memahami strategi health check broker dan cluster, alert kritis untuk under-replicated partition, offline partition, controller flapping, dan lag spike, serta integrasi alert ke PagerDuty, Slack, dan webhook kustom.

Inti yang harus dibawa pulang:

• Health check menguji liveness dan kesehatan cluster secara berkala.
• OfflinePartitions dan controller flapping adalah alert kritis.
• Gunakan for duration untuk menghindari alert fatigue saat rebalance normal.
• PagerDuty untuk kritis, Slack untuk warning; pisahkan severity.
• Lag spike dan disk space butuh threshold yang jelas.
• Setiap alert wajib punya runbook dan konteks yang cukup.

Di episode 24 selanjutnya kita akan membedah replication dan high availability — leader dan follower replica, In-Sync Replicas, high watermark, unclean leader election, min.insync.replicas, dan rack awareness untuk isolasi failure domain.