Résoudre les problèmes de connectivité - Azure Event Hubs

Article
06/14/2024

Il existe plusieurs raisons pour lesquelles des applications clientes peuvent ne pas parvenir à se connecter à un Event Hub. Les problèmes de connectivité peuvent être permanents ou transitoires. Si le problème se produit tout le temps (permanent), vous souhaiterez peut-être vérifier la chaîne de connexion, les paramètres de pare-feu de votre organisation, les paramètres du pare-feu IP, les paramètres de sécurité réseau (points de terminaison de service, points de terminaison privés, etc.), entre autres. Pour les problèmes temporaires, la mise à niveau vers la dernière version du kit de développement logiciel (SDK), l’exécution de commandes pour vérifier les paquets ignorés et l’obtention de traces réseau peuvent vous aider à résoudre les problèmes. Cet article fournit des conseils sur la résolution des problèmes de connectivité avec Azure Event Hubs.

Résoudre les problèmes de connectivité permanents

Si l’application n’est pas en mesure de se connecter à Event Hub du tout, suivez les étapes de cette section pour résoudre le problème.

Vérifier s’il y a une panne de service

Vérifiez s’il y a une panne du service Azure Event Hubs sur le Site d’état du service Azure.

Vérifier la chaîne de connexion

Vérifiez que la chaîne de connexion est que vous utilisez est correcte. Consultez Obtenir la chaîne de connexion pour obtenir la chaîne de connexion à l’aide du portail Azure, de l’interface CLI ou de PowerShell.

Pour les clients Kafka, vérifiez que les fichiers producer.config ou consumer.config files sont configurés correctement. Pour plus d’informations, consultez Envoyer et recevoir des messages avec Kafka dans Event Hubs.

Quels ports du pare-feu dois-je ouvrir ?

Vous pouvez utiliser les protocoles suivants avec Azure Event Hubs pour envoyer et recevoir des événements :

Advanced Message Queuing Protocol 1.0 (AMQP)
Protocole de transfert hypertexte 1.1 avec le protocole HTTPS (Transport Layer Security)
Apache Kafka

Consultez le tableau suivant pour savoir quels ports de sortie vous devez ouvrir afin d’utiliser ces protocoles dans le but de communiquer avec Azure Event Hubs.

Protocol	Ports	Détails
AMQP	5671 et 5672	Consultez le Guide du protocole AMQP
HTTPS	443	Ce port est utilisé pour l’API HTTP/REST et pour AMQP sur WebSockets.
Kafka	9093	Voir Utiliser Azure Event Hubs à partir d’applications Apache Kafka

Le port HTTPS est nécessaire pour la communication sortante quand AMQP est utilisé sur le port 5671, car plusieurs opérations de gestion effectuées par les SDK clients et l’acquisition de jetons à partir de Microsoft Entra ID (le cas échéant) s’exécutent sur HTTPS.

Les kits SDK officiels Azure utilisent généralement le protocole AMQP pour envoyer et recevoir des messages d’Event Hubs. L’option de protocole AMQP sur WebSockets s’exécute sur le port TCP 443, tout comme l’API HTTP, mais son fonctionnement est identique au mode AMQP classique. Cette option présente une latence de connexion initiale plus élevée en raison d’allers-retours supplémentaires pour l’établissement d’une liaison et d’une surcharge légèrement plus importante en compensation du partage du port HTTPS. Si ce mode est sélectionné, le port TCP 443 s’avère suffisant à des fins de communication. Les options suivantes permettent de sélectionner le mode AMQP classique ou le mode AMQP WebSockets :

Language	Option
.NET	Propriété EventHubConnectionOptions.TransportType avec EventHubsTransportType.AmqpTcp ou EventHubsTransportType.AmqpWebSockets
Java	com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype avec AmqpTransportType.AMQP ou AmqpTransportType.AMQP_WEB_SOCKETS
Nœud	EventHubConsumerClientOptions possède une propriété `webSocketOptions`.
Python	EventHubConsumerClient.transport_type avec TransportType.Amqp ou TransportType.AmqpOverWebSocket

Quelles adresses IP dois-je autoriser ?

Lorsque vous utilisez Azure, vous devez parfois autoriser des plages d’adresses IP ou des URL spécifiques dans votre pare-feu ou proxy d’entreprise pour accéder à tous les services Azure que vous utilisez ou essayez d’utiliser. Vérifiez que le trafic est autorisé sur les adresses IP utilisées par Event Hubs. Pour les adresses IP utilisées par Azure Event Hubs : consultez le document Plages d’adresses IP Azure et balises de service – Cloud public.

Vérifiez également que l’adresse IP de votre espace de noms est autorisée. Pour trouver les adresses IP à autoriser pour vos connexions, procédez comme suit :

Exécutez la commande suivante depuis une invite de commandes :
```
nslookup <YourNamespaceName>.servicebus.windows.net
```
Notez l’adresse IP renvoyée dans Non-authoritative answer.

