Pemecahan masalah pemroses acara Azure Event Hubs

Artikel ini menyediakan solusi untuk masalah umum yang mungkin Anda temui saat menggunakan jenis tersebut EventProcessorClient . Jika Anda mencari solusi untuk masalah umum lainnya yang mungkin Anda temui saat menggunakan Azure Event Hubs, lihat Memecahkan Masalah Azure Event Hubs.

Kegagalan prasyarat 412 saat Anda menggunakan pemroses acara

Kesalahan prasyarat 412 terjadi ketika klien mencoba mengambil atau memperbarui kepemilikan partisi, tetapi versi lokal catatan kepemilikan sudah kedaluwarsa. Masalah ini terjadi ketika instans prosesor lain mencuri kepemilikan partisi. Untuk informasi selengkapnya, lihat bagian berikutnya.

Kepemilikan partisi sering berubah

Ketika jumlah EventProcessorClient instans berubah (yaitu, ditambahkan atau dihapus), instans yang sedang berjalan mencoba untuk menyeimbangkan beban partisi di antara mereka sendiri. Selama beberapa menit setelah jumlah prosesor berubah, diharapkan partisi akan berganti pemilik. Setelah seimbang, kepemilikan partisi harus stabil dan jarang berubah. Jika kepemilikan partisi sering berubah ketika jumlah prosesor konstan, kemungkinan menunjukkan masalah. Kami menyarankan agar Anda mengajukan isu di GitHub dengan log dan reproduksi.

Kepemilikan partisi ditentukan melalui catatan kepemilikan di CheckpointStore. Pada setiap interval penyeimbangan beban, EventProcessorClient akan melakukan tugas-tugas berikut:

1. Dapatkan catatan kepemilikan terbaru.
2. Periksa rekaman untuk melihat rekaman mana yang belum memperbarui tanda waktunya dalam interval kedaluwarsa kepemilikan partisi. Hanya rekaman yang cocok dengan kriteria ini yang dipertimbangkan.
3. Jika ada partisi yang tidak dimiliki dan beban tidak merata di antara instans EventProcessorClient, klien pemrosesan peristiwa akan mencoba mengklaim partisi.
4. Perbarui catatan kepemilikan untuk partisi yang dimilikinya yang memiliki tautan aktif ke partisi tersebut.

Anda dapat mengonfigurasi interval kedaluwarsa penyeimbangan beban dan kepemilikan saat membuat EventProcessorClient melalui EventProcessorClientBuilder, seperti yang dijelaskan dalam daftar berikut:

• Metode loadBalancingUpdateInterval(Duration) menunjukkan seberapa sering siklus penyeimbangan beban berjalan.
• Metode partitionOwnershipExpirationInterval(Duration) menunjukkan jumlah waktu minimum sejak rekam kepemilikan telah diperbarui, sebelum prosesor menganggap partisi tidak dimiliki.

Misalnya, jika catatan kepemilikan diperbarui pada pukul 09.30 dan partitionOwnershipExpirationInterval adalah 2 menit. Ketika siklus keseimbangan beban terjadi dan sistem melihat bahwa catatan kepemilikan belum diperbarui selama 2 menit terakhir atau pada pukul 9:32 pagi, sistem akan menganggap partisi tersebut tidak dimiliki.

Jika terjadi kesalahan pada salah satu pengguna partisi, sistem akan menutup pengguna yang sesuai tetapi tidak akan berupaya merebut kembali sampai siklus penyeimbangan beban berikutnya.

"... penerima saat ini '<RECEIVER_NAME>' dengan epoch '0' sedang terputus"

Seluruh pesan kesalahan terlihat mirip dengan output berikut:

New receiver 'nil' with higher epoch of '0' is created hence current receiver 'nil' with epoch '0'
is getting disconnected. If you are recreating the receiver, make sure a higher epoch is used.
TrackingId:<GUID>, SystemTracker:<NAMESPACE>:eventhub:<EVENT_HUB_NAME>|<CONSUMER_GROUP>,
Timestamp:2022-01-01T12:00:00}"}

Kesalahan ini dapat terjadi ketika distribusi beban terjadi setelah EventProcessorClient instans ditambahkan atau dihapus. Penyeimbangan beban adalah proses yang sedang berlangsung. Ketika Anda menggunakan BlobCheckpointStore dengan konsumen Anda, setiap ~ 30 detik (secara default), konsumen memeriksa konsumen mana yang memiliki hak untuk setiap partisi, lalu menggunakan logika tertentu untuk menentukan apakah perlu mengambil alih partisi dari konsumen lain. Mekanisme layanan yang digunakan untuk menegaskan kepemilikan eksklusif atas partisi dikenal sebagai Epoch.

Namun, jika tidak ada instance yang ditambahkan atau dihapus, ada masalah mendasar yang harus ditangani. Untuk informasi selengkapnya, lihat bagian Perubahan kepemilikan partisi sering dan Pengajuan Masalah GitHub.

Penggunaan CPU tinggi

Penggunaan CPU yang tinggi biasanya karena instans memiliki terlalu banyak partisi. Kami merekomendasikan tidak lebih dari tiga partisi untuk setiap inti CPU. Lebih baik memulai dengan 1,5 partisi untuk setiap inti CPU dan kemudian menguji dengan meningkatkan jumlah partisi yang dimiliki.

