Cara Memantau RabbitMQ (Tanpa Kehilangan Pesan, Uang, atau Tidur)

Bayangkan ini: sekarang hari Senin pagi. Situs e-commerce Anda menjalankan “penjualan kilat 48 jam”. Pesanan berdatangan, pembayaran diproses, dan tim dukungan Anda sangat tenang - hal yang indah.

Lalu, tiba-tiba, Slack meledak.

• “Pembayaran macet saat berputar...”

• “Konfirmasi pesanan tidak keluar.”

• “Inventaris terlihat salah.”

• “Mengapa pengembalian dana harus mengantri berjam-jam?”

Pada awalnya, semuanya terlihat sehat: CPU baik-baik saja, server web Anda aktif, dan grafik basis data tidak menunjukkan sesuatu yang dramatis. Tetapi sistem masih terasa... macet.

Setelah 45 menit pemadaman kebakaran, Anda menemukan pelaku yang sebenarnya: RabbitMQ. Beberapa antrian membengkak, konsumen melambat, pengakuan mundur, dan memori mencapai batas tertinggi. RabbitMQ mulai menerapkan kontrol aliran, penerbit mulai kehabisan waktu, dan logika bisnis Anda diam-diam berhenti memindahkan pesan melalui alur kerja yang kritis.

Inilah alasannya mengapa Pemantauan RabbitMQ bukanlah pilihan. Jika RabbitMQ adalah “sistem peredaran darah” dari arsitektur Anda, maka pemantauan adalah monitor jantung yang memberi tahu Anda bahwa ada sesuatu yang salah sebelum pasien pingsan.

Dalam panduan ini Anda akan belajar:

• Apa itu RabbitMQ (dalam bahasa Inggris)

• Mengapa Anda harus memantaunya (meskipun “sudah baik-baik saja selama berbulan-bulan”)

• Metrik mana yang paling penting dan seperti apa “baik” itu

• Pola kegagalan yang umum dan bagaimana pemantauan dapat menangkapnya lebih awal

• Alat-alat tingkat tinggi yang dapat memonitor RabbitMQ

• Daftar periksa pemantauan RabbitMQ yang sederhana dan praktis

Apa itu RabbitMQ?

RabbitMQ adalah yang populer perantara pesan. Ia berada di antara sistem dan membantu mereka bertukar pesan dengan andal.

Alih-alih satu layanan memanggil layanan lain secara langsung (dan gagal jika layanan lain lambat atau mati), layanan dapat mempublikasikan pesan ke RabbitMQ, dan layanan lain mengkonsumsi pesan tersebut ketika mereka siap.

RabbitMQ dalam satu kalimat

RabbitMQ adalah sistem yang pesan antrian sehingga aplikasi Anda dapat berkomunikasi secara asinkron, andal, dan dalam skala besar.

Konsep-konsep utama RabbitMQ (cepat dan ramah)

Anda tidak perlu menghafalkannya, tetapi ini membantu Anda menginterpretasikan sinyal pemantauan:

• Produser / Penerbitaplikasi yang mengirim pesan

• Konsumenaplikasi yang menerima pesan

• Antrian: tempat pesan menunggu

• Pertukarantempat pesan tiba pertama kali dan disalurkan

• Mengikataturan yang menghubungkan sebuah bursa ke antrian

• Host virtual (vhost)ruang nama logis (seperti penyewa/lingkungan)

• Salurankoneksi ringan di dalam koneksi TCP

• Ack (pengakuan)Konsumen mengonfirmasi telah memproses pesan tersebut

• DLQ (antrian huruf mati)pesan yang tidak dapat diproses masuk ke sini (jika dikonfigurasi)

RabbitMQ biasanya mengimplementasikan AMQP (Protokol Antrian Pesan Lanjutan) tetapi juga mendukung protokol lain melalui plugin.

Mengapa Anda Perlu Memantau RabbitMQ?

RabbitMQ sering kali merupakan “ketergantungan yang diam.” Ketika ia kesulitan, gejala-gejala muncul di tempat lain:

• Waktu permintaan web habis

• Latar belakang pekerjaan menumpuk

• Email berhenti dikirim

• Penundaan pemrosesan pembayaran

• Sistem yang digerakkan oleh peristiwa menjadi tidak konsisten

• Layanan mikro mulai mencoba kembali dan saling serang

Masalah RabbitMQ bisa menjadi mahal karena mereka membuat simpanan tersembunyi. Sistem Anda mungkin masih “aktif”, namun tidak memberikan hasil.

Memantau RabbitMQ membantu Anda:

1. Mendeteksi perlambatan secara dini (sebelum pemberitahuan pelanggan)

2. Mencegah kehilangan pesan (atau setidaknya menangkap kondisi yang berisiko)

3. Melindungi keluaran selama lalu lintas puncak

4. Menghindari kegagalan berjenjang di seluruh layanan mikro

5. Kapasitas rencana (Jumlah RAM/disk/jaringan/konsumen)

6. Mempercepat pemecahan masalah ketika terjadi kesalahan

Jebakan “berhasil kemarin”

Kegagalan RabbitMQ sering muncul setelahnya:

• lonjakan lalu lintas

• penyebaran konsumen yang macet

• pemadaman ketergantungan hilir (misalnya, penyedia basis data atau pembayaran)

• penangan pesan yang lambat

• ledakan pesan yang besar

• ruang disk menurun

• tanda air memori terkena

• pertumbuhan antrian yang tidak terbatas karena TTL/batas yang hilang

Dengan kata lain: RabbitMQ tidak hanya gagal secara acak - RabbitMQ gagal ketika sistem di sekitarnya berubah. Pemantauan membuat perubahan itu terlihat.

Apa yang Harus Anda Pantau di RabbitMQ?

Jika Anda hanya memantau satu hal, pantau ini:

✅ Kedalaman antrian + kesehatan konsumen

Karena di situlah “pekerjaan yang tidak terselesaikan” menampakkan dirinya.

Tetapi pengaturan pemantauan RabbitMQ yang solid mencakup empat lapisan:

1. Tingkat antrian (aliran pesan)

2. Tingkat pialang (Internal RabbitMQ)

3. Tingkat simpul/sistem (OS + disk + memori)

4. Tingkat aplikasi (perilaku publikasi/konsumsi dan kesalahan)

Mari kita uraikan metrik yang paling penting.

Metrik Pemantauan RabbitMQ yang Benar-Benar Penting

1) Metrik antrean (peringatan dini #1 Anda)

Metrik ini memberi tahu Anda jika pesan mengalir atau menumpuk.

Metrik utama:

• Pesan siap: menunggu dalam antrian

• Pesan tidak terkuncidikirim ke konsumen tetapi belum diakui

• Total pesansiap + tidak dibongkar

• Tingkat masuknya: pesan yang diterbitkan per detik

• Tingkat jalan keluarpesan yang diterima/dikonsumsi per detik

• Antrian konsumen: jumlah konsumen yang aktif per antrian

Apa yang harus diperhatikan:

• Total pesan yang sedang tren naik seiring berjalannya waktu → konsumen tidak dapat mengikuti

• Pertumbuhan yang tidak dibongkar → konsumen lambat, macet, atau tidak bekerja dengan baik

• Konsumen = 0 pada antrian kritis → pesan akan menumpuk dengan cepat

• Jalan keluar tiba-tiba turun → masalah ketergantungan hilir atau konsumen yang jatuh

Aturan praktis yang sederhana:
Jika antrean terus bertambah selama lebih dari beberapa menit selama “lalu lintas normal”, berarti ada sesuatu yang salah.

2) Kesehatan konsumen (di mana banyak insiden bermula)

RabbitMQ sering kali disalahkan, tetapi akar penyebabnya sering kali adalah masalah konsumen:

• kode yang digunakan dengan bug

• konsumen terjebak dalam percobaan ulang

• kolam benang habis

• Panggilan basis data lambat

• batas tarif API eksternal

• kebocoran memori konsumen

Monitor:

• jumlah konsumen per antrian

• tingkat konsumsi vs tingkat publikasi

• pesan yang belum dibuka

• log kesalahan konsumen (batas waktu, pengecualian)

