接続とメッセージ配信に関する問題のトラブルシューティング方法

  • [アーティクル]

このガイダンスでは、自己診断を行って、根本原因を直接見つけたり、問題を絞り込んだりするのに役立つ方法をいくつか紹介します。 自己診断の結果は、より詳細な調査のために Microsoft に報告する際にも役立ちます。

最初に、Azure portal から、Azure SignalR Service (ASRS) がどの ServiceMode に構成されているかを確認する必要があります。

ServiceMode

次に、サービス トレースをキャプチャしてトラブルシューティングを行う必要があります。 トレースをキャプチャする方法については、「サービス トレースをキャプチャする方法」を参照してください。

トラブルシューティングに関する問題やフィードバックがある場合は、 お知らせください。

サービス トレースをキャプチャする方法

トラブルシューティング プロセスを省力化するために、Azure SignalR サービスには、接続性やメッセージングのカテゴリについてのサービス トレースを公開するライブ トレース ツールが用意されています。 トレースには、接続の接続イベントと切断イベント、メッセージの着信イベントと発信イベントなどが含まれます。 ライブ トレース ツールを使用すると、ライブ トレースのキャプチャ、表示、並べ替え、フィルタリング、エクスポートを実行することができます。 詳しくは、ライブ トレース ツールの使い方に関する記事をご覧ください。

トラブルシューティングに関する問題やフィードバックがある場合は、 お知らせください。

既定モードのトラブルシューティング

ASRS が "既定" モードになっている場合は、"3 つ" のロールがあります。"クライアント"、"サーバー"、"サービス" です。

  • "クライアント": "クライアント" は、ASRS に接続されているクライアントを表します。 クライアントと ASRS を接続する永続的な接続は、このガイダンスではクライアント接続と呼びます。

  • サーバー: "サーバー" は、クライアント ネゴシエーションを提供し、SignalR の Hub ロジックをホストするサーバーを表します。 そして、"サーバー" と ASRS の間の永続的な接続は、このガイダンスでは "サーバー接続" と呼びます。

  • "サービス": "サービス" は、このガイダンスでの ASRS の短い名前です。

アーキテクチャとワークフローの全体の詳しい紹介については、「Azure SignalR Service の内部構造」を参照してください。

問題の絞り込みに役立つ方法はいくつかあります。

  • 問題がまさに発生中であったり、再現可能であったりする場合、単純な方法は、動作中のトラフィックを表示することです。

  • 問題を再現するのが困難な場合は、トレースとログが役立つことがあります。

トラフィックを表示して問題を絞り込む方法

動作中のトラフィックをキャプチャすることは、問題を絞り込むための最も単純な方法です。 以下で説明しているオプションを使用して、ネットワーク トレースをキャプチャできます。

クライアントの要求

SignalR の永続的な接続の場合は、まず、ホストされているアプリ サーバーに対して /negotiate を行い、次に、Azure SignalR サービスにリダイレクトしてから、Azure SignalR サービスへの永続的な接続を実際に確立します。 詳細な手順については、「Azure SignalR Service の内部構造」を参照してください。

クライアント側のネットワーク トレースを入手したら、どの要求がどのような状態コードと応答で失敗しているかを調べて、トラブルシューティング ガイド内で解決策を探します。

サーバー要求

SignalR Server では、"サーバー" と "サービス" の間の "サーバー接続" を管理します。 アプリ サーバーが起動すると、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 portal で新しいサポート リクエストを追加してお問い合わせください。

ディザスター リカバリーの詳細を確認してください。

トラブルシューティングに関する問題やフィードバックがある場合は、 お知らせください。

次のステップ

このガイドでは、接続とメッセージ配信に関する問題のトラブルシューティング方法について学習しました。 一般的な問題を処理する方法についても学習できました。

トラブルシューティング ガイド