Freigeben über

Azure SignalR Service überwachen

  • Artikel

Dieser Artikel beschreibt Folgendes:

  • Die Arten von Überwachungsdaten, die Sie für diesen Dienst sammeln können
  • Möglichkeiten zum Analysieren dieser Daten.

Hinweis

Wenn Sie bereits mit diesem Dienst und/oder Azure Monitor vertraut sind und nur wissen möchten, wie Überwachungsdaten analysiert werden, lesen Sie den Abschnitt Analysieren am Ende dieses Artikels.

Wenn Sie über unternehmenskritische Anwendungen und Geschäftsprozesse verfügen, die auf Azure-Ressourcen basieren, müssen Sie diese überwachen und Warnungen für Ihr System abrufen. Der Azure Monitor-Dienst sammelt und aggregiert Metriken und Protokolle aus jeder Komponente Ihres Systems. Azure Monitor bietet Ihnen eine Übersicht über Verfügbarkeit, Leistung und Resilienz und benachrichtigt Sie über Probleme. Sie können das Azure-Portal, PowerShell, die Azure CLI, die REST-API oder Clientbibliotheken verwenden, um Überwachungsdaten einzurichten und anzuzeigen.

Ressourcentypen

Azure verwendet das Konzept von Ressourcentypen und IDs, um alles in einem Abonnement zu identifizieren. Ressourcentypen sind auch Teil der Ressourcen-IDs für jede Ressource, die in Azure ausgeführt wird. Beispiel: Ein Ressourcentyp für eine VM ist Microsoft.Compute/virtualMachines. Eine Liste der Dienste und ihrer zugehörigen Ressourcentypen finden Sie unter Ressourcenanbieter.

Ähnliche organisiert Azure Monitor die Kernüberwachungsdaten in Metriken und Protokollen basierend auf Ressourcentypen, die auch als Namespaces bezeichnet werden. Für unterschiedliche Ressourcentypen stehen unterschiedliche Metriken und Protokolle zur Verfügung. Ihr Dienst ist möglicherweise mehr als einem Ressourcentyp zugeordnet.

Weitere Informationen zu den Ressourcentypen für Azure SignalR Service finden Sie unter Azure SignalR Service-Überwachungsdatenreferenz.

Datenspeicher

For Azure Monitor:

  • Metrikdaten werden in der Azure Monitor-Metrikendatenbank gespeichert.
  • Protokolldaten werden im Azure Monitor-Protokollspeicher gespeichert. Log Analytics ist ein Tool im Azure-Portal zum Abfragen dieses Speichers.
  • Das Azure-Aktivitätsprotokoll ist ein separater Speicher mit eigener Schnittstelle im Azure-Portal.

Optional können Sie Metrik- und Aktivitätsprotokolldaten an den Azure Monitor-Protokollspeicher weiterleiten. Anschließend können Sie Log Analytics verwenden, um die Daten abzufragen und mit anderen Protokolldaten zu korrelieren.

Viele Dienste können Diagnoseeinstellungen verwenden, um Metrik- und Protokolldaten an andere Speicherorte außerhalb von Azure Monitor zu senden. Beispiele umfassen Azure Storage, gehostete Partnersysteme und Nicht-Azure-Partnersysteme, die Event Hubs verwenden.

Detaillierte Informationen dazu, wie Azure Monitor Daten speichert, finden Sie unter Azure Monitor-Datenplattform.

Die Azure SignalR Service-Protokolle werden im Speicherkonto gespeichert, das in den Diagnoseeinstellungen konfiguriert ist. Ein Container mit dem Namen insights-logs-alllogs wird automatisch erstellt, um Ressourcenprotokolle zu speichern. Innerhalb des Containers werden Protokolle in der Datei resourceId=/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX/y=YYYY/m=MM/d=DD/h=HH/m=00/PT1H.json gespeichert. Grundsätzlich ist der Pfad eine Kombination aus resource ID und Date Time. Die Protokolldateien werden anhand der hour aufgeteilt. Daher sind die Minuten immer m=00.

Alle Protokolle werden im JavaScript Object Notation (JSON)-Format gespeichert. Es folgt ein Codebeispiel für eine JSON-Zeichenfolge im Archivierungsprotokoll:

{
    "properties": {
        "message": "Entered Serverless mode.",
        "type": "ConnectivityLogs",
        "collection": "Connection",
        "connectionId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "userId": "User",
        "transportType": "WebSockets",
        "connectionType": "Client"
    },
    "operationName": "ServerlessModeEntered",
    "category": "AllLogs",
    "level": "Informational",
    "callerIpAddress": "xxx.xxx.xxx.xxx",
    "time": "2019-01-01T00:00:00Z",
    "resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX",
    "location": "xxxx"
}

Die Feldnamen für Speicherziele unterscheiden sich geringfügig von den Feldnamen für Log Analytics. Ausführliche Informationen zur Feldnamenszuordnung für Speicher- und Log Analytics-Tabellen finden Sie unter Tabellenzuordnung für Ressourcenprotokolle.

Azure Monitor-Plattformmetriken

Azure Monitor stellt Plattformmetriken für die meisten Dienste bereit. Diese Metriken sind:

  • Einzeln für jeden Namespace definiert.
  • In der Azure Monitor-Datenbank für Zeitreihenmetriken gespeichert.
  • Einfach strukturiert und in der Lage, Warnmeldungen in Quasi-Echtzeit zu unterstützen.
  • Verwendet zum Nachverfolgen der Leistung einer Ressource im Zeitverlauf.

Erfassung: Azure Monitor sammelt Plattformmetriken automatisch. Es ist keine Konfiguration erforderlich.

Routing: Sie können einige Plattformmetriken auch an Azure Monitor-Protokolle/Log Analytics weiterleiten, damit Sie diese mit anderen Protokolldaten abfragen können. Überprüfen Sie anhand der Einstellung DS-Export für die einzelnen Metriken, ob Sie eine Diagnoseeinstellung zum Weiterleiten der jeweiligen Metrik an Azure Monitor-Protokolle/Log Analytics verwenden können.

Eine Liste aller Metriken, die für alle Ressourcen in Azure Monitor gesammelt werden können, finden Sie unter Unterstützte Metriken in Azure Monitor.

Azure SignalR Service-Metriken

Eine Liste aller verfügbaren Metriken für Azure SignalR Service finden Sie unter Azure SignalR Service-Überwachungsdatenreferenz.

Granularität der Nachrichtenanzahl

Der Mindestwert für die Granularität der Nachrichtenanzahl beträgt 2 KB ausgehender Datenverkehr. Wenn ein Client kleine oder seltene Nachrichten mit insgesamt weniger als 2 KB in einem Stichprobenzeitraum sendet, ist die Nachrichtenanzahl Null (0), auch wenn Nachrichten gesendet wurden. Mit der Metrik Ausgehender Datenverkehr, die die Anzahl gesandter Bytes darstellt, können Sie nach einer geringen Nachrichtenanzahl oder -größe suchen.

Systemfehler und Benutzerfehler

Die Metriken Benutzerfehler und Systemfehler geben den Prozentsatz der versuchten Vorgänge an, z. B. das Verbinden oder Senden einer Nachricht, deren Ausführung fehlgeschlagen ist. Ein Systemfehler ist ein Fehler in der internen Systemlogik. Ein Benutzerfehler ist meist ein Anwendungsfehler, häufig im Zusammenhang mit dem Netzwerk. Normalerweise sollte der Prozentsatz der Systemfehler gering bzw. nahezu Null sein.

Wichtig

