Memecahkan Masalah Amazon MQ untuk ActiveMQ - Amazon MQ

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan Masalah Amazon MQ untuk ActiveMQ

Gunakan informasi di bagian ini untuk membantu Anda mendiagnosis dan menyelesaikan masalah umum yang mungkin Anda temui saat bekerja dengan Amazon MQ untuk broker ActiveMQ.

Saya tidak dapat melihat log umum atau audit untuk broker saya di CloudWatch Log meskipun saya telah mengaktifkan logging.

Jika Anda tidak dapat melihat log untuk broker Anda di CloudWatch Log, lakukan hal berikut.

  1. Periksa apakah pengguna yang membuat atau me-reboot broker memiliki logs:CreateLogGroup izin. Jika Anda tidak menambahkan CreateLogGroup izin ke pengguna sebelum pengguna membuat atau me-reboot broker, Amazon MQ tidak akan membuat grup log.

  2. Periksa apakah Anda telah mengonfigurasi kebijakan berbasis sumber daya untuk mengizinkan Amazon MQ menerbitkan log ke Log. CloudWatch Untuk mengizinkan Amazon MQ memublikasikan log ke grup CloudWatch log Log Anda, konfigurasikan kebijakan berbasis sumber daya untuk memberi Amazon MQ akses ke tindakan Log berikut: CloudWatch API

    • CreateLogStream— Membuat aliran CloudWatch log Log untuk grup log tertentu.

    • PutLogEvents— Mengirimkan peristiwa ke aliran CloudWatch log Log tertentu.

Untuk informasi selengkapnya tentang mengonfigurasi Amazon MQ untuk ActiveMQ untuk memublikasikan log CloudWatch ke Log, lihat Mengonfigurasi logging.

Setelah broker restart atau jendela pemeliharaan, saya tidak dapat terhubung ke broker saya meskipun statusnyaRUNNING. Kenapa?

Anda mungkin mengalami masalah koneksi setelah broker memulai ulang yang Anda mulai, setelah jendela pemeliharaan terjadwal selesai, atau dalam peristiwa kegagalan, di mana instance siaga diaktifkan. Dalam kedua kasus tersebut, masalah koneksi setelah broker memulai ulang kemungkinan besar disebabkan oleh sejumlah besar pesan yang bertahan di volume EBS penyimpanan Amazon atau EFS Amazon broker Anda. Selama restart, Amazon MQ memindahkan pesan tetap dari penyimpanan ke memori broker. Untuk mengonfirmasi diagnosis ini, Anda dapat memantau metrik berikut untuk Amazon MQ Anda CloudWatch untuk broker ActiveMQ:

  • StoragePercentUsagePersentase besar pada atau mendekati 100 persen dapat menyebabkan broker menolak koneksi.

  • JournalFilesForFullRecovery— Menunjukkan jumlah file jurnal yang akan diputar ulang setelah shutdown yang tidak bersih dan restart. Nilai yang meningkat, atau secara konsisten lebih tinggi dari satu, menunjukkan transaksi yang belum terselesaikan yang dapat menyebabkan masalah koneksi setelah restart.

  • OpenTransactionCount— Angka yang lebih besar dari nol setelah restart menunjukkan bahwa broker akan mencoba menyimpan pesan yang dikonsumsi sebelumnya, sehingga menyebabkan masalah koneksi.

Untuk mengatasi masalah ini, kami sarankan untuk menyelesaikan transaksi XA Anda dengan a rollback() atau a. commit() Untuk informasi selengkapnya, dan untuk melihat contoh kode penyelesaian transaksi XA menggunakanrollback(), lihat memulihkan transaksi XA.

Saya melihat beberapa klien saya terhubung ke broker, sementara yang lain tidak dapat terhubung.

Jika broker Anda dalam RUNNING status dan beberapa klien dapat terhubung ke broker dengan sukses, sementara yang lain tidak dapat melakukannya, Anda mungkin telah mencapai batas koneksi tingkat kabel untuk broker. Untuk memverifikasi bahwa Anda telah mencapai batas koneksi tingkat kabel, lakukan hal berikut:

  • Periksa log broker umum untuk Amazon MQ Anda untuk broker ActiveMQ di Log. CloudWatch Jika batas telah tercapai, Anda akan melihat Reached Maximum Connections di log broker. Untuk informasi lebih lanjut tentang CloudWatch Log untuk Amazon MQ untuk broker ActiveMQ, lihat. Memahami struktur logging di CloudWatch Log

Setelah batas koneksi tingkat kabel tercapai, broker akan secara aktif menolak koneksi masuk tambahan. Untuk mengatasi masalah ini, kami sarankan untuk meningkatkan jenis instans broker Anda. Untuk informasi selengkapnya tentang memilih jenis instans terbaik untuk beban kerja Anda, lihatBroker instance types.

Jika Anda telah mengonfirmasi bahwa jumlah koneksi tingkat kabel Anda kurang dari batas koneksi broker, masalahnya mungkin terkait dengan me-reboot klien. Periksa log broker Anda untuk entri yang banyak dan sering. ... Inactive for longer than 600000 ms - removing ... Entri log menunjukkan reboot klien atau masalah konektivitas. Efek ini lebih jelas ketika klien terhubung ke broker melalui Network Load Balancer (NLB) dengan klien yang sering memutuskan dan terhubung kembali ke broker. Ini lebih sering diamati pada klien berbasis kontainer.

Periksa log sisi klien Anda untuk detail lebih lanjut. Broker akan membersihkan TCP koneksi yang tidak aktif setelah 600000 ms, dan membebaskan soket koneksi.

Saya melihat pengecualian org.apache.jasper.JasperException: An exception occurred processing JSP page pada konsol ActiveMQ saat melakukan operasi.

Jika Anda menggunakan otentikasi sederhana dan mengonfigurasi AuthorizationPlugin untuk otorisasi antrian dan topik, pastikan untuk menggunakan AuthorizationEntries elemen dalam file XML konfigurasi Anda, dan izinkan izin activemq-webconsole grup untuk semua antrian dan topik. Ini memastikan bahwa konsol web ActiveMQ dapat berkomunikasi dengan broker ActiveMQ.

Contoh berikut AuthorizationEntry memberikan izin baca dan tulis untuk semua antrian dan topik ke grup. activemq-webconsole

<authorizationEntries> <authorizationEntry admin="activemq-webconsole,admins,users" topic=">" read="activemq-webconsole,admins,users" write="activemq-webconsole,admins,users" /> <authorizationEntry admin="activemq-webconsole,admins,users" queue=">" read="activemq-webconsole,admins,users" write="activemq-webconsole,admins,users" /> </authorizationEntries>

Demikian pula ketika mengintegrasikan broker Anda denganLDAP, pastikan untuk memberikan izin untuk amazonmq-console-admins grup. Untuk informasi selengkapnya tentang LDAP integrasi, lihatBagaimana LDAP integrasi bekerja.