Dela via

Felsöka anslutningsproblem – Azure Event Hubs

  • Artikel

Det finns olika orsaker till att klientappar inte kan ansluta till en händelsehubb. Anslutningsproblemen kan vara permanenta eller tillfälliga.

Om problemet inträffar hela tiden (permanent) kontrollerar du de här inställningarna och andra alternativ som nämns i avsnittet Felsöka permanenta anslutningsproblem i den här artikeln.

  • Connection string
  • Organisationens brandväggsinställningar
  • IP-brandväggsinställningar
  • Nätverkssäkerhetsinställningar (tjänstslutpunkter, privata slutpunkter osv.) med mera

För tillfälliga problem kan du prova följande alternativ som kan hjälpa dig att felsöka problemen. Mer information finns i Felsöka tillfälliga anslutningsproblem.

  • Uppgradera till den senaste versionen av SDK
  • Kör kommandon för att kontrollera borttagna paket
  • Hämta nätverksspårningar.

Felsöka problem med permanent anslutning

Om programmet inte kan ansluta till händelsehubben alls följer du stegen i det här avsnittet för att felsöka problemet.

Kontrollera om det uppstår ett avbrott i tjänsten

Sök efter avbrott i Azure Event Hubs-tjänsten på azure-tjänstens statuswebbplats.

Kontrollera anslutningssträng

Kontrollera att anslutningssträng du använder är korrekt. Se Hämta anslutningssträng för att hämta anslutningssträng med hjälp av Azure Portal, CLI eller PowerShell.

För Kafka-klienter kontrollerar du att filerna producer.config eller consumer.config är korrekt konfigurerade. Mer information finns i Skicka och ta emot meddelanden med Kafka i Event Hubs.

Vilka protokoll kan jag använda för att skicka och ta emot händelser?

Producenter eller avsändare kan använda PROTOKOLL för Advanced Messaging Queuing (AMQP), Kafka eller HTTPS för att skicka händelser till en händelsehubb.

Konsumenter eller mottagare använder AMQP eller Kafka för att ta emot händelser från en händelsehubb. Event Hubs stöder endast pull-modellen för konsumenter att ta emot händelser från den. Även när du använder händelsehanterare för att hantera händelser från en händelsehubb använder händelseprocessorn internt pull-modellen för att ta emot händelser från händelsehubben.

AMQP

Du kan använda PROTOKOLLET AMQP 1.0 för att skicka händelser till och ta emot händelser från Azure Event Hubs. AMQP tillhandahåller tillförlitlig, högpresterande och säker kommunikation för både sändning och mottagning av händelser. Du kan använda den för strömning med höga prestanda och realtid och stöds av de flesta SDK:er för Azure Event Hubs.

HTTPS/REST API

Du kan bara skicka händelser till Event Hubs med HTTP POST-begäranden. Event Hubs har inte stöd för att ta emot händelser via HTTPS. Den är lämplig för lätta klienter där en direkt TCP-anslutning inte är möjlig.

Apache Kafka

Azure Event Hubs har en inbyggd Kafka-slutpunkt som stöder Kafka-producenter och konsumenter. Program som skapas med Kafka kan använda Kafka-protokollet (version 1.0 eller senare) för att skicka och ta emot händelser från Event Hubs utan några kodändringar.

Azure SDK:er abstraherar de underliggande kommunikationsprotokollen och ger ett förenklat sätt att skicka och ta emot händelser från Event Hubs med hjälp av språk som C#, Java, Python, JavaScript osv.

Vilka portar behöver jag öppna i brandväggen?

Du kan använda följande protokoll med Azure Event Hubs för att skicka och ta emot händelser:

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

Se följande tabell för de utgående portar som du behöver öppna för att använda dessa protokoll för att kommunicera med Azure Event Hubs.

Protokoll Hamnar Details
AMQP 5671 och 5672 Se AMQP-protokollguide
HTTPS 443 Den här porten används för HTTP/REST API och för AMQP-over-WebSockets.
Kafka 9093 Se Använda Event Hubs från Kafka-program

HTTPS-porten krävs för utgående kommunikation även när AMQP används via port 5671, eftersom flera hanteringsåtgärder som utförs av klient-SDK:er och förvärv av token från Microsoft Entra-ID (när det används) körs över HTTPS.

De officiella Azure SDK:erna använder vanligtvis AMQP-protokollet för att skicka och ta emot händelser från Event Hubs. Protokollalternativet AMQP-over-WebSockets körs via port TCP 443 precis som HTTP-API:et, men är i övrigt funktionellt identiskt med vanlig AMQP. Det här alternativet har högre inledande anslutningsfördröjning på grund av extra handskakningsturer och något mer omkostnader som kompromiss för att dela HTTPS-porten. Om det här läget är valt räcker det med TCP-port 443 för kommunikation. Med följande alternativ kan du välja vanligt AMQP- eller AMQP WebSockets-läge:

