Pernyataan kueri umum untuk pemecahan masalah - ApsaraMQ for RabbitMQ

Topik ini menjelaskan cara menggunakan log yang dihasilkan untuk instance ApsaraMQ for RabbitMQ guna mengidentifikasi dan menganalisis masalah. Jika pesan tidak dikirim atau diterima sesuai harapan, terjadi pengecualian, atau ada akumulasi pesan selama konsumsi, Anda dapat menggunakan metode dalam topik ini untuk mengidentifikasi pengecualian dan memastikan stabilitas bisnis.

Prasyarat

Fitur manajemen log pesan harus diaktifkan dan indeks dikonfigurasi. Untuk informasi lebih lanjut, lihat Manajemen Log Pesan.

Ikhtisar pernyataan umum

Kueri Daftar Alamat IP Produsen Berdasarkan Pertukaran
Kueri Daftar Alamat IP Konsumen Berdasarkan Antrian
Kueri Jejak Pesan
Kueri Konsumsi Pesan dalam Antrian
Kueri Log Pesan dalam Antrian Pesan Gagal

Topik ini menjelaskan pernyataan kueri umum dalam Layanan Log Sederhana. Untuk informasi tentang operasi dan format log, lihat Manajemen Log Pesan.

Kueri daftar alamat IP produsen berdasarkan pertukaran

Dalam kotak pencarian Layanan Log Sederhana, masukkan pernyataan berikut untuk menanyakan daftar alamat IP produsen:

* and Action : SendMessage and Code : 200 | 
select 
  split_part(ResourceName,',',2) as exchange_name, 
  split_part(ResourceName, ',', 3) as routing_key, 
  RemoteAddress as ip_port, 
  count(*) as total_send_num 
group by 
  exchange_name, routing_key, ip_port 
order by 
  total_send_num DESC 
limit 1000000

Gambar berikut menunjukkan hasil kueri sampel.

Kueri daftar alamat IP konsumen berdasarkan antrian

Dalam kotak pencarian Layanan Log Sederhana, masukkan pernyataan berikut untuk menanyakan daftar alamat IP konsumen:

* and Action : PushMessage and Code : 200 | 
select 
  InstanceId as instance_id,
  VHost as virtual_host, 
  Queue as queue_name, 
  RemoteAddress as ip_port, 
  count(*) as push_total_num 
group by 
  instance_id,virtual_host, ip_port, queue_name 
order by 
  push_total_num DESC
limit 10000000

Gambar berikut menunjukkan hasil kueri sampel.

Kueri jejak pesan

Dalam kotak pencarian Layanan Log Sederhana, masukkan pernyataan kueri untuk menanyakan jejak pesan.

Kueri Jejak Pesan Berdasarkan ID Pesan
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:cycle**** and ResourceName:msgId=27127757-44dc-4373-afc5-f8ea12f****
```
Gambar berikut menunjukkan hasil kueri sampel.
Jika klien berlangganan pesan dengan memanggil metode BasicConsume, jejak pesan yang mencatat pengiriman dan pendorongan pesan dapat dikueri. Dalam log pesan yang dikueri, nilai SendMessage menunjukkan panggilan ke metode BasicPublish pada klien, dan nilai PushMessage menunjukkan pendorongan pesan oleh broker ke klien. Jika klien menarik pesan dengan memanggil metode BasicGet, nilai parameter Action dalam log pesan adalah BasicGet, bukan PushMessage.
Catatan
- Jika SendMessage hanya dicatat dalam satu entri log tetapi PushMessage atau BasicGet dicatat dalam beberapa entri log dalam log pesan yang dikembalikan, klien mungkin gagal mengakui konsumsi pesan dalam periode valid dengan memanggil metode BasicAck. Klien hanya dapat mengakui konsumsi pesan jika Anda memanggil metode BasicAck dalam periode timeout konsumsi setelah pesan pertama kali dikirim. Jika metode BasicAck dipanggil di luar waktu valid, broker menentukan bahwa klien gagal mengonsumsi pesan dan mendorong pesan lagi. Untuk informasi tentang periode timeout konsumsi, lihat Parameter Kebijakan Ulang Instans.
- Jika SendDlqMessage dicatat selain SendMessage dan PushMessage, pesan tersebut dikirim ke antrian pesan gagal.
Kueri Apakah Pesan Dikonsumsi
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:cycle**** and Queue:cycleCheckQueue**** and ConnectionId:00163efffe08281f-00004e11-0009732f-799c0af9bc4e4913-96b3**** and  ChannelId:1 and (ResourceName:deliveryTag=90 or Property:deliveryTag=90) and RemoteAddress:"/192.168.XX.XX:XXXX"            
```
Anda dapat memperoleh nilai parameter ConnectionId, ChannelId, deliveryTag, dan RemoteAddress berdasarkan entri log yang mencatat PushMessage. RemoteAddress menentukan alamat IP klien. ConnectionId menentukan pengenal unik koneksi. ChannelId menentukan pengenal unik saluran. deliveryTag menentukan pengenal unik yang ditambahkan ke pesan oleh broker. Jika DeleteMessage dicatat, pesan dikonsumsi oleh klien.
Gambar berikut menunjukkan hasil kueri sampel.
Catatan
Jika klien memanggil metode BasicConsume dengan pengaturan autoAck=false, broker dapat mengakui konsumsi pesan dan menghapus pesan hanya setelah klien memanggil metode BasicAck. Klien hanya dapat mengakui konsumsi pesan jika Anda memanggil metode BasicAck dalam periode timeout konsumsi setelah pesan pertama kali dikirim. Jika metode BasicAck dipanggil di luar periode valid, broker menentukan bahwa pesan gagal dikonsumsi dan mendorong pesan ke klien lagi. Untuk informasi lebih lanjut, lihat Parameter Kebijakan Ulang Instans.
- Jika klien memanggil metode BasicAck tetapi DeleteMessage tidak dicatat, pesan gagal dikonsumsi. Dalam hal ini, Anda dapat memeriksa perbedaan antara waktu ketika metode PushMessage dipanggil dan waktu ketika metode BasicAck dipanggil. Jika perbedaannya lebih besar dari periode timeout konsumsi, panggilan ke metode BasicAck tidak valid.
- Jika hanya PushMessage dan DeleteMessage yang dicatat, klien mungkin telah memanggil metode BasicAck dengan pengaturan deliveryTag, multiple=true. Pengaturan ini menunjukkan bahwa broker mengakui konsumsi semua pesan sebelum deliveryTag sekaligus.

Kueri konsumsi pesan dalam antrian

Dalam kotak pencarian Layanan Log Sederhana, masukkan pernyataan kueri untuk menanyakan log untuk metode SendMessage, PushMessage atau BasicGet, BasicAck, dan DeleteMessage. Layanan Log Sederhana menghitung persentase pangsa setiap metode terhadap total panggilan metode. Jika pangsa setiap metode sama atau hampir sama, pesan dikirim dan dikonsumsi pada laju yang serupa. Ini menunjukkan bahwa tidak ada pesan atau sejumlah kecil pesan yang terakumulasi dalam antrian.

InstanceId:amqp-cn-i7m29o3s**** and Vhost:cycle**** and Queue: cycleCheckQueue**** and (SendMessage or PushMessage or BasicAck  or DeleteMessage)

Gambar berikut menunjukkan hasil kueri sampel.

Jika salah satu skenario berikut terjadi dalam log pesan yang dikueri, analisis penyebabnya berdasarkan deskripsi berikut:

Jika DeleteMessage tidak dicatat, klien mungkin telah memanggil metode BasicConsume atau BasicGet dengan pengaturan autoAck=true atau gagal memproses permintaan untuk mengakui pesan dalam periode timeout konsumsi. Untuk informasi tentang periode timeout konsumsi, lihat Parameter Kebijakan Ulang Instans.
Jika pangsa panggilan ke metode PushMessage secara signifikan lebih kecil daripada pangsa panggilan ke metode SendMessage, jumlah konsumen yang berlangganan pesan mungkin terlalu sedikit. Dalam hal ini, kami sarankan Anda membuat lebih banyak koneksi dan membuat lebih banyak konsumen.
Jika pangsa panggilan ke metode SendMessage hampir sama dengan pangsa panggilan ke metode PushMessage dan pangsa panggilan ke metode DeleteMessage secara signifikan lebih kecil daripada pangsa panggilan ke metode SendMessage atau PushMessage, klien mungkin gagal memproses permintaan untuk mengakui pesan dalam periode timeout konsumsi. Untuk informasi tentang periode timeout konsumsi, lihat Parameter Kebijakan Ulang Instans.
Jika pangsa panggilan ke metode SendMessage, PushMessage, dan DeleteMessage hampir sama dan pangsa panggilan ke metode BasicAck kecil, klien mungkin telah memanggil metode BasicAck dengan pengaturan multiple=true.

Kueri log pesan dalam antrian pesan gagal

Dalam kotak pencarian Layanan Log Sederhana, masukkan pernyataan kueri untuk menanyakan log pesan dalam antrian pesan gagal.

Kueri Log Pesan yang Dikirim ke Antrian Pesan Gagal Setelah Waktu Hidup (TTL) Pesan Berakhir
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and ResourceName:msgId=02a162ba-f842-440f-bfd4-2595dd19****
```
Gambar berikut menunjukkan hasil kueri sampel.
Nilai SendMessage menunjukkan bahwa klien memanggil metode BasicPublish untuk mengirim pesan. Nilai SendDlqMessage menunjukkan bahwa pesan dikirim ke antrian pesan gagal setelah TTL pesan berakhir.
Catatan
SendDlqMessage hanya dicatat jika antrian pesan gagal dikonfigurasi.

Kueri Log Pesan yang Dikirim ke Antrian Pesan Gagal Setelah TTL Antrian Berakhir

Konfigurasikan atribut pesan gagal dan TTL antrian.

Map<String, Object> argument = new HashMap<>();
argument.put("x-dead-letter-exchange", [exchangeName]);
argument.put("x-dead-letter-routing-key", [routingKey]);
argument.put("x-message-ttl", [ttl]);
channel.queueDeclare([queueName], true, false, false, argument);

Dalam kotak pencarian Layanan Log Sederhana, masukkan informasi berikut untuk menanyakan log untuk SendMessage dan SendDlqMessage:
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and ResourceName:msgId=034a75c5-d957-422f-822e-72dfad2a****
```

Jika klien memanggil metode BasicReject atau BasicNack dengan pengaturan requeue=false, masukkan informasi berikut untuk menanyakan log untuk SendDlqMessage:
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and (ResourceName:msgId=034a75c5-d957-422f-822e-72dfad2a**** or ResourceName:deliveryTag=1)
```
Dalam gambar sebelumnya, entri log untuk PushMessage menunjukkan bahwa broker mendorong pesan ke klien. Setelah pesan diterima oleh klien, klien memanggil metode BasicReject dengan pengaturan requeue=false. Jika SendDlqMessage dicatat, pesan dikirim ke antrian pesan gagal.