Az Azure Event Hubs eseményfeldolgozójának hibaelhárítása

Ez a cikk olyan gyakori problémák megoldását ismerteti, amelyekkel a EventProcessorClient típus használatakor találkozhat. Ha az Azure Event Hubs használatakor felmerülő egyéb gyakori problémákra keres megoldást, tekintse meg az Azure Event Hubs hibaelhárítását.

412 előfeltételhibák eseményfeldolgozó használatakor

412 előfeltételi hiba akkor fordul elő, ha az ügyfél megpróbálja átvenni vagy megújítani egy partíció tulajdonjogát, de a tulajdonosi rekord helyi verziója elavult. Ez a probléma akkor fordul elő, ha egy másik processzorpéldány ellopja a partíció tulajdonjogát. További információkért lásd a következő szakaszt.

A rész tulajdonjoga gyakran változik

Amikor a EventProcessorClient példányok száma megváltozik (vagy hozzáadódnak, vagy eltávolítódnak), a futó példányok megpróbálják tehermentesíteni a partíciókat egymás között. A processzorok számának változása után néhány percig a partíciók várhatóan tulajdonost váltanak. A kiegyensúlyozottság után a partíció tulajdonjogának stabilnak kell lennie, és ritkán kell változnia. Ha a partíció tulajdonjoga gyakran változik, amikor a processzorok száma állandó, az valószínűleg problémát jelez. Javasoljuk, hogy küldjön be egy GitHub-problémát a naplókkal és a hibaelismétléssel kapcsolatban.

A partíció tulajdonjogát a rendszer a tulajdonosi rekordok alapján határozza meg a CheckpointStore. Minden terheléselosztási időközön a EventProcessorClient következő feladatokat hajtja végre:

1. Kérje le a legújabb tulajdonosi rekordokat.
2. Ellenőrizze a rekordokat, hogy mely rekordok nem frissítették az időbélyegüket a partíció tulajdonjogának lejárati időszakában. A rendszer csak a feltételeknek megfelelő rekordokat veszi figyelembe.
3. Ha vannak gazdátlan partíciók, és a terhelés nincs kiegyenlítve a EventProcessorClient példányok között, az eseményfeldolgozó ügyfél megpróbál partíciót igényelni.
4. Frissítse azon partíciók tulajdonosi rekordját, amelyek aktív kapcsolatban állnak az adott partícióval.

A terheléselosztási és tulajdonosi lejárati időközöket konfigurálhatja, amikor létrehozza a EventProcessorClient-t a EventProcessorClientBuilder segítségével, a következő listában ismertetett módon.

• A loadBalancingUpdateInterval(Duration) metódus azt jelzi, hogy milyen gyakran fut a terheléselosztási ciklus.
• A partitionOwnershipExpirationInterval(Duration) metódus jelzi a tulajdonosi rekord frissítése óta eltelt minimális időtartamot, mielőtt a feldolgozó nem veszi figyelembe a partíciót.

Ha például egy tulajdonosi rekordot 9:30-kor frissítettek, és partitionOwnershipExpirationInterval az 2 perc. Amikor terheléselosztási ciklus következik be, és azt veszi észre, hogy a tulajdonosi rekord nem frissült az elmúlt 2 percben vagy 9:32-ig, a partíciót nem veszi figyelembe.

Ha hiba történik az egyik partíciófelhasználóban, bezárja a megfelelő fogyasztót, de a következő terheléselosztási ciklusig nem próbálja visszakövetelni.

"... A jelenlegi "<RECEIVER_NAME>" fogadó a "0" korszakmal megszakad"

A teljes hibaüzenet a következő kimenethez hasonlóan néz ki:

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}"}

Ez a hiba akkor várható, ha a terheléselosztás a példányok hozzáadása vagy eltávolítása után EventProcessorClient következik be. A terheléselosztás egy folyamatban lévő folyamat. Amikor a BlobCheckpointStore együtt használja a fogyasztóval, alapértelmezés szerint a fogyasztó ~30 másodpercenként ellenőrzi, hogy mely fogyasztók regisztráltak az egyes partíciókra, majd futtat egy logikai folyamatot annak meghatározására, hogy szükséges-e „ellopnia” egy partíciót egy másik fogyasztótól. A partíciók kizárólagos tulajdonjogának érvényesítésére használt szolgáltatási mechanizmus az Epoch néven ismert.

Ha azonban nem adnak hozzá vagy távolítanak el példányokat, van egy mögöttes probléma, amelyet meg kell oldani. További információkért tekintse meg a partíció tulajdonjogának gyakori változásait és a GitHub-problémák bejelentését ismertető szakaszt.

Magas processzorhasználat

A magas processzorhasználat általában azért van, mert egy példány túl sok partícióval rendelkezik. Minden cpu-maghoz legfeljebb három partíciót ajánlunk. Érdemes 1,5 partícióval kezdeni az egyes CPU-magok esetében, majd tesztelni a saját partíciók számának növelésével.

Memória elégtelenség és a halomméret kiválasztása

