Broker Health: Mengukur Kesiapan dan Kesehatan Node Kafka di Produksi #

Mengelola kluster Apache Kafka di tingkat produksi menuntut kita untuk selalu mengetahui status kesehatan setiap node broker secara akurat. Namun, mendefinisikan kesehatan sebuah broker Kafka tidaklah sesederhana memeriksa apakah proses JVM (Java Virtual Machine) miliknya sedang berjalan atau tidak. Sebuah broker bisa saja “hidup” secara proses OS, namun secara fungsi ia lumpuh karena mengalami kegagalan sistem berkas disk (disk I/O hang), kehabisan batas berkas deskriptor (file descriptor exhaustion), atau sedang terjebak dalam proses pemulihan log (log recovery path) yang memakan waktu berjam-jam setelah mati mendadak.

Untuk mengamankan kestabilan sistem, kita harus membedakan antara konsep ketersediaan dasar proses (Liveness) dengan kesiapan broker untuk melayani lalu lintas replikasi dan klien (Readiness). Kita juga harus memahami siklus hidup internal broker, memantau kesehatan tingkat sistem operasi, dan mengintegrasikan probe kesehatan otomatis pada platform orkestrasi seperti Kubernetes.

Dalam artikel ini, kita akan mengupas tuntas perbedaan liveness vs readiness pada Kafka, memetakan diagram status transisi siklus hidup broker, mendiagnosis parameter OS krusial, mempelajari toleransi kegagalan disk JBOD, serta menyusun konfigurasi Kubernetes health probes yang tepat.

Perbedaan Liveness vs Readiness pada Apache Kafka #

Di dalam ekosistem sistem terdistribusi modern, liveness dan readiness memiliki definisi operasional yang berbeda:

1. Liveness (Keaktifan Proses) #

Menunjukkan apakah proses JVM Apache Kafka berjalan di sistem operasi dan mampu mengeksekusi thread dasar. Jika suatu broker kehilangan liveness-nya (misalnya karena mengalami kebocoran memori OOM atau JVM crash), sistem operasi atau orkestrator (seperti systemd atau Kubernetes) harus segera membunuh dan menyalakan kembali (restart) proses broker tersebut.

2. Readiness (Kesiapan Fungsi) #

Menunjukkan apakah broker telah menyelesaikan inisialisasi internal dan siap melayani permintaan baca/tulis dari produser dan konsumen, serta siap bertindak sebagai pemimpin (leader) partisi. Sebuah broker bisa saja hidup (liveness terpenuhi), tetapi tidak siap (readiness gagal) saat ia sedang memuat indeks log raksasa dari disk selama startup. Selama broker belum siap, ia tidak boleh menerima lalu lintas klien baru.

Siklus Hidup Internal Kafka Broker (State Machine) #

Selama masa operasinya, setiap broker Kafka bertransisi melalui serangkaian status internal. Mari kita pelajari diagram alur transisi status broker (Broker Lifecycle) berikut:

stateDiagram-v2
    [*] --> Offline
    Offline --> Starting : Proses JVM Dinyalakan
    Starting --> Recovering : Memuat Log Segmen dari Disk
    Recovering --> Running : Terhubung ke Controller (KRaft/ZK) & Metadata Sinkron
    Running --> ShuttingDown : Menerima Sinyal SIGTERM (Clean Shutdown)
    Running --> Offline : Crash / Terbakar Disk / SIGKILL (Unclean)
    ShuttingDown --> Offline : Migrasi Replicas Selesai

Penjelasan Status Siklus Hidup: #

1. Offline: Broker belum aktif atau proses JVM-nya telah mati sepenuhnya.
2. Starting: Proses JVM mulai menyala, membaca konfigurasi server.properties, mengalokasikan buffer memori, dan menginisialisasi socket listener.
3. Recovering: Broker memindai seluruh direktori data (log.dirs) untuk memuat file indeks. Jika sebelumnya broker mati secara tidak bersih (unclean shutdown akibat listrik padam atau crash), broker akan menjalankan Log Recovery. Proses ini memindai pesan di dalam log segmen untuk membangun ulang file indeks .index dan .timeindex yang rusak. Pada disk berukuran terabyte, proses verifikasi serial ini bisa memakan waktu puluhan menit hingga beberapa jam, di mana selama proses ini broker belum siap melayani klien.
4. Running: Broker sukses terhubung ke kuorum pengawas (KRaft Controller atau ZooKeeper), menyinkronkan metadata kluster, melayani replikasi data, dan mulai memproses request baca/tulis klien.
5. Shutting Down: Broker menerima sinyal penghentian bersih (SIGTERM). Sebelum benar-benar mati, broker menjalankan Controlled Shutdown di mana ia memindahkan status kepemimpinan (leader election) seluruh partisinya secara anggun ke broker lain di dalam ISR, mengamankan penulisan sisa data dari page cache ke disk, dan memutuskan koneksi klien secara aman untuk meminimalisir interupsi data.

Pembedahan Log Recovery: File Checkpoint & Multi-Threading #

Ketika broker Kafka dihentikan secara normal (clean shutdown), broker menulis file checkpoint kecil bernama clean-shutdown-checkpoint ke dalam setiap direktori data log. Keberadaan file ini menandakan kepada broker pada startup berikutnya bahwa seluruh data log di disk telah disiram (flushed) sepenuhnya dan file indeks tidak ada yang korup.

Namun, jika terjadi mati lampu, kernel panic, atau server di-kill secara paksa (kill -9), file checkpoint ini tidak sempat ditulis. Hal ini memicu skenario Unclean Shutdown pada startup berikutnya:

flowchart TD
    Start["Startup Proses Broker Kafka"] --> Check{"Apakah 'clean-shutdown-checkpoint' Ada?"}
    Check -- "Ya" --> Clean["Langsung Muat Induk Segmen (Waktu startup < 1 Menit)"]
    Check -- "Tidak" --> Unclean["Jalankan Scan Log Segmen<br/>* Scan offset pasca recovery-point<br/>* Rekonstruksi berkas .index dan .timeindex<br/>* Waktu startup: Menit s.d. Jam"]

Optimasi Waktu Recovery #

Secara bawaan, Java hanya menggunakan 1 thread per direktori data untuk memverifikasi segmen log. Jika kita menggunakan JBOD dengan 12 disk fisik, membiarkan setelan ini default akan membuat verifikasi berjalan lambat dan bergiliran. Kita harus mengonfigurasi parameter parallel recovery threads untuk mempercepat startup broker pasca crash:

# server.properties - OPTIMASI LOG RECOVERY THREADS
# Setel jumlah thread pemulihan per direktori data
# Sangat disarankan disetel sama dengan jumlah disk fisik pada JBOD (misal 4 disk)
num.recovery.threads.per.data.dir=4

Dengan parameter ini, broker akan memanggil 4 thread paralel untuk memproses 4 direktori disk secara bersamaan, sehingga mempercepat waktu recovery hingga 4 kali lipat dan mengurangi masa tunggu unready pada kluster.

Analisis Mendalam controlled Shutdown (Penghentian Bersih) #

Menyetel Controlled Shutdown agar berjalan dengan sukses adalah kunci utama pemeliharaan kluster tanpa downtime. Ketika kita memperbarui OS server atau menaikkan versi Kafka (rolling upgrades), kita harus mematikan broker satu per satu.

Berikut adalah 4 tahapan eksekusi Controlled Shutdown ketika broker menerima sinyal SIGTERM:

1. Notifikasi ke Controller: Broker target mengirimkan request ControlledShutdownRequest ke active controller.
2. Migrasi Kepemimpinan (Leader Evacuation): Controller segera mencari broker alternatif di dalam ISR untuk mengambil alih kepemimpinan partisi aktif yang saat ini dipimpin oleh broker target. Selama fase ini, klien produser/konsumen akan otomatis diarahkan ke leader baru tanpa interupsi kegagalan.
3. Flushing Page Cache: Broker target menyiram seluruh sisa data log segmen yang masih tertahan di memori page cache OS ke dalam media penyimpanan disk fisik.
4. Shutdown socket: Setelah seluruh leader dipindahkan dan data aman ditulis, broker menutup socket listener internal dan menghentikan proses JVM.

Konfigurasi controlled shutdown di server.properties:

# server.properties - CONTROLLED SHUTDOWN
controlled.shutdown.enable=true
controlled.shutdown.max.retries=3
controlled.shutdown.retry.backoff.ms=5000

Tip Pemeliharaan: Jika migrasi leader tidak selesai dalam waktu tertentu (misalnya karena ada partisi yang tidak sinkron/ISR pincang), controlled shutdown akan gagal dan broker akan fallback ke shutdown biasa. Memantau kegagalan ini sangat penting agar kita tidak merusak durabilitas data.

Diagnostik Kesehatan Tingkat Sistem Operasi (OS) #

Kesehatan broker Kafka sangat dipengaruhi oleh limitasi sumber daya pada kernel Linux. Administrator wajib memantau dan menyetel parameter-parameter berikut:

1. Penggunaan Kapasitas Disk (Disk Space Exhaustion) #

Jika disk yang menampung direktori data Kafka penuh 100%, sistem penyimpanan broker akan mengalami kemacetan total. Kafka tidak dapat menulis pesan baru, dan thread pembersih log segmen (log.retention) akan gagal berjalan. Lebih buruk lagi, crash akibat disk penuh sering kali memicu kerusakan file indeks segmen (index corruption).

• Mitigasi: Selalu pasang alarm peringatan (alert) ketika penggunaan disk mencapai 80% dan alarm kritis pada 90% agar kita memiliki waktu untuk melakukan ekspansi volume disk atau mempercepat masa retensi topik.

2. Batas Berkas Deskriptor (Open File Descriptors) #

Setiap partisi di Apache Kafka membuka minimal dua file di disk (file .log dan .index), ditambah koneksi TCP socket dari ribuan klien. Jika batas maksimum berkas deskriptor (file descriptors limit) di Linux terlalu rendah, broker akan melontarkan error fatal java.io.IOException: Too many open files dan crash seketika.

• Mitigasi: Edit berkas /etc/security/limits.conf dan naikkan batas untuk user kafka:

  kafka  soft  nofile  100000
  kafka  hard  nofile  100000
  

