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

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

首先,你需要从 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 门户中添加新的支持请求来联系我们。

详细了解灾难恢复

后续步骤

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