Verwenden von Ressourcenprotokollen zum Überwachen von SignalR Service

In diesem Artikel wird beschrieben, wie Sie mit Azure Monitor-Features die von Azure SignalR generierten Überwachungsdaten für Ressourcenprotokolle analysieren und Probleme damit behandeln können.

Auf der Seite Übersicht im Azure-Portal finden Sie eine kurze Übersicht über die Ressourcennutzung durch Azure SignalR Service, beispielsweise die Anzahl gleichzeitiger Verbindungen und die Nachrichtenanzahl. Dies sind hilfreiche Informationen, die aber nur einen kleinen Teil der im Portal verfügbaren Überwachungsdaten ausmachen. Einige dieser Daten werden automatisch erfasst und sind für die Analyse verfügbar, sobald Sie die Ressource erstellen.

Sie können nach einiger Konfiguration auch andere Arten der Datenerfassung aktivieren. In diesem Artikel wird Schritt für Schritt erläutert, wie Sie die Protokolldatensammlung konfigurieren und wie Sie mithilfe von Azure Monitor-Tools diese Daten analysieren und Probleme damit behandeln.

• Weitere Informationen zum Überwachen von Azure SignalR Service finden Sie unter Überwachen von Azure SignalR Service.
• Eine detaillierte Liste der Metriken und Protokolle, die für Azure SignalR Service erfasst werden, finden Sie unter Referenz zu Überwachungsdaten für Azure SignalR Service.

Voraussetzungen

Zum Aktivieren von Ressourcenprotokollen müssen Sie einen Ort zum Speichern Ihrer Protokolldaten einrichten, z. B. Azure Storage oder Log Analytics.

• Azure Storage speichert die Ressourcenprotokolle für die Richtlinienüberwachung, für statische Analysen oder als Sicherung.
• Log Analytics ist ein flexibles Tool für die Protokollsuche und -analyse, mit dem Sie die von einer Azure-Ressource generierten unformatierten Protokolle analysieren können.

Aktivieren von Ressourcenprotokollen

Azure SignalR Service unterstützt Verbindungs-, Messaging- und HTTP-Anforderungsprotokolle. Weitere Informationen zu diesen Arten von Protokollen finden Sie unter Kategorien von Ressourcenprotokollen. Die Protokolle werden in dem Speicherkonto gespeichert, das im Bereich Diagnoseprotokolle konfiguriert ist. Weitere Informationen zum Speicherformat und den verfügbaren Feldern finden Sie unter Datenspeicherung.

Erstellen von Diagnoseeinstellungen

Ressourcenprotokolle sind standardmäßig deaktiviert. Informationen zum Aktivieren von Protokollen mit Diagnoseeinstellungen finden Sie unter Erstellen von Diagnoseeinstellungen in Azure Monitor.

Abfragen für Ressourcenprotokolle

Führen Sie folgende Schritte aus, um Abfragen für Ressourcenprotokolle durchzuführen:

1. Wählen Sie in Ihrer Zielinstanz von Log Analytics Protokolle aus.

   

2. Geben Sie SignalRServiceDiagnosticLogs ein, und wählen Sie den Zeitraum aus. Informationen zu komplexeren Abfragen finden Sie unter Erste Schritte mit Log Analytics in Azure Monitor.

   

Führen Sie die folgenden Schritte aus, um Beispielabfragen für Azure SignalR Service zu verwenden:

1. Wählen Sie in Ihrer Zielinstanz von Log Analytics Protokolle aus.

2. Klicken Sie auf die Registerkarte Abfragen, um den Abfrage-Explorer zu öffnen.

3. Wählen Sie Ressourcentyp aus, um Beispielabfragen im Ressourcentyp zu gruppieren.

4. Klicken Sie auf Ausführen, um das Skript auszuführen.

   

Beispielabfragen für Azure SignalR Service finden Sie unter Abfragen für die Tabelle SignalRServiceDiagnosticLogs.

Hinweis