In einigen Situationen ist die Benutzerfehlerrate sehr hoch, insbesondere im serverlosen Modus. In manchen Browsern wird der SignalR-Client nicht ordnungsgemäß heruntergefahren, wenn ein bzw. eine Benutzer*in die Webseite schließt. Es kann vorkommen, dass eine Verbindung geöffnet bleibt, aber nicht reagiert, bis sie schließlich von Azure SignalR Service aufgrund eines Timeouts geschlossen wird. Das Schließen aufgrund eines Timeouts wird in der Metrik „Benutzerfehler“ erfasst.

Für die automatische Skalierung geeignete Metriken

Die Metriken Auslastung des Verbindungskontingents und Serverauslastung zeigen den Prozentsatz der Auslastung oder die Auslastung im Vergleich zur aktuell zugewiesenen Anzahl von Einheiten. Diese Metriken werden häufig in Regeln für die automatische Skalierung verwendet. Wenn die aktuelle Zuordnung beispielsweise eine Einheit ist und 750 Verbindungen mit dem Dienst bestehen, beträgt die Auslastung des Verbindungskontingents 750/1.000 = 0,75. Die Serverauslastung wird auf ähnliche Weise anhand von Werten für die Computekapazität berechnet. Weitere Informationen finden Sie unter Automatisches Skalieren der Einheiten einer Azure SignalR Service-Instanz.

Hinweis

Das Feature für die automatische Skalierung ist nur im Premium-Tarif verfügbar.

Azure Monitor-Ressourcenprotokolle

Ressourcenprotokolle bieten Einblicke in Vorgänge, die von einer Azure-Ressourcen ausgeführt wurden. Protokolle werden automatisch generiert, aber Sie müssen sie an Azure Monitor-Protokolle weiterleiten, um sie zu speichern oder abzufragen. Protokolle sind in Kategorien organisiert. Ein bestimmter Namespace verfügt möglicherweise über mehrere Ressourcenprotokollkategorien.

Sammlung: Ressourcenprotokolle werden erst gesammelt und gespeichert, nachdem Sie eine Diagnoseeinstellung erstellt und die Protokolle an mindestens einen Speicherort weitergeleitet haben. Wenn Sie eine Diagnoseeinstellung erstellen, legen Sie fest, welche Kategorien von Protokollen gesammelt werden sollen. Es gibt mehrere Möglichkeiten zum Erstellen und Verwalten von Diagnoseeinstellungen, u. a. das Azure-Portal, programmgesteuert und über Azure Policy.

Routing: Der vorgeschlagene Standard besteht darin, Ressourcenprotokolle an Azure Monitor-Protokolle weiterzuleiten, damit Sie diese mit anderen Protokolldaten abfragen können. Andere Speicherorte wie z. B. Azure Storage, Azure Event Hubs und bestimmte Microsoft-Überwachungspartner sind ebenfalls verfügbar. Weitere Informationen finden Sie unter Azure-Ressourcenprotokolle und Ressourcenprotokollziele.

Ausführliche Informationen zum Sammeln, Speichern und Weiterleiten von Ressourcenprotokollen finden Sie unter Diagnoseeinstellungen in Azure Monitor.

Eine Liste aller verfügbaren Ressourcenprotokollkategorien in Azure Monitor finden Sie unter Unterstützte Ressourcenprotokolle in Azure Monitor.

Alle Ressourcenprotokolle in Azure Monitor enthalten dieselben Headerfelder, gefolgt von dienstspezifischen Feldern. Das allgemeine Schema wird in Azure Monitor-Ressourcenprotokollschema beschrieben.

Ressourcenprotokollkategorien

Die Ressourcenprotokolle werden in Kategoriegruppen zusammengefasst. Kategoriegruppen enthalten eine Sammlung verschiedener Protokolle, die es Ihnen erleichtern, unterschiedliche Überwachungsziele zu erreichen. Azure SignalR unterstützt Verbindungs-, Messaging- und HTTP-Anforderungsprotokolle.

Konnektivitätsprotokolle

