Behandeln von Konnektivitätsproblemen: Azure Event Hubs

Es gibt verschiedene Gründe dafür, dass Clientanwendungen keine Verbindung mit einem Event Hub herstellen können. Die Verbindungsprobleme können dauerhaft oder vorübergehend sein.

Wenn das Problem ständig (permanent) auftritt, überprüfen Sie diese Einstellungen und andere Optionen, die im Abschnitt Behandeln dauerhafter Konnektivitätsprobleme in diesem Artikel erwähnt werden.

• Verbindungszeichenfolge
• Firewalleinstellungen Ihrer Organisation
• IP-Firewalleinstellungen
• Netzwerksicherheitseinstellungen (Dienstendpunkte, private Endpunkte usw.)

Probieren Sie für vorübergehende Probleme die folgenden Optionen aus, die Ihnen bei der Problembehandlung helfen können. Weitere Informationen finden Sie unter Beheben zeitweiliger Konnektivitätsprobleme.

• Upgrade auf die neueste Version des SDK
• Ausführen von Befehlen zum Überprüfen übersprungener Pakete
• Rufen Sie Netzwerkablaufverfolgungen ab.

Behandeln dauerhafter Konnektivitätsprobleme

Wenn die Anwendung überhaupt keine Verbindung mit Event Hub herstellen kann, führen Sie die in diesem Abschnitt aufgeführten Schritte aus, um das Problem zu beheben.

Überprüfen, ob ein Dienstausfall vorliegt

Überprüfen Sie auf der Azure-Dienststatuswebsite, ob ein Azure Event Hubs-Dienstausfall vorliegt.

Überprüfen der Verbindungszeichenfolge

Vergewissern Sie sich, dass die verwendete Verbindungszeichenfolge richtig ist. Weitere Informationen zum Abrufen der Verbindungszeichenfolge mit dem Azure-Portal, der CLI oder PowerShell finden Sie unter Abrufen der Verbindungszeichenfolge.

Vergewissern Sie sich bei Kafka-Clients, dass die Dateien „producer.config“ oder „consumer.config“ ordnungsgemäß konfiguriert sind. Weitere Informationen finden Sie unter Senden und Empfangen von Nachrichten mit Kafka in Event Hubs.

Welche Protokolle kann ich zum Senden und Empfangen von Ereignissen verwenden?

Producer oder Absender können die Protokolle AMQP (Advanced Message Queueing Protocol), Kafka oder HTTPS verwenden, um Ereignisse an einen Event Hub zu senden.

Consumer oder Empfänger verwenden AMQP oder Kafka, um Ereignisse von einem Event Hub zu empfangen. Event Hubs unterstützt nur das Pullmodell für Consumer für den Empfang von Ereignisse. Selbst wenn Sie Ereignishandler zum Behandeln von Ereignissen von einem Event Hub verwenden, verwendet der Ereignisprozessor intern das Pullmodell, um Ereignisse vom Event Hub zu empfangen.

AMQP

Sie können das AMQP 1.0-Protokoll für das Senden und Empfangen von Ereignissen an und von Azure Event Hubs verwenden. AMQP ermöglicht eine zuverlässige, leistungsfähige und sichere Kommunikation für das Senden und Empfangen von Ereignissen. Sie können es für ein leistungsstarkes Echtzeitstreaming verwenden, und es wird von den meisten Azure Event Hubs-SDKs unterstützt.

HTTPS-/REST-API

Sie können Ereignisse nur mithilfe von HTTP POST-Anforderungen an Event Hubs senden. Event Hubs unterstützt nicht das Empfangen von Ereignissen über HTTPS. Es eignet sich für einfache Clients, bei denen eine direkte TCP-Verbindung nicht sinnvoll ist.

Apache Kafka

Azure Event Hubs verfügt über einen integrierten Kafka-Endpunkt, der Kafka-Producer und -Consumer unterstützt. Anwendungen, die mit Kafka erstellt wurden, können das Kafka-Protokoll (ab Version 1.0) ohne Codeänderungen für das Senden und Empfangen von Ereignissen an und von Event Hubs verwenden.