Die Feldnamen bei Abfragen für Storage-Ziele unterscheiden sich geringfügig von den Feldnamen für Log Analytics. Ausführliche Informationen zu den Feldnamenszuordnungen für Storage- und Log Analytics-Tabellen finden Sie unter Tabellenzuordnung für Ressourcenprotokolle.

Problembehandlung mit Ressourcenprotokollen

Für die Problembehandlung für Azure SignalR Service können Sie server- oder clientseitige Protokolle aktivieren, um Fehler zu erfassen. Wenn Azure SignalR Service Ressourcenprotokolle verfügbar macht, können Sie Ressourcenprotokolle nutzen, um Probleme mit Protokollen für den Dienst zu behandeln.

Probleme mit Verbindungen

Wenn die Anzahl der Verbindungen unerwartet zu- oder abnimmt, können Sie die Konnektivitätsprotokolle für die Problembehandlung nutzen. Typische Probleme umfassen häufig unerwartete Änderungen bei der Anzahl der Verbindungen, das Erreichen von Verbindungslimits sowie Autorisierungsfehler. In den folgenden Abschnitten wird beschrieben, wie Sie diese Probleme behandeln.

Unerwartete Verbindungsunterbrechungen

Wenn bei Ihnen die Anzahl der Verbindungen unerwartet sinkt, aktivieren Sie zuerst Protokolle auf Dienst-, Server- und Clientseite.

Wenn eine Verbindung getrennt wird, wird dieses Trennungsereignis in den Ressourcenprotokollen erfasst, und unter operationName wird ConnectionAborted oder ConnectionEnded angezeigt.

Der Unterschied zwischen ConnectionAborted und ConnectionEnded besteht darin, dass es sich bei ConnectionEnded um eine erwartete Trennung handelt, die vom Client oder Server ausgelöst wird. Bei ConnectionAborted handelt es sich in der Regel um ein unerwartetes Verbindungstrennungsereignis, bei dem der Grund für den Abbruch unter message zu finden ist.

Die Gründe für den Abbruch sind in der folgenden Tabelle aufgeführt.

`Reason`	BESCHREIBUNG
Anzahl der Verbindungen erreicht das Limit.	Die Anzahl der Verbindungen erreicht das Limit Ihres aktuellen Tarifs. Erwägen Sie, die Diensteinheit hochzuskalieren.
Der Anwendungsserver hat die Verbindung geschlossen.	Der App-Server löst den Abbruch aus. Dies kann als erwarteter Abbruch betrachtet werden.
Timeout des Verbindungspings.	Häufig wird dieser Fehler durch ein Netzwerkproblem verursacht. Erwägen Sie, die Verfügbarkeit Ihres App-Servers aus dem Internet zu überprüfen.
Der Dienst wird neu laden. Versuchen Sie, die Verbindung erneut herzustellen.	Azure SignalR Service wird neu geladen. Azure SignalR unterstützt automatisches erneutes Verbinden. Sie können bis zur erneuten Verbindungsherstellung warten oder die Verbindung mit Azure SignalR Service manuell erneut herstellen.
Vorübergehender interner Serverfehler.	Ein vorübergehender Fehler tritt in Azure SignalR Service auf; sollte automatisch wiederhergestellt werden.
Serververbindung unterbrochen.	Die Serververbindung wird mit unbekanntem Fehler unterbrochen. Erwägen Sie, die Problembehandlung zuerst selbst mithilfe der Dienst-/Server-/Clientprotokolle durchzuführen. Versuchen Sie, grundlegende Probleme auszuschließen (z.B. Netzwerkprobleme, Probleme auf App-Serverseite usw.). Wenn sich das Problem nicht beheben lässt, wenden Sie sich wegen weiterer Hilfe an uns. Weitere Informationen finden Sie im Abschnitt Hilfe erhalten.

Unerwarteter Anstieg der Verbindungsauslastung.

