Problemen met azure Event Hubs-gebeurtenisprocessor oplossen

Dit artikel helpt u bij het oplossen van problemen met Azure Event Hubs gebeurtenisprocessor wanneer u het EventProcessorClient type gebruikt. Gebruik dit om veelvoorkomende problemen met eigendom, CPU, geheugen en ontvanger op te lossen. Zie Problemen met Azure Event Hubs oplossen voor oplossingen voor andere veelvoorkomende problemen die u kunt tegenkomen bij het gebruik van Azure Event Hubs.

412 voorwaardefouten wanneer u een gebeurtenisprocessor gebruikt

412 voorwaardefouten treden op wanneer de client probeert het eigendom van een partitie te nemen of te vernieuwen, maar de lokale versie van de eigendomsrecord is verouderd. Dit probleem treedt op wanneer een andere processorinstantie het eigendom van partities overneemt. Zie de volgende sectie voor meer informatie.

Het eigendom van partities verandert vaak

Wanneer het aantal EventProcessorClient exemplaren verandert (dat wil gezegd, wanneer u exemplaren toevoegt of verwijdert), proberen de actieve exemplaren partities tussen zichzelf te verdelen. Enkele minuten nadat het aantal processors is gewijzigd, worden de eigenaren van partities gewijzigd. Zodra de partitie in balans is, is het eigenaarschap van de partitie stabiel en verandert het zelden. Als het eigendom van partities vaak verandert wanneer het aantal processors constant is, duidt dit waarschijnlijk op een probleem. Dien een GitHub probleem met logboeken en een repro in.

Het CheckpointStore bepaalt het eigenaarschap van de partitie aan de hand van eigendomsrecords. Tijdens elk taakverdelingsinterval voert de EventProcessorClient de volgende taken uit:

1. Haal de meest recente eigendomsgegevens op.
2. Controleer de records om te zien welke records hun tijdstempel niet hebben bijgewerkt binnen het vervalinterval voor het eigendom van partities. Alleen records die aan deze criteria voldoen, worden overwogen.
3. Als er niet-beheerde partities zijn en de belasting niet wordt verdeeld tussen exemplaren van EventProcessorClient, probeert de gebeurtenisprocessorclient een partitie te claimen.
4. Werk de eigendomsrecord bij voor de partities die eigenaar zijn van een actieve koppeling naar die partitie.

U kunt de verloopintervallen voor taakverdeling en eigendom configureren wanneer u de EventProcessorClient taakverdeling maakt via de EventProcessorClientBuilder, zoals beschreven in de volgende lijst:

• De methode loadBalancingUpdateInterval(Duration) geeft aan hoe vaak de taakverdelingscyclus wordt uitgevoerd.
• De methode partitionOwnershipExpirationInterval(Duration) geeft de minimale tijdsduur aan sinds het eigendomsrecord is bijgewerkt, voordat de processor een partitie als niet meer in eigendom beschouwt.

Als een eigendomsrecord bijvoorbeeld om 9:30 uur is bijgewerkt en partitionOwnershipExpirationInterval 2 minuten is. Wanneer er een load-balancingcyclus plaatsvindt en wordt vastgesteld dat de eigendomsregistratie in de afgelopen 2 minuten niet is bijgewerkt of uiterlijk om 9:32 uur nog niet is bijgewerkt, beschouwt het systeem de partitie als niet in eigendom.

Als er een fout optreedt in een van de partitiegebruikers, sluit deze de bijbehorende consument, maar probeert deze pas vrij te maken tijdens de volgende taakverdelingscyclus.

"...de huidige ontvanger '<RECEIVER_NAME>' met epoch '0' wordt momenteel verbroken"

Het volledige foutbericht ziet er ongeveer als volgt uit:

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

Deze fout treedt op wanneer taakverdeling plaatsvindt nadat u EventProcessorClient exemplaren hebt toegevoegd of verwijderd. Taakverdeling is een doorlopend proces. Wanneer u de BlobCheckpointStore met uw consument gebruikt, controleert de consument elke ~30 seconden (standaard) welke consumenten een claim voor elke partitie hebben. Vervolgens wordt er enige logica uitgevoerd om te bepalen of het nodig is om een partitie van een andere consumer te 'stelen'. Het servicemechanisme dat wordt gebruikt om exclusief eigendom van een partitie te bevestigen, wordt het Epoch genoemd.

Als u echter geen exemplaren toevoegt of verwijdert, bestaat er een onderliggend probleem dat u moet oplossen. Zie voor meer informatie de sectie Partition ownership changes frequently en Filing GitHub issues.

Hoog CPU-gebruik

Hoog CPU-gebruik treedt meestal op omdat een exemplaar eigenaar is van te veel partities. Overschrijd niet meer dan drie partities voor elke CPU-kern. Begin met 1,5 partities voor elke CPU-kern en test vervolgens door het aantal partities in eigendom te verhogen.

Onvoldoende geheugen en kiezen voor de heapgrootte

Het probleem met onvoldoende geheugen (OOM) kan optreden als de huidige maximale heap voor de JVM onvoldoende is om de toepassing uit te voeren. U kunt overwegen de benodigde heapgrootte van de toepassing te meten. Pas vervolgens op basis van het resultaat de heap aan door het juiste maximale heap-geheugen in te stellen met behulp van de -Xmx JVM-optie.

Geef niet -Xmx op als een waarde die groter is dan het beschikbare geheugen of de limiet die is ingesteld voor de host (de VM of container), bijvoorbeeld het geheugen dat is aangevraagd in de configuratie van de container. Wijs voldoende geheugen toe voor de host om de Java heap te ondersteunen.

In de volgende stappen wordt een typische manier beschreven om de waarde voor maximale Java Heap te meten:

1. Voer de toepassing uit in een omgeving dicht bij de productie, waarbij de toepassing gebeurtenissen verzendt, ontvangt en verwerkt onder de piekbelasting die in productie wordt verwacht.

2. Wacht totdat de toepassing een stabiele status heeft bereikt. In deze fase laden de toepassing en JVM alle domeinobjecten, klassetypen, statische exemplaren, objectgroepen (TCP, DB-verbindingsgroepen), enzovoort.

   Onder de stabiele toestand ziet u het stabiele zaagtandvormige patroon voor de heapverzameling, zoals wordt weergegeven in de volgende schermopname:

   

3. Nadat de toepassing de stabiele status heeft bereikt, dwingt u een volledige garbagecollection (GC) af met behulp van hulpprogramma's zoals JConsole. Observeer de hoeveelheid geheugen bezet na de volledige GC. U wilt de heap zo groot maken dat slechts 30% na de volledige GC bezet is. Gebruik deze waarde om de maximale heapgrootte in te stellen (met behulp van -Xmx).

Als u een container gebruikt, moet u de container zo dimensioneren dat deze ongeveer 1 GB extra geheugen heeft voor de niet-heap-geheugenbehoefte van de JVM-instantie.

Processorclient stopt met ontvangen

De processorclient wordt vaak voortdurend uitgevoerd in een hosttoepassing gedurende dagen aan het einde. Soms merkt het op dat EventProcessorClient een of meer partities niet verwerkt. Meestal is er onvoldoende informatie om te bepalen waarom de uitzondering heeft plaatsgevonden. Het EventProcessorClient stoppen is het symptoom van een onderliggende oorzaak (dat wil gezegd de racevoorwaarde) die is opgetreden tijdens het herstellen van een tijdelijke fout. Zie GitHub-problemen archiveren voor de informatie die we nodig hebben.

Dubbele EventData ontvangen wanneer de processor opnieuw wordt opgestart

De EventProcessorClient Service en Event Hubs garanderen een minstens één keer levering. U kunt metagegevens toevoegen om dubbele gebeurtenissen te onderscheiden. Zie Voor meer informatie biedt Azure Event Hubs een garantie voor ten minste één levering? op Stack Overflow. Als u slechts eenmaal levering nodig hebt, kunt u overwegen Service Bus, die wacht op een bevestiging van de client. Zie Kiezen tussen Azure-berichtenservices voor een vergelijking van de berichtenservices.

Consumentenclient op laag niveau ontvangt niet meer

De Event Hubs-bibliotheek biedt de EventHubConsumerAsyncClient als een low-level client voor consumenten. Het is ontworpen voor geavanceerde gebruikers die meer controle en flexibiliteit nodig hebben over hun reactieve toepassingen. Deze client biedt een interface op laag niveau, zodat u backpressie, threading en herstel binnen de Reactor-keten kunt beheren. In tegenstelling tot EventProcessorClient, EventHubConsumerAsyncClient bevat geen automatische herstelmechanismen voor alle terminaloorzaken. Daarom moet u terminale gebeurtenissen afhandelen en de juiste Reactor-operators selecteren om herstelstrategieën te implementeren.

De EventHubConsumerAsyncClient::receiveFromPartition methode verzendt een terminalfout wanneer de verbinding een niet-ophaalbare fout tegenkomt of wanneer een reeks verbindingsherstelpogingen opeenvolgend mislukt, waardoor de maximale limiet voor opnieuw proberen wordt uitgeput. Hoewel de ontvanger op laag niveau probeert te herstellen van tijdelijke fouten, zullen gebruikers van de consumentenclient naar verwachting terminalgebeurtenissen verwerken. Als continue ontvangst van events gewenst is, moet de toepassing de Reactor-keten aanpassen om een nieuwe consumentclient te maken bij een terminal event.

Migreren van verouderde naar nieuwe clientbibliotheek

De migratiehandleiding bevat stappen voor het migreren van de verouderde client en het migreren van verouderde controlepunten.

Volgende stappen

Als de richtlijnen voor probleemoplossing in dit artikel niet helpen bij het oplossen van problemen wanneer u de Azure SDK voor Java clientbibliotheken gebruikt, moet u een probleem indienen in de Azure SDK voor Java GitHub opslagplaats.