A memóriahiány (OOM) probléma akkor fordulhat elő, ha a JVM aktuális maximális halomja nem elegendő az alkalmazás futtatásához. Érdemes lehet mérni az alkalmazás heap-követelményét. Ezután az eredmény alapján méretezheti a halommemóriát a megfelelő maximális halommemória JVM-beállítással történő beállításával -Xmx .

Nem szabad -Xmx értékét a rendelkezésre álló memória vagy a gazdagép (a virtuális gép vagy tároló) számára beállított korlátnál nagyobbra állítani, például a tároló konfigurációjában kért memóriát. Elegendő memóriát kell kiosztania a gazdagépnek a Java-készlet támogatásához.

Az alábbi lépések a Java-halom maximális értékének mérésére szolgáló tipikus módszert írják le:

1. Futtassa az alkalmazást egy éles környezethez közeli környezetben, ahol az alkalmazás az éles környezetben várható legnagyobb terhelés alatt küldi, fogadja és dolgozza fel az eseményeket.

2. Várja meg, amíg az alkalmazás eléri az állandó állapotot. Ebben a szakaszban az alkalmazás és a JVM betöltötte volna az összes tartományobjektumot, osztálytípust, statikus példányt, objektumkészletet (TCP, DB kapcsolatkészletek) stb.

   Állandósult állapotban megjelenik a halomgyűjtés stabil fűrészfog alakú mintázata, ahogyan az alábbi képernyőképen látható.

   

3. Miután az alkalmazás elérte az állandó állapotot, kényszerítse ki a teljes szemétgyűjtést (GC) olyan eszközökkel, mint a JConsole. Figyelje meg a teljes GC után elfoglalt memóriát. Úgy szeretné méretezni a halomot, hogy a teljes GC után csak 30% legyen foglalt. Ezzel az értékkel beállíthatja a halom maximális méretét (-Xmx használatával).

Ha a tárolóval dolgozik, méretezze úgy a tárolót, hogy a JVM-példány nem halomhoz tartozó memóriaigényéhez további ~1 GB memóriával rendelkezzen.

A processzor kliens leállítja a fogadást

A processzorügyfél gyakran napokig folyamatosan fut egy gazdaalkalmazásban. Néha észreveheti, hogy EventProcessorClient nem dolgoz fel egy vagy több partíciót. Általában nincs elég információ a kivétel okának megállapításához. A EventProcessorClient leállítás egy mögöttes ok (vagyis a versenyállapot) tünete, amely egy átmeneti hiba utáni helyreállítás során következett be. A szükséges információkért lásd: GitHub-problémák bejelentése.

Duplikált EventData érkezett a processzor újraindításakor

Az EventProcessorClient és az Event Hubs szolgáltatás legalább egyszer biztosítja a kézbesítést . Metaadatokat is hozzáadhat az ismétlődő események észleléséhez. További információ: Az Azure Event Hubs legalább egyszeri kézbesítést garantál a Stack Overflow-on . Ha csak egyszeri kézbesítést igényel, fontolja meg a Service Bus használatát, amely megvárja az ügyfél nyugtázását. Az üzenetkezelési szolgáltatások összehasonlítását lásd: Kiválasztás az Azure üzenetkezelési szolgáltatások között.

Az alacsony szintű fogyasztói kliens leáll a fogadással

EventHubConsumerAsyncClient az Event Hubs-kódtár által biztosított alacsony szintű fogyasztói ügyfél, amelyet olyan fejlett felhasználók számára terveztek, akik nagyobb ellenőrzést és rugalmasságot igényelnek a reaktív alkalmazások felett. Ez az ügyfél alacsony szintű felületet kínál, amely lehetővé teszi a felhasználók számára a visszanyomó hatás, a szálkezelés és a helyreállítás kezelését a Reactor láncban. Ellentétben EventProcessorClient-val, a EventHubConsumerAsyncClient nem tartalmaz automatikus helyreállítási mechanizmusokat az összes terminálesethez. Ezért a felhasználóknak kezelnie kell a termináleseményeket, és ki kell választaniuk a megfelelő reaktorüzemeltetőket a helyreállítási stratégiák megvalósításához.

A EventHubConsumerAsyncClient::receiveFromPartition metódus terminálhibát ad ki, ha a kapcsolat nem újrapróbálkozási hibába ütközik, vagy ha egy sor kapcsolat-helyreállítási kísérlet egymás után meghiúsul, és kimeríti a maximális újrapróbálkozási korlátot. Bár az alacsony szintű fogadó megpróbál helyreállni átmeneti hibákból, a fogyasztói ügyfél felhasználóinak várhatóan kezelnie kell a termináleseményeket. Ha folyamatos eseményfogadásra van szükség, az alkalmazásnak módosítania kell a Reactor-láncot, hogy új fogyasztói ügyfelet hozzon létre egy termináleseményen.

Migrálás régiről új ügyfélkódtárba

A migrálási útmutató az örökölt ügyfélről való migrálás és az örökölt ellenőrzőpontok migrálásának lépéseit tartalmazza.

Következő lépések

Ha a cikkben található hibaelhárítási útmutató nem segít megoldani az Azure SDK for Java ügyfélkönyvtárak használatakor felmerülő problémákat, javasoljuk, hogy hibajegyet nyújtson be a Java-hoz készült Azure SDK GitHub-adattárban.