Um unerwartete Anstiege der Verbindungsauslastung zu behandeln, müssen Sie zuerst die zusätzlichen Verbindungen ausfiltern. Sie können Ihrer Testclientverbindung eine eindeutige Testbenutzer-ID hinzufügen. Überprüfen Sie die Ressourcenprotokolle. Wenn mehrere Clientverbindungen dieselbe Testbenutzer-ID oder IP-Adresse aufweisen, werden wahrscheinlich auf Clientseite mehr Verbindungen hergestellt als erwartet. Überprüfen Sie die Clientseite.

Autorisierungsfehler

Wenn Sie bei Clientanforderungen die Rückgabe „401 – Nicht autorisiert“ erhalten, überprüfen Sie Ihre Ressourcenprotokolle. Wenn Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience> auftritt, bedeutet dies, dass alle Zielgruppen in Ihrem Zugriffstoken ungültig sind. Versuchen Sie, die im Protokoll vorgeschlagenen gültigen Zielgruppen zu verwenden.

Drosselung

Wenn Sie feststellen, dass Sie keine SignalR-Client-Verbindungen mit dem Azure SignalR Dienst herstellen können, überprüfen Sie Ihre Ressourcenprotokolle. Wenn im Ressourcenprotokoll Connection count reaches limit auftritt, stellen Sie zu viele Verbindungen mit dem SignalR Service her, die das Limit für die Verbindungsanzahl erreichen. Erwägen Sie, Ihren SignalR Service zentral hochzuskalieren. Wenn im Ressourcenprotokoll Message count reaches limit steht, bedeutet dies, dass Sie den Free-Tarif verwenden und das Nachrichtenkontingent aufgebraucht haben. Wenn Sie weitere Nachrichten senden möchten, ziehen Sie in Betracht, Ihr SignalR Service-Abonnement auf den Standard-Tarif umzustellen. Weitere Informationen finden Sie unter Azure SignalR Service – Preise.

Nachrichtenbezogene Probleme

Wenn nachrichtenbezogene Probleme auftreten, können Sie für die Problembehandlung Messagingprotokolle nutzen. Aktivieren Sie zunächst im Dienst Ressourcenprotokolle und Protokolle für Server und Client.

Hinweis

Informationen zu ASP.NET Core finden Sie hier, um die Protokollierung auf Server und Client zu aktivieren.

Informationen zu ASP.NET finden Sie hier, um die Protokollierung auf Server und Client zu aktivieren.

Wenn Sie sich nicht daran stören, dass die Leistung potentiell beeinträchtigt werden könnte und dass keine Kommunikation vom Client zum Server vorhanden ist, aktivieren Sie das Messaging in Log Source Settings/Types, um das Protokollsammlungsverhalten collect-all zu aktivieren. Weitere Informationen zu diesem Verhalten finden Sie im Abschnitt Alles sammeln.

Andernfalls deaktivieren Sie das Messaging zum Aktivieren des teilweisen Protokollsammlungsverhaltens. Dieses Verhalten erfordert die Konfiguration in Client und Server, um es zu aktivieren. Weitere Informationen finden Sie im Abschnitt Teilweise sammeln.

Nachrichtenverlust

Wenn Probleme mit Nachrichtenverlust auftreten, ist es von zentraler Bedeutung, herauszufinden, wo die Nachricht verloren geht. Grundsätzlich stehen Ihnen bei der Nutzung von Azure SignalR Service drei Komponenten zur Verfügung: SignalR Service, Server und Client. Sowohl Server als auch Client sind mit SignalR Service verbunden. Sie stellen nach Abschluss der Aushandlung jedoch keine direkte Verbindung miteinander her. Daher müssen für Nachrichten zwei Richtungen berücksichtigt werden und für jede Richtung zwei Pfade:

• Von Client zu Server über SignalR-Dienst
  • Pfad 1: Client zu SignalR-Dienst
  • Pfad 2: SignalR-Dienst zu Server
• Von Server zu Client über SignalR-Dienst
  • Pfad 3: Server zu SignalR-Dienst
  • Pfad 4: SignalR-Dienst zu Server

Für das alle Sammeln-Sammlungsverhalten:

