Mengapa AliyunAMQPReadOnlyAccess tidak mendukung kueri pesan antrian?
Kebijakan AliyunAMQPReadOnlyAccess hanya memberikan izin amqp:Get* dan amqp:List*. Untuk mengakses pesan dalam antrian, tambahkan izin amqp:BasicGet dalam kebijakan kustom. Untuk informasi selengkapnya, lihat Referensi kebijakan kustom ApsaraMQ for RabbitMQ.
{
"Version": "1",
"Statement": [
{
"Action": [
"amqp:BasicGet"
],
"Resource": [
"acs:amqp:*:*:/instances/$instanceId/vhosts/$vhostName/queues/$queueName/messages/*"
],
"Effect": "Allow"
}
]
}Mengapa Konsol tetap menampilkan akumulasi pesan setelah melakukan purge pada antrian?
Operasi purge pada antrian secara default tidak menghapus pesan yang tertunda (delayed messages).
Bagaimana cara kerja QoS?
Jika terjadi timeout atau blocking, Anda dapat mengatur Quality of Service (QoS) atau Prefetch Count menjadi 1 untuk menghindari caching terlalu banyak pesan di sisi client yang kedaluwarsa secara bersamaan.
Kapan sebuah pesan menjadi pesan dead-letter?
Jika sebuah pesan tidak memiliki pengaturan Time-to-Live (TTL), pesan tersebut hanya menjadi dead-letter message dalam dua kondisi: ditolak dengan negative acknowledgement (NACK), atau jumlah percobaan ulang telah mencapai batas maksimum.
Bagaimana cara mengatur message ID?
Untuk informasi selengkapnya, lihat Cara mengatur message ID.
Mengapa jumlah pesan di dead-letter queue berkurang?
ApsaraMQ for RabbitMQ menyimpan pesan hingga 3 hari. Jika pesan di dead-letter queue tidak dikonsumsi lebih dari 3 hari, pesan tersebut akan dihapus, sehingga jumlah pesan berkurang. Untuk informasi selengkapnya, lihat Batasan.
Apa itu periode retensi pesan?
ApsaraMQ for RabbitMQ menyimpan semua pesan—baik yang telah berhasil dikonsumsi maupun yang belum—hingga 3 hari. Untuk informasi selengkapnya, lihat Batasan.
Apa Blok CIDR untuk RabbitMQ?
Blok CIDR untuk ApsaraMQ for RabbitMQ tidak tetap dan tidak dapat diperoleh sebelumnya.
Mengapa penghapusan antrian otomatis tidak berlaku?
Jika konsumen gagal berlangganan ke antrian, pemanggilan channel.close tidak memicu penghapusan antrian otomatis. Fitur penghapusan otomatis hanya diaktifkan setelah konsumen berhasil berlangganan ke antrian menggunakan channel.basicConsume.
Apa itu biaya penyimpanan?
ApsaraMQ for RabbitMQ menyimpan pesan selama 3 hari. Biaya penyimpanan dihitung berdasarkan ukuran total isi pesan yang disimpan. Anda tidak dapat mengosongkan ruang penyimpanan ini secara manual. Ruang penyimpanan akan dilepas secara otomatis ketika pesan kedaluwarsa.
Operasi purge pada antrian hanya mengatur ulang offset konsumen. Pesan historis tetap dapat diakses setelah operasi purge, sehingga ruang penyimpanan tidak berkurang.
Apa yang dilakukan oleh operasi purge pada antrian?
Operasi purge pada antrian mengatur ulang offset konsumen, sehingga konsumen melewatkan pesan yang belum dikonsumsi. Operasi ini tidak menghapus pesan tersebut. Pesan historis tetap dapat diakses setelah antrian dipurge.
Apa yang menentukan jumlah pesan yang dikirimkan oleh antrian per detik?
Jumlah pesan yang dapat dikirimkan oleh antrian per detik bergantung pada volume pesan, jumlah konsumen, dan pengaturan Quality of Service (QoS) untuk setiap konsumen.
Apa yang perlu dipertimbangkan saat menggunakan exclusive queues?
Saat Anda menggunakan Spring dengan mode CONNECTION, Anda harus membuat exchange, antrian, dan binding di Konsol sebelum menjalankan aplikasi. Hal ini karena mode CONNECTION tidak secara otomatis mendeklarasikan atau membuat resource tersebut.
Jika sebuah pesan masuk ke antrian dan mencoba ulang 16 kali, apakah penagihan dikenakan satu kali atau 16 kali?
Penagihan hanya dikenakan satu kali. Proses re-queuing dan re-consuming pesan tidak menimbulkan biaya tambahan. Hanya pengiriman awal yang dikenai biaya.
Re-queuing berarti pesan dikembalikan ke antrian di sisi server setelah upaya konsumsi gagal. Server kemudian menggunakan antrian retry khusus dan mendorong pesan kembali ke konsumen pada interval waktu tertentu.
Metrik Cloud Monitor mana yang sesuai dengan batas TPS?
Metrik tersebut adalah Peak API Request Rate per Instance di Cloud Monitor.
Apakah jumlah koneksi bisa melebihi batas?
Ya, bisa. Meskipun dokumentasi resmi menyatakan bahwa batas koneksi berlaku per instans, batas tersebut sebenarnya diterapkan per node backend. Oleh karena itu, jumlah total koneksi untuk suatu instans dapat sedikit melebihi batas yang dinyatakan.
Untuk instansi langganan, konfigurasi tidak dapat disesuaikan secara dinamis. Anda harus merencanakan sumber daya dengan cermat saat membuat instans untuk menghindari gangguan layanan akibat batasan sumber daya.
Laju produksi dan konsumsi sesuai, tetapi Pemantauan menunjukkan akumulasi. Mengapa?
Laju pengiriman dan konsumsi aktual kira-kira sama, tetapi beberapa acknowledgement (ACK) memerlukan waktu lebih lama untuk diproses. Hal ini dapat menyebabkan Pemantauan melaporkan akumulasi pesan pada titik pengambilan sampel tertentu. Tingkat akumulasi biasanya kembali normal pada siklus pengambilan sampel berikutnya.
Mengapa konsumsi turun tiba-tiba untuk beberapa Pod?
Anda harus memeriksa performa Pod tersebut. Penggunaan CPU yang tinggi dapat mencegah client mengirimkan acknowledgement (ACK) secara tepat waktu. Jika server tidak menerima ACK, server akan berhenti mendorong pesan baru dan menunggu hingga timeout sebelum mencoba ulang. Perilaku ini mengakibatkan laju konsumsi yang lebih rendah.
Sebagai contoh, jika Quality of Service (QoS) diatur ke 1, konsumen hanya dapat menahan satu pesan yang belum di-ACK pada satu waktu. Server harus menunggu ACK sebelum mengirimkan pesan berikutnya. Jika ACK tidak diterima, server akan menunggu hingga periode timeout berakhir sebelum melanjutkan.
Apakah RabbitMQ dapat menggunakan master key default?
Ya, bisa.
Error: “The channelMax limit is reached”
Server membatasi jumlah channel per koneksi, bukan jumlah total channel.
Di SDK, error "The channelMax limit is reached" dilaporkan setiap kali createChannel mengembalikan nilai null.
Setelah Anda melakukan peningkatan instans, Anda harus restart client. Jika tidak, client akan terus menggunakan batas channel sebelum peningkatan saat membuat koneksi dan akan terus melaporkan error tersebut.
Sebagai contoh, jika instans dibeli dengan nilai Channel Max sebesar 100, client melakukan negosiasi batas ini dengan server saat pembentukan koneksi. Koneksi yang sudah ada sebelum peningkatan tetap menggunakan nilai negosiasi 100, bukan nilai yang ditingkatkan menjadi 2.000 atau 2.500. Akibatnya, error tetap muncul.
Proses negosiasi parameter channel
Apakah peningkatan TPS memengaruhi layanan yang sedang berjalan?
Tidak. Peningkatan transaksi per detik (TPS) di Konsol tidak menyebabkan pemutusan sementara atau memutus koneksi yang sedang aktif.
Apakah pembuatan koneksi dapat mematikan channel lain?
Secara normal, tidak. Namun, sumber daya client yang tidak mencukupi—seperti lebar pita jaringan, memori, atau kapasitas Java Virtual Machine (JVM)—dapat mengganggu koneksi atau channel lain. Anda harus memeriksa penggunaan sumber daya client untuk mengidentifikasi adanya konflik sumber daya atau kekurangan yang menyebabkan gangguan tersebut.
Mengapa konsumen suatu antrian menghilang?
Pertama, Anda harus memeriksa logika bisnis dan penggunaan sumber daya client selama periode terkait. Cari proses yang tertunda atau kekurangan sumber daya yang dapat menyebabkan gangguan layanan. Jika client berjalan normal, verifikasi apakah server mengirimkan pesan dengan benar.
Mengapa operasi purge pada antrian tidak menghapus pesan?
1) Pesan yang belum diacknowledged (unacked) tidak dapat dihapus melalui purge. Ini adalah pesan yang telah dikirim ke client tetapi belum di-acknowledge. Jumlahnya diperbarui secara otomatis saat kedaluwarsa.
2) Jika pesan dengan Time-to-Live (TTL) tidak dihapus, Anda dapat mengajukan tiket untuk memastikan apakah sakelar konfigurasi terkait telah diaktifkan.
Apakah instans RabbitMQ berbasis cloud mendukung fitur reply-to?
Instans RabbitMQ berbasis cloud tidak mendukung fitur reply-to.
Bagaimana cara menghitung TPS dari log client?
Kueri SQL yang sesuai adalah:
* and amqp-cn-xxx and Action : SendMessage | select InstanceId as instance_id, VHost as virtual_host, Queue as queue, microtime / 1000 / 1000 as time_second, count(*) as send_qps group by instance_id, virtual_host, queue, time_second order by time_second, send_qps limit 10000000Contoh hasil:
Setelah mengganti Logstore untuk log RabbitMQ, mengapa log kosong?
Di Logstore baru, klik Enable Indexing. Setelah sekitar satu menit, refresh halaman untuk melihat log.
Prosedur:
1) Klik Enable Indexing
2) Klik OK
Apa penyebab pemutusan koneksi RabbitMQ?
Jika client hanya mengirimkan beberapa acknowledgement (ACK) yang valid, server akan terus-menerus mengirim ulang pesan karena respons yang hilang. Hal ini menyebabkan akumulasi pesan yang terus-menerus.
Hal ini juga menunjukkan bahwa pesan menumpuk di sisi client, yang dapat mencegah pengiriman paket heartbeat. Akhirnya, koneksi terputus dengan error Connection ALL_IDLE. Anda harus terlebih dahulu menyelidiki mengapa client gagal mengirimkan ACK yang valid.
Pengaturan TTL
Time-to-Live (TTL) maksimum yang dapat Anda atur adalah 3 hari. Pengaturan yang melebihi 3 hari tidak berpengaruh. Jika TTL tidak berlaku, pesan yang kedaluwarsa tidak akan dikirim ke dead-letter queue dan dapat berperilaku tidak sesuai harapan.
1) Jika TTL tidak diatur, semua pesan dalam antrian adalah pesan Normal. Metrik readyMessage dalam Pemantauan mencerminkan jumlah pesan Normal, yaitu akumulasi aktual.
2) Jika TTL diatur, metrik readyMessage mencerminkan jumlah pesan yang masih aktif:
a) Jika TTL berfungsi dengan benar, jumlah pesan aktif dihitung secara dinamis berdasarkan TTL. Metrik readyMessage menunjukkan jumlah aktual pesan aktif. Ini adalah perilaku yang diharapkan.
b) Jika TTL diatur tetapi tidak aktif, jumlah pesan aktif tetap 0, dan metrik readyMessage selalu menunjukkan 0. Hal ini gagal mencerminkan akumulasi pesan aktual.
Error: java.lang.IllegalArgumentException: Content headers exceeded max frame size: 40209 > 32768
Ukuran frame header pesan melebihi batas. Batas ukuran header default adalah 32 KB, dan batas ini tidak dapat diubah di sisi server.
Anda dapat memindahkan data besar dari header ke isi pesan untuk menghindari melebihi batas ukuran frame header.
Mengapa saya masih dapat menemukan pesan setelah melakukan purge pada antrian?
Setelah antrian dipurge, fungsi pencarian pesan mengambil data dari log. Karena log disimpan lebih lama daripada pesan, pesan historis tetap dapat dicari.
Mengapa pemutusan hubungan langganan gagal?
Penyebab:
Antrian eksklusif hanya terlihat oleh koneksi yang pertama kali mendeklarasikannya. Hanya koneksi tersebut yang dapat menghapus antrian. Anda tidak dapat menghapusnya dari Konsol.
Untuk informasi selengkapnya, lihat Exclusive queue.
Solusi:
1) Jika Anda tidak lagi memerlukan antrian eksklusif tersebut, Anda dapat memutus koneksi terkait. Antrian dan binding-nya kemudian akan dihapus secara otomatis.
2) Jika Anda tidak dapat menemukan ID koneksi yang digunakan untuk membuat antrian eksklusif, Anda dapat restart client untuk menghapus antrian tersebut.
Error: VPC flow is not allowed to login in
Penyebab:
Server mendeteksi bahwa username dan password yang digunakan bukan kredensial statis yang dihasilkan di Konsol. Server salah mengidentifikasi traffic tersebut sebagai traffic autentikasi open-source dan menolak koneksi.
Solusi:
Setelah Anda memastikan konektivitas ke titik akhir VPC, verifikasi bahwa username dan password adalah kredensial statis yang dihasilkan di Konsol. Jika ragu, Anda dapat membuat ulang kredensial tersebut untuk memastikan konfigurasi yang benar.
Bagaimana cara mengaktifkan akses jaringan pribadi cross-region?
Solusi standarnya adalah PrivateLink + CEN.
Catatan: Solusi ini dikenai biaya PrivateLink. Untuk menggunakannya, Anda harus mengajukan tiket untuk meminta titik akhir pribadi. Setelah permintaan disetujui, Anda dapat mengonfigurasi titik akhir tersebut di Konsol. Saat mengonfigurasi titik akhir, verifikasi pengaturan zona vSwitch dan grup keamanan.
Untuk informasi selengkapnya, lihat Titik akhir PrivateLink.