如何排查连接性问题和消息传送问题
本指南介绍了多种有助于执行自我诊断的方法,用于直接查明根本原因或缩小问题的范围。 自我诊断结果也很有用,可以将其报告给我们进行进一步的调查。
首先,你需要从 Azure 门户中检查 Azure SignalR 服务(也称为 ASRS)配置为哪种 ServiceMode。
对于
Default
模式,请参考默认模式故障排除对于
Serverless
模式,请参考无服务器模式故障排除对于
Classic
模式,请参考经典模式故障排除
其次,需要捕获服务跟踪以进行故障排除。 若要了解如何捕获跟踪,请参阅如何捕获服务跟踪。
如何捕获服务跟踪
为了简化故障排除过程,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 门户中添加新的支持请求来联系我们。
详细了解灾难恢复。
后续步骤
在本指南中,你已了解如何排查连接性问题和消息传送问题。 你还可以了解如何处理常见问题。