Akumulasi pesan terjadi ketika offset yang dikomit oleh kelompok konsumen tertinggal dari offset terbaru yang diproduksi oleh broker (high-water mark). Selisih antara kedua offset tersebut menunjukkan jumlah pesan yang terakumulasi. Peningkatan jumlah ini tidak selalu mengindikasikan adanya masalah—yang penting adalah apakah laju konsumsi mampu mengimbangi laju produksi. Gunakan panduan ini untuk mendiagnosis apakah akumulasi tersebut normal dan menangani kasus yang tidak normal.
Cara kerja konsumsi pesan
Sebelum mendiagnosis akumulasi, pahami siklus konsumsi dua fase pada setiap klien:
Pull: Klien mengambil pesan dari broker.
Process: Klien menjalankan logika bisnis pada setiap pesan, lalu mengirimkan kembali offset konsumen ke broker.
Jumlah pesan yang terakumulasi sama dengan high-water mark broker dikurangi offset yang dikomit oleh kelompok konsumen. Angka besar saja tidak serta-merta menandakan adanya masalah. Fokuslah pada trennya: apakah selisih tersebut stabil, terus meningkat, atau disebabkan oleh offset yang belum dikomit?
Diagnosis akumulasi
Untuk memeriksa apakah akumulasi bersifat normal, periksa metrik kelompok konsumen di konsol ApsaraMQ for Kafka:
Masuk ke konsol ApsaraMQ for Kafka.
Pada bilah navigasi atas, pilih wilayah tempat instans Anda berada.
Pada panel navigasi kiri, klik Instances.
Pada halaman Instances, klik nama instans target.
Pada halaman Instance Details, klik Groups di panel navigasi kiri.
Pada halaman Groups, temukan kelompok target dan pilih More > Consumer Status pada kolom Actions.
Pada halaman Consumer Status, periksa nilai Last Consumed At, Accumulated Messages, dan Consumer Offset.
Nilai-nilai ini diperbarui setiap 1 menit. Klik Details untuk melihat offset konsumen tiap partisi.
Gunakan tabel keputusan berikut untuk menginterpretasikan metrik tersebut:
| Symptom | Diagnosis | Action |
|---|---|---|
| Last Consumed At mendekati waktu saat ini, dan Accumulated Messages berfluktuasi dalam rentang yang stabil | Normal — klien sedang menarik dan memproses pesan dengan laju yang stabil. | Tidak perlu tindakan. |
| Accumulated Messages terus meningkat, dan Consumer Offset tidak berubah | Tidak normal — thread konsumen terblokir. Klien telah berhenti memproses pesan dan mengirimkan offset. | Lihat Mengatasi Penumpukan Tidak Normal. |
| Accumulated Messages terus meningkat, tetapi Consumer Offset terus maju | Tidak normal — konsumsi terlalu lambat. Klien memang memproses pesan, tetapi laju pemrosesannya lebih rendah daripada laju produksi. Bottleneck terletak pada fase pemrosesan (fase 2), bukan fase pull. | Lihat Mengatasi Akumulasi Tidak Normal. |
| Pesan tampak terakumulasi di partisi, tetapi pemrosesan downstream berjalan normal | Kemungkinan false positive. Jika sistem downstream menggunakan mode konsumsi assign, offset dikelola secara manual. Pesan mungkin sudah dikonsumsi tetapi tetap ditampilkan sebagai terakumulasi karena offset belum dikomit. | Komit offset secara manual untuk menghilangkan laporan akumulasi tersebut. |
| Accumulated Messages meningkat dan Consumer Offset maju secara perlahan, tetapi pemantauan bandwidth konsumen tingkat instans menunjukkan bahwa throughput telah mencapai batas laju | Kemungkinan terjadi rate limiting pada konsumen. Instans telah memicu throttling throughput konsumen. Klien tidak sepenuhnya terblokir—masih dapat menarik pesan, tetapi dengan laju yang dibatasi, sehingga menyebabkan akumulasi bertahap. | Periksa metrik pemantauan bandwidth konsumen tingkat instans. Jika throttling dikonfirmasi, pertimbangkan untuk melakukan upgrade spesifikasi instans atau mengurangi volume pull konsumen. |
| Accumulated Messages meningkat signifikan untuk satu topik, dan konsumsi melambat pada topik lain dalam instans yang sama | Kemungkinan dampak tidak langsung dari cold read. Akumulasi pada satu topik biasanya tidak secara langsung memengaruhi topik lain dalam instans yang sama. Namun, jika pesan yang terakumulasi telah di-flush ke disk, pengambilannya memicu I/O disk alih-alih pembacaan dari memori (cold read). IOPS baca disk atau throughput yang tinggi dapat menurunkan performa keseluruhan instans. | Periksa metrik pemantauan I/O disk dan throughput jaringan tingkat instans. Jika IOPS baca disk atau trafik tidak biasa tinggi, prioritaskan pengurangan akumulasi pada topik yang terdampak terlebih dahulu. |
Nilai Accumulated Messages yang besar tidak selalu berarti ada masalah. Jumlah yang ditampilkan bergantung pada laju produksi dan frekuensi komit offset. Misalnya, jika suatu topik menerima 10.000 pesan per detik dan offset dikomit sekali per detik, jumlah akumulasi biasanya berfluktuasi sekitar 10.000.
Menyelesaikan akumulasi tidak normal
Setelah memastikan adanya akumulasi tidak normal, identifikasi bottleneck dan tingkatkan laju konsumsi.
Identifikasi bottleneck
Tentukan apakah thread konsumen terblokir atau hanya lambat:
Thread terblokir: Jika Consumer Offset tidak maju, kemungkinan besar thread konsumen macet. Gunakan
jstack(untuk aplikasi Java) untuk mengambil thread dump dan mengidentifikasi titik blokirnya. Untuk informasi lebih lanjut, lihat jstack - Stack Trace.Pemrosesan lambat: Jika Consumer Offset maju tetapi tertinggal dari produksi, lakukan profiling terhadap logika pemrosesan pesan dalam aplikasi Anda. Cari panggilan I/O yang lambat, penulisan database, atau operasi blocking pada fase pemrosesan.
Tingkatkan laju konsumsi
Gunakan salah satu atau kedua pendekatan berikut:
Tambahkan konsumen: Tambahkan lebih banyak instans konsumen dalam kelompok konsumen yang sama, baik sebagai thread tambahan dalam proses yang sudah ada maupun sebagai proses terpisah. Setiap konsumen menangani satu atau beberapa partisi. Jika jumlah konsumen sudah sama dengan atau melebihi jumlah partisi, penambahan konsumen tidak akan berpengaruh—konsumen tambahan akan menganggur.
Tingkatkan thread konsumsi: Gunakan konsumsi multi-threaded dalam setiap instans konsumen. Untuk detail implementasi, lihat bagian "Increase consumption rate" dalam Best practices for consumers.
Dalam kebanyakan kasus, akumulasi pesan yang tidak normal disebabkan oleh konsumsi pesan yang lambat atau thread konsumsi yang terblokir. Hindari mengatur durasi panjang untuk parameter terkait dalam logika konsumsi.
Periksa rebalance
Jika pesan terakumulasi dan status konsumen tampak tidak normal di konsol, kemungkinan kelompok konsumen sedang melakukan rebalance. Selama rebalance, tidak ada pesan yang dikonsumsi.
Rebalance yang sering umumnya disebabkan oleh konsumen yang terhubung dan terputus dengan frekuensi tinggi. Untuk informasi lebih lanjut, lihat Why do rebalances frequently occur on my consumer client?
Troubleshoot error read tcp i/o timeout
Q: Apakah skalabilitas vertikal instans ApsaraMQ for Kafka dapat menyelesaikan error read tcp i/o timeout yang menyebabkan akumulasi pesan?
A: Skalabilitas vertikal biasanya tidak dapat langsung menyelesaikan error read tcp i/o timeout. Error ini lebih sering terkait dengan masalah konektivitas jaringan atau konfigurasi klien, bukan kendala sumber daya di sisi server. Sebelum mempertimbangkan scale-up, ikuti langkah troubleshooting berikut:
Verifikasi bahwa koneksi jaringan antara klien dan broker stabil. Periksa adanya kehilangan paket, latensi tinggi, atau gangguan konektivitas intermiten.
Periksa versi klien. Jika versi klien lebih awal dari 0.10.2, lakukan upgrade ke versi yang didukung.
Lakukan tuning terhadap parameter
max.poll.interval.msdansession.timeout.ms. Jika nilai-nilai ini terlalu singkat dibandingkan waktu yang dibutuhkan untuk memproses setiap batch poll, klien mungkin mengalami timeout dan memicu Rebalance yang tidak disengaja, sehingga mengganggu konsumsi dan meningkatkan akumulasi. Atur nilai-nilai ini sesuai dengan durasi pemrosesan pesan aktual Anda.Di konsol ApsaraMQ for Kafka, periksa halaman Consumer Status untuk memverifikasi apakah jumlah akumulasi dan perubahan offset sesuai ekspektasi. Pertimbangkan scale-up hanya jika Anda telah memastikan bahwa timeout disebabkan oleh bottleneck sumber daya di sisi server.