Azure SignalR Service führt nur eine Ablaufverfolgung für Nachrichten über SignalR Service vom Server an den Client durch. Die Ablaufverfolgungs-ID wird auf dem Server generiert. Die Nachricht wird zusammen mit dieser ID an SignalR Service gesendet.

Hinweis

Wenn Sie Nachrichten nachverfolgen und Nachrichten von außerhalb eines Hubs in Ihrem App-Server senden möchten, müssen Sie alle Sammlungsverhalten für Alle Sammeln-Nachrichtenprotokollen für die Nachrichten aktivieren, die nicht aus Diagnose-Clients stammen. Diagnoseclients können sowohl mit dem Sammelverhalten Alles sammeln als auch mit Teilweise sammeln verwendet werden, genießen jedoch eine höhere Priorität bei der Protokollierung. Weitere Informationen finden Sie im Abschnitt Diagnose-Client.

Indem Sie die Anmeldeserver- und Dienstseite überprüfen, können Sie einfach herausfinden, ob die Nachricht vom Server gesendet wird, beim SignalR-Dienst ankommt und diesen verlässt. Im Grunde können Sie feststellen, ob das Problem mit dem Nachrichtenverlust auf Server- oder SignalR-Dienst in dieser Richtung übereinstimmt oder nicht auf der Grundlage der Nachrichtenablaufverfolgungs-ID übereinstimmt. Weitere Informationen finden Sie im Abschnitt Details unten.

Zum teilweise Sammeln Sammelverhalten :

Nachdem Sie den Client als Diagnoseclient gekennzeichnet haben, führt Azure SignalR Service eine Ablaufverfolgung für Nachrichten in beide Richtungen durch.

Indem Sie die Anmeldeserver- und Dienstseite überprüfen, können Sie einfach herausfinden, ob die Nachricht den Server oder SignalR-Dienst erfolgreich durchlaufen hat. Im Grunde können Sie feststellen, ob die Nachricht, die erhalten und gesendet wurde, mit der Grundlage der Nachrichtenablaufverfolgungs-ID übereinstimmt. Sie können mitteilen, ob das Problem mit dem Nachrichtenverlust beim Server oder beim SignalR-Dienst liegt. Ausführlichere Informationen finden Sie im weiteren Verlauf.

Details des Nachrichtenflusses

Für die Richtung vom Client zum Server über SignalR Service berücksichtigt SignalR Service nur den Aufruf, der vom Diagnoseclient stammt, d. h. die Nachricht, die direkt im Diagnoseclient generiert wurde, oder die Dienstnachricht, die aufgrund des Aufrufs des Diagnoseclients indirekt generiert wurde.

Die Ablaufverfolgungs-ID wird in SignalR Service generiert, sobald die Nachricht über Pfad 1 in SignalR Service empfangen wird. SignalR Service generiert für jede Nachricht im Diagnoseclient den Protokolleintrag Received a message <MessageTracingId> from client connection <ConnectionId>.. Sobald die Nachricht von SignalR an den Server gesendet wird, generiert SignalR Service den Eintrag Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Wenn diese beiden Protokolle angezeigt werden, können Sie sicher sein, dass die Nachricht den SignalR-Dienst erfolgreich durchläuft.

Hinweis

Aufgrund der Einschränkung von ASP.NET Core SignalR enthält die vom Client empfangene Nachricht keine Nachrichtenebenen-ID, ASP.NET SignalR generiert jedoch für jede Nachricht eine Aufrufs-ID. Diese können Sie verwenden, um die Ablaufverfolgungs-ID zuzuordnen.

Anschließend trägt die Nachricht den Rückverfolgungs-ID-Server in Pfad 2. Sobald die Nachricht empfangen wurde, generiert der Server den Protokolleintrag Received message <messagetracingId> from client connection <connectionId>.