• waktu pemrosesan (dari telemetri aplikasi jika tersedia)

Kiat pro:
Antrian yang terus bertambah tidak selalu buruk saat terjadi lonjakan. Antrian yang tumbuh dan tidak pernah pulih buruk.

3) Koneksi dan saluran (sumber ketidakstabilan yang licik)

Terlalu banyak koneksi atau saluran dapat menurunkan kinerja.

Monitor:

• koneksi terbuka

• saluran per koneksi

• gangguan koneksi (sering terputus/terhubung kembali)

• koneksi yang diblokir (kontrol aliran)

Apa yang harus diperhatikan:

• lonjakan koneksi secara tiba-tiba (klien yang salah konfigurasi)

• jumlah saluran yang sangat besar (kebocoran)

• sering menyambungkan kembali loop (masalah jaringan atau autentikasi)

4) Kesehatan node: memori, disk, CPU, deskriptor file

RabbitMQ sensitif terhadap memori dan disk.

Monitor:

• Penggunaan memori dan apakah mendekati tanda air yang tinggi

• Ruang kosong disk (RabbitMQ akan memblokir penerbit jika disk hampir habis)

• CPU (CPU tinggi yang berkelanjutan dapat mengurangi throughput)

• Deskriptor file (kehabisan daya dapat memutus koneksi)

• Throughput dan kesalahan jaringan (pialang memiliki banyak jaringan)

Mengapa disk sangat penting
RabbitMQ menyimpan pesan (tergantung pada pengaturan daya tahan) dan menggunakan disk secara besar-besaran dalam kondisi tertentu. Ketika disk terlalu rendah, RabbitMQ dapat melindungi dirinya sendiri dengan memblokir penerbit. Hal ini terlihat seperti “aplikasi sedang down”, meskipun server sedang berjalan.

5) Kesehatan broker dan status klaster

Jika Anda menjalankan klaster RabbitMQ, pantau juga:

• status node naik/turun

• partisi cluster

• pencerminan antrean/kesehatan antrean kuorum (tergantung pengaturan Anda)

• status sinkronisasi (jika ada)

• perubahan pemimpin dan penundaan replikasi (untuk antrean kuorum)

6) Keamanan tingkat pesan: DLQ, percobaan ulang, TTL

Banyak sistem yang menggunakan percobaan ulang dan huruf mati untuk menangani kegagalan dengan anggun. Pemantauan membantu memastikan bahwa “kegagalan yang anggun” tidak menjadi “kegagalan yang diam-diam.”

Monitor:

• kedalaman antrian huruf mati

• tingkat pesan berhuruf mati

• coba lagi kedalaman antrean (jika digunakan)

• pesan kedaluwarsa TTL (jika ada)

Jika DLQ meningkat, sering kali itu berarti konsumen Anda gagal dan pesan dialihkan - pelanggan mungkin terpengaruh meskipun antrean utama Anda “terlihat baik-baik saja.”

Masalah Umum RabbitMQ (dan Sinyal Pemantauan yang Menangkapnya)

Masalah: Konsumen menurun

Sinyal:

• Konsumen = 0

• Pesan siap naik dengan cepat

Masalah: Bug konsumen menyebabkan pemrosesan lambat

Sinyal:

• Kenaikan yang tidak dibongkar

• Tingkat keluar turun

• Waktu pemrosesan (metrik aplikasi) meningkat

Masalah: Pemadaman ketergantungan hilir (DB/API)

Sinyal:

• Pendakian yang tidak dibongkar

• Lonjakan kesalahan konsumen/timeout

• Pertumbuhan antrian semakin cepat

Masalah: Memori tanda air tinggi dipicu

Sinyal:

• Penggunaan memori mendekati tanda air

• Koneksi menjadi terhambat

• Peningkatan latensi publikasi

Masalah: Alarm disk / ruang disk rendah

Sinyal:

• Disk kosong turun di bawah ambang batas

• RabbitMQ memblokir penerbitan

• Batas waktu produsen meningkat

Masalah: Kebocoran koneksi/saluran pada aplikasi

Sinyal:

