Condividi tramite

Risoluzione dei problemi di connettività - Hub eventi di Azure

  • Articolo

Sono diversi i motivi per cui le applicazioni client non riescono a connettersi a un hub eventi. I problemi di connettività possono essere permanenti o temporanei. Se il problema si verifica sempre (permanente), si possono controllare la stringa di connessione, le impostazioni del firewall dell'organizzazione, le impostazioni del firewall IP, le impostazioni di sicurezza di rete (endpoint di servizio, endpoint privati e così via) e altro ancora. Per i problemi temporanei, l'aggiornamento alla versione più recente dell'SDK, l'esecuzione di comandi per controllare i pacchetti rimossi e l'acquisizione di tracce di rete possono contribuire alla risoluzione dei problemi. Questo articolo fornisce suggerimenti sulla risoluzione dei problemi di connettività con l'Hub eventi di Azure.

Risolvere i problemi di connettività permanenti

Se l'applicazione non è in grado di connettersi all'hub eventi, seguire la procedura descritta in questa sezione per risolvere il problema.

Controllare se è presente un'interruzione del servizio

Verificare la presenza di un'interruzione del servizio Hub eventi di Azure nel sito di stato del servizio di Azure.

Verificare la stringa di connessione

Verificare che la stringa di connessione in uso sia corretta. Vedere Ottenere la stringa di connessione per ottenere la stringa di connessione usando il portale di Azure, l'interfaccia della riga di comando o PowerShell.

I client Kafka devono verificare che il file producer.config o consumer.config sia configurato correttamente. Per altre informazioni, vedere Inviare e ricevere messaggi con Kafka nell'Hub eventi.

Quali porte è necessario aprire nel firewall?

È possibile usare i protocolli seguenti con l'Hub eventi di Azure per inviare e ricevere eventi:

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

Vedere la tabella seguente per le porte in uscita da aprire per usare questi protocolli per comunicare con Hub eventi di Azure.

Protocollo Porte Dettagli
AMQP 5671 e 5672 Vedere Guida al protocollo AMQP
HTTPS 443 Questa porta viene usata per HTTP o API REST e per AMQP-over-WebSockets.
Kafka 9093 Vedere Usare Hub eventi da applicazioni Apache Kafka

La porta HTTPS è necessaria per le comunicazioni in uscita anche quando AMQP viene usato sulla porta 5671, poiché su HTTPS vengono eseguite diverse operazioni di gestione eseguite dagli SDK client e l'acquisizione di token da Microsoft Entra ID (se usato).

Gli SDK ufficiali di Azure usano in genere il protocollo AMQP per l'invio e la ricezione di eventi dall'Hub eventi. L'opzione di protocollo AMQP-over-WebSockets viene eseguita sulla porta TCP 443 esattamente come l'API HTTP, ma per il resto è funzionalmente identica all'AMQP normale. Questa opzione ha una latenza di connessione iniziale più elevata a causa di round trip aggiuntivi di handshake e un po' più sovraccarico come compromesso per la condivisione della porta HTTPS. Se è selezionata questa modalità, la porta TCP 443 è sufficiente per la comunicazione. Le opzioni seguenti consentono di selezionare la modalità WebSockets AMQP o AMQP normale:

Lingua Opzione
.NET Proprietà EventHubConnectionOptions.TransportType con EventHubsTransportType.AmqpTcp o EventHubsTransportType.AmqpWebSockets
Java com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype con AmqpTransportType.AMQP o AmqpTransportType.AMQP_WEB_SOCKETS
Nodo EventHubConsumerClientOptions ha una proprietà webSocketOptions.
Python EventHubConsumerClient.transport_type con TransportType.Amqp o TransportType.AmqpOverWebSocket

Quali indirizzi IP occorre consentire?

Quando si usa Azure, talvolta occorre consentire URL o intervalli di indirizzi IP specifici nel firewall o nel proxy aziendale per accedere a tutti i servizi di Azure in uso o che si sta provando a usare. Verificare che il traffico sia consentito negli indirizzi IP usati dall'Hub eventi. Per gli indirizzi IP usati dall'Hub eventi di Azure: vedere Tag del servizio e intervalli IP di Azure - Cloud pubblico.

Verificare inoltre che l'indirizzo IP per lo spazio dei nomi sia consentito. Per trovare gli indirizzi IP corretti per consentire le connessioni, attenersi alla procedura seguente:

  1. Al prompt dei comandi eseguire il comando seguente:

    nslookup <YourNamespaceName>.servicebus.windows.net

  2. Annotare l'indirizzo IP restituito in Non-authoritative answer.

Se si usa la ridondanza della zona per lo spazio dei nomi, occorre eseguire alcuni passaggi aggiuntivi:

  1. Per prima cosa, eseguire nslookup nello spazio dei nomi.

    nslookup <yournamespace>.servicebus.windows.net

  2. Annotare il nome nella sezione di risposta non autorevole, presente in uno dei formati seguenti:

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

  3. Eseguire nslookup per ciascuna di esse con suffissi S1, S2 e S3 per ottenere gli indirizzi IP di tutte e tre le istanze in esecuzione in tre zone di disponibilità.

    Nota

    L'indirizzo IP restituito dal comando nslookup non è un indirizzo IP statico. Rimane tuttavia costante fino a quando la distribuzione sottostante non viene eliminata o spostata in un cluster diverso.

Quali indirizzi IP client inviano o ricevono eventi dallo spazio dei nomi?

Abilitare innanzitutto il filtro IP nello spazio dei nomi.

Abilitare quindi i log di diagnostica per gli eventi di connessione di rete virtuale dell'Hub eventi seguendo le istruzioni riportate in Abilitare i log di diagnostica. Viene visualizzato l'indirizzo IP per cui viene negata la connessione.

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

Importante

I log di rete virtuale vengono generati solo se lo spazio dei nomi consente l'accesso da indirizzi IP specifici (regole di filtro IP). Se non si vuole limitare l'accesso allo spazio dei nomi usando queste funzionalità e si vogliono comunque ottenere i log della rete virtuale per tenere traccia degli indirizzi IP dei client che si connettono allo spazio dei nomi dell'Hub eventi, è possibile usare la soluzione alternativa seguente: Abilitare il filtro IP e aggiungere l'intervallo IPv4 indirizzabile totale (0.0.0.0/1 - 128.0.0.0/1) e l'intervallo IPv6 (::/1 - 8000::/1).

Nota

Al momento non è possibile determinare l'indirizzo IP di origine di un singolo messaggio o evento.

Verificare che il tag del servizio Hub eventi sia consentito nei gruppi di sicurezza di rete

Se l'applicazione è in esecuzione all'interno di una subnet ed è presente un gruppo di sicurezza di rete associato, verificare se è consentito Internet in uscita o se è consentito il tag del servizio Hub eventi (EventHub). Vedere Tag del servizio di rete virtuale e cercare EventHub.

Controllare se l'applicazione deve essere in esecuzione in una subnet specifica di una rete virtuale

Verificare che l'applicazione sia in esecuzione in una subnet di rete virtuale che abbia accesso allo spazio dei nomi. In caso contrario, eseguire l'applicazione nella subnet che ha accesso allo spazio dei nomi o aggiungere l'indirizzo IP del computer in cui è in esecuzione l'applicazione al firewall IP.

Quando si crea un endpoint servizio di rete virtuale per uno spazio dei nomi dell'Hub eventi, lo spazio dei nomi accetta il traffico solo dalla subnet associata all'endpoint del servizio. C'è un'eccezione a questo comportamento. È possibile aggiungere indirizzi IP specifici nel firewall IP per abilitare l'accesso all'endpoint pubblico dell'Hub eventi. Per altre informazioni, vedere Endpoint di servizio di rete.

Controllare le impostazioni del firewall IP per lo spazio dei nomi

Verificare che l'indirizzo IP pubblico del computer in cui è in esecuzione l'applicazione non sia bloccato dal firewall IP.

Per impostazione predefinita, gli spazi dei nomi di Hub eventi sono accessibili da Internet, purché la richiesta sia accompagnata da un'autenticazione e da un'autorizzazione valide. Con il firewall IP, è possibile limitarlo ulteriormente a un set di indirizzi IPv4 o IPv6, o intervalli di indirizzi in notazione CIDR (Classless Inter-Domain Routing).

Le regole del firewall IP vengono applicate a livello dello spazio dei nomi di Hub eventi. Vengono pertanto applicate a tutte le connessioni provenienti dai client con qualsiasi protocollo supportato. Qualsiasi tentativo di connessione proveniente da un indirizzo IP che non corrisponde a una regola di indirizzi IP consentiti nello spazio dei nomi dell'Hub eventi viene rifiutato come non autorizzato. Nella risposta non viene fatto riferimento alla regola IP. Le regole del filtro IP vengono applicate in ordine e la prima regola corrispondente all'indirizzo IP determina l'azione di accettazione o rifiuto.

