Behandeln von Konnektivitätsproblemen: Azure Event Hubs

Wenn Ihre Clientanwendung keine Verbindung mit einem Event Hub herstellen kann, verwenden Sie diesen Artikel, um das Problem zu diagnostizieren und zu beheben. Konnektivitätsprobleme sind in zwei Kategorien unterteilt: dauerhafte Probleme (die Verbindung ist nie erfolgreich) und vorübergehende Probleme (zeitweilige Fehler).

Überprüfen Sie bei dauerhaften Problemen diese Einstellungen und andere Optionen, die im Abschnitt "Problembehandlung für dauerhafte Konnektivitätsprobleme " erwähnt werden:

• Verbindungszeichenfolge
• Firewalleinstellungen Ihrer Organisation
• IP-Firewalleinstellungen
• Netzwerksicherheitseinstellungen (Dienstendpunkte, private Endpunkte und mehr)

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

• Upgrade auf die neueste Version des SDK
• Befehle ausführen, um verworfene Pakete zu prüfen
• Rufen Sie Netzwerkablaufverfolgungen ab.

Behandeln dauerhafter Konnektivitätsprobleme

Wenn die Anwendung überhaupt keine Verbindung mit dem Event Hub herstellen kann, führen Sie die Schritte in diesem Abschnitt 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 Sie die Verbindungszeichenfolge

Vergewissern Sie sich, dass die verwendete Verbindungszeichenfolge richtig ist. Siehe Get Verbindungszeichenfolge, um die Verbindungszeichenfolge mithilfe des Azure-Portals, der CLI oder PowerShell abzurufen.

Überprüfen Sie bei Kafka-Clients, ob producer.config-Dateien 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.

Konsumenten verwenden AMQP oder Kafka, um Ereignisse von einem Ereignis-Hub zu empfangen. Event Hubs unterstützt nur das Pull-Modell für Consumer zum Empfang von Ereignissen. 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.

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 Handshake-Schleifen ausgeführt werden und der Overhead etwas höher ist. Dies ist ein Kompromiss aufgrund der gemeinsamen Nutzung des HTTPS-Ports. 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:

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 auf den 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 in der Eingabeaufforderung aus:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

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

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 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 jede Instanz mit den Suffixen s1, s2 und s3 aus, um die IP-Adressen aller drei Instanzen zu erhalten, die in drei Verfügbarkeitszonen laufen.

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

Stellen Sie sicher, dass das Event Hubs-Dienst-Tag in Ihren Netzwerksicherheitsgruppen zulässig ist.

Wenn Ihre Anwendung in einem Subnetz ausgeführt wird und eine zugeordnete Netzwerksicherheitsgruppe vorhanden ist, überprüfen Sie, ob der ausgehende Internetdatenverkehr zulässig ist oder ob 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 virtuellen Netzwerk-Subnetz ausgeführt wird, das Zugriff auf den Namespace hat. Führen Sie andernfalls die Anwendung in dem Subnetz aus, das Zugriff auf den Namespace hat, oder fügen Sie die IP-Adresse des Computers, auf dem die Anwendung läuft, 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 Sie die IP-Firewalleinstellungen für Ihren Namespace

Überprüfen Sie, dass die öffentliche IP-Adresse des Computers, auf dem die Anwendung läuft, nicht von der 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 zum Überprüfen, ob Probleme mit ip-Filterung, virtuellem Netzwerk oder Zertifikatketten auftreten, finden Sie unter "Behandeln von Netzwerkproblemen".

Ü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.

Behandeln von Netzwerkproblemen

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

Verwenden Sie wget, um auf https://<yournamespacename>.servicebus.windows.net/ zuzugreifen, oder browsen Sie dorthin. In diesem Schritt können Sie überprüfen, ob IP-Filterung, virtuelles Netzwerk oder Zertifikatkettenprobleme auftreten (am häufigsten bei Verwendung von 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>

Behandeln vorübergehender Konnektivitätsprobleme

Wenn es zu zeitweiligen Verbindungsproblemen kommt, sehen Sie sich die folgenden Abschnitte für Tipps zur Problembehandlung an.

Verwenden Sie die neueste Version des Client-SDK

In späteren Versionen des SDK können einige vorübergehende Konnektivitätsprobleme behoben werden. Stellen Sie sicher, dass Sie die neueste Version von Client-SDKs in Ihren Anwendungen verwenden. SDKs werden kontinuierlich mit neuen oder aktualisierten Features und Fehlerbehebungen verbessert, also testen Sie immer mit dem neuesten Paket. Überprüfen Sie die Versionshinweise auf behobene Probleme und hinzugefügte oder aktualisierte Features.

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

Führen Sie den Befehl aus, um gelöschte Pakete zu überprüfen.

Wenn zeitweilige Konnektivitätsprobleme auftreten, führen Sie den folgenden Befehl aus, um zu überprüfen, ob verworfene 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 von ihnen erfolgreich waren oder fehlgeschlagen sind, und auch die TCP-Verbindungslatenz anzeigen. Sie können das psping-Tool von hier 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 und Neustarts

Vorübergehende Konnektivitätsprobleme können aufgrund von Back-End-Dienstupgrades und Neustarts auftreten. Wenn diese Probleme auftreten, sehen Sie möglicherweise die folgenden Symptome:

• Eingehende Nachrichten oder Anfragen gehen verloren.
• Die Protokolldatei zeigt Fehlermeldungen an.
• Die Anwendungen trennen sich für einige Sekunden vom Dienst.
• Anfragen werden momentan gedrosselt.

Wenn Ihr Anwendungscode das SDK verwendet, verfügt er bereits über eine aktive Wiederholungsrichtlinie. Die Anwendung wird ohne erhebliche Auswirkungen auf die Anwendung oder den Workflow erneut verbunden. Indem Sie diese vorübergehenden Fehler abfangen, sich kurzzeitig zurückziehen und dann den Aufruf wiederholen, stellen Sie sicher, dass Ihr Code diese vorübergehenden Fehler behandeln kann.

Nächste Schritte

Weitere Informationen finden Sie in folgenden Artikeln:

• Behandeln von Authentifizierungs- und Autorisierungsproblemen