Si vous utilisez un espace de noms hébergé dans un cluster plus ancien (basé sur Services cloud – CNAME se terminant par *.cloudapp.net) et que l’espace de noms est redondant interzone, vous devez effectuer les quelques étapes supplémentaires ci-dessous. Si votre espace de noms se trouve sur un cluster plus récent (basé sur Virtual Machine Scale Set (VMSS) – CNAME se terminant par *.cloudapp.azure.com) et redondant interzone, vous pouvez ignorer les étapes ci-dessous.

Tout d’abord, exécutez nslookup sur l’espace de noms.
```
nslookup <yournamespace>.servicebus.windows.net
```
Notez le nom dans la section Réponse ne faisant pas autorité, qui se présente dans l’un des formats suivants :
```
<name>-s1.cloudapp.net
<name>-s2.cloudapp.net
<name>-s3.cloudapp.net
```
Exécutez nslookup pour chacun d’eux avec des suffixes s1, s2 et s3 pour obtenir les adresses IP des 3 instances en cours d’exécution dans 3 zones de disponibilité.

Notes

L’adresse IP retournée par la commande nslookup n’est pas une adresse IP statique. Toutefois, elle reste constante jusqu’à ce que le déploiement sous-jacent soit supprimé ou déplacé vers un autre cluster.

Quelles adresses IP clientes envoient ou reçoivent des événements vers/depuis mon espace de noms ?

Tout d’abord, activez le Filtrage IP sur l’espace de noms.

Activez ensuite les journaux de diagnostic pour Événements de connexion au réseau virtuel Event Hubs en suivant les instructions dans Activer les journaux de diagnostic. Vous voyez l’adresse IP pour laquelle la connexion est refusée.

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

Important

Les journaux de réseau virtuel ne sont générés que si l’espace de noms autorise l’accès provenant d’adresses IP spécifiques (règles de filtre d’adresse IP). Si vous souhaitez obtenir des journaux de réseau virtuel pour suivre l’adresse IP des clients qui se connectent à l’espace de noms Event Hubs sans pour autant restreindre l’accès à votre espace de noms à l’aide de ces fonctionnalités, vous pouvez appliquer la solution de contournement suivante : Activer le filtrage d’adresse IP, et ajoutez la plage IPv4 adressable totale (0.0.0.0/1 - 128.0.0.0/1) et la plage IPv6 (::/1 - 8000::/1).

Remarque

Actuellement, il n’est pas possible de déterminer l’adresse IP source d’un message ou d’un événement individuel.

Vérification du fait que l’étiquette de service Event Hubs est autorisée dans les groupes de sécurité réseau

Si votre application s’exécute à l’intérieur d’un sous-réseau auquel est associé un groupe de sécurité réseau, confirmez si le trafic sortant Internet ou l’étiquette de service Event Hubs (EventHub) est autorisé. Consultez Balises de service du réseau virtuel et recherchez EventHub.

Vérifier si l’application doit être en exécutée sur un sous-réseau spécifique d’un réseau virtuel

Vérifiez que votre application s’exécute sur un sous-réseau de réseau virtuel qui a accès à l’espace de noms. Si ce n’est pas le cas, exécutez l’application dans le sous-réseau qui a accès à l’espace de noms ou ajoutez l’adresse IP de la machine sur laquelle l’application s’exécute au pare-feu IP.

Lorsque vous créez un point de terminaison de service de réseau virtuel pour un espace de noms Event Hub, l’espace de noms accepte le trafic uniquement à partir du sous-réseau qui est lié au point de terminaison du service. Toutefois, il existe une exception à ce comportement. Vous pouvez ajouter des adresses IP spécifiques dans le pare-feu IP pour permettre l’accès au point de terminaison public du hub d’événements. Pour plus d’informations, consultez Points de terminaison de service réseau.

Vérifiez les paramètres de pare-feu IP pour votre espace de noms

Vérifiez que l’IP publique de la machine sur laquelle l’application s’exécute n’est pas bloquée par le pare-feu IP.

Par défaut, les espaces de noms Event Hubs sont accessibles sur Internet tant que la demande s’accompagne d’une authentification et d’une autorisation valides. Avec le pare-feu IP, vous pouvez les limiter à un ensemble d’adresses IPv4 ou IPv6 ou de plages d’adresses dans la notation CIDR (Classless InterDomain Routing).

Les règles de pare-feu IP sont appliquées au niveau de l’espace de noms Event Hubs. Par conséquent, les règles s’appliquent à toutes les connexions de clients utilisant un protocole pris en charge. Toute tentative de connexion à partir d’une adresse IP qui ne correspond pas à une règle IP autorisée dans l’espace de noms Event Hubs est rejetée comme étant non autorisée. La réponse ne mentionne pas la règle IP. Les règles de filtre IP sont appliquées dans l’ordre et la première règle qui correspond à l’adresse IP détermine l’action d’acceptation ou de rejet.

Pour plus d'informations, consultez Configuration des règles de pare-feu IP pour un espace de noms Azure Event Hubs. Pour vérifier si vous avez des problèmes de filtrage IP, de réseau virtuel ou de chaîne de certificats, consultez Résoudre les problèmes liés au réseau.

Vérifier si l’espace de noms est accessible uniquement à l’aide d’un point de terminaison privé

Si l’espace de noms Event Hubs est configuré pour être accessible uniquement par le biais d’un point de terminaison privé, vérifiez que l’application cliente accède à l’espace de noms sur le point de terminaison privé.

Le service Azure Private Link vous permet d’accéder à Azure Event Hubs sur un point de terminaison privé de votre réseau virtuel. Un point de terminaison privé est une interface réseau qui vous permet de vous connecter de façon privée et sécurisée à un service basé sur Azure Private Link. Le point de terminaison privé utilise une adresse IP privée de votre réseau virtuel, plaçant de fait le service dans votre réseau virtuel. Sachant que l’ensemble du trafic à destination du service peut être routé via le point de terminaison privé, il n’y a aucun besoin de passerelles, d’appareils NAT, de connexions ExpressRoute ou VPN ou d’adresses IP publiques. Le trafic entre votre réseau virtuel et le service transite par le réseau principal de Microsoft, éliminant ainsi toute exposition à l’Internet public. Vous pouvez vous connecter à une instance d’une ressource Azure, ce qui vous donne le plus haut niveau de granularité en matière de contrôle d’accès.

Pour plus d’informations, consultez Configurer des points de terminaison privés. Reportez-vous à la section Valider le fonctionnement de la connexion au point de terminaison privé pour confirmer qu’un point de terminaison privé est utilisé.

Pour résoudre les problèmes liés au réseau avec Event Hubs, procédez comme suit :

Accédez à wget ou utilisez https://<yournamespacename>.servicebus.windows.net/. Cet outil facilite les vérifications quand vous rencontrez des problèmes avec le filtrage des adresses IP, le réseau virtuel ou les chaînes de certificats (problème fréquent avec le SDK Java).

Voici un exemple de message de réussite :

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

Voici un exemple de message d’échec :

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

Résoudre les problèmes de connectivité temporaires

Si vous rencontrez des problèmes de connectivité intermittents, consultez les sections suivantes pour obtenir des conseils de dépannage.

Utiliser la dernière version du kit de développement logiciel (SDK) client

Certains problèmes de connectivité temporaires ont peut-être été résolus dans les versions ultérieures du kit de développement logiciel (SDK) par rapport à celui que vous utilisez. Vérifiez que vous utilisez la dernière version des kits de développement logiciel (SDK) clients dans vos applications. Les kits de développement logiciel (SDK) sont améliorés en permanence avec des fonctionnalités nouvelles ou mises à jour et des correctifs de bogues. Consultez les notes de publication concernant les problèmes résolus et les fonctionnalités ajoutées/mises à jour.

Pour plus d’informations sur les kits de développement logiciel (SDK) clients, consultez l’article Azure Event Hubs - Kits de développement logiciel (SDK).

Exécutez la commande pour vérifier les paquets ignorés

Si vous constatez des problèmes de connectivité intermittents, exécutez la commande suivante pour détecter les paquets supprimés. Cette commande essaye d’établir 25 connexions TCP différentes au service toutes les secondes. Ensuite, vous pouvez vérifier le nombre d’entre elles ayant réussi ou échoué, ainsi que la latence de connexion TCP. Vous pouvez télécharger l’outil psping à partir d’psping.

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

Vous pouvez utiliser des commandes équivalentes dans d’autres outils, par exemple tnc, ping, etc.

Si les étapes précédentes n’ont pas résolu le problème, obtenez une trace réseau et analysez-la à l’aide d’un outil tel que Wireshark. Contactez le support Microsoft si nécessaire.

Mises à niveau/redémarrages du service

Des problèmes de connectivité temporaires risquent de se produire en raison de mises à niveau et de redémarrages du service back-end. Lorsqu’ils se produisent, vous pouvez observer les symptômes suivants :

Il peut y avoir une chute des messages/requêtes entrantes.
Le fichier journal peut contenir des messages d’erreur.
Les applications peuvent être déconnectées du service pendant quelques secondes.
Les requêtes peuvent être momentanément limitées.

Si le code d’application utilise le kit de développement logiciel (SDK), la stratégie de nouvelle tentative est déjà intégrée et active. L’application se reconnecte sans impact significatif sur l’application/le workflow. Le fait d’intercepter ces erreurs temporaires, d’effectuer une sauvegarde et une nouvelle tentative d’appel permet de garantir la résilience de votre code à ces problèmes temporaires.

Étapes suivantes

Voir les articles suivants :

Résoudre les problèmes d’authentification et d’autorisation

Partager via