Teilen über


Behandeln von Konnektivitätsproblemen und von Problemen bei der Nachrichtenübermittlung

In diesem Leitfaden werden verschiedene Methoden zur Selbstdiagnose vorgestellt, mit denen Sie direkt die Ursache ermitteln oder das Problem zumindest eingrenzen können. Das Ergebnis der Selbstdiagnose ist auch hilfreich, wenn Sie das Problem zur weiteren Untersuchung an uns melden.

Überprüfen Sie als Erstes im Azure-Portal, mit welchem Dienstmodus (ServiceMode) Azure SignalR Service (auch ASRS genannt) konfiguriert ist.

ServiceMode

Als Nächstes müssen Dienstablaufverfolgungen für die Problembehandlung erfasst werden. Informationen zum Erfassen von Ablaufverfolgungen finden Sie unter Erfassen von Dienstablaufverfolgungen.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Erfassen von Dienstablaufverfolgungen

Zur Vereinfachung des Problembehandlungsprozesses bietet der Azure SignalR-Dienst ein Tool für die Liveablaufverfolgung, mit dem Dienstablaufverfolgungen für die Kategorien Konnektivität und Messaging verfügbar gemacht werden können. Die Ablaufverfolgungen beinhalten, sind aber nicht beschränkt auf Ereignisse für verbundene/getrennte Verbindungen und Ereignisse für empfangene/verlassene Nachrichten. Mit dem Tool für die Liveablaufverfolgung können Sie Liveablaufverfolgungen erfassen, anzeigen, sortieren, filtern und exportieren. Weitere Informationen finden Sie unter So verwenden Sie das Live-Trace-Tool.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Problembehandlung für den Standardmodus

Wenn sich ASRS im Modus Standard befindet, gibt es drei Rollen: Client, Server und Dienst:

  • Client:Client steht für Clients, die mit ASRS verbunden sind. Die dauerhaften Verbindungen zwischen Client und ASRS werden in diesem Leitfaden als Clientverbindungen bezeichnet.

  • Server: Server steht für den Server, der die Clientaushandlung verarbeitet und die SignalR-Logik vom Typ Hub hostet. Die dauerhaften Verbindungen zwischen Server und ASRS werden in diesem Leitfaden als Serververbindungen bezeichnet.

  • Dienst: Dienst ist der Kurzname für ASRS in diesem Leitfaden.

Die ausführlichen Informationen zu Azure SignalR Service enthalten eine detaillierte Einführung in die gesamte Architektur und den Workflow.

Das Problem kann auf verschiedene Arten eingegrenzt werden.

  • Wenn das Problem direkt im Verlauf auftritt oder reproduzierbar ist, empfiehlt sich eine Betrachtung des aktuellen Datenverkehrs.

  • Sollte sich das Problem nicht ohne Weiteres reproduzieren lassen, können Ablaufverfolgungen und Protokolle weiterhelfen.

Anzeigen des Datenverkehrs und Eingrenzen des Problems

Die Erfassung des aktuellen Datenverkehrs ist die einfachste Möglichkeit zur Eingrenzung des Problems. Die Netzwerkablaufverfolgungen können mithilfe der unten beschriebenen Optionen erfasst werden:

Clientanforderungen

Für eine dauerhafte SignalR-Verbindung wird zunächst eine Aushandlung (/negotiate) mit dem Server Ihrer gehosteten App durchgeführt. Anschließend erfolgt eine Umleitung zum Azure SignalR-Dienst, bevor schließlich die eigentliche dauerhafte Verbindung mit dem Azure SignalR-Dienst hergestellt wird. Die detaillierten Schritte finden Sie in den ausführlichen Informationen zu Azure SignalR Service.

Überprüfen Sie anhand der clientseitigen Netzwerkablaufverfolgung, welche Anforderung nicht erfolgreich war und welcher Statuscode und welche Antwort zurückgegeben wurde, und suchen Sie im Leitfaden zur Problembehandlung nach Lösungen.

Serveranforderungen

Der Server von SignalR verwaltet die Serververbindung zwischen Server und Service. Beim Start des App-Servers wird die WebSocket-Verbindung mit dem Azure SignalR-Dienst gestartet. Der gesamte Clientdatenverkehr wird über den Azure SignalR-Dienst an diese Serververbindungen und anschließend an den Hub weitergeleitet. Wenn eine Serververbindung ausfällt, werden die an diese Serververbindung weitergeleiteten Clients beeinträchtigt. Die Azure SignalR SDK Wiederholungslogik sorgt dafür, dass die Serververbindung nach höchstens einer Minute Verzögerung wiederhergestellt wird, um die Auswirkungen zu minimieren.

Serververbindungen können aufgrund von Netzwerkinstabilität oder regulärer Wartungsmaßnahmen für Azure SignalR Service oder aufgrund von Updates/Wartungsmaßnahmen für den Server Ihrer gehosteten App ausfallen. Solange die Clientseite über den Mechanismus zum Trennen/Wiederverbinden verfügt, ist der Effekt minimal, wie bei jedem vom Client verursachten Trennen/Wiederverbinden.

