你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
如何排查连接性问题和消息传送问题
本指南介绍了多种有助于执行自我诊断的方法，用于直接查明根本原因或缩小问题的范围。 自我诊断结果也很有用，可以将其报告给我们进行进一步的调查。
首先，你需要从 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}.service.signalr.net/api/v1/health响应状态代码：
- 200：正常。
- 503：你的服务不正常。 您可以：
- 等待几分钟以便自动恢复。
- 检查 IP 地址是否与门户中的 IP 地址相同。
- 或者重启实例。
- 如果上述所有选项都不起作用，请通过在 Azure 门户中添加新的支持请求来联系我们。
详细了解灾难恢复。
后续步骤
在本指南中，你已了解如何排查连接性问题和消息传送问题。 你还可以了解如何处理常见问题。