3. Kehabisan Port Socket (Socket Port Depletion) #

Jika klien terhubung dan terputus dari broker secara terus-menerus tanpa menggunakan pooling koneksi yang baik, socket TCP akan terjebak dalam status TIME_WAIT di tingkat OS broker. Jika jumlahnya menumpuk, broker akan kehabisan alokasi port lokal.

• Mitigasi: Sesuaikan parameter kernel sysctl di /etc/sysctl.conf untuk mendaur ulang socket secara cepat:

  net.ipv4.tcp_tw_reuse = 1
  net.ipv4.tcp_fin_timeout = 15
  

Toleransi Kegagalan Disk (JBOD & Offline Log Directories) #

Di lingkungan bare-metal, kita sering mengonfigurasi penyimpanan broker menggunakan skema JBOD (Just a Bunch of Disks) dengan mendaftarkan banyak mount-point disk ke parameter log.dirs di server.properties:

# server.properties - KONFIGURASI JBOD
log.dirs=/mnt/disk1/kafka-data,/mnt/disk2/kafka-data,/mnt/disk3/kafka-data

Apache Kafka memiliki fitur ketahanan bawaan yang sangat hebat untuk menangani kegagalan salah satu disk dalam JBOD tanpa harus mematikan seluruh proses broker. Jika disk /mnt/disk2/ mengalami kerusakan hardware atau sistem berkasnya menjadi Read-Only:

1. Kafka akan mendeteksi kegagalan I/O tersebut dan menandai direktori /mnt/disk2/kafka-data sebagai Offline Log Directory.
2. Broker akan menonaktifkan seluruh partisi yang tersimpan di dalam disk tersebut dan melaporkan status URP ke kluster agar broker lain mengambil alih kepemimpinan partisi tersebut.
3. Broker tetap berjalan normal untuk melayani aktivitas baca/tulis partisi lain yang tersimpan di /mnt/disk1/ dan /mnt/disk3/.

Metrik JMX untuk memantau direktori offline ini adalah:

• MBean: kafka.log:type=LogManager,name=OfflineLogDirectoryCount
• Tindakan: Buat alert jika nilai metrik ini > 0, menandakan ada disk broker yang rusak secara fisik dan harus diganti.

Integrasi Kubernetes Health Probes #

Jika kita menjalankan Apache Kafka di dalam Kubernetes (misalnya menggunakan Strimzi Operator), kita wajib mengonfigurasi livenessProbe and readinessProbe secara presisi untuk menghindari siklus reboot tanpa henti (restart loops) saat broker sedang memulihkan log.

Sering kali tim menyetel livenessProbe yang memeriksa port TCP Kafka dengan timeout yang terlalu agresif. Saat broker mengalami unclean shutdown dan harus memproses Log Recovery selama 30 menit, liveness probe Kubernetes akan menganggap broker mati karena port TCP 9092 belum terbuka. Akibatnya, Kubernetes akan membunuh pod broker tersebut dan menyalakannya lagi dari awal, memicu proses Log Recovery baru dari detik ke-0, dan membuat broker terjebak dalam lingkaran reboot tanpa akhir.

Berikut adalah konfigurasi Kubernetes probe produksi yang aman:

# ==============================================================================
# KUBERNETES KAFKA POD PROBES CONFIGURATION
# ==============================================================================
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kafka-broker
spec:
  template:
    spec:
      containers:
      - name: kafka
        image: apache/kafka:latest
        ports:
        - containerPort: 9092
          name: client
        
        # Liveness Probe: Hanya memastikan proses JVM berjalan. 
        # Disetel sangat toleran untuk mencegah restart loop saat log recovery.
        livenessProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - "ps -ef | grep kafka.Kafka"
          initialDelaySeconds: 60
          periodSeconds: 15
          timeoutSeconds: 5
          failureThreshold: 5

        # Readiness Probe: Memastikan broker siap menerima lalu lintas data.
        # Memeriksa apakah port TCP listener internal sudah aktif mendengarkan koneksi.
        readinessProbe:
          tcpSocket:
            port: 9092
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3

Checklist Audit Kesehatan Broker #

Gunakan checklist kepatuhan berikut untuk memverifikasi sistem diagnostik kesehatan broker kita:

Ringkasan #

• Pahami Bedanya — Liveness memastikan proses sistem operasi broker tetap hidup, sementara Readiness memastikan broker siap bertransaksi data dengan klien luar.
• Cegah Restart Loop — Jangan membuat liveness probe membunuh pod broker saat ia sedang sibuk memproses Log Recovery pasca-crash. Berikan waktu toleransi yang cukup.
• Konfigurasikan JBOD — Gunakan fitur offline directories pada JBOD agar kerusakan pada satu disk fisik tidak melumpuhkan aktivitas partisi disk lainnya di broker yang sama.
• Tingkatkan Limit OS — Selalu sesuaikan batas maksimum open file descriptors pada sistem Linux untuk memproteksi broker dari error fatal kehabisan file handle.

← Sebelumnya: Consumer Lag   Berikutnya: Broker Log →