Solución de problemas de conectividad: Azure Event Hubs

Hay varias razones por las que las aplicaciones cliente no pueden conectarse a un centro de eventos. Los problemas de conectividad pueden ser permanentes o transitorios.

Si el problema se produce todo el tiempo (permanente), compruebe esta configuración y otras opciones mencionadas en la sección Solución de problemas de conectividad permanentes en este artículo.

• Cadena de conexión
• Configuración del firewall de la organización
• Configuración del firewall de IP
• Configuración de la seguridad de red (puntos de conexión de servicio, puntos de conexión privados, etc.) y mucho más

Para problemas transitorios, pruebe las siguientes opciones que pueden ayudar a solucionar los problemas. Para obtener más información, consulte Solucionar problemas de conectividad transitorios.

• Actualización a la versión más reciente del SDK
• Ejecución de comandos para comprobar los paquetes eliminados
• Obtener seguimientos de red.

Solución de problemas de conectividad permanentes

Si la aplicación no puede conectarse al centro de eventos, siga los pasos de esta sección para solucionar el problema.

Comprobación de una interrupción del servicio

Compruebe la interrupción del servicio de Azure Event Hubs en el sitio de estado del servicio de Azure.

Compruebe la cadena de conexión

Compruebe que la cadena de conexión que está usando es correcta. Consulte Obtención de una cadena de conexión de Event Hubs para obtener la cadena de conexión mediante Azure Portal, la CLI o PowerShell.

Para clientes de Kafka, compruebe que los archivos productor.config o consumer.config están configurados correctamente. Para más información, consulte Envío y recepción de mensajes con Kafka en Event Hubs.

¿Qué protocolos puedo usar para enviar y recibir eventos?

Los productores o remitentes pueden usar protocolos Advanced Messaging Queuing (AMQP), Kafka o HTTPS para enviar eventos a un centro de eventos.

Los consumidores o receptores usan AMQP o Kafka para recibir eventos de un centro de eventos. Event Hubs solo admite el modelo de extracción para que los consumidores reciban eventos de él. Incluso cuando se usan controladores de eventos para controlar eventos desde un centro de eventos, el procesador de eventos usa internamente el modelo de extracción para recibir eventos del centro de eventos.

AMQP

Puede usar el protocolo AMQP 1.0 para enviar y recibir eventos de Azure Event Hubs. AMQP proporciona una comunicación confiable, eficaz y segura para enviar y recibir eventos. Puede usarlo para streaming en tiempo real y de alto rendimiento y es compatible con la mayoría de los SDK de Azure Event Hubs.

HTTPS/API de REST

Solo puede enviar eventos a Event Hubs mediante solicitudes HTTP POST. Event Hubs no admite la recepción de eventos a través de HTTPS. Es adecuado para clientes ligeros en los que una conexión TCP directa no es factible.

Apache Kafka

Azure Event Hubs tiene un punto de conexión de Kafka integrado que admite productores y consumidores de Kafka. Las aplicaciones compiladas mediante Kafka pueden usar el protocolo Kafka (versión 1.0 o posterior) para enviar y recibir eventos de Event Hubs sin cambios en el código.

Los SDK de Azure abstraen los protocolos de comunicación subyacentes y proporcionan una manera simplificada de enviar y recibir eventos de Event Hubs mediante lenguajes como C#, Java, Python, JavaScript, etc.

¿Qué puertos es necesario abrir en el firewall?

Puede usar los siguientes protocolos con Azure Event Hubs para enviar y recibir eventos:

• Advanced Message Queuing Protocol 1.0 (AMQP)
• Protocolo de transferencia de hipertexto 1.1 con seguridad de la capa de transporte (HTTPS)
• Apache Kafka

Consulte en la siguiente tabla los puertos de salida que se deben abrir para usar estos protocolos para comunicarse con Azure Event Hubs.

Protocolo	Puertos	Detalles
AMQP	5671 y 5672	Consulte la guía del protocolo AMQP
HTTPS	443	Este puerto se usa para la API HTTP/REST y para AMQP a través de WebSockets.
Kafka	9093	Consulte Uso de Azure Event Hubs desde aplicaciones de Apache Kafka

El puerto HTTPS también es necesario para la comunicación saliente cuando se usa AMQP a través del puerto 5671, ya que varias operaciones de administración realizadas por los SDK de cliente y la adquisición de tokens desde Microsoft Entra ID (cuando se usa) se ejecutan a través de HTTPS.

Los SDK de Azure oficiales suelen usar el protocolo AMQP para enviar y recibir eventos de Event Hubs. La opción de protocolo AMQP sobre WebSockets se ejecuta a través del puerto TCP 443 como la API HTTP, pero, de lo contrario, es funcionalmente idéntica a AMQP sin modificar. Esta opción tiene una mayor latencia de conexión inicial debido a los intercambios de protocolo de enlace adicionales y una sobrecarga ligeramente mayor como compensación para compartir el puerto HTTPS. Si se selecciona este modo, el puerto TCP 443 es suficiente para la comunicación. Las opciones siguientes permiten seleccionar el modo WebSockets AMQP o AMQP:

