Überwachen von Azure Cache for Redis

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.

• Weitere Informationen zu Azure Monitor finden Sie unter Azure Monitor – Übersicht.
• Weitere Informationen zum Überwachen von Azure-Ressourcen im Allgemeinen finden Sie unter Überwachen von Azure-Ressourcen mit Azure Monitor.

Erkenntnisse

Einige Dienste in Azure verfügen über ein integriertes Überwachungsdashboard im Azure-Portal, das einen Ausgangspunkt für die Überwachung Ihres Diensts bietet. Diese Dashboards werden als Erkenntnisse bezeichnet, und Sie finden sie im Erkenntnishub von Azure Monitor im Azure-Portal.

Erkenntnisse für Azure Cache for Redis bieten die folgende Erfahrung:

• Sicht im gewünschten Umfang auf Ihre Azure Cache for Redis-Ressourcen in allen Ihren Abonnements. Sie können den Bereich selektiv auf die Abonnements und Ressourcen festlegen, die Sie bewerten möchten.
• Drilldownanalyse einer Azure Cache for Redis-Ressource. Um Probleme zu diagnostizieren, können Sie eine detaillierte Analyse der Auslastung, Fehler, Kapazität und Vorgänge anzeigen oder eine umfassende Ansicht relevanter Informationen anzeigen.
• Anpassung, die auf Azure Monitor-Arbeitsmappenvorlagen basiert. Sie können ändern, welche Metriken angezeigt werden, sowie Schwellenwerte entsprechend Ihren Grenzwerten ändern oder festlegen. Sie können die Änderungen in einer benutzerdefinierten Arbeitsmappe speichern und dann Arbeitsmappendiagramme an Azure-Dashboards anheften.

Erkenntnisse für Azure Cache for Redis erfordern keine Aktivierung oder Konfiguration. Azure Cache for Redis-Informationen werden standardmäßig gesammelt, und für den Zugriff auf Erkenntnisse fallen keine zusätzlichen Kosten an.

Informationen zum Anzeigen, Konfigurieren und Anpassen von Einblicken für Azure Cache for Redis finden Sie unter Azure Monitor-Erkenntnisse für Azure Cache für Redis.

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 Cache for Redis finden Sie unter Azure Cache for Redis-Ü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.

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.

• Weitere Informationen finden Sie in der Diagnoseeinstellung „Metriken“.
• Informationen zum Konfigurieren von Diagnoseeinstellungen für einen Dienst finden Sie unter Erstellen von Diagnoseeinstellungen in Azure Monitor.

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.

Eine Liste der verfügbaren Metriken für Azure Cache for Redis finden Sie unter Azure Cache for Redis-Überwachungsdatenreferenz.

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.

Die verfügbaren Ressourcenprotokollkategorien, ihre zugehörigen Log Analytics-Tabellen und die Protokollschemas für Azure Cache for Redis finden Sie unter Azure Cache for Redis-Überwachungsdatenreferenz.

Azure Cache for Redis-Ressourcenprotokolle

In Azure Cache for Redis stehen zwei Optionen für die Protokollierung zur Verfügung:

• Mit Cachemetriken („AllMetrics“) werden Metriken aus Azure Monitor protokolliert.
• Verbindungsprotokolle zum Protokollieren von Verbindungen mit dem Cache zu Sicherheits- und Diagnosezwecken.

Cachemetriken

Azure Cache for Redis gibt viele Metriken wie Server Load und Connections per Second aus, deren Protokollierung nützlich ist. Wenn Sie die Option AllMetrics auswählen, können diese und andere Cachemetriken protokolliert werden. Sie können konfigurieren, wie lange die Metriken aufbewahrt werden.

Verbindungsprotokolle

Azure Cache for Redis verwendet Azure-Diagnoseeinstellungen, um Informationen zu Clientverbindungen mit Ihrem Cache zu protokollieren. Dank der Protokollierung und anschließenden Analyse dieser Diagnoseeinstellung können Sie besser verstehen, wer eine Verbindung mit Ihren Caches herstellt und welchen Zeitstempel diese Verbindungen aufweisen. Mit diesen Protokoll-Daten können Sie das Ausmaß einer Sicherheitsverletzung ermitteln und Sicherheitsüberprüfungen durchführen.

Die Verbindungsprotokolle weisen geringfügig unterschiedliche Implementierungen, Inhalte und Einrichtungsverfahren für die verschiedenen Azure Cache for Redis-Ebenen auf. Ausführliche Informationen finden Sie unter Azure Monitor-Diagnoseeinstellungen.

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:

• Metriken-Explorer, ein Tool im Azure-Portal, mit dem Sie Metriken für Azure-Ressourcen anzeigen und analysieren können. Weitere Informationen finden Sie unter Analysieren von Metriken mit dem Azure Monitor-Metrik-Explorer.

