排查连接问题 - Azure 事件中心

项目
03/20/2024

客户端应用程序无法连接到事件中心的原因有很多。连接问题可能是永久性的或暂时性的。如果问题一直发生（永久性的），则可能需要检查连接字符串、组织的防火墙设置、IP 防火墙设置、网络安全设置（服务终结点、专用终结点等），等等。对于暂时性问题，升级到最新版本的 SDK、运行命令来检查丢弃的数据包以及获取网络跟踪可能有助于解决问题。本文提供了排查 Azure 事件中心的连接问题的技巧。

排查永久性连接问题

如果应用程序根本无法连接到事件中心，请按此部分的步骤操作来解决问题。

检查是否存在服务中断

在 Azure 服务状态站点上检查是否存在 Azure 事件中心服务中断的情况。

验证连接字符串

验证你使用的连接字符串是否正确。请参阅获取连接字符串，以便使用 Azure 门户、CLI 或 PowerShell 获取连接字符串。

对于 Kafka 客户端，请验证是否正确配置了 producer.config 或 consumer.config 文件。有关详细信息，请参阅在事件中心内使用 Kafka 发送和接收消息。

需要在防火墙上打开哪些端口？

可以将以下协议与 Azure 事件中心配合使用，以便发送和接收事件：

高级消息队列协议 1.0 (AMQP)
具有传输层安全性的超文本传输协议 1.1 (HTTPS)
Apache Kafka

请查看下表，了解需要打开哪些出站端口，以便使用这些协议与 Azure 事件中心通信。

协议	端口	详细信息
AMQP	5671 和 5672	请参阅 AMQP 协议指南
HTTPS	443	此端口用于 HTTP/REST API 和 AMQP-over-WebSockets。
Kafka	9093	请参阅使用 Kafka 应用程序中的事件中心

在通过端口 5671 使用 AMQP 时，还需要使用 HTTPS 端口进行出站通信，因为客户端 SDK 执行的一些管理操作和从 Microsoft Entra ID（使用时）获取令牌的操作是通过 HTTPS 运行的。

正式的 Azure SDK 通常使用 AMQP 协议通过事件中心发送和接收事件。与 HTTP API 一样，AMQP-over-WebSockets 协议选项通过端口 TCP 443 运行，但在功能上与普通 AMQP 相同。由于额外的握手往返，此选项的初始连接延迟较高，并且作为共享 HTTPS 端口的折衷方案，此选项的开销略高。如果选择此模式，TCP 端口 443 足以进行通信。以下选项允许选择普通 AMQP 或 AMQP WebSockets 模式：

语言	选项
.NET	具有 EventHubsTransportType.AmqpTcp 或 EventHubsTransportType.AmqpWebSockets 的 EventHubConnectionOptions.TransportType 属性
Java	具有 AmqpTransportType.AMQP 或 AmqpTransportType.AMQP_WEB_SOCKETS 的 com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype
节点	EventHubConsumerClientOptions 具有 `webSocketOptions` 属性。
Python	具有 TransportType.Amqp 或 TransportType.AmqpOverWebSocket 的 EventHubConsumerClient.transport_type

需要允许哪些 IP 地址？

使用 Azure 时，有时必须在公司防火墙或代理中允许特定的 IP 地址范围或 URL 才能访问正在使用或尝试使用的所有 Azure 服务。确认在事件中心使用的 IP 地址上是否允许该流量。有关 Azure 事件中心使用的 IP 地址：请参阅 Azure IP 范围和服务标记 - 公有云。

另外，请验证是否允许你的命名空间的 IP 地址。若要查找允许你的连接的正确 IP 地址，请执行以下步骤：

从命令提示符处运行以下命令：

nslookup <YourNamespaceName>.servicebus.chinacloudapi.cn

记下 Non-authoritative answer 中返回的 IP 地址。

如果对命名空间使用区域冗余，则需执行一些额外的步骤：

首先，在命名空间中运行 nslookup。

nslookup <yournamespace>.servicebus.chinacloudapi.cn

记下“非权威回答”部分中的名称，该名称采用下述格式之一：
```
<name>-s1.chinacloudapp.cn
<name>-s2.chinacloudapp.cn
<name>-s3.chinacloudapp.cn
```
为每一个运行 nslookup，使用后缀 s1、s2 和 s3 获取所有三个在三个可用性区域中运行的实例的 IP 地址。

注意

nslookup 命令返回的 IP 地址不是静态 IP 地址。但是，在删除基础部署或将其移至其他群集之前，该地址保持不变。

哪些客户端 IP 正在向/从我的命名空间发送/接收事件？

首先，在命名空间上启用 IP 筛选。

然后，按照启用诊断日志中的说明，为事件中心虚拟网络连接事件启用诊断日志。你会看到连接遭到拒绝的 IP 地址。

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

重要

只有当命名空间允许从特定的 IP 地址（IP 筛选器规则）进行访问时，才会生成虚拟网络日志。如果不希望使用这些功能限制对命名空间的访问，但仍希望获取虚拟网络日志来跟踪连接到事件中心命名空间的客户端的 IP 地址，可使用以下解决方法：启用 IP 筛选并添加整个可寻址 IPv4 范围 (0.0.0.0/1 - 128.0.0.0/1) 和 IPv6 范围 (::/1 - 8000::/1)。

注意

目前，无法确定单个消息或事件的源 IP。

验证网络安全组中是否允许使用事件中心服务标记

如果你的应用程序在子网内运行，并且存在关联的网络安全组，请确认是否允许 Internet 出站或是否允许事件中心服务标记 (EventHub)。请参阅虚拟网络服务标记并搜索 EventHub。

检查应用程序是否需要在虚拟网络的特定子网中运行

确认应用程序在有权访问该命名空间的虚拟网络子网中运行。如果没有，请在有权访问命名空间的子网中运行应用程序或将运行应用程序的计算机的 IP 地址添加到 IP 防火墙。

为事件中心命名空间创建虚拟网络服务终结点时，该命名空间仅接受来自绑定到服务终结点的子网的流量。此行为有一个例外。可以在 IP 防火墙中添加特定 IP 地址，以便启用对事件中心公共终结点的访问权限。有关详细信息，请参阅网络服务终结点。

检查命名空间的 IP 防火墙设置

确认运行应用程序的计算机的公共 IP 地址未被 IP 防火墙阻止。

默认情况下，只要请求附带有效的身份验证和授权，就可以从 Internet 访问事件中心命名空间。使用 IP 防火墙，可以将其进一步限制为采用 CIDR（无类域间路由）表示法的一组 IPv4 地址或一个 IPv4 地址。

IP 防火墙规则应用于事件中心命名空间级别。因此，这些规则适用于通过任何受支持协议从客户端发出的所有连接。如果某 IP 地址与事件中心命名空间上的允许 IP 规则不匹配，则将拒绝来自该地址的任何连接尝试并将其标记为“未经授权”。响应不会提及 IP 规则。 IP 筛选器规则将按顺序应用，与 IP 地址匹配的第一个规则决定了将执行接受操作还是执行拒绝操作。

有关详细信息，请参阅为 Azure 事件中心命名空间配置 IP 防火墙规则。若要检查你是否有 IP 筛选、虚拟网络或证书链问题，请参阅排查网络相关问题。

若要排查事件中心的网络相关问题，请执行以下步骤：

浏览到 https://<yournamespacename>.servicebus.chinacloudapi.cn/ 或对其运行 wget。这可帮助检查是否存在 IP 筛选或虚拟网络或证书链问题（使用 Java SDK 时最常见）。

成功消息的示例：

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

失败错误消息的示例：

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

排查暂时性连接问题

如果遇到间歇性连接问题，请参阅以下部分来了解排查技巧。

使用最新版本的客户端 SDK

在较高的 SDK 版本（高于你所用版本）中，一些暂时性的连接问题可能已经修复。确保在应用程序中使用最新版本的客户端 SDK。 SDK 通过新的/更新的功能和 bug 修复持续进行改进，因此请始终使用最新的包进行测试。请查看发行说明，了解已修复的问题以及已添加/更新的功能。

有关客户端 SDK 的信息，请参阅 Azure 事件中心 - 客户端 SDK 一文。

运行命令来检查丢弃的数据包

出现间歇性连接问题时，请运行以下命令，检查是否存在任何丢弃的数据包。此命令尝试每 1 秒与服务建立 25 个不同的 TCP 连接。然后，可以检查其中有多少成功/失败，还可以查看 TCP 连接延迟。可以从psping下载 psping 工具。

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

如果使用的是其他工具（如 tnc、ping 等），则可以使用等效的命令。

如果上述步骤没有帮助，请获取网络跟踪，并使用 Wireshark 之类的工具对其进行分析。如果需要，请联系 Azure 支持部门。

服务升级/重启

后端服务升级和重启可能会导致暂时性的连接问题。出现这种情况时，可能会看到以下症状：

传入的消息/请求可能会减少。
日志文件可能包含错误消息。
应用程序可能会与服务断开连接几秒钟。
请求可能会暂时受到限制。

如果应用程序代码使用 SDK，则重试策略已内置且处于活动状态。应用程序会重新连接，此操作不会对应用程序/工作流产生重大影响。捕获这些暂时性错误，后退然后重试调用，这样可确保代码能够从这些暂时性错误中复原。

后续步骤

请参阅以下文章：

排查身份验证和授权问题