• Koneksi/saluran yang terus meningkat dengan mantap

• Deskriptor file naik

• Akhirnya: kegagalan koneksi

Masalah: Satu antrian “panas” mendominasi sumber daya broker

Sinyal:

• Satu antrian memiliki kedalaman yang sangat besar dan tarif yang tinggi

• Yang lain menjadi lambat meskipun volume rendah

• Lonjakan CPU dan peningkatan latensi broker

Pemantauan tidak hanya memberi tahu Anda bahwa ada sesuatu yang salah - ini menunjuk ke arah di mana.

Cara Memantau RabbitMQ: Pendekatan Praktis

Strategi yang sederhana dan efektif adalah:

1. Mulailah dengan hal-hal yang penting
   Kedalaman antrean, konsumen, masuk/keluar, tidak dibongkar, memori, disk.

2. Tambahkan peringatan yang sesuai dengan dampak bisnis
   Waspada terhadap tren (backlog yang terus bertambah), bukan hanya ambang batas.

3. Membangun dasbor di sekitar alur kerja
   Tampilkan antrean yang dikelompokkan berdasarkan domain bisnis: checkout, pemberitahuan, penagihan.

4. Menghubungkan metrik broker dengan telemetri aplikasi
   Metrik RabbitMQ + log kesalahan konsumen = akar penyebab yang cepat.

5. Gunakan sinyal gaya SLO
   “Pesan diproses dalam waktu X menit” lebih bermakna daripada CPU%.

Solusi Tingkat Tinggi untuk Memantau RabbitMQ

Di bawah ini adalah opsi yang telah terbukti digunakan dalam lingkungan produksi nyata.

1) Xitoring (Pemantauan all-in-one untuk RabbitMQ dan seluruh tumpukan Anda)

Xitoring.com adalah solusi pemantauan lengkap yang dirancang untuk membantu Anda memantau infrastruktur dan layanan penting - termasuk perantara pesan seperti RabbitMQ - dengan cara yang jelas dan dapat ditindaklanjuti.

Mengapa ini cocok dengan pemantauan RabbitMQ dengan baik:

• Dasbor pusat untuk infrastruktur + layanan (satu tempat untuk melihat)

• Peringatan yang dirancang untuk saat-saat “ada yang tidak beres saat ini”

• Visibilitas tingkat tinggi yang membantu tim pengembang dan operasional

• Berguna ketika masalah RabbitMQ merupakan gejala dari masalah sistem yang lebih luas (DB, jaringan, latensi aplikasi)

Terbaik untuk:
Tim yang menginginkan pusat pemantauan tunggal alih-alih menggabungkan beberapa alat, dan menginginkan pemantauan RabbitMQ sebagai bagian dari gambaran “full-stack” yang lebih besar.

2) Plugin Manajemen RabbitMQ (UI bawaan + metrik dasar)

RabbitMQ termasuk antarmuka manajemen (jika diaktifkan) yang menunjukkan antrian, tarif, koneksi, konsumen, dan statistik node.

Kelebihan:

• Cepat untuk mengaktifkan

• Sangat bagus untuk pemeriksaan dan debugging manual

• Menampilkan detail tingkat antrian dengan jelas

Kekurangan:

• Bukan sistem pemantauan yang lengkap dengan sendirinya

• Peringatan terbatas dan tren jangka panjang kecuali jika diintegrasikan di tempat lain

Terbaik untuk:
Pemecahan masalah yang cepat dan visibilitas sehari-hari, terutama dalam pengaturan yang lebih kecil.

3) Prometheus + Grafana (tumpukan pemantauan sumber terbuka yang populer)

Pendekatan yang umum dilakukan adalah:

• Ekspor metrik RabbitMQ melalui eksportir atau titik akhir bawaan

• Kumpulkan dengan Prometheus

• Visualisasikan dan beri peringatan dengan Grafana/Alertmanager

Kelebihan:

• Dasbor dan peringatan yang kuat

• Templat ekosistem dan komunitas yang kuat

• Sangat bagus untuk tren jangka panjang dan SLO

Kekurangan:

• Penyiapan dan pemeliharaan lebih lanjut

• Anda mungkin perlu menyetel peringatan dan dasbor

Terbaik untuk:
Tim yang sudah menjalankan Prometheus atau menginginkan stack open-source yang fleksibel.

4) Datadog (platform pengamatan SaaS)

Datadog mendukung pemantauan RabbitMQ melalui integrasi dan dapat mengkorelasikan metrik broker dengan host, kontainer, dan jejak APM.

Kelebihan:

• Proses orientasi yang cepat

• Korelasi yang kuat di seluruh metrik, log, jejak

• Peringatan dan visualisasi yang luar biasa

Kekurangan:

• Biaya tumbuh seiring dengan skala

• Ketergantungan SaaS

Terbaik untuk:
Tim yang menginginkan waktu yang cepat untuk mendapatkan nilai dan kemampuan pengamatan yang luas.

5) New Relic (platform pengamatan SaaS)

New Relic menyediakan pemantauan infrastruktur, APM, dasbor, dan peringatan. RabbitMQ dapat dipantau melalui integrasi dan pipeline metrik khusus.

Kelebihan:

• Visibilitas tumpukan penuh (APM + infra)

• Dasbor dan peringatan yang baik

Kekurangan:

• Membutuhkan konfigurasi yang cermat untuk sinyal RabbitMQ terbaik

Terbaik untuk:
Tim yang sudah menggunakan New Relic untuk pemantauan aplikasi.

6) Tumpukan Elastis (ELK) untuk log + metrik (dan dasbor Kibana)

Elastic banyak digunakan untuk agregasi log dan juga dapat menangani metrik tergantung pengaturan Anda.

Kelebihan:

• Pencarian dan korelasi log yang sangat baik

• Dasbor yang kuat untuk analisis operasional

Kekurangan:

• Dapat menjadi kompleks dalam skala besar

• Membutuhkan disiplin yang baik di sekitar skema dan retensi

Terbaik untuk:
Tim yang menggunakan log sebagai alat bantu utama untuk diagnosis dan kepatuhan.

7) Splunk

Splunk umum digunakan di organisasi besar untuk agregasi log, peringatan, dan intelijen operasional.

Kelebihan:

• Kemampuan perusahaan yang kuat

• Kueri dan peringatan yang kuat

Kekurangan:

• Bisa mahal dan berat untuk dioperasikan

Terbaik untuk:
Perusahaan besar dengan alur kerja pengamatan yang matang.

8) Pemantauan penyedia cloud (ketika RabbitMQ dikelola)

Jika Anda menjalankan RabbitMQ melalui layanan terkelola (atau penawaran yang dikelola vendor), Anda bisa mengandalkannya:

• Pemantauan awan (seperti CloudWatch yang setara)

• Dasbor vendor + titik akhir metrik

Kelebihan:

• Lebih sedikit pekerjaan operasional

• Terintegrasi dengan peringatan platform

Kekurangan:

• Mungkin tidak mengekspos kedalaman yang Anda inginkan untuk operasi tingkat antrean

• Masih membutuhkan visibilitas tingkat aplikasi

Terbaik untuk:
Tim memprioritaskan pengurangan biaya operasional.

Membangun Dasbor Pemantauan RabbitMQ (Apa yang Harus Disertakan)

Jika Anda membuat dasbor di Xitoring (atau alat lainnya), buatlah dasbor berdasarkan pertanyaan yang Anda ajukan selama insiden.

Bagian A: “Apakah aliran pesan sehat?”

• total pesan per antrian kritis

• pesan siap vs tidak siap

• tingkat publikasi vs tingkat ack

• jumlah konsumen per antrian

• Kedalaman DLQ dan laju DLQ

Bagian B: “Apakah broker berada di bawah tekanan?”

• penggunaan memori (dan kedekatan tanda air)

• ruang kosong disk

• Penggunaan CPU

• throughput jaringan

• deskriptor file

Bagian C: “Apakah cluster stabil?”

• simpul atas / bawah

• peristiwa partisi

• replikasi antrean / kesehatan kuorum (jika ada)

Bagian D: “Apakah aplikasi berperilaku?”

• kesalahan publikasi produsen / waktu habis