• Log Analytics, ein Tool im Azure-Portal, mit dem Sie Protokolldaten mithilfe der KQL-Abfragesprache abfragen und analysieren können. Weitere Informationen finden Sie unter Erste Schritte mit Protokollabfragen in Azure Monitor.

• Das Aktivitätsprotokoll, das über eine Benutzeroberfläche im Azure-Portal für die Anzeige und einfache Suchvorgänge verfügt. Um ausführlichere Analysen durchzuführen, müssen Sie die Daten an Azure Monitor-Protokolle weiterleiten und komplexere Abfragen in Log Analytics ausführen.

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:

• Metriken: Verwenden Sie die REST-API für Metriken, um Metrikdaten aus der Azure Monitor-Metrikendatenbank zu extrahieren. Die API unterstützt Filterausdrücke, um die abgerufenen Daten zu verfeinern. Weitere Informationen finden Sie in der Referenz zur Azure Monitor-REST-API.

• Protokolle: Verwenden Sie die REST-API oder die zugeordneten Clientbibliotheken.

• Eine weitere Option ist der Arbeitsbereichsdatenexport.

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.

Azure Cache for Redis-Metriken

Metriken für Azure Cache for Redis-Instanzen werden über den Redis-Befehl INFO gesammelt. Metriken werden etwa zweimal pro Minute gesammelt, sodass sie in den Metrikdiagrammen angezeigt und durch Warnungsregeln ausgewertet werden können. Informationen dazu, wie lange Daten aufbewahrt werden und wie Sie eine andere Aufbewahrungsrichtlinie konfigurieren, finden Sie unter Datenaufbewahrung und Archivierung in Azure Monitor-Protokollen.

Die Metriken werden in verschiedenen Berichtsintervallen gemeldet, z. B. Letzte Stunde, Heute, Letzte Woche und Benutzerdefiniert. Kedes Metrikdiagramm zeigt die Durchschnitts-, Minimal- und Maximalwerte für jede Metrik im Diagramm an. Einige Metriken zeigen einen Gesamtwert für das Berichtsintervall an.

Jede Metrik enthält zwei Versionen: Eine Metrik misst die Leistung für den gesamten Cache und für Caches, die Clustering verwenden. Eine zweite Version der Metrik, die (Shard 0-9) im Namen enthält, misst die Leistung für einen einzelnen Shard in einem Cache. Wenn z. B. ein Cache vier Shards enthält, ist Cache Hits die Gesamtanzahl der Treffer für den gesamten Cache, und Cache Hits (Shard 3) misst lediglich die Treffer für dieses Shard des Caches an.

Anzeigen von Cachemetriken

Sie können Azure Monitor-Metriken für Azure Cache for Redis direkt in einer Azure Cache for Redis-Ressource im Azure-Portal anzeigen.

Wählen Sie Ihre Azure Cache for Redis-Instanz im Portal aus. Auf der Seite Übersicht werden die vordefinierten Überwachungsdiagramme Speicherauslastung und Redis-Serverlast angezeigt. Diese Diagramme sind hilfreiche Zusammenfassungen, mit denen Sie den Status Ihres Caches schnell betrachten können.

Für ausführlichere Informationen können Sie die folgenden nützlichen Azure Cache for Redis-Metriken im Abschnitt Überwachung des Ressourcenmenüs überwachen.

Azure Cache for Redis-Metrik	Weitere Informationen
Netzwerkbandbreiten-Nutzung	Cacheleistung – verfügbare Bandbreite
Verbundene Clients	Standardmäßig verwendete Redis-Serverkonfiguration: Max. Anzahl von Clients
Serverauslastung	Redis-Serverlast
Speicherauslastung	Cacheleistung – Größe

Erstellen eigener Metriken

Erstellen Sie ihr eigenes benutzerdefiniertes Diagramm, um die Metriken nachzuverfolgen, die Sie sehen möchten. Cachemetriken werden in verschiedenen Berichtsintervallen gemeldet, z.B. Letzte Stunde, Heute, Letzte Woche und Benutzerdefiniert. Wählen Sie auf der linken Seite Metriken im Abschnitt Überwachung aus. Kedes Metrikdiagramm zeigt die Durchschnitts-, Minimal- und Maximalwerte für jede Metrik im Diagramm an. Einige Metriken zeigen einen Gesamtwert für das Berichtsintervall an.