Sobald die Nachricht die Hub-Methode auf dem Server aufruft, wird eine neue Dienstnachricht mit einer neuen Ablaufverfolgungs-ID generiert. Nach der Erstellung der Dienstnachricht generiert der Server die Anmeldevorlage Start to broadcast/send message <MessageTracingId> .... Der tatsächliche Protokolleintrag basiert auf Ihrem Szenario. Anschließend wird die Nachricht über Pfad 3 an SignalR Service übermittelt. Sobald die Dienstnachricht den Server verlässt, wird der Protokolleintrag Succeeded to send message <MessageTracingId> generiert.

Hinweis

Die Ablaufverfolgungs-ID der Nachricht vom Client kann nicht der Ablaufverfolgungs-ID der Dienstnachricht zugeordnet werden, die an SignalR Service gesendet wird.

Sobald die Dienstnachricht in SignalR Service empfangen wurde, wird der Protokolleintrag Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. generiert. Anschließend verarbeitet der SignalR-Dienst die Dienstnachricht und liefert an Ziel-Client(s). Sobald die Nachricht über Pfad 4 an einen oder mehrere Clients gesendet wird, wird der Protokolleintrag Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. generiert.

Kurz gesagt: Einträge im Nachrichtenprotokoll werden jeweils generiert, wenn die Nachricht von SignalR Service bzw. vom Server empfangen und gesendet wird. Sie können diese Protokolle verwenden, um zu überprüfen, ob die Nachricht in diesen Komponenten verloren geht oder nicht.

Im folgenden Beispiel wird ein typisches Problem mit Nachrichtenverlust veranschaulicht.

Ein Client kann keine Nachrichten in einer Gruppe empfangen

Die typische Geschichte in diesem Problem besteht darin, dass der Client nach dem Senden einer Gruppennachricht einer Gruppe beigetreten ist.

Class Chat : Hub
{
    public void JoinAndSendGroup(string name, string groupName)
    {
        Groups.AddToGroupAsync(Context.ConnectionId, groupName); // join group
        Clients.Group(groupName).SendAsync("ReveiceGroupMessage", name, "I'm in group"); // send group message
    }
}

Beispielsweise kann jemand Aufrufe der Verknüpfungsgruppe vornehmen und gesendete Gruppennachrichten in derselben Hub-Methode senden. Das Problem hier ist, dass AddToGroupAsync in einer async-Methode enthalten ist. Da nirgends das Keyword await verwendet wird, um dafür zu sorgen, dass bis zum Abschluss von AddToGroupAsync gewartet wird, wird die Gruppennachricht gesendet, bevor AddToGroupAsync fertig ist. Aufgrund der Netzwerkverzögerung und der Verzögerung des Prozesses des Beitretens von Client zu einer Gruppe kann die Gruppenaktion später als die Übermittlung von Gruppennachrichten abgeschlossen werden. Wenn dies der Fall ist, verfügt die erste Gruppennachricht über keinen Client als Empfänger, da der Gruppe noch kein Client beigetreten ist. Hierdurch entsteht ein Problem mit Nachrichtenverlust.

Ohne Ressourcenprotokolle können Sie nicht herausfinden, wann der Client der Gruppe beigetreten ist und wann die Gruppennachricht gesendet wird. Nachdem Sie Messaging-Protokolle aktiviert haben, können Sie die Eingangszeit der Nachricht im SignalR-Dienst vergleichen. Gehen Sie folgendermaßen vor, um das Problem zu behandeln:

1. Suchen Sie die Nachrichtenprotokolle auf dem Server, um zu suchen, wann der Client der Gruppe beigetreten ist und wann die Gruppennachricht gesendet wird.
2. Rufen Sie die Nachrichtenrückverfolgungs-ID A der Gruppe und die Nachrichtenrückverfolgungs-ID B der Gruppennachricht aus den Nachrichtenprotokollen ab.
3. Filtern Sie in den Messagingprotokollen in Ihrem Protokollarchivziel nach diesen Nachrichtenablaufverfolgungs-IDs, und vergleichen Sie dann die Empfangszeitstempel. So finden Sie heraus, welche Nachricht zuerst in SignalR Service empfangen wurde.
4. Wenn der Empfangszeitpunkt der Nachricht mit der Ablaufverfolgungs-ID A nach dem der Nachricht mit ID B liegt, muss die Gruppennachricht gesendet worden sein, bevor der Client der Gruppe beigetreten ist. Sie müssen sicherstellen, dass sich der Client in der Gruppe befindet, bevor Sie Gruppennachrichten senden.