Azure SDKs abstrahieren die zugrunde liegenden Kommunikationsprotokolle und bieten eine vereinfachte Möglichkeit zum Senden und Empfangen von Ereignissen an und von Event Hubs mit Programmiersprachen wie C#, Java, Python, JavaScript usw.

Welche Ports muss ich in der Firewall öffnen?

Sie können die folgenden Protokolle mit Azure Event Hubs verwenden, um Ereignisse zu senden und zu empfangen:

• Advanced Message Queuing Protocol 1.0 (AMQP)
• Hypertext Transfer Protocol 1.1 mit Transport Layer Security (HTTPS)
• Apache Kafka

In der folgenden Tabelle finden Sie die ausgehenden Ports, die Sie öffnen müssen, um diese Protokolle für die Kommunikation mit Azure Event Hubs verwenden zu können.

Protocol	Ports	Details
AMQP	5671 und 5672	Weitere Informationen finden Sie im AMQP 1.0 in Azure Service Bus und Event Hubs – Protokollleitfaden.
HTTPS	443	Dieser Port wird für die HTTP/REST-API und für AMQP-over-WebSockets verwendet.
Kafka	9093	Weitere Informationen finden Sie unter Verwenden von Azure Event Hubs aus Apache Kafka-Anwendungen.

Der HTTPS-Port ist für die ausgehende Kommunikation auch dann erforderlich, wenn AMQP über Port 5671 verwendet wird, da mehrere Verwaltungsvorgänge, die von den Client-SDKs ausgeführt werden, und der Abruf von Token aus Microsoft Entra ID (falls verwendet) über HTTPS erfolgen.

Die offiziellen Azure-SDKs verwenden im Allgemeinen das AMQP-Protokoll zum Senden von Ereignissen an und Empfangen von Ereignissen von Event Hubs. Die Option AMQP-over-WebSockets-Protokoll wird über TCP-Port 443 wie die HTTP-API ausgeführt, ist aber ansonsten funktionell identisch mit einfachem AMQP. Diese Option weist eine höhere anfängliche Verbindungslatenz auf, weil zusätzliche Handshakeroundtrips ausgeführt werden und der Mehraufwand geringfügig höher ist. Dies ist ein Kompromiss, der aufgrund der gemeinsamen Verwendung des HTTPS-Ports eingegangen werden muss. Wenn dieser Modus ausgewählt ist, ist TCP-Port 443 für die Kommunikation ausreichend. Mit den folgenden Optionen können Sie den einfachen AMQP- oder den AMQP-WebSockets-Modus auswählen:

Sprache	Option
.NET	Eigenschaft EventHubConnectionOptions.TransportType mit EventHubsTransportType.AmqpTcp oder EventHubsTransportType.AmqpWebSockets
Java	com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype mit AmqpTransportType.AMQP oder AmqpTransportType.AMQP_WEB_SOCKETS
Knoten	EventHubConsumerClientOptions verfügt über eine webSocketOptions-Eigenschaft.
Python	EventHubConsumerClient.transport_type mit TransportType.Amqp oder TransportType.AmqpOverWebSocket

Welche IP-Adressen muss ich zulassen?

Wenn Sie mit Azure arbeiten, müssen Sie manchmal bestimmten IP-Adressbereichen oder URLs in Ihrer Unternehmensfirewall oder Ihrem Proxy erlauben, auf alle Azure-Dienste zuzugreifen, die Sie verwenden oder zu verwenden versuchen. Überprüfen Sie, ob der Datenverkehr für die von Event Hubs verwendeten IP-Adressen zulässig ist. Weitere Informationen zu den von Azure Event Hubs verwendeten IP-Adressen finden Sie unter Azure-IP-Bereiche und Diensttags – öffentliche Cloud.

Vergewissern Sie sich außerdem, dass die IP-Adresse für Ihren Namespace zulässig ist. Um die richtigen IP-Adressen zu ermitteln, die für Ihre Verbindungen zulässig sind, führen Sie die folgenden Schritte aus:

1. Führen Sie den folgenden Befehl an einer Eingabeaufforderung aus:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Notieren Sie sich die IP-Adresse, die in Non-authoritative answer zurückgegeben werden.

Wenn Sie einen Namespace verwenden, der in einem älteren Cluster gehostet wird (basierend auf Cloud Services; der CNAME endet auf *.cloudapp.net), und der Namespace zonenredundant ist, müssen Sie einige zusätzliche Schritte ausführen. Wenn sich Ihr Namespace in einem neueren Cluster (basierend auf VM-Skalierungsgruppen; der CNAME endet auf *.cloudapp.azure.com) mit Zonenredundanz befindet, können Sie die folgenden Schritte überspringen.

1. Führen Sie zunächst nslookup für den Namespace aus.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Notieren Sie sich den Namen im Abschnitt non-authoritative answer (nicht autorisierende Antwort), der in einem der folgenden Formate vorliegt:

   <name>-s1.cloudapp.net
   <name>-s2.cloudapp.net
   <name>-s3.cloudapp.net
   

3. Führen Sie den Befehl „nslookup“ für jeden Namen mit den Suffixen s1, s2 und s3 aus, um die IP-Adressen aller drei Instanzen zu erhalten, die in drei Verfügbarkeitszonen ausgeführt werden.

   Hinweis

   Die vom nslookup-Befehl zurückgegebene IP-Adresse ist keine statische IP-Adresse. Allerdings bleibt sie gleich, bis die zugrunde liegende Bereitstellung gelöscht oder in einen anderen Cluster verschoben wird.

Welche Client-IP-Adressen senden Ereignisse an meinen Namespace oder empfangen Ereignisse daraus?

Aktivieren Sie zunächst die IP-Filterung für den Namespace.

Aktivieren Sie dann Diagnoseprotokolle für Event Hubs-Verbindungsereignisse für virtuelle Netzwerke, indem Sie den Anweisungen unter Aktivieren von Diagnoseprotokollen folgen. Es wird die IP-Adresse angezeigt, für die die Verbindung verweigert wird.

{
    "SubscriptionId": "0000000-0000-0000-0000-000000000000",
    "NamespaceName": "namespace-name",
    "IPAddress": "1.2.3.4",
    "Action": "Deny Connection",
    "Reason": "IPAddress doesn't belong to a subnet with Service Endpoint enabled.",
    "Count": "65",
    "ResourceId": "/subscriptions/0000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.eventhub/namespaces/namespace-name",
    "Category": "EventHubVNetConnectionEvent"
}

Wichtig

Protokolle virtueller Netzwerke werden nur dann generiert, wenn der Namespace Zugriff über spezifische IP-Adressen (IP-Filterregeln) erlaubt. Wenn Sie den Zugriff auf Ihren Namespace mit diesen Features nicht einschränken und dennoch Protokolle virtueller Netzwerke erhalten möchten, um IP-Adressen von Clients nachzuverfolgen, die sich mit dem Namespace der Event Hubs verbinden, können Sie die folgende Umgehungslösung verwenden: Aktivieren Sie IP-Filterung, und fügen Sie den gesamten adressierbaren IPv4-Bereich (0.0.0.0/1 - 128.0.0.0/1) und den IPv6 Bereich (::/1 - 8000::/1) hinzu.

Hinweis

Derzeit ist es nicht möglich, die IP-Quelladresse einer einzelnen Nachricht oder eines einzelnen Ereignisses zu bestimmen.

Sicherstellen, dass das Event Hubs-Diensttag in Ihren Netzwerksicherheitsgruppen zulässig ist

Wenn Ihre Anwendung in einem Subnetz ausgeführt wird und eine zugeordnete Netzwerksicherheitsgruppe vorhanden ist, stellen Sie sicher, dass ausgehender Internetdatenverkehr oder das Event Hubs-Diensttag (EventHub) zulässig ist. Lesen Sie Diensttags des virtuellen Netzwerks, und suchen Sie nach EventHub.

Überprüfen, ob die Anwendung in einem bestimmten Subnetz eines virtuellen Netzwerks ausgeführt werden muss

Vergewissern Sie sich, dass Ihre Anwendung in einem Subnetz des virtuellen Netzwerks ausgeführt wird, das Zugriff auf den Namespace besitzt. Wenn dies nicht der Fall ist, führen Sie die Anwendung in dem Subnetz aus, das Zugriff auf den Namespace besitzt, oder fügen Sie die IP-Adresse des Computers, auf dem die Anwendung ausgeführt wird, der IP-Firewall hinzu.

Wenn Sie einen Dienstendpunkt für ein virtuelles Netzwerk für einen Event Hub-Namespace erstellen, akzeptiert der Namespace nur Datenverkehr aus dem Subnetz, das an den Dienstendpunkt gebunden ist. Es gibt eine Ausnahme für dieses Verhalten. Sie können bestimmte IP-Adressen in der IP-Firewall hinzufügen, um den Zugriff auf den öffentlichen Endpunkt des Event Hub zu ermöglichen. Weitere Informationen finden Sie unter Netzwerkdienstendpunkte.

Überprüfen der IP-Firewalleinstellungen für Ihren Namespace

Überprüfen Sie, ob die öffentliche IP-Adresse des Computers, auf dem die Anwendung ausgeführt wird, durch die IP-Firewall blockiert wird.

Standardmäßig kann über das Internet auf Event Hubs-Namespaces zugegriffen werden, solange die Anforderung eine gültige Authentifizierung und Autorisierung aufweist. Mit der IP-Firewall können Sie den Zugriff auf eine Gruppe von IPv4- oder IPv6-Adressen oder -Adressbereichen in der CIDR-Notation (Classless Inter-Domain Routing) weiter einschränken.

Die IP-Firewallregeln werden auf der Event Hubs-Namespaceebene angewendet. Daher gelten die Regeln für alle Clientverbindungen mit einem beliebigen unterstützten Protokoll. Jeder Verbindungsversuch von einer IP-Adresse, die nicht mit einer zulässigen IP-Regel im Event Hubs-Namespace übereinstimmt, wird als nicht autorisiert abgelehnt. In der Antwort wird die IP-Regel nicht erwähnt. IP-Filterregeln werden der Reihe nach angewendet, und die erste Regel, die eine Übereinstimmung mit der IP-Adresse ergibt, bestimmt die Aktion (Zulassen oder Ablehnen).

Weitere Informationen finden Sie unter Konfigurieren von IP-Firewallregeln für ein Azure Event Hubs-Namespace. Informationen zur Überprüfung, ob Probleme mit der IP-Filterung, dem virtuellen Netzwerk oder der Zertifikatkette vorliegen, finden Sie unter Beheben von netzwerkbezogenen Problemen.

Überprüfen, ob auf den Namespace nur mit einem privaten Endpunkt zugegriffen werden kann

Wenn der Event Hubs-Namespace so konfiguriert ist, dass darauf nur über einen privaten Endpunkt zugegriffen werden kann, vergewissern Sie sich, dass die Clientanwendung über den privaten Endpunkt auf den Namespace zugreift.

Mit dem Azure Private Link-Dienst können Sie über einen privaten Endpunkt in Ihrem virtuellen Netzwerk auf Azure Event Hubs zugreifen. Ein privater Endpunkt ist eine Netzwerkschnittstelle, die Sie privat und sicher mit einem von Azure Private Link betriebenen Dienst verbindet. Der private Endpunkt verwendet eine private IP-Adresse aus Ihrem virtuellen Netzwerk und bindet den Dienst dadurch in Ihr virtuelles Netzwerk ein. Der gesamte für den Dienst bestimmte Datenverkehr kann über den privaten Endpunkt geleitet werden. Es sind also keine Gateways, NAT-Geräte, ExpressRoute-/VPN-Verbindungen oder öffentlichen IP-Adressen erforderlich. Der Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Dienst wird über das Microsoft-Backbone-Netzwerk übertragen und dadurch vom öffentlichen Internet isoliert. Sie können eine Verbindung mit einer Instanz einer Azure-Ressource herstellen, was ein Höchstmaß an Granularität bei der Zugriffssteuerung ermöglicht.

Weitere Informationen finden Sie unter Konfigurieren privater Endpunkte. Weitere Informationen zum Bestätigen, dass ein privater Endpunkt verwendet wird, finden Sie unter Überprüfen, ob die private Endpunktverbindung funktioniert.

Beheben von netzwerkbezogenen Problemen

Führen Sie die folgenden Schritte aus, um netzwerkbezogene Probleme mit Event Hubs zu beheben:

Navigieren Sie zu https://<yournamespacename>.servicebus.windows.net/, oder verwenden Sie wget. Dies hilft bei der Überprüfung, ob Probleme mit der IP-Filterung oder dem virtuellen Netzwerk bzw. der Zertifikatkette vorliegen (häufiges Problem bei Verwendung des Java SDK).

Beispiel für eine erfolgreiche Meldung:

<feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>

Beispiel für eine Fehlermeldung:

<Error>
    <Code>400</Code>
    <Detail>
        Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
    </Detail>
</Error>

Beheben zeitweiliger Konnektivitätsprobleme

Wenn vorübergehend Konnektivitätsprobleme auftreten, finden Sie in den folgenden Abschnitten Tipps zur Problembehandlung.

Verwenden der neuesten Version des SDK

Einige der vorübergehenden Konnektivitätsprobleme wurden möglicherweise in neueren Versionen des SDK als der von Ihnen verwendeten behoben. Stellen Sie sicher, dass Sie die neueste Version der Client-SDKs in Ihren Anwendungen verwenden. SDKs werden durch neue/aktualisierte Features und Fehlerbehebungen kontinuierlich verbessert. Testen Sie daher immer mit dem neuesten Paket. Überprüfen Sie die Versionshinweise auf behobene Probleme und hinzugefügte/aktualisierte Features.

Weitere Informationen zu Client-SDKs finden Sie im Artikel Azure Event Hubs – Client-SDKs.

Ausführen der Befehle zum Überprüfen gelöschter Pakete

Führen Sie bei zeitweiligen Konnektivitätsproblemen den folgenden Befehl aus, um zu überprüfen, ob gelöschte Pakete vorhanden sind. Dieser Befehl versucht, jede Sekunde 25 verschiedene TCP-Verbindungen mit dem Dienst herzustellen. Anschließend können Sie überprüfen, wie viele davon erfolgreich/fehlerhaft waren, und außerdem die Latenz der TCP-Verbindung anzeigen. Sie können das psping-Tool psping herunterladen.

.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner     

Sie können äquivalente Befehle verwenden, wenn Sie andere Tools wie tnc, ping usw. nutzen.

Rufen Sie eine Netzwerkablaufverfolgung ab, wenn die vorherigen Schritte nicht hilfreich sind, und analysieren Sie diese mit Tools wie Wireshark. Wenden Sie sich bei Bedarf an den Microsoft-Support.

Dienstupgrades/-neustarts

Vorübergehende Konnektivitätsprobleme können aufgrund von Upgrades und Neustarts des Back-End-Diensts auftreten. Wenn solche Probleme vorliegen, treten möglicherweise die folgenden Symptome auf:

• Es gehen möglicherweise weniger Nachrichten/Anforderungen ein.
• Die Protokolldatei enthält unter Umständen Fehlermeldungen.
• Die Verbindung zwischen Anwendungen und dem Dienst wird möglicherweise für einige Sekunden getrennt.
• Anforderungen werden ggf. vorübergehend gedrosselt.

Wenn im Anwendungscode das SDK verwendet wird, ist die Wiederholungsrichtlinie bereits integriert und aktiv. Die Verbindung stellt ohne nennenswerte Auswirkungen auf die Anwendung/den Workflow die Verbindung wieder her. Das Abfangen dieser vorübergehenden Fehler, das Zurücksetzen und anschließende Wiederholen des Aufrufs stellen sicher, dass der Code bei diesen vorübergehenden Probleme stabil ist.

Nächste Schritte

Weitere Informationen finden Sie in folgenden Artikeln:

• Behandeln von Authentifizierungs- und Autorisierungsproblemen