Problembehandlung bei Azure Event Hubs-Ereignisprozessor

Dieser Artikel enthält Lösungen für häufig auftretende Probleme, die beim Verwenden des EventProcessorClient Typs auftreten können. Wenn Sie nach Lösungen für andere häufige Probleme suchen, die bei der Verwendung von Azure Event Hubs auftreten können, lesen Sie die Problembehandlung für Azure Event Hubs.

412 Fehler aufgrund nichterfüllter Vorbedingungen bei Verwendung eines Ereignisprozessors

412 Vorbedingungsfehler treten auf, wenn der Client versucht, den Besitz einer Partition zu übernehmen oder zu erneuern, die lokale Version des Besitzerdatensatzes ist jedoch veraltet. Dieses Problem tritt auf, wenn eine andere Prozessorinstanz den Partitionsbesitz übernimmt. Weitere Informationen finden Sie im nächsten Abschnitt.

Die Eigentümerschaft einer Partition ändert sich häufig

Wenn sich die Anzahl der EventProcessorClient Instanzen ändert (also hinzugefügt oder entfernt werden), versuchen die laufenden Instanzen, die Last der Partitionen selbst untereinander auszugleichen. Einige Minuten nachdem sich die Anzahl der Prozessoren geändert hat, wird erwartet, dass die Partitionen ihren Besitzer ändern. Nachdem die Partition ausgeglichen ist, sollte der Besitz der Partition stabil sein und sich nur selten ändern. Wenn sich der Partitionsbesitz häufig ändert, wenn die Anzahl der Prozessoren konstant ist, deutet dies wahrscheinlich auf ein Problem hin. Wir empfehlen Ihnen, einen GitHub-Problembericht mit Protokollen und einem Repro zu erstellen.

Der Besitz einer Partition wird durch die Besitzerdatensätze in der CheckpointStore bestimmt. Das EventProcessorClient führt bei jedem Lastenausgleichsintervall die folgenden Aufgaben aus:

1. Rufen Sie die neuesten Besitzerdatensätze ab.
2. Überprüfen Sie die Datensätze, um festzustellen, welche Datensätze ihren Zeitstempel nicht innerhalb des Ablaufintervalls der Partitionseigentümerschaft aktualisiert haben. Es werden nur Datensätze berücksichtigt, die diesen Kriterien entsprechen.
3. Wenn unzugeordnete Partitionen vorhanden sind und die Last nicht zwischen Instanzen von EventProcessorClient ausgewogen verteilt ist, versucht der Ereignisprozessorclient, eine Partition zu beanspruchen.
4. Aktualisieren Sie den Datensatz für die Partitionen, die einen aktiven Link zu dieser Partition haben.

Sie können die Load-Balancing- und Ownership-Ablaufintervalle konfigurieren, wenn Sie die EventProcessorClient über die EventProcessorClientBuilder erstellen, wie in der folgenden Liste beschrieben:

• Die loadBalancingUpdateInterval(Duration)- Methode gibt an, wie oft der Lastenausgleichszyklus ausgeführt wird.
• Die partitionOwnershipExpirationInterval(Duration) -Methode gibt die mindeste Zeitdauer an, seit der Besitzerdatensatz aktualisiert wurde, bevor der Prozessor eine Partition als nicht freigegeben betrachtet.

Wenn ein Datensatz zum Beispiel um 9:30 Uhr aktualisiert wurde und partitionOwnershipExpirationInterval 2 Minuten beträgt. Wenn ein Load-Balancing-Zyklus auftritt und er feststellt, dass der Datensatz in den letzten 2 Minuten oder bis 9:32 Uhr nicht aktualisiert wurde, betrachtet er die Partition als unbesetzt.

Wenn in einem der Consumer der Partition ein Fehler auftritt, wird der entsprechende Consumer geschlossen, aber erst im nächsten Load-Balancing-Zyklus versucht, die Partition zurückzufordern.

"...aktueller Empfänger '<RECEIVER_NAME>' mit Epoche "0' wird getrennt“

Die gesamte Fehlermeldung sieht ähnlich wie die folgende Ausgabe aus:

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

Dieser Fehler wird erwartet, wenn der Lastenausgleich auftritt, nachdem EventProcessorClient Instanzen hinzugefügt oder entfernt wurden. Lastenausgleich ist ein fortlaufender Prozess. Wenn Sie die BlobCheckpointStore mit Ihrem Consumer verwenden, prüft der Consumer alle ~30 Sekunden (standardmäßig), welche Consumer einen Anspruch auf jede Partition haben und führt dann eine Logik aus, um festzustellen, ob er eine Partition von einem anderen Consumer 'stehlen' muss. Der Dienstmechanismus, der verwendet wird, um den exklusiven Besitz einer Partition geltend zu machen, ist als Epoche bekannt.

Wenn jedoch keine Instanzen hinzugefügt oder entfernt werden, gibt es ein zugrunde liegendes Problem, das behoben werden sollte. Weitere Informationen finden Sie im Abschnitt "Partitionseigentum ändert sich häufig" und "GitHub-Probleme melden".

Hohe CPU-Auslastung

Hohe CPU-Auslastung liegt in der Regel daran, dass eine Instanz zu viele Partitionen besitzt. Wir empfehlen nicht mehr als drei Partitionen für jeden CPU-Kern. Es ist besser, mit 1,5 Partitionen pro CPU-Kern zu beginnen und dann zu testen, indem Sie die Anzahl der einer CPU zugewiesenen Partitionen erhöhen.

Out of Memory und Wahl der Heap-Größe

Das Problem mit nicht genügend Arbeitsspeicher (OOM) kann auftreten, wenn der aktuelle maximale Heap für das JVM nicht ausreicht, um die Anwendung auszuführen. Vielleicht möchten Sie den Heap-Bedarf der Anwendung messen. Legen Sie dann basierend auf dem Ergebnis die Heap-Größe fest, indem Sie die maximale Heap-Speichergröße mit der entsprechenden -Xmx JVM-Option einstellen.

Sie sollten keinen Wert angeben -Xmx , der größer als der für den Host (die VM oder den Container) festgelegte Arbeitsspeicher ist, z. B. der in der Konfiguration des Containers angeforderte Arbeitsspeicher. Sie sollten genügend Arbeitsspeicher für den Host zuweisen, um den Java-Heap zu unterstützen.

Die folgenden Schritte beschreiben eine typische Methode zum Messen des Werts für max. Java Heap:

1. Führen Sie die Anwendung in einer Umgebung in der Nähe der Produktion aus, in der die Anwendung Ereignisse unter der in der Produktion erwarteten Spitzenlast sendet, empfängt und verarbeitet.

2. Warten Sie, bis die Anwendung einen stabilen Zustand erreicht. In diesem Stadium hätte die Anwendung und JVM alle Domänenobjekte, Klassentypen, statische Instanzen, Objektpools (TCP, DB-Verbindungspools) usw. geladen.

   Im stabilen Status sehen Sie das stabile, gezackte Muster für die Heap-Collection, wie im folgenden Screenshot dargestellt:

   

3. Nachdem die Anwendung den stabilen Status erreicht hat, erzwingen Sie eine vollständige Garbage Collection (GC) mit Tools wie JConsole. Beobachten Sie den belegten Speicher nach der vollständigen GC. Sie wollen den Heap so dimensionieren, dass nach der vollständigen GC nur noch 30 % belegt sind. Mit diesem Wert können Sie die maximale Heapgröße (mit -Xmx) festlegen.

Wenn Sie sich im Container befinden, vergrößern Sie den Container so, dass er für den Nicht-Heap-Bedarf für die JVM-Instanz einen zusätzlichen ~ 1 GB Arbeitsspeicher benötigt.

Processor Client empfängt nicht mehr

Der Prozessorclient wird häufig ununterbrochen über mehrere Tage hinweg in einer Hostanwendung ausgeführt. Manchmal bemerkt man, dass EventProcessorClient eine oder mehrere Partitionen nicht verarbeitet. In der Regel gibt es nicht genügend Informationen, um zu bestimmen, warum die Ausnahme aufgetreten ist. Das EventProcessorClient Anhalten ist das Symptom einer zugrundeliegenden Ursache (d.h. der Race Condition), die bei dem Versuch auftrat, sich von einem vorübergehenden Fehler zu erholen. Informationen, die wir benötigen, finden Sie unter GitHub-Probleme bei der Einreichung.

Doppelte Ereignisdaten, die empfangen werden, wenn der Prozessor neu gestartet wird

Der Dienst EventProcessorClient und Event Hubs garantiert eine mindestens einmalige Zustellung. Sie können Metadaten hinzufügen, um doppelte Ereignisse zu erkennen. Weitere Informationen finden Sie im Abschnitt Garanteriert Azure Event Hubs eine mindestens einmalige Zustellung? auf Stack Overflow. Wenn Sie eine einmalige Lieferung benötigen, sollten Sie den Service Bus in Betracht ziehen, der auf eine Empfangsbestätigung des Kunden wartet. Einen Vergleich der Messagingdienste finden Sie unter Auswählen zwischen Azure-Messagingdiensten.

Der Verbraucherclient auf niedriger Ebene beendet den Empfang

EventHubConsumerAsyncClient ist ein Low-Level-Consumer-Client, der von der Event Hubs-Bibliothek bereitgestellt wird und für fortgeschrittene Nutzer entwickelt wurde, die größere Kontrolle und Flexibilität in ihren reaktiven Anwendungen wünschen. Dieser Client bietet eine Low-Level-Schnittstelle, mit der Benutzer Backpressure, Threading und Wiederherstellung innerhalb der Reaktorkette verwalten können. Im Gegensatz zu EventProcessorClient enthält EventHubConsumerAsyncClient keine automatischen Wiederherstellungsmechanismen für alle terminalen Ursachen. Daher müssen die Benutzer Terminalereignisse behandeln und geeignete Reaktorbetreiber auswählen, um Wiederherstellungsstrategien zu implementieren.

Die EventHubConsumerAsyncClient::receiveFromPartition Methode gibt einen endgültigen Fehler aus, wenn bei der Verbindung ein nicht wiederholbarer Fehler auftritt oder wenn aufeinander folgende Versuche zur Wiederherstellung der Verbindung fehlschlagen und die maximale Wiederholungsgrenze ausgeschöpft ist. Obwohl der Low-Level-Empfänger versucht, sich von vorübergehenden Fehlern zu erholen, wird von den Benutzern des Consumer-Clients erwartet, dass sie Terminal-Ereignisse behandeln. Wenn ein kontinuierlicher Empfang von Ereignissen gewünscht ist, sollte die Anwendung die Reactor-Kette so anpassen, dass bei einem Terminal-Ereignis ein neuer Consumer Client erstellt wird.

Migrieren von Legacy zu neuer Clientbibliothek

Der Migrationsleitfaden enthält Schritte für die Migration vom Legacy-Client und die Übertragung von Legacy-Checkpoints.

Nächste Schritte

Wenn die Richtlinien zur Fehlerbehebung in diesem Artikel nicht helfen, Probleme bei der Verwendung der Azure SDK for Java Client-Bibliotheken zu lösen, empfehlen wir Ihnen, einen Fehler im Azure SDK for Java GitHub Repository zu melden.