Řešení potíží s procesorem událostí Služby Azure Event Hubs

Tento článek obsahuje řešení běžných problémů, se kterými se můžete setkat při použití EventProcessorClient typu. Pokud hledáte řešení jiných běžných problémů, se kterými se můžete setkat při používání služby Azure Event Hubs, přečtěte si téma Řešení potíží se službou Azure Event Hubs.

412 selhání předběžných podmínek při použití procesoru událostí

K chybám 412 předběžné podmínky dochází, když se klient pokusí převzít nebo obnovit vlastnictví oddílu, ale lokální verze záznamu o vlastnictví je zastaralá. K tomuto problému dochází, když jiná instance procesoru ukradne vlastnictví oddílu. Další informace najdete v další části.

Vlastnictví oddílů se často mění

Když se počet EventProcessorClient instancí změní (to znamená, že se přidají nebo odeberou), spuštěné instance se pokusí vyrovnávat zatížení oddílů mezi sebou. Po několika minutách po změně počtu procesorů se očekává, že se vlastníci změní. Po vyvážení by mělo být vlastnictví oddílů stabilní a často se měnit. Pokud se vlastnictví oddílů často mění, když je počet procesorů konstantní, pravděpodobně to značí problém. Doporučujeme, abyste s protokoly a ukázkou problému vytvořili problém na GitHubu.

Vlastnictví oddílu se určuje prostřednictvím záznamů vlastnictví v souboru CheckpointStore. V každém intervalu vyrovnávání zatížení provede následující EventProcessorClient úlohy:

1. Načtěte nejnovější záznamy vlastnictví.
2. Zkontrolujte záznamy a zjistěte, které záznamy neaktualizovaly časové razítko v intervalu vypršení platnosti vlastnictví oddílu. Zvažují se pouze záznamy odpovídající tomuto kritériu.
3. Pokud existují nějaké nevlastněné oddíly a zatížení není vyváženo mezi instancemi EventProcessorClient, klient procesoru událostí se pokusí deklarovat oddíl.
4. Aktualizujte záznam vlastnictví pro oddíly, které vlastní a které mají aktivní propojení k tomuto oddílu.

Intervaly vypršení platnosti vyrovnávání zatížení a vlastnictví můžete nakonfigurovat při vytváření EventProcessorClient prostřednictvím EventProcessorClientBuildernástroje , jak je popsáno v následujícím seznamu:

• Metoda loadBalancingUpdateInterval(Duration) označuje, jak často cyklus vyrovnávání zatížení běží.
• Metoda partitionOwnershipExpirationInterval(Duration) označuje minimální dobu od aktualizace záznamu vlastnictví, než procesor považuje oddíl bez vlastníka.

Pokud se například záznam o vlastnictví aktualizoval v 9:30 a partitionOwnershipExpirationInterval 2 minuty. Když dojde k cyklu vyrovnávání zatížení a systém zjistí, že záznam vlastnictví nebyl aktualizován během posledních dvou minut nebo do 9:32 ráno, považuje odpovídající oddíl za neobsazený.

Pokud dojde k chybě v jednom z příjemců oddílů, zavře odpovídající příjemce, ale nebude se pokoušet ho uvolnit až do dalšího cyklu vyrovnávání zatížení.

"... aktuální přijímač '<RECEIVER_NAME>' s epochou '0' se odpojí"

Celá chybová zpráva vypadá podobně jako v následujícím výstupu:

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

Tato chyba se očekává, když dojde k vyrovnávání zatížení po přidání nebo odebrání instancí EventProcessorClient. Vyrovnávání zatížení je probíhající proces. Když použijete BlobCheckpointStore s příjemcem každých přibližně 30 sekund (ve výchozím nastavení), příjemce zkontroluje, kteří příjemci mají deklaraci identity pro každý oddíl, a pak spustí logiku, která určí, jestli potřebuje "ukrást" oddíl od jiného příjemce. Služební mechanismus používaný k uplatnění výhradního vlastnictví nad oddílem se nazývá Epocha.

Pokud se ale nepřidají ani neodeberou žádné instance, měl by se vyřešit základní problém. Další informace najdete v oddílu Změny vlastnictví oddílu a oznamování problémů na GitHubu.

Vysoké využití procesoru

Vysoké využití procesoru je obvykle způsobeno tím, že instance vlastní příliš mnoho oddílů. Pro každé jádro procesoru doporučujeme maximálně tři oddíly. Je lepší začít s jedním a půl oddílem pro každé jádro procesoru a poté provádět testy zvyšováním počtu vlastněných oddílů.

Nedostatek paměti a volba velikosti haldy

K problému s nedostatkem paměti (OOM) může dojít, pokud aktuální maximální velikost haldy pro JVM není dostatečná ke spuštění aplikace. Možná budete chtít změřit požadavky na haldu aplikace. Pak na základě výsledku nastavte velikost haldy tím, že pomocí možnosti JVM -Xmx určíte odpovídající maximální paměť haldy.

Neměli byste zadávat -Xmx hodnotu větší než dostupná paměť nebo omezení nastavené pro hostitele (virtuální počítač nebo kontejner), například paměť požadovanou v konfiguraci kontejneru. Abyste zajistili podporu hromady paměti Java, měli byste přidělit dostatek paměti pro hostitelský systém.

Následující kroky popisují typický způsob určení hodnoty pro maximální Java Heap:

1. Spusťte aplikaci v prostředí v blízkosti produkčního prostředí, kde aplikace odesílá, přijímá a zpracovává události v produkčním prostředí v očekávaném zatížení ve špičce.

2. Počkejte, až aplikace dosáhne stabilního stavu. V této fázi by aplikace a JVM načetly všechny objekty domény, typy tříd, statické instance, fondy objektů (TCP, fondy připojení k databázi) atd.

   V ustáleném stavu uvidíte stabilní pilový vzor pro sběrnici haldy, jak je znázorněno na následujícím snímku obrazovky.

   

3. Jakmile aplikace dosáhne stabilního stavu, vynuťte úplné uvolňování paměti (GC) pomocí nástrojů, jako je JConsole. Sledujte zaplněnou paměť po úplném uvolňování paměti. Chcete nastavit velikost haldy tak, aby po úplném uvolnění paměti bylo obsazeno pouze 30%. Tuto hodnotu můžete použít k nastavení maximální velikosti haldy (pomocí -Xmx).

Pokud jste v kontejneru, nastavte velikost kontejneru tak, aby měl extra ~1 GB paměti pro potřebu mimo haldu instance JVM.

Klient procesoru přestane přijímat

Klient procesoru často běží v hostitelské aplikaci po celé dny. Někdy se zjistí, že EventProcessorClient nezpracovává jeden nebo více oddílů. Obvykle není k dispozici dostatek informací, abyste zjistili, proč k výjimce došlo. Zastavení EventProcessorClient je příznakem základní příčiny (tj. stavu časování), ke které došlo při pokusu o zotavení z přechodné chyby. Informace, které požadujeme, najdete v části Podávání problémů na GitHubu.

Duplicitní data událostí přijatá při restartování procesoru

Služba EventProcessorClient Event Hubs zaručuje aspoň jedno doručení. Můžete přidat metadata pro rozlišení duplicitních událostí. Další informace najdete v tématu Zaručuje služba Azure Event Hubs alespoň jedno doručení? ve službě Stack Overflow. Pokud vyžadujete pouze jedno doručení, měli byste zvážit službu Service Bus, která čeká na potvrzení od klienta. Porovnání služeb zasílání zpráv najdete v tématu Volba mezi službami zasílání zpráv Azure.

Klient příjemce nízké úrovně přestane přijímat

EventHubConsumerAsyncClient je nízkoúrovňový spotřebitelský klient poskytovaný knihovnou Event Hubs, určený pro pokročilé uživatele, kteří vyžadují větší kontrolu a flexibilitu nad svými reaktivními aplikacemi. Tento klient nabízí nízkoúrovňové rozhraní, které uživatelům umožňuje spravovat zpětný tlak, správu vláken a zotavení v rámci řetězce Reactor. Na rozdíl od EventProcessorClient, EventHubConsumerAsyncClient nezahrnuje automatické zotavovací mechanismy pro všechny konečné příčiny. Proto musí uživatelé zpracovávat terminálové události a vybírat vhodné operátory Reactor k implementaci strategií obnovení.

Metoda EventHubConsumerAsyncClient::receiveFromPartition vygeneruje chybu terminálu v případě, že dojde k chybě, která se neopakuje, nebo když řada pokusů o obnovení připojení po sobě selže a vyčerpá maximální limit opakování. I když se příjemce nízké úrovně pokusí zotavit z přechodných chyb, očekává se, že uživatelé spotřebitelského klienta zpracovávají koncové události. Pokud je vyžadován nepřetržitý příjem událostí, měla by aplikace upravit řetěz Reactor tak, aby při terminální události vytvořila nového klienta příjemce.

Migrace ze starší verze do nové klientské knihovny

Průvodce migrací zahrnuje kroky migrace ze starší verze klienta a migraci starších kontrolních bodů.

Další kroky

Pokud pokyny pro řešení potíží v tomto článku nepomohly vyřešit problémy při používání klientských knihoven Azure SDK pro Java, doporučujeme nahlásit problém v úložišti Azure SDK pro Java na GitHubu.