Per altre informazioni, vedere Configurare le regole del firewall IP per uno spazio dei nomi dell'Hub eventi di Azure. Per verificare se sono presenti problemi di filtro IP, rete virtuale o catena di certificati, vedere Risolvere i problemi relativi alla rete.

Controllare se è possibile accedere allo spazio dei nomi usando solo un endpoint privato

Se lo spazio dei nomi dell'Hub eventi è configurato per essere accessibile solo tramite endpoint privato, verificare che l'applicazione client acceda allo spazio dei nomi tramite l'endpoint privato.

Il servizio collegamento privato di Azure consente di accedere all'Hub eventi di Azure tramite un endpoint privato nella rete virtuale. Un endpoint privato è un'interfaccia di rete che connette privatamente e in modo sicuro a un servizio basato su Collegamento privato di Azure. L'endpoint privato usa un indirizzo IP privato della rete virtuale, introducendo efficacemente il servizio nella rete virtuale. Tutto il traffico verso il servizio può essere instradato tramite l'endpoint privato, quindi non sono necessari gateway, dispositivi NAT, ExpressRoute o connessioni VPN oppure indirizzi IP pubblici. Il traffico tra la rete virtuale e il servizio attraversa la rete backbone Microsoft, impedendone l'esposizione alla rete Internet pubblica. È possibile connettersi a un'istanza di una risorsa di Azure, garantendo il massimo livello di granularità nel controllo di accesso.

Per altre informazioni, vedere Configurare gli endpoint privati. Vedere la sezione Verificare il funzionamento della connessione all'endpoint privato per verificare che venga usato un endpoint privato.

Per risolvere i problemi relativi alla rete con l'Hub eventi, attenersi alla procedura seguente:

Sfogliare a wgethttps://<yournamespacename>.servicebus.windows.net/. Consente di verificare se si verificano problemi di filtro IP o rete virtuale o catena di certificati (più comune quando si usa l'SDK Java).

Esempio di messaggio completato:

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

Esempio di messaggio di errore:

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

Risolvere i problemi di connettività temporanei

Se si verificano problemi di connettività intermittenti, vedere le sezioni seguenti per suggerimenti per la risoluzione dei problemi.

Usare la versione più recente dell'SDK client

Alcuni dei problemi di connettività temporanei potrebbero essere stati risolti nelle versioni successive dell'SDK rispetto a quelle in uso. Assicurarsi di usare la versione più recente degli SDK client nelle proprie applicazioni. Gli SDK vengono costantemente migliorati con funzionalità e correzioni di bug nuove o aggiornate, quindi eseguire sempre test con il pacchetto più recente. Controllare le note sulla versione per individuare i problemi risolti e le funzionalità aggiunte o aggiornate.

Per informazioni sugli SDK client, vedere l'articolo Hub eventi di Azure - SDK client.

Eseguire il comando per controllare i pacchetti rimossi

Quando si verificano problemi di connettività intermittenti, eseguire il comando seguente per verificare se sono presenti pacchetti rimossi. Questo comando tenterà di stabilire 25 connessioni TCP diverse al servizio ogni 1 secondo. Sarà quindi possibile verificare quanti di essi hanno avuto esito positivo/negativo e vedere anche la latenza della connessione TCP. È possibile scaricare lo strumento psping da qui.

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

È possibile usare comandi equivalenti se si usano altri strumenti, ad esempio tnc, ping e così via.

Ottenere una traccia di rete se i passaggi precedenti non sono utili e analizzarli usando strumenti come Wireshark. Contattare il Supporto tecnico Microsoft, se necessario.

Aggiornamenti o riavvii del servizio

Potrebbero verificarsi problemi di connettività temporanei a causa di aggiornamenti e riavvii del servizio back-end. Quando si verificano, è possibile che vengano visualizzati i sintomi seguenti:

  • Potrebbe verificarsi un calo di messaggi o richieste in ingresso.
  • Il file di log potrebbe contenere messaggi di errore.
  • Le applicazioni potrebbero essere disconnesse dal servizio per alcuni secondi.
  • Le richieste potrebbero essere momentaneamente limitate.

Se il codice dell'applicazione usa l'SDK, i criteri di ripetizione dei tentativi sono già incorporati e attivi. L'applicazione si riconnette senza alcun impatto significativo sull'applicazione o flusso di lavoro. Rilevare questi errori temporanei, eseguire il back-off e quindi ripetere la chiamata garantisce che il codice sia resiliente a questi problemi temporanei.

Passaggi successivi

Fai riferimento ai seguenti articoli: