Felsöka eventprocessor för Azure Event Hubs

Den här artikeln hjälper dig att felsöka problem med Azure Event Hubs händelseprocessor när du använder EventProcessorClient typen . Använd den för att lösa vanliga problem med ägarskap, PROCESSOR, minne och mottagare. Lösningar på andra vanliga problem som kan uppstå när du använder Azure Event Hubs finns i Felsöka Azure Event Hubs.

412 förhandsvillkorsfel när du använder en händelseprocessor

412 förhandsvillkorsfel uppstår när klienten försöker ta eller förnya ägarskapet för en partition, men den lokala versionen av ägarskapsposten är inaktuell. Det här problemet uppstår när en annan processorinstans stjäl partitionsägarskapet. Mer information finns i nästa avsnitt.

Ägarskap för partitioner ändras ofta

När antalet EventProcessorClient-instanser ändras (det vill säga när du lägger till eller tar bort instanser) försöker de instanser som kör att belastningsutjämna partitionerna mellan sig. Under några minuter efter att antalet processorer har ändrats ändrar partitionerna ägare. När den har balanserats är partitionsägarskapet stabilt och ändras sällan. Om partitionsägarskapet ändras ofta när antalet processorer är konstant indikerar det sannolikt ett problem. Skicka in ett GitHub-ärende med loggar och ett reproducerbart exempel.

CheckpointStore fastställer ägarskapet för partitioner genom ägarposter. Vid varje lastbalanseringsintervall utför EventProcessorClient följande uppgifter:

  1. Hämta de senaste ägardokumenten.
  2. Kontrollera posterna för att se vilka poster som inte uppdaterade tidsstämpeln inom förfallointervallet för partitionsägarskapet. Endast poster som matchar detta villkor beaktas.
  3. Om det finns några icke-ägda partitioner och belastningen inte balanseras mellan instanser av EventProcessorClientförsöker händelseprocessorklienten göra anspråk på en partition.
  4. Uppdatera ägarskapsposten för de partitioner som den äger och som har en aktiv länk till partitionen.

Du kan konfigurera intervaller för belastningsutjämning och förfallotider för ägarskap när du skapar EventProcessorClient via EventProcessorClientBuilder, enligt beskrivningen i följande lista:

Om en ägarskapspost till exempel uppdaterades kl. 09:30 och partitionOwnershipExpirationInterval är 2 minuter. När en lastbalanseringscykel inträffar och den upptäcker att ägarposten inte har uppdaterats under de senaste två minuterna eller senast kl. 09:32, betraktas partitionen som utan ägare.

Om ett fel uppstår i någon av partitionskonsumenterna stänger den motsvarande konsumenten, men försöker inte återta den förrän vid nästa cykel för belastningsutjämning.

Den aktuella mottagaren "<RECEIVER_NAME>" med epok "0" kopplas från.

Hela felmeddelandet ser ut ungefär så här:

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:&lt;GUID&gt;, SystemTracker:&lt;NAMESPACE&gt;:eventhub:&lt;EVENT_HUB_NAME&gt;|&lt;CONSUMER_GROUP&gt;,
Timestamp:2022-01-01T12:00:00}"}

Det här felet uppstår när belastningsutjämning inträffar när du lägger till eller tar bort EventProcessorClient instanser. Belastningsutjämning är en pågående process. När du använder BlobCheckpointStore med din konsument kontrollerar konsumenten var ~30:e sekund (som standard) vilka konsumenter som har ett anspråk för varje partition. Sedan körs viss logik för att avgöra om den behöver "stjäla" en partition från en annan konsument. Den servicemekanism som används för att hävda exklusivt ägande över en partition kallas Epoch.

Men om du inte lägger till eller tar bort instanser finns det ett underliggande problem som du bör åtgärda. Mer information finns i avsnittet Ändringar av partitionsägarskap sker ofta och Rapportera GitHub-problem.

Hög processoranvändning

Hög CPU-användning sker vanligtvis eftersom en instans äger för många partitioner. Överskrid inte tre partitioner för varje CPU-kärna. Börja med 1,5 partitioner för varje CPU-kärna och testa sedan genom att öka antalet partitioner som ägs.

Slut på minne och välja heapstorlek

Problemet med slut på minne (OOM) kan inträffa om den aktuella maxhögen för JVM inte är tillräcklig för att köra programmet. Du kanske vill mäta programmets heapkrav. Baserat på resultatet ändrar du sedan storleken på heapen genom att ange lämpligt maximalt heapminne med hjälp av -Xmx JVM-alternativet.

Ange inte -Xmx till ett värde som är större än det tillgängliga minnet eller den gräns som angetts för värddatorn (den virtuella datorn eller containern) – till exempel det minne som begärs i containerns konfiguration. Allokera tillräckligt med minne för värden så att den kan hantera Java-heapen.

Följande steg beskriver ett typiskt sätt att mäta värdet för maximal Java Heap:

  1. Kör programmet i en miljö nära produktion, där programmet skickar, tar emot och bearbetar händelser under den högsta belastning som förväntas i produktionen.

  2. Vänta tills programmet når ett stabilt tillstånd. I det här skedet läser programmet och JVM in alla domänobjekt, klasstyper, statiska instanser, objektpooler (TCP, DB-anslutningspooler) och så vidare.

    I det stadiga tillståndet ser du det stabila sågtandsformade mönstret för heap-samlingen, som visas i följande skärmbild.

    Skärmbild av heapminnessamlingen som visar det stabila sågtandsmönstret.

  3. När applikationen har nått ett stabilt tillstånd tvingar du fram en fullständig garbage collection (GC) med hjälp av verktyg som JConsole. Observera det minne som upptas efter den fullständiga GC:en. Du vill anpassa högen så att endast 30% är upptagna efter fullständig GC. Använd det här värdet för att ange maximal heapstorlek (genom att använda -Xmx).

Om du kör i en container ska du dimensionera containern så att den har ytterligare cirka 1 GB minne för JVM-instansens behov av minne utanför heapen.

Processorklienten upphör att ta emot

Processorklienten körs ofta kontinuerligt i ett värdprogram i flera dagar i sträck. Ibland märker den att EventProcessorClient inte bearbetar en eller flera partitioner. Vanligtvis finns det inte tillräckligt med information för att avgöra varför undantaget inträffade. Stoppet EventProcessorClient är symptomet på en underliggande orsak (dvs. kapplöpningstillståndet) som inträffade när man försökte återhämta sig från ett tillfälligt fel. Den informationen vi behöver finns i Rapportera GitHub-ärenden.

Duplicera EventData som tas emot när processorn startas om

Event EventProcessorClient Hubs-tjänsten och garanterar en leverans minst en gång . Du kan lägga till metadata för att urskilja duplicerade händelser. Mer information finns i Garanterar Azure Event Hubs en leverans minst en gång? på Stack Overflow. Om du bara behöver leverans en gång bör du överväga Service Bus, som väntar på en bekräftelse från klienten. En jämförelse av meddelandetjänsterna finns i Välja mellan Azure-meddelandetjänster.

Konsumentklient på låg nivå slutar ta emot

Event Hubs-biblioteket tillhandahåller EventHubConsumerAsyncClient som en konsumentklient på låg nivå. Den är utformad för avancerade användare som behöver större kontroll och flexibilitet i sina reaktiva program. Den här klienten erbjuder ett lågnivågränssnitt, så att du kan hantera ryggtryck, trådning och återställning i reaktorkedjan. Till skillnad från EventProcessorClientinnehåller EventHubConsumerAsyncClient inte automatiska återställningsmekanismer för alla terminalorsaker. Därför måste du hantera terminalhändelser och välja lämpliga reaktoroperatorer för att implementera återställningsstrategier.

Metoden EventHubConsumerAsyncClient::receiveFromPartition genererar ett terminalfel när anslutningen stöter på ett fel som inte kan försökas igen eller när en serie anslutningsåterställningsförsök misslyckas i följd, vilket uttömmer den maximala återförsöksgränsen. Även om mottagaren på låg nivå försöker återställa från tillfälliga fel förväntas användare av konsumentklienten hantera terminalhändelser. Om kontinuerlig händelsemottagning önskas bör programmet justera reaktorkedjan för att skapa en ny konsumentklient för en terminalhändelse.

Migrera från äldre till nytt klientbibliotek

Migreringsguiden innehåller steg för att migrera från den äldre klienten och migrera äldre kontrollpunkter.

Nästa steg

Om felsökningsguiden i den här artikeln inte hjälper dig att lösa problem när du använder Azure SDKs för Java klientbibliotek kan du ange ett problem i Azure SDKs för Java GitHub lagringsplats.

  • Last updated on