Kehabisan memori dan memilih ukuran tumpukan

Masalah kehabisan memori (OOM) dapat terjadi jika tumpukan maksimal saat ini bagi JVM tidak cukup untuk menjalankan aplikasi. Anda mungkin ingin mengukur kebutuhan memori heap dari aplikasi. Kemudian, berdasarkan hasilnya, atur ukuran heap dengan mengatur memori heap maksimum yang sesuai menggunakan JVM opsi -Xmx.

Anda tidak boleh menentukan -Xmx sebagai nilai yang lebih besar dari memori yang tersedia atau batas yang ditetapkan untuk host (VM atau kontainer) - misalnya, memori yang diminta dalam konfigurasi kontainer. Anda harus mengalokasikan memori yang cukup untuk host agar dapat mendukung heap Java.

Langkah-langkah berikut menjelaskan cara umum untuk mengukur nilai Heap Java maksimum.

1. Jalankan aplikasi di lingkungan yang dekat dengan produksi, tempat aplikasi mengirim, menerima, dan memproses peristiwa di bawah beban puncak yang diharapkan dalam produksi.

2. Tunggu hingga aplikasi mencapai status stabil. Pada tahap ini, aplikasi dan JVM akan memuat semua objek domain, jenis kelas, instans statis, kumpulan objek (TCP, kumpulan koneksi DB), dll.

   Di bawah keadaan mantap, Anda melihat pola berbentuk gigi gergaji yang stabil untuk koleksi tumpukan, seperti yang ditunjukkan pada cuplikan layar berikut:

   

3. Setelah aplikasi mencapai status stabil, paksa pengumpulan sampah penuh (GC) menggunakan alat seperti JConsole. Amati memori yang ditempati setelah GC penuh. Anda ingin mengukur tumpukan sedemikian rusa sehingga hanya 30% yang ditempati setelah GC penuh. Anda dapat menggunakan nilai ini untuk mengatur ukuran timbunan maks (menggunakan -Xmx).

Jika Anda berada di kontainer, maka ukuran kontainer untuk memiliki memori ~1 GB tambahan untuk kebutuhan non-timbunan untuk instans JVM.

Klien prosesor berhenti menerima

Klien prosesor sering terus berjalan dalam aplikasi host selama ber hari-hari. Terkadang, ia melihat bahwa EventProcessorClient tidak memproses satu atau beberapa partisi. Biasanya, tidak ada cukup informasi untuk menentukan mengapa pengecualian terjadi. Penghentian EventProcessorClient adalah gejala penyebab yang mendasar (yaitu, kondisi balapan) yang terjadi saat mencoba pulih dari kesalahan sementara. Untuk informasi yang kami butuhkan, lihat Melaporkan masalah GitHub.

Duplikat EventData diterima saat prosesor dimulai ulang

Layanan EventProcessorClient azure Event Hubs dan menjamin pengiriman setidaknya sekali . Anda dapat menambahkan metadata untuk membedakan peristiwa duplikat. Untuk informasi selengkapnya, lihat Apakah Azure Event Hubs menjamin pengiriman setidaknya sekali? di Stack Overflow. Jika Anda memerlukan pengiriman hanya sekali , Anda harus mempertimbangkan Service Bus, yang menunggu pengakuan dari klien. Untuk perbandingan layanan olahpesan, lihat Memilih antara layanan olahpesan Azure.

Klien konsumen tingkat rendah berhenti menerima

EventHubConsumerAsyncClient adalah klien konsumen tingkat rendah yang disediakan oleh pustaka Azure Event Hubs, yang dirancang untuk pengguna tingkat lanjut yang memerlukan kontrol dan fleksibilitas yang lebih besar atas aplikasi Reaktif mereka. Klien ini menawarkan antarmuka tingkat rendah, memungkinkan pengguna untuk mengelola backpressure, threading, dan pemulihan dalam rantai Reaktor. Tidak seperti EventProcessorClient, EventHubConsumerAsyncClient tidak termasuk mekanisme pemulihan otomatis untuk semua penyebab terminal. Oleh karena itu, pengguna harus menangani peristiwa terminal dan memilih operator Reactor yang sesuai untuk menerapkan strategi pemulihan.

Metode ini EventHubConsumerAsyncClient::receiveFromPartition mengeluarkan kesalahan fatal ketika koneksi mengalami kesalahan yang tidak dapat diulang atau ketika serangkaian upaya pemulihan koneksi gagal berturut-turut, melebihi batas maksimum percobaan ulang. Meskipun penerima tingkat rendah mencoba pulih dari kesalahan sementara, pengguna klien konsumen diharapkan untuk menangani peristiwa terminal. Jika penerimaan acara berkelanjutan diinginkan, aplikasi harus menyesuaikan rantai Reaktor untuk membuat klien konsumen baru pada peristiwa terminal.

Migrasi dari warisan ke pustaka klien baru

Panduan migrasi mencakup langkah-langkah migrasi dari klien warisan dan memigrasikan titik pemeriksaan warisan.

Langkah berikutnya

Jika panduan pemecahan masalah dalam artikel ini tidak membantu mengatasi masalah saat Anda menggunakan pustaka klien Azure SDK for Java, kami sarankan Anda mengajukan masalah di repositori Azure SDK for Java GitHub .