Pemantauan, Consumer Lag & Kapasitas — Belajar Apache Kafka

Metrik yang Benar-Benar Penting

Metrik	Nilai sehat	Artinya bila menyimpang
`UnderReplicatedPartitions`	0	Replika tertinggal — daya tahan data sedang menurun
`OfflinePartitionsCount`	0	Partisi tanpa leader — produksi dan konsumsi terhenti
`ActiveControllerCount`	Tepat 1 di seluruh klaster	0 berarti tanpa controller; lebih dari 1 berarti split brain
`UnderMinIsrPartitionCount`	0	Penulisan dengan acks=all sedang ditolak
`RequestHandlerAvgIdlePercent`	> 30%	Broker kehabisan thread penangan permintaan
Consumer lag	Stabil / rendah	Konsumen tidak mengejar laju produksi

🚫 UnderReplicatedPartitions > 0 bukan peringatan kecil

Angka ini berarti sebagian replika tidak sinkron, sehingga jumlah salinan data yang benar-benar aman lebih sedikit dari yang Anda kira. Bila broker leader kemudian gagal, kehilangan data menjadi mungkin. Ini termasuk peringatan yang layak membangunkan orang.

Consumer Lag: Angka Tunggal Paling Berguna

lag = offset terakhir di partisi − offset yang sudah di-commit konsumen

Yang menentukan bukan besar angkanya, melainkan arah pergerakannya:

Pola	Tafsiran
Lag kecil dan datar	Sehat
Lag naik terus	Konsumen lebih lambat dari produser — butuh perbaikan atau skala
Lag naik lalu turun berkala	Beban bergelombang; wajar selama sempat kembali normal
Lag melonjak pada satu partisi saja	Kunci pesan tidak merata, atau satu konsumen bermasalah

⚠️ Lag dalam satuan pesan bisa menyesatkan

Lag 100.000 pesan pada topik berlaju 1.000 pesan/detik berarti tertinggal 100 detik. Lag yang sama pada topik berlaju 100.000 pesan/detik berarti tertinggal satu detik. Peringatan sebaiknya berbasis lag dalam satuan waktu, bukan jumlah pesan.

Partisi Panas

🚫 Kunci yang timpang menghancurkan paralelisme

Bila kunci pesan memakai id_penyewa dan satu penyewa besar menghasilkan 80% lalu lintas, satu partisi menerima hampir semua beban sementara sisanya menganggur. Menambah konsumen tidak menolong sama sekali, karena satu partisi tetap dipegang satu konsumen.

Perbaikannya adalah mengubah kunci menjadi lebih halus — misalnya id_penyewa:id_pengguna — selama jaminan urutan yang dibutuhkan masih terpenuhi pada level tersebut.

Kapasitas dan Perencanaan Disk

Kebutuhan disk ≈ laju masuk (byte/hari)
                 × hari retensi
                 × replication factor
                 ÷ rasio kompresi
                 × 1,3   ← ruang cadangan untuk lonjakan dan rebalance

Contoh: 200 GB/hari × 7 hari × 3 replika ÷ 3 (zstd) × 1,3 ≈ 1,8 TB

⚠️ Disk penuh membuat broker mati, bukan sekadar melambat

Broker Kafka yang kehabisan ruang disk akan berhenti, dan pemulihannya rumit karena penghapusan data manual mudah merusak indeks partisi. Pasang peringatan pada 70% pemakaian disk, bukan 90% — Anda membutuhkan waktu untuk bertindak.

Perkakas

JMX Exporter + Prometheus + Grafana — jalur standar; tersedia papan pantau siap pakai untuk broker dan konsumen.
Cruise Control — penyeimbangan ulang partisi otomatis dan penambahan/pengurangan broker.
kafka-consumer-groups.sh — pemeriksaan lag cepat tanpa perkakas tambahan.
AKHQ / Kafka UI / Redpanda Console — antarmuka web untuk menjelajah topik dan pesan.

💡 Empat peringatan minimum

Bila hanya sempat memasang empat peringatan: UnderReplicatedPartitions > 0, OfflinePartitionsCount > 0, lag konsumen kritis melebihi ambang waktu, dan pemakaian disk broker > 70%. Empat ini menangkap sebagian besar insiden nyata.