Jede Metrik enthält zwei Versionen: Eine Metrik misst die Leistung für den gesamten Cache und für Caches, die Clustering verwenden. Eine zweite Version der Metrik, die (Shard 0-9) im Namen enthält, misst die Leistung für einen einzelnen Shard in einem Cache. Wenn z. B. ein Cache vier Shards enthält, ist Cache Hits die Gesamtanzahl der Treffer für den gesamten Cache, und Cache Hits (Shard 3) misst lediglich die Treffer für dieses Shard des Caches an.

Wählen Sie im Ressourcenmenü links Metriken unter Überwachung aus. Hier entwerfen Sie Ihr eigenes Diagramm für Ihren Cache, definieren den Metriktyp und den Aggregationstyp.

Aggregationstypen

Allgemeine Informationen zu Aggregationstypen finden Sie unter Konfigurieren der Aggregation.

Unter normalen Cachebedingungen sind Average und Max ähnlich, da nur der primäre Knoten diese Metriken ausgibt. In einem Szenario, in dem sich die Anzahl der verbundenen Clients schnell ändert, zeigen Max., Average und Min unterschiedliche Werte, und dies ist auch das erwartete Verhalten.

Die Typen Count und Sum können bei bestimmten Metriken irreführend sein, z. B. bei verbundenen Clients. Daher wird empfohlen, sich die Average-Metriken und nicht die Sum-Metriken anzusehen.

Hinweis

Selbst wenn keine der mit dem Cache verbundenen Clientanwendungen aktiv ist, wird möglicherweise Cacheaktivität angezeigt, wie z. B. verbundene Clients, Arbeitsspeicherauslastung und Vorgänge, die gerade ausgeführt werden. Die Aktivität ist im Cachebetrieb normal.

Für nicht gruppierte Caches wird empfohlen, die Metriken ohne das Suffix Instance Based zu verwenden. Verwenden Sie beispielsweise die Metrik Serverlast, um die Serverauslastung für Ihre Cache-Instanz zu überprüfen.

Verwenden Sie für gruppierte Caches dagegen die Metriken mit dem Suffix Instance Based. Fügen Sie dann eine Aufteilung oder einen Filter für hinzu „ShardId“. Um beispielsweise die Serverauslastung von Shard 1 zu überprüfen, verwenden Sie die Metrik Serverlast (instanzbasiert) und wenden dann den Filter ShardId = 1 an.

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.

Log Analytics-Abfragen

Hinweis

Ein Tutorial zur Verwendung von Azure Log Analytics finden Sie unter Übersicht über Log Analytics in Azure Monitor. Denken Sie daran, dass es bis zu 90 Minuten dauern kann, bis Protokolle in Log Analtyics angezeigt werden.

Hier sind einige grundlegende Abfragen, die als Modelle verwendet werden sollten.

Abfragen für die Tarife „Basic“, „Standard“ und „Premium“

• Azure Cache für Redis-Clientverbindungen pro Stunde innerhalb des angegebenen IP-Adressbereichs:

let IpRange = "10.1.1.0/24";
ACRConnectedClientList
// For particular datetime filtering, add '| where TimeGenerated between (StartTime .. EndTime)'
| where ipv4_is_in_range(ClientIp, IpRange)
| summarize ConnectionCount = sum(ClientCount) by TimeRange = bin(TimeGenerated, 1h)

• Eindeutige Redis-Client-IP-Adressen, die mit dem Cache verbunden sind:

ACRConnectedClientList
| summarize count() by ClientIp

Abfragen für die Tarife „Enterprise“ und „Enterprise Flash“

• Azure Cache for Redis-Clientverbindungen pro Stunde innerhalb des angegebenen IP-Adressbereichs:

REDConnectionEvents
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
| where EventType == "new_conn"
| summarize ConnectionCount = count() by TimeRange = bin(EventTime, 1h)

• Azure Cache for Redis-Authentifizierungsanforderungen pro Stunde innerhalb des angegebenen IP-Adressbereichs:

REDConnectionEvents
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| where EventType == "auth"
| summarize AuthenticationRequestsCount = count() by TimeRange = bin(EventTime, 1h)

• Eindeutige Redis-Client-IP-Adressen, die mit dem Cache verbunden sind:

REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus :
// 0    AUTHENTICATION_FAILED    -    Invalid username and/or password.
// 1    AUTHENTICATION_FAILED_TOO_LONG    -    Username or password are too long.
// 2    AUTHENTICATION_NOT_REQUIRED    -    Client tried to authenticate, but authentication isn’t necessary.
// 3    AUTHENTICATION_DIRECTORY_PENDING    -    Attempting to receive authentication info from the directory in async mode.
// 4    AUTHENTICATION_DIRECTORY_ERROR    -    Authentication attempt failed because there was a directory connection error.
// 5    AUTHENTICATION_SYNCER_IN_PROGRESS    -    Syncer SASL handshake. Return SASL response and wait for the next request.
// 6    AUTHENTICATION_SYNCER_FAILED    -    Syncer SASL handshake. Returned SASL response and closed the connection.
// 7    AUTHENTICATION_SYNCER_OK    -    Syncer authenticated. Returned SASL response.
// 8    AUTHENTICATION_OK    -    Client successfully authenticated.
| where EventType == "auth" and EventStatus == 2 or EventStatus == 8 or EventStatus == 7
| summarize count() by ClientIp