Konnektivitätsprotokolle bieten ausführliche Informationen zu SignalR-Hubverbindungen. Zum Beispiel:

  • Grundlegende Informationen wie Benutzer-ID, Verbindungs-ID und Transporttyp
  • Ereignisinformationen wie Connect-, Disconnect- und Abbruchereignisse

Aus diesem Grund ist das Konnektivitätsprotokoll hilfreich, um verbindungsbezogene Probleme zu beheben. Eine typische Problembehandlung im Zusammenhang mit Verbindungen finden Sie unter verbindungsbezogene Probleme.

Messagingprotokolle

Messaging-Protokolle bieten Ablaufverfolgungsinformationen für die SignalR-Hub-Nachrichten, die über den SignalR-Dienst empfangen und gesendet werden, z. B. Ablaufverfolgungs-ID und Nachrichtentyp der Nachricht. Die Ablaufverfolgungs-ID und der Nachrichtentyp werden auch auf dem App-Server protokolliert. In der Regel wird die Nachricht aufgezeichnet, wenn sie beim Dienst eintrifft oder ihn verlässt. Daher sind Messagingprotokolle hilfreich für die Behandlung von Problemen im Zusammenhang mit Nachrichten. Eine typische Problembehandlung im Zusammenhang mit Nachrichten finden Sie unter Nachrichtenbezogene Probleme.

Hinweis

Dieser Protokolltyp wird für jede Nachricht generiert. Wenn die Nachrichten häufig gesendet werden, können Messaging-Protokolle die Leistung des SignalR-Diensts beeinflussen. Sie können jedoch verschiedene Sammlungsverhalten auswählen, um die Leistungswirkung zu minimieren. Weitere Informationen findest du unter Verhaltensweisen zum Sammeln von Ressourcenprotokollen.

HTTP-Anforderungsprotokolle

HTTP-Anforderungsprotokolle bieten detaillierte Informationen für die von Azure SignalR empfangenen HTTP-Anforderungen, z. B. Statuscode und URL der Anforderung. Das Http-Anforderungsprotokoll ist hilfreich, um anforderungsbezogene Probleme zu beheben.

Die verfügbaren Kategorien der Ressourcenprotokolle, die zugehörigen Log Analytics-Tabellen und die Protokollschemata für Azure SignalR Service finden Sie unter Azure SignalR Service-Überwachungsdatenreferenz.

Ressourcenprotokolle zum Sammeln von Verhaltensweisen

Es gibt zwei typische Szenarios für die Verwendung von Ressourcenprotokollen, insbesondere für Messaging-Protokolle.

  • Die Nachrichtenqualität protokolliert, ob die Nachricht erfolgreich gesandt oder empfangen wurde, oder erfasst jede Nachricht, die über den SignalR-Dienst übermittelt wird.
  • Die Performance protokolliert die Nachrichtenlatenz, oder verfolgt die Nachricht in einigen Verbindungen anstelle aller Verbindungen nach.

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

  • Alle sammeln sammelt Protokolle in allen Verbindungen.
  • Teilweise sammeln sammelt Protokolle in einigen bestimmten Verbindungen.

Weitere Informationen zu den Verhaltensweisen zum Sammeln von Ressourcenprotokollen und zur Konfiguration dieser finden Sie unter Verhaltensweisen zum Sammeln von Ressourcenprotokollen.

Azure-Aktivitätsprotokoll

Das Aktivitätsprotokoll enthält Ereignisse auf Abonnementebene, die Vorgänge für jede Azure-Ressource nachverfolgen, so wie sie von außerhalb dieser Ressource gesehen werden, z. B. das Erstellen einer neuen Ressource oder das Starten einer VM.

Sammlung: Aktivitätsprotokollereignisse werden automatisch generiert und in einem separaten Speicher für die Anzeige im Azure-Portal gesammelt.

Routing: Sie können Aktivitätsprotokolldaten an Azure Monitor-Protokolle senden, damit Sie diese zusammen mit anderen Protokolldaten analysieren können. Andere Speicherorte wie z. B. Azure Storage, Azure Event Hubs und bestimmte Microsoft-Überwachungspartner sind ebenfalls verfügbar. Weitere Informationen zum Weiterleiten von Aktivitätsprotokollen finden Sie unter Übersicht über das Azure-Aktivitätsprotokoll.

Analysieren von Überwachungsdaten

Es gibt viele Tools zum Analysieren von Überwachungsdaten.

Azure Monitor-Tools

Azure Monitor unterstützt die folgenden grundlegenden Tools:

Zu den Tools, die eine komplexere Visualisierung ermöglichen, gehören:

  • Dashboards, mit denen Sie verschiedene Typen von Daten in einen einzelnen Bereich im Azure-Portal kombinieren können.
  • Arbeitsmappen, anpassbare Berichte, die Sie im Azure-Portal erstellen können. Arbeitsmappen können Text, Metriken und Protokollabfragen enthalten.
  • Grafana, ein Tool auf einer offenen Plattform, das für operationale Dashboards ideal ist. Sie können Grafana verwenden, um Dashboards zu erstellen, die Daten aus mehreren anderen Quellen als Azure Monitor enthalten.
  • Power BI ist ein Geschäftsanalysedienst, der interaktive Visualisierungen für verschiedene Datenquellen bereitstellt. Sie können Power BI für den automatischen Import von Protokolldaten aus Azure Monitor konfigurieren, um diese Visualisierungen zu nutzen.

Exporttools für Azure Monitor

Sie können Daten aus Azure Monitor in andere Tools abrufen, indem Sie die folgenden Methoden verwenden:

Informationen zu den ersten Schritten mit der REST-API für Azure Monitor finden Sie in der exemplarischen Vorgehensweise für die Azure-Überwachungs-REST-API.

Kusto-Abfragen

Sie können Überwachungsdaten im Azure Monitor Logs / Log Analytics Store mithilfe der Kusto-Abfragesprache (KQL) analysieren.

Wichtig

Wenn Sie Protokolle im Menü des Diensts im Portal auswählen, wird Log Analytics geöffnet, wobei der Abfragebereich auf den aktuellen Dienst festgelegt ist. Dieser Bereich bedeutet, dass Protokollabfragen nur Daten aus diesem Ressourcentyp umfassen. Wenn Sie eine Abfrage durchführen möchten, die Daten aus anderen Azure-Diensten enthält, wählen Sie im Menü Azure Monitor die Option Protokolle aus. Ausführliche Informationen finden Sie unter Protokollabfragebereich und Zeitbereich in Azure Monitor Log Analytics.

Eine Liste häufiger Abfragen für alle Dienste finden Sie unter Log Analytics-Abfrageschnittstelle.

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

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 Speicher- und Log Analytics-Tabellen finden Sie unter Tabellenzuordnung für Ressourcenprotokolle.

Alerts

Azure Monitor-Warnungen informieren Sie proaktiv, wenn bestimmte Bedingungen in Ihren Überwachungsdaten auftreten. Warnungen ermöglichen Ihnen, Probleme in Ihrem System zu identifizieren und zu beheben, bevor Ihre Kunden sie bemerken. Weitere Informationen finden Sie unter Azure Monitor-Warnungen.

Es gibt viele Quellen allgemeiner Warnungen für Azure-Ressourcen. Beispiele für häufige Warnungen für Azure-Ressourcen finden Sie in den Beispielabfragen für Protokollwarnungen. Die Website Azure Monitor-Baselinewarnungen (Azure Monitor Baseline Alerts, AMBA) stellt eine halbautomatisierte Methode für die Implementierung wichtiger Metrikwarnungen der Plattform, Dashboards und Richtlinien bereit. Die Website gilt für eine fortlaufend erweiterte Teilmenge von Azure-Diensten, einschließlich aller Dienste, die Teil der Azure-Zielzone (Azure Landing Zone, ALZ) sind.

Mit dem allgemeinen Warnungsschema wird die Benutzeroberfläche für Warnungsbenachrichtigungen in Azure Monitor standardisiert. Weitere Informationen finden Sie unter Allgemeines Warnungsschema.

Warnungstypen

Sie können zu jeder Metrik oder Protokolldatenquelle der Azure Monitor-Datenplattform Warnungen erhalten. Es gibt viele verschiedene Typen von Warnungen, abhängig von den Diensten, die Sie überwachen, und den Überwachungsdaten, die Sie sammeln. Verschiedene Typen von Warnungen haben jeweils ihre Vor- und Nachteile. Weitere Informationen finden Sie unter Auswählen des richtigen Warnungsregeltyps.

In der folgenden Liste werden die Typen von Azure Monitor-Warnungen beschrieben, die Sie erstellen können:

  • Metrikwarnungen bewerten Ressourcenmetriken in regelmäßigen Abständen. Metriken können Plattformmetriken, benutzerdefinierte Metriken, in Metriken konvertierte Protokolle aus Azure Monitor oder Application Insights-Metriken sein. Metrikwarnungen können auch mehrere Bedingungen und dynamische Schwellwerte anwenden.
  • Protokollwarnungen ermöglichen es Benutzern, eine Log Analytics-Abfrage zum Auswerten von Ressourcenprotokollen in vordefinierten Frequenz zu verwenden.
  • Aktivitätsprotokollwarnungen werden ausgelöst, wenn ein neues Aktivitätsprotokollereignis eintritt, das definierte Bedingungen erfüllt. Resource Health- und Service Health-Warnungen sind Aktivitätsprotokollwarnungen, die über die Dienst- und Ressourcenintegrität berichten.

Einige Azure-Dienste unterstützen auch intelligente Erkennungswarnungen, Prometheus-Warnungen oder empfohlene Warnungsregeln.

Einige Dienste können Sie im großen Stil überwachen, indem Sie dieselbe Metrikwarnungsregel auf mehrere Ressourcen desselben Typs anwenden, die sich in derselben Azure-Region befinden. Für jede überwachte Ressource werden einzelne Benachrichtigungen gesendet. Unterstützte Azure-Dienste und -Clouds finden Sie unter Überwachen mehrerer Ressourcen mit einer Warnungsregel.

Azure SignalR Service-Warnungsregeln

In der folgenden Tabelle sind einige vorgeschlagene Warnungsregeln für Azure SignalR Service aufgeführt. Diese Warnungen sind nur Beispiele. Sie können Warnungen für jede Metrik, jeden Protokolleintrag oder jeden Aktivitätsprotokolleintrag festlegen, der in der Azure SignalR Service-Überwachungsdatenreferenz aufgeführt ist.

Warnungstyp Bedingung Beschreibung
Plattformmetriken Auslastung des Verbindungskontingents Immer wenn die maximale Verbindungskontingentauslastung größer als der dynamische Schwellenwert ist
Plattformmetriken SignalR löschen Wenn das Aktivitätsprotokoll über ein Ereignis mit Category='Administrative', Signal name='Delete SignalR (SignalR)' verfügt

Advisor-Empfehlungen

Wenn in einigen Diensten während eines Ressourcenvorgangs kritische Bedingungen oder unmittelbar bevorstehende Änderungen auftreten, wird auf der Dienstseite Übersicht im Portal eine Warnung angezeigt. Weitere Informationen und empfohlene Korrekturen für die Warnung finden Sie in Advisor-Empfehlungen unter Überwachung im linken Menü. Während des normalen Betriebs werden keine Advisor-Empfehlungen angezeigt.

Weitere Informationen zu Azure Advisor finden Sie unter Azure Advisor – Übersicht.

Zugehöriger Inhalt