Zeigen Sie die serverseitige Netzwerkablaufverfolgung an, um den Statuscode und Fehlerdetails zu finden, warum die Serververbindung unterbrochen oder vom Service abgelehnt wird. Suchen Sie in der Anleitung zur Fehlerbehebung nach der Ursache.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Hinzufügen von Protokollen

Protokolle können hilfreich sein, um Probleme zu diagnostizieren und den Ausführungsstatus zu überwachen.

Aktivieren der clientseitigen Protokollierung

Die clientseitige Protokollierung ist die gleiche wie bei der selbstgehosteten Variante von SignalR.

Aktivieren der clientseitigen Protokollierung für ASP.NET Core SignalR
Aktivieren der clientseitigen Protokollierung für ASP.NET SignalR

Aktivieren der serverseitigen Protokollierung

Aktivieren der serverseitigen Protokollierung für ASP.NET Core SignalR

Die serverseitige Protokollierung für ASP.NET Core SignalR wird in die ILogger-basierte Protokollierung integriert, der im ASP.NET Core-Framework bereitgestellt wird. Sie können die serverseitige Protokollierung mithilfe von ConfigureLogging aktivieren, wie im folgenden Beispiel gezeigt:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Protokollierungskategorien für Azure SignalR beginnen immer mit Microsoft.Azure.SignalR. Wenn Sie detaillierte Protokolle von Azure SignalR aktivieren möchten, konfigurieren Sie die Präfixe in der Datei appsettings.json mit der Ebene Information, wie hier gezeigt:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Information",
            ...
        }
    }
}

Überprüfen Sie, ob ungewöhnliche Warnungs-/Fehlerprotokolle erfasst wurden.

Aktivieren serverseitiger Ablaufverfolgungen für ASP.NET SignalR

Ab der SDK-Version >= 1.0.0können Sie Ablaufverfolgungen aktivieren, indem Sie in web.config: (Details) Folgendes hinzufügen:

<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>

Überprüfen Sie, ob ungewöhnliche Warnungs-/Fehlerprotokolle erfasst wurden.

Aktivieren von Protokollen in Azure SignalR Service

Sie können auch für Azure SignalR Service Diagnoseprotokolle aktivieren. Diese Protokolle enthalten ausführliche Informationen zu jeder Verbindung mit Azure SignalR Service.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Problembehandlung für den serverlosen Modus

Wenn sich ASRS im serverlosen Modus befindet, wird der Modus Serverless nur von ASP.NET Core SignalR unterstützt. Von ASP.NET SignalR wird dieser Modus NICHT unterstützt.

Die einfachste Methode, um Konnektivitätsprobleme im Modus Serverless zu diagnostizieren, besteht in der Betrachtung des clientseitigen Datenverkehrs. Das Aktivieren der clientseitigen Protokollierung und der serverseitigen Protokollierung kann ebenfalls hilfreich sein.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Problembehandlung für den klassischen Modus

Classic-Modus ist veraltet und wird nicht zur Verwendung empfohlen. Im klassischen Modus verwendet der Azure SignalR-Dienst die verbundenen Serververbindungen, um zu bestimmen, ob sich der aktuelle Dienst im default-Modus oder im serverless-Modus befindet. Der klassische Modus kann zu zwischenzeitlichen Problemen mit der Clientkonnektivität führen, da Azure SignalR bei einem plötzlichen Ausfall aller verbundenen Serververbindungen, z. B. aufgrund von Netzwerkinstabilität, davon ausgeht, dass es jetzt in den serverless-Modus gewechselt ist, und Clients, die während dieses Zeitraums verbunden sind, niemals weitergeleitet werden zum gehosteten App-Server. Aktivieren Sie dienstseitige Protokolle und prüfen Sie, ob Clients als ServerlessModeEntered aufgezeichnet sind, wenn Sie einen gehosteten App-Server haben. Einige Clients erreichen jedoch nie die Seite des App-Servers. Wenn eine dieser Clients angezeigt wird, beenden Sie die Clientverbindungen, und lassen Sie die Clients neu starten.

Die Behandlung von Konnektivitätsproblemen und von Problemen bei der Nachrichtenübermittlung im Modus classic ist vergleichbar mit der Problembehandlung für den Standardmodus.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Dienstintegrität

Die Dienstintegrität kann mithilfe der Integritäts-API überprüft werden.

  • Anforderung: GET https://{instance_name}.service.signalr.net/api/v1/health

  • Antwortstatuscode:

    • 200: Fehlerfrei
    • 503: Der Dienst ist fehlerhaft. Sie haben folgende Möglichkeiten:
      • Warten Sie einige Minuten auf eine automatische Wiederherstellung.
      • Überprüfen Sie, ob die IP-Adresse mit der IP des Portals identisch ist.
      • Starten Sie die Instanz neu.
      • Wenn alle oben genannten Optionen nicht funktionieren, kontaktieren Sie uns, indem Sie eine neue Support-Anforderung im Azure-Portal hinzufügen.

Weitere Informationen zur Notfallwiederherstellung finden Sie hier.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Nächste Schritte

In diesem Leitfaden haben Sie gelernt, wie Sie Konnektivitätsprobleme und Probleme bei der Nachrichtenübermittlung behandeln. Informationen zur Behandlung allgemeiner Probleme finden Sie im folgenden Artikel: