Compartir a través de

如何排查连接性问题和消息传送问题

  • Artículo

本指南介绍了多种有助于执行自我诊断的方法，用于直接查明根本原因或缩小问题的范围。 自我诊断结果也很有用，可以将其报告给我们进行进一步的调查。

首先，你需要从 Azure 门户中检查 Azure SignalR 服务（也称为 ASRS）配置为哪种 ServiceMode。

ServiceMode

其次，需要捕获服务跟踪以进行故障排除。 若要了解如何捕获跟踪，请参阅如何捕获服务跟踪。

如何捕获服务跟踪

为了简化故障排除过程，Azure SignalR 服务提供了实时跟踪工具来公开有关连接和消息类别的服务跟踪 。 跟踪包括但不限于已连接/已断开连接事件以及已收到消息/已留言事件。 使用实时跟踪工具，可以对实时跟踪执行捕获、查看、排序、筛选和导出操作。 有关详细信息，请参阅如何使用实时跟踪工具。

默认模式故障排除

当 ASRS 处于默认模式时，有三个角色：客户端、服务器和服务：

  • 客户端：客户端代表连接到 ASRS 的客户端。 在本指南中，连接客户端和 ASRS 的持久连接称为客户端连接。

  • 服务器：服务器代表为客户端协商提供服务并承载着 SignalR Hub 逻辑的服务器。 在本指南中，服务器与 ASRS 之间的持久连接称为服务器连接。

  • 服务：在本指南中，“服务”是 ASRS 的短名称。

有关整个体系结构和工作流的详细介绍，请参阅 Azure SignalR 服务的内部机制。

有多种方式可帮助你缩小问题范围。

  • 如果问题正在发生或者是可重现的，则直接了当的方式是查看正在产生的流量。

  • 如果问题很难重现，则跟踪和日志可能会有所帮助。

如何查看流量并缩小问题范围

捕获正在产生的流量是缩小问题范围的最直接了当的方式。 你可以使用下述选项捕获网络跟踪：

客户端请求

对于 SignalR 持久性连接，它首先 /negotiate 到你的托管应用服务器，然后重定向到 Azure SignalR 服务，最后建立到 Azure SignalR 服务的实际持久性连接。 有关详细步骤，请参阅 Azure SignalR 服务的内部机制。

在获取的客户端网络跟踪中，检查哪个请求失败以及返回了什么状态代码和响应，并在故障排除指南中查找解决方案。

服务器请求数

SignalR 服务器维护服务器与服务之间的服务器连接。 当应用服务器启动时，它会启动到 Azure SignalR 服务的 WebSocket 连接。 所有客户端流量都通过 Azure SignalR 服务路由到这些服务器连接，然后被分派到 Hub。 当某个服务器连接断开时，路由到此服务器连接的客户端会受影响。 我们的 Azure SignalR SDK 有一个“始终重试”逻辑，它以最多 1 分钟的延迟重新连接服务器连接，以最大程度地降低影响。

服务器连接可能会由于以下原因而断开：网络不稳定、Azure SignalR 服务的定期维护，或者你的托管应用服务器进行更新/维护。 只要客户端存在断开连接/重新连接机制，影响就会很小，就像任何客户端导致的断开连接-重新连接一样。

查看服务器端网络跟踪，找到服务器连接断开或被服务拒绝的状态代码和错误详细信息。 在故障排除指南中查找根本原因。

如何添加日志

日志可用来诊断问题并监视运行状态。

如何启用客户端日志

客户端日志记录体验与使用自承载 SignalR 时的体验完全相同。

为 ASP.NET Core SignalR 启用客户端日志记录
为 ASP.NET SignalR 启用客户端日志记录

如何启用服务器端日志

为 ASP.NET Core SignalR 启用服务器端日志记录

ASP.NET Core SignalR 的服务器端日志记录与 ASP.NET Core Framework 中提供的基于 ILogger 的日志记录集成。 你可以使用 ConfigureLogging 来启用服务器端日志记录，示例用法如下：

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Azure SignalR 的记录器类别始终以 Microsoft.Azure.SignalR 开头。 若要从 Azure SignalR 启用详细日志，请在 appsettings.json 文件中将前面的前缀配置为 Information 级别，如下所示：

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Information",
            ...
        }
    }
}

检查是否记录了任何异常的警告/错误日志。

为 ASP.NET SignalR 启用服务器端跟踪

使用 >= 1.0.0 的 SDK 版本时，可以通过将以下内容添加到 web.config 来启用跟踪：（详细信息）

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

检查是否记录了任何异常的警告/错误日志。

如何在 Azure SignalR 服务内启用日志

你还可以为 Azure SignalR 服务启用诊断日志，这些日志提供连接到 Azure SignalR 服务的每个连接的详细信息。

无服务器模式故障排除

当 ASRS 处于无服务器模式时，只有 ASP.NET Core SignalR 支持 Serverless 模式，ASP.NET SignalR 不支持此模式。

若要在 Serverless 模式下诊断连接性问题，最直接了当的方式是查看客户端流量。 启用客户端日志和服务端日志可能也会有所帮助。

经典模式故障排除

Classic 模式已过时，不建议使用。 在经典模式下，Azure SignalR 服务使用已连接的服务器连接来确定当前服务是处于 default 模式还是 serverless 模式。 经典模式可能会导致出现中间客户端连接性问题，因为当所有已连接的服务器连接突然断开（例如，由于网络不稳定而断开）时，Azure SignalR 会认为它现在已切换到 serverless 模式，因此在此期间连接的客户端永远不会路由到托管应用服务器。 如果你有托管应用服务器，但某些客户端永远不会到达应用服务器端，请启用服务端日志，并检查是否有任何记录为 ServerlessModeEntered 的客户端。 如果看到任何这些客户端，请中止客户端连接，然后让客户端重启。

排查 classic 模式连接性问题和消息传送问题与排查默认模式问题类似。

服务运行状况

你可以检查运行状况 API 来查看服务运行状况。

  • 请求：GET https://{instance_name}.signalr.azure.cn/api/v1/health

  • 响应状态代码：

    • 200：正常。
    • 503：你的服务不正常。 您可以：
      • 等待几分钟以便自动恢复。
      • 检查 IP 地址是否与门户中的 IP 地址相同。
      • 或者重启实例。
      • 如果上述所有选项都不起作用，请通过在 Azure 门户中添加新的支持请求来联系我们。

详细了解灾难恢复。

后续步骤

在本指南中，你已了解如何排查连接性问题和消息传送问题。 你还可以了解如何处理常见问题。

故障排除指南