Monitoring #

RabbitMQ bisa berjalan dengan sangat baik… sampai suatu hari tidak lagi.

Masalah dalam sistem messaging jarang muncul secara dramatis di awal.

Ia muncul perlahan:

• Queue depth naik sedikit demi sedikit
• Publish latency meningkat
• Retry bertambah
• Memory mendekati watermark

Tanpa monitoring yang tepat, semua itu tidak terlihat.

Dan ketika akhirnya terlihat, biasanya sudah terlambat.

Monitoring bukan pelengkap dalam arsitektur RabbitMQ.

Ia adalah fondasi stabilitas jangka panjang.

“Sistem yang tidak dimonitor bukan berarti stabil — hanya belum terlihat masalahnya.”

Mengapa Monitoring Sangat Penting di Sistem Messaging? #

Berbeda dengan sistem synchronous:

• Error tidak selalu langsung terasa
• Backlog bisa menumpuk diam-diam
• Retry bisa terjadi tanpa alarm
• Poison message bisa berulang tanpa terlihat

RabbitMQ adalah sistem asynchronous.

Masalahnya sering tersembunyi dalam antrian.

Monitoring adalah satu-satunya cara membuatnya terlihat.

Metric Kunci yang Harus Dipantau #

1️⃣ Queue Depth #

• Messages Ready
• Messages Unacked

Indikator:

• Backlog meningkat → consumer lambat
• Unacked tinggi → prefetch terlalu besar atau consumer bermasalah

Queue depth adalah indikator kesehatan paling dasar.

2️⃣ Publish Rate vs Consume Rate #

Bandingkan:

• Messages published per second
• Messages delivered per second

Jika publish rate > consume rate secara konsisten:

• Backlog akan terus bertambah

Monitoring rasio ini sangat penting.

3️⃣ Confirm Latency #

Untuk persistent atau quorum queue:

• Pantau waktu publisher confirm

Jika confirm semakin lambat:

• Disk I/O overload
• Replication lambat
• Backpressure mendekat

Confirm latency adalah early warning overload.

4️⃣ Memory Usage & Watermark #

Pantau:

• Total memory
• High watermark threshold

Jika watermark sering tercapai:

• Flow control aktif
• Producer akan diblokir

Ini tanda beban terlalu tinggi.

5️⃣ Disk Usage #

Terutama untuk:

• Persistent message
• Quorum queue

Disk hampir penuh → broker akan menghentikan publish.

6️⃣ Connection & Channel Count #

Pantau:

• Jumlah connection aktif
• Channel per connection

Lonjakan connection bisa berarti:

• Connection leak
• Scaling tidak terkendali

7️⃣ DLQ Depth #

DLQ bukan hanya tempat error.

Ia adalah indikator bug.

DLQ yang meningkat artinya:

• Ada mismatch schema
• Ada dependency bermasalah
• Ada poison message

DLQ harus memiliki alert.

Monitoring Cluster Quorum #

Untuk quorum queue, tambahan metric penting:

• Leader election frequency
• Replication lag
• Raft commit latency

Jika leader sering berpindah:

• Cluster tidak stabil
• Network issue mungkin terjadi

Quorum membutuhkan monitoring lebih ketat.

Alerting: Jangan Tunggu Sistem Mati #

Monitoring tanpa alert tidak cukup.

Beberapa alert penting:

• Queue depth melebihi threshold
• DLQ depth > 0 (untuk critical queue)
• Confirm latency meningkat tajam
• Memory watermark tercapai
• Disk usage > 80%

Alert harus actionable.

Tool yang Bisa Digunakan #

Beberapa opsi umum:

• RabbitMQ Management UI
• Prometheus + Grafana
• Datadog
• New Relic
• Cloud provider monitoring

Gunakan dashboard yang menunjukkan:

• Trend
• Rate
• Bukan hanya snapshot angka

Trend jauh lebih informatif daripada angka statis.

Anti-Pattern Monitoring #

Beberapa kesalahan umum:

• Hanya melihat CPU
• Tidak memonitor DLQ
• Tidak memonitor confirm latency
• Tidak membuat alert
• Tidak pernah melakukan capacity planning

Monitoring bukan sekadar melihat grafik saat ada masalah.

Ia harus menjadi bagian dari operasi harian.

Capacity Planning #

Monitoring juga membantu menjawab:

• Berapa rata-rata throughput?
• Kapan peak terjadi?
• Seberapa cepat queue bertambah?
• Kapan perlu scale consumer?

Tanpa data historis, scaling menjadi spekulatif.

Ringkasan Metric Penting #

Monitoring harus mencakup seluruh dimensi ini.

Penutup #

RabbitMQ bukan sistem yang “set and forget”.

Ia membutuhkan pengamatan yang konsisten.

Masalah dalam messaging jarang terjadi secara instan.

Ia tumbuh perlahan di dalam queue.

Monitoring membuat pertumbuhan masalah itu terlihat.

Tanpa monitoring, kita hanya menunggu kegagalan berikutnya.

Dengan monitoring yang matang, kita bisa bertindak sebelum sistem benar-benar jatuh.

Karena dalam sistem asynchronous, visibilitas adalah setengah dari stabilitas.