如何針對連線與訊息傳遞問題進行疑難排解
本指南介紹數種方式來協助進行自我診斷，以直接找出根本原因或縮小問題範圍。 在向我們回報以供進一步調查時，自我診斷結果也很有用。
首先，您必須從 ServiceMode 為 Azure SignalR Service (也稱為 ASRS) 設定的 Azure 入口網站，進行檢查。
針對
Default模式，請參閱預設模式疑難排解針對
Serverless模式，請參閱無伺服器模式疑難排解針對
Classic模式，請參閱傳統模式疑難排解
其次，您需要擷取服務追蹤以進行疑難排解。 如需了解如何擷取追蹤，請參閱如何擷取服務追蹤。
如何擷取服務追蹤
為了簡化疑難排解流程，Azure SignalR 服務會提供即時追蹤工具，來公開連線和傳訊類別上的服務追蹤。 追蹤包含但不限於連線/中斷連線的事件，以及已接收/離開訊息的事件。 使用即時追蹤工具，您可以擷取、檢視、排序、篩選和匯出即時追蹤。 如需詳細資訊，請參閱如何使用即時追蹤工具。
預設模式疑難排解
當 ASRS 處於預設模式時，會有三個角色：用戶端、伺服器和服務：
用戶端：用戶端代表連線至 ASRS 的用戶端。 連線用戶端和 ASRS 的持續性連線，在本指南中稱為用戶端連線。
伺服器：伺服器代表提供用戶端交涉和主機 SignalR
Hub邏輯的伺服器。 在本指南中，伺服器與 ASRS 之間的持續性連線，稱為伺服器連線。服務：服務是本指南中 ASRS 的簡稱。
如需整個架構和工作流程的詳細簡介，請參閱 Azure SignalR Service 的內部。
有數種方式可協助您縮小問題範圍。
如果問題以正確方式發生或可重現，直接的縮小方式就是檢視進行中的流量。
如果問題難以重現，則可使用追蹤和記錄。
如何檢視流量並縮小問題範圍
擷取進行中的流量是縮小問題範圍最直接的方式。 您可以使用以下所述的選項來擷取網路追蹤：
用戶端要求
若為 SignalR 持續性連線，會先 /negotiate 連線到託管的應用程式伺服器，然後重新導向至 Azure SignalR 服務，再建立與 Azure SignalR 服務的實際持續性連線。 如需詳細步驟，請參閱 Azure SignalR Service 的內部。
使用用戶端連線追蹤，即可查看狀態碼與回應內容，得知哪項要求失敗，並可查看疑難排解指南中的解決方案。
伺服器要求
SignalR 伺服器會維持伺服器和服務之間的伺服器連線。 應用程式伺服器啟動時，會啟動與 Azure SignalR 服務的 WebSocket 連線。 所有用戶端流量都會透過 Azure SignalR 服務路由傳送至這些伺服器連線，然後分派至 Hub。 伺服器連線卸除時，路由至此伺服器連線的用戶端會受到影響。 我們的 Azure SignalR SDK 有一個邏輯「永遠重試」，可重新連接伺服器連線，最多可延遲 1 分鐘，將影響降至最低。
伺服器連線可能會因為網路不穩定或定期維護 Azure SignalR Service，或託管的應用程式伺服器更新/維護而中斷。 只要用戶端具有中斷連線/重新連線機制，其影響就會像任何用戶端造成的中斷連線-重新連線一樣為最小影響。
檢視伺服器端網路追蹤，以尋找伺服器連線卸除，或遭到服務拒絕的狀態碼和錯誤詳細資料。 在疑難排解指南中尋找根本原因。
如何新增記錄
記錄有助於診斷問題並監視執行中狀態。
如何啟用用戶端記錄
用戶端記錄體驗與使用自我裝載 SignalR 時完全相同。
啟用 ASP.NET Core SignalR 的用戶端記錄
啟用 ASP.NET SignalR 的用戶端記錄
如何啟用伺服器端記錄
啟用 ASP.NET Core SignalR 的伺服器端記錄
ASP.NET Core SignalR 的伺服器端記錄，與以 ASP.NET Core 架構中提供的 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 啟用伺服器端追蹤
使用 SDK 版本 >= 1.0.0 時，您可以將下列內容新增至 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 入口網站中新增支援要求，以聯絡我們。
關於災害復原的更多資訊。
下一步
在本指南中，您已了解如何針對連線能力和訊息傳遞問題進行疑難排解。 您可能也已了解如何處理常見問題。