Språk Alternativ
.NET Egenskapen EventHubConnectionOptions.TransportType med EventHubsTransportType.AmqpTcp eller EventHubsTransportType.AmqpWebSockets
Java com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype med AmqpTransportType.AMQP eller AmqpTransportType.AMQP_WEB_SOCKETS
Nod EventHubConsumerClientOptions har en webSocketOptions egenskap.
Python EventHubConsumerClient.transport_type med TransportType.Amqp eller TransportType.AmqpOverWebSocket

Vilka IP-adresser behöver jag tillåta?

När du arbetar med Azure måste du ibland tillåta att specifika IP-adressintervall eller URL:er i företagets brandvägg eller proxy får åtkomst till alla Azure-tjänster som du använder eller försöker använda. Kontrollera att trafiken tillåts på IP-adresser som används av Event Hubs. För IP-adresser som används av Azure Event Hubs: se Azure IP-intervall och tjänsttaggar – offentligt moln.

Kontrollera också att IP-adressen för ditt namnområde är tillåten. Följ dessa steg för att hitta rätt IP-adresser för att tillåta dina anslutningar:

  1. Kör följande kommando från en kommandotolk:

    nslookup <YourNamespaceName>.servicebus.windows.net

  2. Anteckna IP-adressen som returnerades i Non-authoritative answer.

Om du använder ett namnområde som finns i ett äldre kluster (baserat på Cloud Services – CNAME som slutar på *.cloudapp.net) och namnområdet är zonredundant måste du följa några extra steg. Om ditt namnområde finns i ett nyare kluster (baserat på VM-skalningsuppsättning – CNAME som slutar på *.cloudapp.azure.com) och zonredundant kan du hoppa över stegen nedan.

  1. Först kör du nslookup på namnområdet.

    nslookup <yournamespace>.servicebus.windows.net

  2. Anteckna namnet i avsnittet icke-auktoritativt svar , som är i något av följande format:

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

  3. Kör nslookup för var och en med suffixen s1, s2 och s3 för att hämta IP-adresserna för alla tre instanser som körs i tre tillgänglighetszoner.

    Kommentar

    IP-adressen som returneras av nslookup kommandot är inte en statisk IP-adress. Den förblir dock konstant tills den underliggande distributionen tas bort eller flyttas till ett annat kluster.

Vilka klient-IP-adresser skickar händelser till eller tar emot händelser från mitt namnområde?

Aktivera först IP-filtrering på namnområdet.

Aktivera sedan diagnostikloggar för händelsehubbars virtuella nätverksanslutningshändelser genom att följa anvisningarna i Aktivera diagnostikloggar. Du ser DEN IP-adress som anslutningen nekas för.

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

Viktigt!

Virtuella nätverksloggar genereras endast om namnområdet tillåter åtkomst från specifika IP-adresser (IP-filterregler). Om du inte vill begränsa åtkomsten till ditt namnområde med hjälp av dessa funktioner och ändå vill hämta loggar för virtuella nätverk för att spåra IP-adresser för klienter som ansluter till Event Hubs-namnområdet kan du använda följande lösning: Aktivera IP-filtrering och lägga till det totala adresserbara IPv4-intervallet (128.0.0.0/10.0.0.0/1 - ) och IPv6-intervallet (::/1 - 8000::/1).

Kommentar

För närvarande går det inte att fastställa käll-IP-adressen för ett enskilt meddelande eller en enskild händelse.

Kontrollera att Event Hubs-tjänsttaggen tillåts i dina nätverkssäkerhetsgrupper

Om ditt program körs i ett undernät och det finns en associerad nätverkssäkerhetsgrupp kontrollerar du om utgående internettrafik tillåts eller om Event Hubs-tjänsttaggen (EventHub) tillåts. Se Tjänsttaggar för virtuellt nätverk och sök EventHubefter .

Kontrollera om programmet måste köras i ett specifikt undernät i ett virtuellt nätverk

Bekräfta att programmet körs i ett virtuellt nätverksundernät som har åtkomst till namnområdet. Om det inte är det kör du programmet i undernätet som har åtkomst till namnområdet eller lägger till IP-adressen för den dator där programmet körs i IP-brandväggen.

När du skapar en tjänstslutpunkt för virtuellt nätverk för ett namnområde för händelsehubben accepterar namnområdet endast trafik från det undernät som är bundet till tjänstslutpunkten. Det finns ett undantag till det här beteendet. Du kan lägga till specifika IP-adresser i IP-brandväggen för att aktivera åtkomst till händelsehubbens offentliga slutpunkt. Mer information finns i Nätverkstjänstslutpunkter.

Kontrollera IP-brandväggsinställningarna för ditt namnområde

Kontrollera att den offentliga IP-adressen för den dator där programmet körs inte blockeras av IP-brandväggen.

Som standard är Event Hubs-namnområden tillgängliga från Internet så länge begäran levereras med giltig autentisering och auktorisering. Med IP-brandväggen kan du begränsa den ytterligare till endast en uppsättning IPv4- eller IPv6-adresser eller adressintervall i notationen CIDR (Classless Inter-Domain Routing).