Lenguaje	Opción
.NET	Propiedad 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 tiene una propiedad webSocketOptions.
Python	EventHubConsumerClient.transport_type con TransportType.Amqp o TransportType.AmqpOverWebSocket

¿Qué direcciones IP tengo que permitir?

Cuando trabaja con Azure, en ocasiones tiene que permitir intervalos de direcciones IP específicos o direcciones URL en el firewall o proxy corporativo para acceder a todos los servicios de Azure usa o intenta usar. Compruebe que se permite el tráfico en las direcciones IP utilizadas por Event Hubs. En el caso de las direcciones IP usadas por Azure Event Hubs, vea Intervalos de direcciones IP y etiquetas de servicio de Azure: nube pública.

Además, compruebe que se permite la dirección IP del espacio de nombres. Para buscar las direcciones IP correctas para permitirlas para las conexiones, siga estos pasos:

1. Ejecute el siguiente comando desde el símbolo del sistema:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Anote la dirección IP devuelta en Non-authoritative answer.

Si usa un espacio de nombres hospedado en un clúster anterior (basado en Cloud Services - CNAME que termina en *.cloudapp.net) y el espacio de nombres es redundante de zona, debe seguir algunos pasos adicionales. Si el espacio de nombres está en un clúster más reciente (basado en el conjunto de escalado de máquinas virtuales: CNAME que termina en *.cloudapp.azure.com) y con redundancia de zona, puede omitir los pasos siguientes.

1. En primer lugar, ejecute nslookup en el espacio de nombres.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Anote el nombre de la sección respuesta no autoritativa, que se encuentra en uno de los siguientes formatos:

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

3. Ejecute nslookup para cada uno con los sufijos s1, s2 y s3 para obtener las direcciones IP de las tres instancias que se ejecutan en tres zonas de disponibilidad.

   Nota

   La dirección IP devuelta por el comando nslookup no es una dirección IP estática. Sin embargo, permanece constante hasta que la implementación subyacente se elimine o se mueva a otro clúster.

¿Qué direcciones IP de cliente envían o reciben eventos desde mi espacio de nombres?

En primer lugar, habilite el filtrado de IP en el espacio de nombres.

A continuación, habilite los registros de diagnóstico para eventos de conexión de red virtual de Event Hubs siguiendo las instrucciones indicadas en Habilitar registros de diagnóstico. Verá la dirección IP para la que se deniega la conexión.

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

Los registros de red virtual solo se generan si el espacio de nombres permite el acceso desde direcciones IP específicas (reglas de filtro de IP). Si no quiere restringir el acceso al espacio de nombres con estas características y quiere obtener registros de red virtual para realizar un seguimiento de las direcciones IP de los clientes que se conectan al espacio de nombres de Event Hubs, puede usar la siguiente solución alternativa: Habilitar el filtrado IP y agregar los intervalos IPv4 direccionable total (0.0.0.0/1 - 128.0.0.0/1) y IPv6 (::/1 - 8000::/1).

Nota:

Actualmente no es posible determinar la IP de origen de un mensaje o evento individual.

Comprobación de que se permite la etiqueta de servicio Event Hubs en los grupos de seguridad de red

Si la aplicación se ejecuta dentro de una subred y hay un grupo de seguridad de red asociado, confirme si se permite la salida de tráfico de Internet o la etiqueta de servicio Event Hubs (EventHub). Vea Etiquetas de servicio de red virtual y busque EventHub.

Comprobar si la aplicación debe ejecutarse en una subred específica de una red virtual

Confirme que la aplicación se está ejecutando en una subred de red virtual que tiene acceso al espacio de nombres. Si no es así, ejecute la aplicación en la subred que tenga acceso al espacio de nombres o agregue la dirección IP del equipo en el que se ejecuta la aplicación al firewall de IP.

Cuando se crea un punto de conexión de servicio de red virtual para un espacio de nombres del centro de eventos, el espacio de nombres solamente acepta tráfico de la subred enlazada al punto de conexión de servicio. Hay una excepción a este comportamiento. Puede agregar direcciones IP específicas en el firewall de IP para habilitar el acceso al punto de conexión público del centro de eventos. Para obtener más información, vea Puntos de conexión de servicio de red.

Comprobar la configuración del firewall de IP para su espacio de nombres

Compruebe que el firewall de IP no bloquea la dirección IP pública de la máquina en la que se ejecuta la aplicación.

De forma predeterminada, los espacios de nombres de Azure Event Hubs son accesibles desde Internet, siempre que la solicitud venga con una autenticación y una autorización válidas. Con el firewall de IP, puede restringirlo aún más a solo un conjunto de direcciones o intervalos de direcciones IPv4 o IPv6 en notación CIDR (Enrutamiento de interdominios sin clases).

Las reglas de firewall de IP se aplican en el nivel del espacio de nombres de Event Hubs. Por lo tanto, las reglas se aplican a todas las conexiones de clientes que usan cualquier protocolo admitido. Cualquier intento de conexión desde una dirección IP que no coincida con una regla IP admitida en el espacio de nombres de Event Hubs se rechaza como no autorizado. La respuesta no menciona la regla IP. Las reglas de filtro IP se aplican en orden y la primera regla que coincida con la dirección IP determina la acción de aceptar o rechazar.

Para obtener más información, consulte Configuración de reglas de firewall de IP para un espacio de nombres de Azure Event Hubs. Para comprobar si tiene problemas de filtrado de direcciones IP, red virtual o cadena de certificados, consulte Solución de problemas relacionados con la red.

Comprobar si se puede acceder al espacio de nombres con solo un punto de conexión privado

Si el espacio de nombres de Event Hubs está configurado para ser accesible únicamente a través de un punto de conexión privado, confirme que la aplicación cliente accede al espacio de nombres a través del punto de conexión privado.

El servicio Azure Private Link permite el acceso a Azure Event Hubs a través de un punto de conexión privado en la red virtual. Un punto de conexión privado es una interfaz de red que le conecta de forma privada y segura a un servicio con la tecnología de Azure Private Link. El punto de conexión privado usa una dirección IP privada de la red virtual para incorporar el servicio de manera eficaz a su red virtual. Todo el tráfico dirigido al servicio se puede enrutar mediante el punto de conexión privado, por lo que no se necesita ninguna puerta de enlace, dispositivos NAT, conexiones de ExpressRoute o VPN ni direcciones IP públicas. El tráfico entre la red virtual y el servicio atraviesa la red troncal de Microsoft, eliminando la exposición a la red pública de Internet. Puede conectarse a una instancia de un recurso de Azure, lo que le otorga el nivel más alto de granularidad en el control de acceso.

Para obtener más información, consulte Configuración de puntos de conexión privados. Vea la sección Validación de que la conexión del punto de conexión privado funciona para confirmar que se usa un punto de conexión privado.

Solución de problemas relacionados con la red

Para solucionar problemas relacionados con la red con Event Hubs, siga estos pasos:

Desplácese a https://<yournamespacename>.servicebus.windows.net/ o use wget ir allí. Le ayudará a comprobar si tiene problemas de cadena de certificados (lo más común al usar el SDK de Java), filtrado IP o red virtual.

Un ejemplo de mensaje correcto:

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

Un ejemplo de mensaje de error:

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

Solución de problemas de conectividad transitorios

Si tiene problemas de conectividad intermitentes, consulte las sugerencias de solución de problemas de las secciones siguientes.

Usar la versión más reciente del SDK

Es posible que algunos de los problemas de conectividad transitorios se hayan corregido en las versiones posteriores del SDK de las que está usando. Asegúrese de que está usando la versión más reciente de los SDK cliente en las aplicaciones. Los SDK se han mejorado continuamente con características nuevas o actualizadas y correcciones de errores, por lo que siempre debe probar con el paquete más reciente. Compruebe las notas de la versión para conocer los problemas corregidos y las características agregadas o actualizadas.

Para obtener información sobre los SDK cliente, consulte el artículo Azure Event Hubs: SDK cliente.

Ejecutar el comando para comprobar los paquetes descartados

Si hay problemas de conectividad intermitentes, ejecute el siguiente comando para comprobar si hay paquetes descartados. Este comando intenta establecer 25 conexiones TCP diferentes cada segundo con el servicio. A continuación, puede comprobar cuántas de ellas se han realizado correctamente y cuántas han fallado y, además, ver la latencia de conexión TCP. Puede descargar la herramienta psping desde psping.

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

Puede usar comandos equivalentes si utiliza otras herramientas como tnc, ping, etc.

Realice un seguimiento de red si los pasos anteriores no ayudan y analícelo con herramientas como Wireshark. Si lo necesita, póngase en contacto con el soporte técnico de Microsoft.

Actualizaciones o reinicios del servicio

Pueden producirse problemas de conectividad transitorios debido a actualizaciones y reinicios del servicio back-end. Cuando se producen, es posible que vea los síntomas siguientes:

• Puede haber una caída en la llegada de mensajes o solicitudes entrantes.
• El archivo de registro puede contener mensajes de error.
• Puede que las aplicaciones se desconecten del servicio durante unos segundos.
• Puede que las solicitudes se limiten momentáneamente.

Si el código de aplicación usa SDK, la directiva de reintento ya está integrada y activa. La aplicación se vuelve a conectar sin un impacto significativo en la aplicación o el flujo de trabajo. La detección de estos errores transitorios, la interrupción y el posterior reintento de la llamada garantizan que el código sea resistente a estos problemas transitorios.

Pasos siguientes

Vea los artículos siguientes:

• Solución de problemas de autenticación y autorización