• Fehlgeschlagene Authentifizierungsversuche im Cache

REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus : 
// 0    AUTHENTICATION_FAILED    -    Invalid username and/or password.
// 1    AUTHENTICATION_FAILED_TOO_LONG    -    Username or password are too long.
// 2    AUTHENTICATION_NOT_REQUIRED    -    Client tried to authenticate, but authentication isn’t necessary.
// 3    AUTHENTICATION_DIRECTORY_PENDING    -    Attempting to receive authentication info from the directory in async mode.
// 4    AUTHENTICATION_DIRECTORY_ERROR    -    Authentication attempt failed because there was a directory connection error.
// 5    AUTHENTICATION_SYNCER_IN_PROGRESS    -    Syncer SASL handshake. Return SASL response and wait for the next request.
// 6    AUTHENTICATION_SYNCER_FAILED    -    Syncer SASL handshake. Returned SASL response and closed the connection.
// 7    AUTHENTICATION_SYNCER_OK    -    Syncer authenticated. Returned SASL response.
// 8    AUTHENTICATION_OK    -    Client successfully authenticated.
| where EventType == "auth" and EventStatus != 2 and EventStatus != 8 and EventStatus != 7
| project ClientIp, EventStatus, ConnectionId

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.

Erstellen von Warnungen

Sie können die Konfiguration so durchführen, dass Warnungen basierend auf Metriken und Aktivitätsprotokollen empfangen werden. Mit Azure Monitor können Sie eine Warnung so konfigurieren, dass Folgendes erfolgt, wenn sie ausgelöst wird:

• Senden einer E-Mail-Benachrichtigung
• Aufrufen eines Webhooks
• Aufrufen einer Azure-Logik-App

Um Warnungen für den Cache zu konfigurieren, wählen Sie Warnungen unter Überwachung im Ressourcenmenü aus.

Gängige Azure Cache for Redis-Warnungsregeln

Die folgende Tabelle enthält allgemeine und empfohlene Warnungsregeln für Azure Cache for Redis.

Warnungstyp	Condition	BESCHREIBUNG
Metrik	Wartezeit 99. Perzentil	Warnung bei der im ungünstigsten Fall auftretende Wartezeit von serverseitigen Befehlen in Azure Cache for Redis-Instanzen. Die Latenz wird mithilfe von PING-Befehlen und der Nachverfolgung der Antwortzeiten gemessen. Verfolgen Sie die Integrität Ihrer Cacheinstanz nach und stellen Sie fest, ob Befehle mit einer langen Ausführungszeit die Wartezeitleistung beeinträchtigen.
Metrik	Hoher Server Load-Verbrauch oder Spitzen	Eine hohe Serverlast bedeutet, dass der Redis-Server nicht mit Anforderungen Schritt halten kann, was zu Timeouts oder langsamen Reaktionen führt. Erstellen Sie Warnungen für Metriken wie Serverlastmetriken, um frühzeitig über mögliche Beeinträchtigungen benachrichtigt zu werden.
Metrik	Hohe Auslastung der Netzwerkbandbreite	Wenn der Server die verfügbare Bandbreite überschreitet, werden die Daten nicht so schnell an den Client gesendet wie erwartet. Bei Anforderungen von Clients kann es zu Timeouts kommen, weil der Server die Daten nicht schnell genug an den Client übertragen kann. Richten Sie Warnungen für serverseitige Netzwerkbandbreitenbeschränkungen mithilfe der Zähler Cache Read und Cache Write ein.

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.

Der folgende Screenshot zeigt eine Advisor-Empfehlung für eine Azure Cache for Redis-Warnung:

Wählen Sie zum Upgraden Ihres Caches die Option Jetzt aktualisieren aus, um den Tarif zu ändern und Ihren Cache zu skalieren. Weitere Informationen zur Tarifauswahl finden Sie unter Auswählen des richtigen Tarifs.

Zugehöriger Inhalt

• Eine Referenz der Metriken, Protokolle und anderer wichtiger Werte, die für Azure Cache for Redis erstellt wurden, finden Sie unter Azure Cache for Redis-Überwachungsdatenreferenz.
• Allgemeine Informationen zur Überwachung von Azure-Ressourcen finden Sie unter Überwachen von Azure-Ressourcen mit Azure Monitor.