IP-brandväggsreglerna tillämpas på Event Hubs-namnområdesnivå. Därför gäller reglerna för alla anslutningar från klienter som använder protokoll som stöds. Alla anslutningsförsök från en IP-adress som inte matchar en tillåten IP-regel i Event Hubs-namnområdet avvisas som obehöriga. I svaret nämns inte IP-regeln. IP-filterregler tillämpas i ordning och den första regeln som matchar IP-adressen avgör åtgärden acceptera eller avvisa.

Mer information finns i Konfigurera IP-brandväggsregler för ett Azure Event Hubs-namnområde. Information om huruvida du har problem med IP-filtrering, virtuellt nätverk eller certifikatkedja finns i Felsöka nätverksrelaterade problem.

Kontrollera om namnområdet endast kan nås med hjälp av en privat slutpunkt

Om Event Hubs-namnområdet är konfigurerat att endast vara tillgängligt via en privat slutpunkt kontrollerar du att klientprogrammet har åtkomst till namnområdet via den privata slutpunkten.

Med Azure Private Link-tjänsten kan du komma åt Azure Event Hubs via en privat slutpunkt i ditt virtuella nätverk. En privat slutpunkt är ett nätverksgränssnitt som ger dig en privat och säker anslutning till en tjänst som drivs av Azure Private Link. En privat slutpunkt använder en privat IP-adress från ditt virtuella nätverk, vilket i praktiken flyttar tjänsten till ditt virtuella nätverk. All trafik till tjänsten kan dirigeras via den privata slutpunkten, så inga gatewayer, NAT-enheter, ExpressRoute- eller VPN-anslutningar, eller offentliga IP-adresser behövs. Trafik mellan ditt virtuella nätverk och tjänsten passerar över Microsofts stamnätverk, vilket eliminerar exponering från det offentliga Internet. Du kan ansluta till en instans av en Azure-resurs, vilket ger dig den högsta detaljnivån i åtkomstkontrollen.

Mer information finns i Konfigurera privata slutpunkter. Se avsnittet Verifiera att den privata slutpunktsanslutningen fungerar för att bekräfta att en privat slutpunkt används.

Följ dessa steg för att felsöka nätverksrelaterade problem med Event Hubs:

Bläddra till eller wget https://<yournamespacename>.servicebus.windows.net/. Det hjälper dig att kontrollera om du har PROBLEM med IP-filtrering eller virtuellt nätverk eller certifikatkedja (vanligast när du använder Java SDK).

Ett exempel på lyckat meddelande:

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

Ett exempel på felmeddelande:

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

Felsöka tillfälliga anslutningsproblem

Om du har problem med tillfälliga anslutningar går du igenom följande avsnitt för felsökningstips.

Använd den senaste versionen av klient-SDK

Vissa av de tillfälliga anslutningsproblemen kan ha åtgärdats i de senare versionerna av SDK:et än vad du använder. Se till att du använder den senaste versionen av klient-SDK:er i dina program. SDK:er förbättras kontinuerligt med nya/uppdaterade funktioner och felkorrigeringar, så testa alltid med det senaste paketet. Kontrollera viktig information om problem som är fasta och funktioner som har lagts till/uppdaterats.

Information om klient-SDK:er finns i artikeln Azure Event Hubs – Client SDK:er .

Kör kommandot för att kontrollera borttagna paket

När det uppstår tillfälliga anslutningsproblem kör du följande kommando för att kontrollera om det finns några borttagna paket. Det här kommandot försöker upprätta 25 olika TCP-anslutningar var 1 sekund med tjänsten. Sedan kan du kontrollera hur många av dem som lyckades/misslyckades och även se TCP-anslutningsfördröjningen. Du kan ladda ned psping verktyget härifrån.

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

Du kan använda motsvarande kommandon om du använder andra verktyg som tnc, pingoch så vidare.

Hämta en nätverksspårning om föregående steg inte hjälper och analyserar den med hjälp av verktyg som Wireshark. Kontakta Microsoft Support om det behövs.

Tjänstuppgraderingar/omstarter

Tillfälliga anslutningsproblem kan uppstå på grund av uppgraderingar och omstarter av serverdelstjänsten. När de inträffar kan du se följande symtom:

  • Det kan finnas en minskning av inkommande meddelanden/begäranden.
  • Loggfilen kan innehålla felmeddelanden.
  • Programmen kan vara frånkopplade från tjänsten i några sekunder.
  • Begäranden kan tillfälligt begränsas.

Om programkoden använder SDK är återförsöksprincipen redan inbyggd och aktiv. Programmet återansluter utan betydande påverkan på programmet/arbetsflödet. Genom att fånga dessa tillfälliga fel, säkerhetskopiera och sedan försöka igen ser du till att koden är motståndskraftig mot dessa tillfälliga problem.

Nästa steg

Mer information finns i följande artiklar: