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

Tento článek vám pomůže vyřešit problémy s procesorem událostí Azure Event Hubs při použití EventProcessorClient typu. Slouží k řešení běžných problémů s vlastnictvím, procesorem, pamětí a přijímačem. Řešení jiných běžných problémů, se kterými se můžete setkat při používání Azure Event Hubs, najdete v tématu Řešení potíží 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í (tj. když přidáte nebo odeberete instance), spuštěné instance se pokusí mezi sebou vyrovnávat zatížení oddílů. Několik minut poté, co se změní počet procesorů, oddíly změní vlastníka. Po vyvážení je vlastnictví oddílu stabilní a mění se zřídka. Pokud se vlastnictví oddílu často mění, i když počet procesorů zůstává stejný, pravděpodobně to signalizuje problém. Založte na GitHubu issue s logy a kroky k reprodukci problému.

Určuje CheckpointStore vlastnictví oddílu prostřednictvím záznamů vlastnictví. Při každém intervalu vyrovnávání zatížení EventProcessorClient provádí následující úkony:

1. Načtěte nejnovější záznamy vlastnictví.
2. Zkontrolujte záznamy, abyste zjistili, které záznamy neaktualizovaly své č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 byl například záznam o vlastnictví aktualizován v 9:30 a partitionOwnershipExpirationInterval jsou 2 minuty. Když dojde k cyklu vyvažování zatížení a zjistí se, že záznam o vlastnictví nebyl za poslední 2 minuty aktualizován, tedy do 9:32, považuje se oddíl za bez vlastníka.

Pokud v některém z příjemců oddílů dojde k chybě, uzavře odpovídajícího příjemce, ale nepokusí se ho znovu převzít, dokud nenastane další cyklus 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}"}

K této chybě dochází v případě, že vyrovnávání zatížení proběhne po přidání nebo odebrání EventProcessorClient instancí. Vyrovnávání zatížení je probíhající proces. Když s příjemcem použijete BlobCheckpointStore, příjemce každých přibližně 30 sekund (ve výchozím nastavení) kontroluje, kteří příjemci mají nárok na jednotlivé oddíly. Potom provede logiku, která určí, zda potřebuje „převzít“ partici od jiného konzumenta. Služební mechanismus používaný k uplatnění výhradního vlastnictví nad oddílem se nazývá Epocha.

Pokud však instance nepřidáváte ani neodebíráte, existuje skrytý problém, který byste měli řešit. Další informace najdete v oddílu Změny vlastnictví oddílu a oznamování problémů na GitHubu.

Vysoké využití procesoru

K vysokému zatížení CPU obvykle dochází, protože instance má přiřazeno příliš mnoho partition. Nepřekračujte tři oddíly pro každé jádro procesoru. Začněte s 1,5 partice na každé jádro procesoru a poté testujte postupným zvyšováním počtu přiřazených particí.

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 nároky aplikace na haldu. 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.

Nezadávejte -Xmx jako hodnotu větší než dostupná paměť nebo limit nastavený pro hostitele (virtuální počítač nebo kontejner), například paměť požadovanou v konfiguraci kontejneru. Přidělte hostiteli dostatek paměti pro podporu haldy Java.

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 aplikace a JVM načítají všechny doménové objekty, 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 ustáleného stavu, vynuťte úplné spuštění garbage collectoru (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%. Pomocí této hodnoty nastavíte maximální velikost haldy (pomocí -Xmx).

Pokud aplikaci provozujete v kontejneru, nastavte velikost kontejneru tak, aby měl o přibližně 1 GB paměti navíc pro neheapové potřeby 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í, zvažte 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

Knihovna Event Hubs poskytuje EventHubConsumerAsyncClient jako klienta příjemce nízké úrovně. Je určená pro pokročilé uživatele, kteří potřebují větší kontrolu a flexibilitu nad jejich reaktivními aplikacemi. Tento klient nabízí nízkoúrovňové rozhraní, takže můžete v řetězci Reactor spravovat řízení zpětného tlaku, vlákna a zotavení. Na rozdíl od EventProcessorClient, EventHubConsumerAsyncClient nezahrnuje automatické zotavovací mechanismy pro všechny konečné příčiny. Proto musíte zpracovat terminálové události a vybrat vhodné operátory Reactor pro 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 k řešení potíží v tomto článku nepomohly vyřešit problémy při použití Azure SDK pro Java klientské knihovny, založte problém v Azure SDK pro úložiště Java GitHub.