• tingkat kesalahan konsumen

• waktu pemrosesan konsumen

• tingkat penyambungan kembali

Tip: Letakkan antrian yang paling penting bagi bisnis Anda di bagian atas. Dalam sebuah insiden, tidak ada yang mau menggulir.

Peringatan untuk RabbitMQ: Tetap Sederhana dan Berguna

Peringatan harus dapat ditindaklanjuti. Sebuah jawaban peringatan RabbitMQ yang baik:

• Apa yang terkena dampak?

• Di mana hal itu terjadi (antrean/simpul mana)?

• Seberapa mendesak?

Peringatan praktis yang bekerja dengan baik

1) Tumpukan antrian yang terus bertambah

• Memicu ketika kedalaman antrian meningkat terus menerus selama N menit

2) Konsumen hilang

• Memicu ketika jumlah konsumen adalah 0 untuk antrian kritis selama lebih dari 1-2 menit

3) Pesan yang tidak terkunci terlalu tinggi

• Memicu ketika tidak terkunci melebihi ambang batas (atau terus bertambah)

4) Ruang disk rendah

• Memicu ketika ruang kosong disk turun di bawah buffer yang aman (diatur berdasarkan lingkungan Anda)

5) Tekanan memori

• Memicu ketika memori tinggi dan naik menuju tanda air

6) Pertumbuhan DLQ

• Memicu ketika kedalaman DLQ meningkat melebihi garis dasar normal

Hindari peringatan yang berisik

• Jangan waspada pada lonjakan CPU saja.

• Jangan memperingatkan kedalaman antrean saja tanpa konteks.

• Lakukan peringatan pada tren + konsumen yang hilang + batas sumber daya broker.

Praktik Terbaik yang Membuat Pemantauan Lebih Efektif

Pemantauan akan lebih kuat ketika pengaturan RabbitMQ Anda juga dirancang untuk stabilitas.

1) Mencegah pertumbuhan tanpa batas

• Gunakan TTL jika sesuai

• Gunakan DLQ dengan sengaja

• Pertimbangkan kebijakan panjang maksimum untuk antrian yang harus dibatasi

2) Jaga agar pesan tetap ramping

Pesan yang besar akan menambah beban memori dan jaringan. Lebih suka mengirim ID dan mengambil detail di tempat lain, jika memungkinkan.

3) Gunakan ucapan terima kasih dengan benar

• Ack hanya setelah pemrosesan berhasil

• Hati-hati dengan auto-ack (dapat menyembunyikan kegagalan)

4) Kontrol pengambilan awal

Pengaturan prefetch konsumen memengaruhi jumlah dan throughput yang tidak dibongkar. Memantau jumlah yang tidak dibongkar membantu Anda menyetel prefetch.

5) Pisahkan beban kerja

Letakkan beban kerja yang lambat/jarang pada antrian terpisah sehingga tidak memblokir aliran prioritas tinggi.

6) Perhatikan “badai percobaan ulang”

Jika konsumen mencoba ulang terlalu agresif, Anda dapat membebani RabbitMQ dan sistem hilir. DLQ dan percobaan ulang yang tertunda membantu.

Pikiran Akhir: Memantau RabbitMQ Seperti Sebuah Produk

RabbitMQ bukan hanya sekedar “infrastruktur”. Ini adalah bagian hidup dari perilaku sistem Anda. Ketika melambat, bisnis Anda melambat.

Pengaturan pemantauan yang baik memungkinkan Anda menjawab, dengan cepat dan percaya diri:

• Apakah pesan mengalir?

• Jika tidak, antrean mana yang macet?

• Apakah broker itu sehat?

• Apakah konsumen bekerja - atau gagal secara diam-diam?

• Apakah ini lonjakan, bug, atau masalah kapasitas?

Jika Anda menginginkan pemantauan RabbitMQ yang sesuai dengan pendekatan “pantau semuanya di satu tempat” yang lebih luas, Xitoring adalah pilihan pertama yang kuat untuk dipertimbangkan - terutama ketika masalah RabbitMQ hanya satu bagian dari teka-teki kinerja yang lebih besar.