Wenn eine Nachricht in SignalR oder auf Serverseite verloren geht, versuchen Sie, die Warnungsprotokolle basierend auf der Ablaufverfolgungs-ID der Nachricht abzurufen, um den Grund zu erfahren. Wenn Sie weitere Hilfe benötigen, lesen Sie den Abschnitt Hilfe abrufen.

Ressourcenprotokolle zum Sammeln von Verhaltensweisen

Es gibt zwei typische Szenarios für die Verwendung von Ressourcenprotokollen, insbesondere für Messagingprotokolle.

Jemand kann sich um die Qualität jeder Nachricht kümmern. Sie sind beispielsweise vertraulich, ob die Nachricht erfolgreich gesendet/empfangen wurde, oder sie möchten jede Nachricht aufzeichnen, die über SignalR-Dienst übermittelt wird.

In der Zwischenzeit können andere sich um die Leistung kümmern. Sie sind auf der Latenz der Nachricht vertraulich und manchmal müssen sie die Nachricht in einigen Verbindungen statt alle Verbindungen aus irgendeinem Grund nachverfolgen.

Der SignalR-Dienst bietet daher zwei Arten von Verhalten zum Sammeln von Verhaltensweisen

• Alle sammeln: Sammeln von Protokollen in allen Verbindungen
• Teilweise sammeln: Sammeln von Protokollen in einigen bestimmten Verbindungen

Hinweis

Um zwischen den Verbindungen mit und ohne Protokollierung zu unterscheiden, behandelt SignalR Service einige Clients basierend auf den Diagnoseclientkonfigurationen von Server und Client als Diagnoseclients. Bei diesen Clients werden die Ressourcenprotokolle immer gesammelt, die anderen Protokolle jedoch nicht. Weitere Informationen finden Sie im teilweise Sammlung-Abschnitt.

Alle sammeln

Ressourcenprotokolle werden von allen Verbindungen erfasst. Nehmen Sie beispielsweise Messaging-Protokolle an. Wenn dieses Verhalten aktiviert ist, sendet SignalR Service eine Benachrichtigung an den Server, damit begonnen wird, für jede Nachricht eine Ablaufverfolgungs-ID zu generieren. Die Ablaufverfolgungs-ID wird zusammen mit der Nachricht an den Dienst gesendet. Der Dienst protokolliert auch die Nachricht zusammen mit der Ablaufverfolgungs-ID.

Hinweis

Beachten Sie, dass SignalR Service nicht auf die gesamte vom Client gesendete Nachricht wartet und diese parst, damit die Leistung von SignalR Service nicht beeinträchtigt wird. Daher werden die Clientnachrichten nicht protokolliert. Wenn der Client als Diagnoseclient gekennzeichnet ist, wird die Clientnachricht in SignalR Service protokolliert.

Konfigurationsleitfaden

Um dieses Verhalten zu aktivieren, aktivieren Sie das Kontrollkästchen im Abschnitt Typen in den Protokollquelle-Einstellungen.

Dieses Verhalten erfordert nicht, dass Sie serverseitige Konfigurationen aktualisieren. Diese Konfigurationsänderung wird immer automatisch an den Server gesendet.

Teilweise sammeln

Ressourcenprotokolle werden nur von Diagnose-Clients erfasst. Alle Nachrichten werden protokolliert, einschließlich Client-Nachrichten und Konnektivitätsereignissen in den Diagnoseclients.

Hinweis

Die Grenze der Anzahl der Diagnose-Clients beträgt 100. Wenn die Anzahl der Diagnoseclients 100 überschreitet, werden der 101. Diagnoseclient und alle darauffolgenden von SignalR Service gedrosselt. Die neuen Clients über dem Grenzwert können keine Verbindung zu SignalR Service herstellen und lösen System.Net.Http.HttpRequestException aus, wodurch die Meldung Response status code does not indicate success: 429 (Too Many Requests) ausgegeben wird. Die Funktion der bereits verbundenen Clients ist von der Drosselungsrichtlinie nicht betroffen.

Diagnose-Client

Diagnoseclients sind ein logisches Konzept. Jeder Client kann ein Diagnoseclient sein. Der Server steuert, welche Client ein Diagnose-Client sein kann. Wenn ein Client als Diagnoseclient gekennzeichnet wird, werden alle Ressourcenprotokolle in diesem Client aktiviert. Informationen zum Festlegen eines Clients als Diagnoseclient finden Sie im Konfigurationsleitfaden.

Konfigurationsleitfaden

Um dieses Verhalten zu aktivieren, müssen Sie Dienst, Server und Clientseite konfigurieren.

Dienstseite

Um dieses Verhalten zu aktivieren, deaktivieren Sie das Kontrollkästchen für einen bestimmten Protokolltyp im Abschnitt Typen im Protokollquelle-Einstellungen.

Serverseitig

Richten Sie ServiceOptions.DiagnosticClientFilter, um einen Filter von Diagnose-Clients basierend auf dem http-Kontext aus Clients zu definieren. Erstellen Sie beispielsweise Client mit Hub-URL <HUB_URL>?diag=yes und filtern Sie ServiceOptions.DiagnosticClientFilter dann, um den Diagnose-Client zu filtern. Wenn true zurückgegeben wird, wird der Client als Diagnoseclient gekennzeichnet. Andernfalls bleibt er ein normaler Client. Diese ServiceOptions.DiagnosticClientFilter kann in Ihrer Startup-Klasse wie folgt festgelegt werden:

// sample: mark a client as diagnostic client when it has query string "?diag=yes" in hub URL
public IServiceProvider ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services
        .AddSignalR()
        .AddAzureSignalR(o =>
        {
            o.ConnectionString = "<YOUR_ASRS_CONNECTION_STRING>";
            o.DiagnosticClientFilter = context => context.Request.Query["diag"] == "yes";
        });

    return services.BuildServiceProvider();
}

Clientseitig

Markieren Sie den Client als Diagnose-Client, indem Sie den http-Kontext konfigurieren. Der Client wird beispielsweise als Diagnose-Client markiert, indem die Abfragezeichenfolge diag=yes hinzugefügt wird.

var connection = new HubConnectionBuilder()
    .WithUrl("<HUB_URL>?diag=yes")
    .Build();

Hilfe erhalten

Wir empfehlen Ihnen, zuerst eine eigenständige Problembehandlung durchzuführen. Die meisten Probleme werden vom App-Server oder durch Netzwerkprobleme verursacht. Befolgen Sie den Leitfaden zur Problembehandlung mit Ressourcenprotokollen sowie den Grundlegenden Leitfaden zur Problembehandlung, um die Grundursache zu ermitteln. Wenn das Problem immer noch nicht gelöst werden kann, sollten Sie in Betracht ziehen, ein Issue auf GitHub zu öffnen oder ein Ticket im Azure-Portal zu erstellen. Bereitstellen:

1. Zeitraum von etwa 30 Minuten, wann das Problem auftritt
2. Ressourcen-ID Ihres Azure SignalR Service
3. Problemdetails, so spezifisch wie möglich: Beispielsweise sendet der App-Server keine Nachrichten, Client-Verbindungsunterbrechungen usw.
4. Auf Server-/Clientseite erfasste Protokolle sowie weitere Materialien, die nützlich sein könnten
5. [Optional] Reproduktionscode

Hinweis

Wenn Sie ein Issue auf GitHub öffnen, halten Sie Ihre vertraulichen Informationen (z. B. Ressourcen-ID und Server- bzw. Clientprotokolle) privat. Senden Sie sie nur privat an Mitglieder der Microsoft-Organisation.