Verbindingsproblemen oplossen - Azure Event Hubs
Er zijn verschillende redenen waarom clienttoepassingen geen verbinding kunnen maken met een Event Hub. De verbindingsproblemen kunnen permanent of tijdelijk zijn.
Als het probleem altijd (permanent) optreedt, controleert u deze instellingen en andere opties die worden vermeld in de sectie Problemen met permanente connectiviteit oplossen in dit artikel.
- Connection string
- Firewallinstellingen van uw organisatie
- IP-firewallinstellingen
- Instellingen voor netwerkbeveiliging (service-eindpunten, privé-eindpunten, enzovoort) en meer
Voor tijdelijke problemen kunt u de volgende opties proberen die u kunnen helpen bij het oplossen van de problemen. Zie Problemen met tijdelijke connectiviteit oplossen voor meer informatie.
- Upgrade uitvoeren naar de nieuwste versie van de SDK
- Opdrachten uitvoeren om verwijderde pakketten te controleren
- Haal netwerktraceringen op.
Problemen met permanente connectiviteit oplossen
Als de toepassing helemaal geen verbinding kan maken met de Event Hub, volgt u de stappen in deze sectie om het probleem op te lossen.
Controleer of er een servicestoring is
Controleer op de servicestoring van Azure Event Hubs op de azure-servicestatussite.
De verbindingsreeks controleren
Controleer of de verbindingsreeks die u gebruikt juist is. Zie Verbindingsreeks ophalen om de verbindingsreeks op te halen met behulp van Azure Portal, CLI of PowerShell.
Controleer voor Kafka-clients of producer.config- of consumer.config-bestanden juist zijn geconfigureerd. Zie Berichten verzenden en ontvangen met Kafka in Event Hubs voor meer informatie.
Welke protocollen kan ik gebruiken om gebeurtenissen te verzenden en te ontvangen?
Producenten of afzenders kunnen Advanced Messaging Queuing Protocol (AMQP), Kafka- of HTTPS-protocollen gebruiken om gebeurtenissen naar een Event Hub te verzenden.
Consumenten of ontvangers gebruiken AMQP of Kafka om gebeurtenissen te ontvangen van een Event Hub. Event Hubs ondersteunt alleen het pull-model voor consumenten om er gebeurtenissen van te ontvangen. Zelfs wanneer u gebeurtenis-handlers gebruikt om gebeurtenissen van een Event Hub te verwerken, gebruikt de gebeurtenisprocessor intern het pull-model om gebeurtenissen van de Event Hub te ontvangen.
AMQP
U kunt het AMQP 1.0-protocol gebruiken om gebeurtenissen te verzenden naar en te ontvangen van Azure Event Hubs. AMQP biedt betrouwbare, performante en veilige communicatie voor zowel het verzenden als ontvangen van gebeurtenissen. U kunt deze gebruiken voor high-performance en realtime streaming en wordt ondersteund door de meeste Azure Event Hubs SDK's.
HTTPS/REST API
U kunt alleen gebeurtenissen verzenden naar Event Hubs met behulp van HTTP POST-aanvragen. Event Hubs biedt geen ondersteuning voor het ontvangen van gebeurtenissen via HTTPS. Het is geschikt voor lichtgewicht clients waarbij een directe TCP-verbinding niet haalbaar is.
Apache Kafka
Azure Event Hubs heeft een ingebouwd Kafka-eindpunt dat ondersteuning biedt voor Kafka-producenten en -consumenten. Toepassingen die zijn gebouwd met Behulp van Kafka, kunnen het Kafka-protocol (versie 1.0 of hoger) gebruiken om gebeurtenissen van Event Hubs te verzenden en te ontvangen zonder codewijzigingen.
Azure SDK's abstraheren de onderliggende communicatieprotocollen en bieden een vereenvoudigde manier om gebeurtenissen van Event Hubs te verzenden en te ontvangen met behulp van talen zoals C#, Java, Python, JavaScript, enzovoort.
Welke poorten moet ik openen op de firewall?
U kunt de volgende protocollen met Azure Event Hubs gebruiken om gebeurtenissen te verzenden en te ontvangen:
- Advanced Message Queuing Protocol 1.0 (AMQP)
- Hypertext Transfer Protocol 1.1 met Transport Layer Security (HTTPS)
- Apache Kafka
Zie de volgende tabel voor de uitgaande poorten die u moet openen om deze protocollen te kunnen gebruiken om te communiceren met Azure Event Hubs.
Protocol | Poorten | DETAILS |
---|---|---|
AMQP | 5671 en 5672 | Zie de HANDLEIDING voor HET AMQP-protocol |
HTTPS | 443 | Deze poort wordt gebruikt voor de HTTP/REST API en voor AMQP-over-WebSockets. |
Kafka | 9093 | Zie Event Hubs gebruiken vanuit Kafka-toepassingen |
De HTTPS-poort is vereist voor uitgaande communicatie ook wanneer AMQP wordt gebruikt via poort 5671, omdat verschillende beheerbewerkingen die worden uitgevoerd door de client-SDK's en het verkrijgen van tokens van Microsoft Entra ID (wanneer gebruikt) via HTTPS worden uitgevoerd.
De officiële Azure SDK's gebruiken over het algemeen het AMQP-protocol voor het verzenden en ontvangen van gebeurtenissen van Event Hubs. De protocoloptie AMQP-over-WebSockets wordt uitgevoerd via poort TCP 443, net als de HTTP-API, maar is anders functioneel identiek aan gewone AMQP. Deze optie heeft een hogere initiële verbindingslatentie vanwege extra handshake-retouren en iets meer overhead als compromis voor het delen van de HTTPS-poort. Als deze modus is geselecteerd, is TCP-poort 443 voldoende voor communicatie. Met de volgende opties kunt u de normale AMQP- of AMQP WebSockets-modus selecteren:
Taal | Optie |
---|---|
.NET | Eigenschap EventHubConnectionOptions.TransportType met EventHubsTransportType.AmqpTcp of EventHubsTransportType.AmqpWebSockets |
Java | com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype met AmqpTransportType.AMQP of AmqpTransportType.AMQP_WEB_SOCKETS |
Knooppunt | EventHubConsumerClientOptions heeft een webSocketOptions eigenschap. |
Python | EventHubConsumerClient.transport_type met TransportType.Amqp of TransportType.AmqpOverWebSocket |
Welke IP-adressen moet ik toestaan?
Wanneer u met Azure werkt, moet u soms specifieke IP-adresbereiken of URL's in uw bedrijfsfirewall of proxy toestaan voor toegang tot alle Azure-services die u gebruikt of probeert te gebruiken. Controleer of het verkeer is toegestaan op IP-adressen die worden gebruikt door Event Hubs. Zie Azure IP-bereiken en servicetags - openbare cloud voor IP-adressen die worden gebruikt door Azure Event Hubs.
Controleer ook of het IP-adres voor uw naamruimte is toegestaan. Voer de volgende stappen uit om de juiste IP-adressen te vinden om uw verbindingen toe te staan:
Voer de volgende opdracht uit vanaf een opdrachtprompt:
nslookup <YourNamespaceName>.servicebus.windows.net
Noteer het IP-adres dat is geretourneerd in
Non-authoritative answer
.
Als u een naamruimte gebruikt die wordt gehost in een ouder cluster (op basis van Cloud Services - CNAME die eindigt op *.cloudapp.net) en de naamruimte zoneredundant is, moet u enkele extra stappen volgen. Als uw naamruimte zich op een nieuw cluster bevindt (op basis van virtuele-machineschaalset - CNAME eindigend op *.cloudapp.azure.com) en zone-redundant, kunt u de onderstaande stappen overslaan.
Eerst voert u nslookup uit op de naamruimte.
nslookup <yournamespace>.servicebus.windows.net
Noteer de naam in de sectie niet-bindende antwoorden , die zich in een van de volgende notaties bevindt:
<name>-s1.cloudapp.net <name>-s2.cloudapp.net <name>-s3.cloudapp.net
Voer nslookup uit voor elk exemplaar met achtervoegsels s1, s2 en s3 om de IP-adressen op te halen van alle drie exemplaren die worden uitgevoerd in drie beschikbaarheidszones,
Notitie
Het IP-adres dat door de
nslookup
opdracht wordt geretourneerd, is geen statisch IP-adres. Het blijft echter constant totdat de onderliggende implementatie wordt verwijderd of verplaatst naar een ander cluster.
Naar welke ip-adressen van clients worden gebeurtenissen verzonden of ontvangen van mijn naamruimte?
Schakel eerst IP-filtering in voor de naamruimte.
Schakel vervolgens diagnostische logboeken in voor gebeurtenissen in het virtuele netwerk van Event Hubs door de instructies in de diagnostische logboeken inschakelen te volgen. U ziet het IP-adres waarvoor de verbinding is geweigerd.
{
"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"
}
Belangrijk
Virtuele netwerklogboeken worden alleen gegenereerd als de naamruimte toegang toestaat vanaf specifieke IP-adressen (IP-filterregels). Als u de toegang tot uw naamruimte niet wilt beperken met behulp van deze functies en toch virtuele netwerklogboeken wilt ophalen om IP-adressen bij te houden van clients die verbinding maken met de Event Hubs-naamruimte, kunt u de volgende tijdelijke oplossing gebruiken: IP-filtering inschakelen en het totale adresseerbare IPv4-bereik () en het IPv6-bereik (0.0.0.0/1
128.0.0.0/1
- ) toevoegen.::/1
- 8000::/1
Notitie
Momenteel is het niet mogelijk om het bron-IP-adres van een afzonderlijk bericht of afzonderlijke gebeurtenis te bepalen.
Controleer of de Event Hubs-servicetag is toegestaan in uw netwerkbeveiligingsgroepen
Als uw toepassing wordt uitgevoerd in een subnet en er een gekoppelde netwerkbeveiligingsgroep is, controleert u of het uitgaande internetverkeer is toegestaan of dat de Event Hubs-servicetag (EventHub
) is toegestaan. Zie servicetags voor virtueel netwerk en zoek naar EventHub
.
Controleer of de toepassing moet worden uitgevoerd in een specifiek subnet van een virtueel netwerk
Controleer of uw toepassing wordt uitgevoerd in een subnet van een virtueel netwerk dat toegang heeft tot de naamruimte. Als dit niet het probleem is, voert u de toepassing uit in het subnet dat toegang heeft tot de naamruimte of voegt u het IP-adres toe van de computer waarop de toepassing wordt uitgevoerd naar de IP-firewall.
Wanneer u een service-eindpunt voor een virtueel netwerk voor een Event Hub-naamruimte maakt, accepteert de naamruimte alleen verkeer van het subnet dat is gebonden aan het service-eindpunt. Er is een uitzondering op dit gedrag. U kunt specifieke IP-adressen toevoegen in de IP-firewall om toegang tot het openbare eindpunt van de Event Hub in te schakelen. Zie Netwerkservice-eindpunten voor meer informatie.
Controleer de IP-firewallinstellingen voor uw naamruimte
Controleer of het openbare IP-adres van de computer waarop de toepassing wordt uitgevoerd, niet wordt geblokkeerd door de IP-firewall.
Event Hubs-naamruimten zijn standaard toegankelijk vanaf internet zolang de aanvraag wordt geleverd met geldige verificatie en autorisatie. Met IP-firewall kunt u deze verder beperken tot alleen een set IPv4- of IPv6-adressen of adresbereiken in CIDR-notatie (Classless Inter-Domain Routing).
De IP-firewallregels worden toegepast op het niveau van de Event Hubs-naamruimte. Daarom zijn de regels van toepassing op alle verbindingen van clients die elk ondersteund protocol gebruiken. Een verbindingspoging van een IP-adres dat niet overeenkomt met een toegestane IP-regel in de Event Hubs-naamruimte, wordt geweigerd als onbevoegd. Het antwoord vermeldt de IP-regel niet. IP-filterregels worden op volgorde toegepast en de eerste regel die overeenkomt met het IP-adres bepaalt de actie Accepteren of Weigeren.
Zie IP-firewallregels configureren voor een Azure Event Hubs-naamruimte voor meer informatie. Zie Problemen met netwerkgerelateerde problemen oplossen om te controleren of u problemen met IP-filtering, virtueel netwerk of certificaatketen hebt.
Controleer of de naamruimte alleen toegankelijk is via een privé-eindpunt
Als de Event Hubs-naamruimte zo is geconfigureerd dat deze alleen toegankelijk is via een privé-eindpunt, controleert u of de clienttoepassing toegang heeft tot de naamruimte via het privé-eindpunt.
Met de Azure Private Link-service hebt u toegang tot Azure Event Hubs via een privé-eindpunt in uw virtuele netwerk. Een privé-eindpunt is een netwerkinterface waarmee u privé en veilig verbinding maakt met een service die door Azure Private Link mogelijk wordt gemaakt. Het privé-eindpunt maakt gebruik van een privé IP-adres van uw virtuele netwerk waardoor de service feitelijk in uw virtuele netwerk wordt geplaatst. Al het verkeer naar de service kan worden gerouteerd via het privé-eindpunt, zodat er geen gateways, NAT-apparaten, ExpressRoute of VPN-verbindingen of openbare IP-adressen nodig zijn. Verkeer tussen uw virtuele netwerk en de services wordt via het backbonenetwerk van Microsoft geleid, waarmee de risico's van het openbare internet worden vermeden. U kunt verbinding maken met een exemplaar van een Azure-resource, zodat u het hoogste granulariteit krijgt in toegangsbeheer.
Zie Privé-eindpunten configureren voor meer informatie. Zie de sectie Valideren of de privé-eindpuntverbinding werkt om te bevestigen dat een privé-eindpunt wordt gebruikt.
Netwerkgerelateerde problemen oplossen
Volg deze stappen om netwerkproblemen met Event Hubs op te lossen:
Blader naar of wgethttps://<yournamespacename>.servicebus.windows.net/
. Het helpt bij het controleren of u problemen hebt met IP-filtering of virtueel netwerk of certificaatketen (meest voorkomende bij het gebruik van Java SDK).
Een voorbeeld van een geslaagd bericht:
<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>
Een voorbeeld van een foutbericht:
<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>
Tijdelijke verbindingsproblemen oplossen
Als u onregelmatige verbindingsproblemen ondervindt, doorloopt u de volgende secties voor tips voor het oplossen van problemen.
De nieuwste versie van de client-SDK gebruiken
Sommige tijdelijke verbindingsproblemen zijn mogelijk opgelost in de latere versies van de SDK dan wat u gebruikt. Zorg ervoor dat u de nieuwste versie van client-SDK's in uw toepassingen gebruikt. SDK's worden continu verbeterd met nieuwe/bijgewerkte functies en bugfixes, dus test altijd met het nieuwste pakket. Controleer de releaseopmerkingen op problemen die zijn opgelost en functies die zijn toegevoegd/bijgewerkt.
Zie het artikel Azure Event Hubs - Client SDK's voor informatie over client-SDK's .
Voer de opdracht uit om verwijderde pakketten te controleren
Als er onregelmatige verbindingsproblemen zijn, voert u de volgende opdracht uit om te controleren of er verwijderde pakketten zijn. Met deze opdracht wordt geprobeerd om de 1 seconde 25 verschillende TCP-verbindingen tot stand te brengen met de service. Vervolgens kunt u controleren hoeveel van deze zijn geslaagd/mislukt en ook TCP-verbindingslatentie zien. U kunt het psping
hulpprogramma hier downloaden.
.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner
U kunt gelijkwaardige opdrachten gebruiken als u andere hulpprogramma's gebruikt, zoals tnc
ping
, enzovoort.
Haal een netwerktracering op als de vorige stappen niet helpen en analyseren met behulp van hulpprogramma's zoals Wireshark. Neem indien nodig contact op met Microsoft Ondersteuning.
Service-upgrades/opnieuw opstarten
Tijdelijke verbindingsproblemen kunnen optreden vanwege upgrades en opnieuw opstarten van de back-endservice. Wanneer ze optreden, ziet u mogelijk de volgende symptomen:
- Er kan sprake zijn van een daling van binnenkomende berichten/aanvragen.
- Het logboekbestand kan foutberichten bevatten.
- De verbinding tussen de toepassingen en de service kan enkele seconden worden verbroken.
- Aanvragen kunnen tijdelijk worden beperkt.
Als de toepassingscode gebruikmaakt van SDK, is het beleid voor opnieuw proberen al ingebouwd en actief. De toepassing maakt opnieuw verbinding zonder aanzienlijke gevolgen voor de toepassing/werkstroom. Als u deze tijdelijke fouten onderscheppen, een back-up maakt en vervolgens de aanroep opnieuw probeert uit te voeren, zorgt u ervoor dat uw code bestand is tegen deze tijdelijke problemen.
Volgende stappen
Zie de volgende artikelen: