Auswählen des richtigen Warnungsregeltyps

  • Artikel

In diesem Artikel werden die Arten von Azure Monitor-Warnungen beschrieben, die Sie erstellen können. Er hilft Ihnen zu verstehen, wann die einzelnen Warnungstypen verwendet werden. Weitere Informationen zu den Preisen finden Sie auf der Seite mit den Preisen.

Es gibt folgende Arten von Warnungen:

Typen von Azure Monitor-Warnungen

Warnungstyp Verwendung Preisinformationen
Metrikwarnung Metrikdaten sind im System bereits vorberechnet gespeichert. Metrikwarnungen sind nützlich, wenn Sie über Daten benachrichtigt werden möchten, die wenig oder keine Bearbeitung erfordern. Verwenden Sie Metrikwarnungen, wenn die Daten, die Sie überwachen möchten, in Metrikdaten verfügbar sind. Jede Metrikwarnungsregel wird basierend auf der Anzahl der Zeitreihen berechnet, die überwacht werden.
Protokollsuchwarnung Sie können Protokollsuchwarnungen verwenden, um erweiterte logische Vorgänge auf Ihren Daten auszuführen. Wenn die Daten, die Sie überwachen möchten, in Protokollen verfügbar sind oder erweiterte Logik erfordern, können Sie die robusten Features der Kusto-Abfragesprache (Kusto Query Language, KQL) für die Datenbearbeitung mittels Protokollsuchwarnungen verwenden. Jede Regel für Protokollsuchwarnungen wird basierend auf dem Intervall in Rechnung gestellt, in dem die Protokollabfrage ausgewertet wird. Eine häufigere Abfrageauswertung führt zu höheren Kosten. Bei Protokollsuchwarnungen, welche für die Überwachung im großen Stil mittels Aufteilung nach Dimensionen konfiguriert sind, hängen die Kosten auch von der Anzahl der Zeitreihen ab, die von den Dimensionen erstellt werden, die sich aus Ihrer Abfrage ergeben.
Aktivitätsprotokollwarnung Aktivitätsprotokolle stellen die Überwachung aller Aktionen bereit, die auf Ressourcen aufgetreten sind. Verwenden Sie Aktivitätsprotokollwarnungen, um benachrichtigt zu werden, wenn ein bestimmtes Ereignis für eine Ressource eintritt (also beispielsweise bei einem Neustart, beim Herunterfahren oder beim Erstellen oder Löschen einer Ressource). Service Health- und Resource Health-Warnungen können Sie darüber informieren, dass ein Problem mit einem Ihrer Dienste oder einer Ihrer Ressourcen vorliegt. Weitere Informationen hierzu finden Sie in der Preisübersicht.
Prometheus-Warnungen Prometheus-Warnungen basieren auf Prometheus-Metriken, die in verwalteten Azure Monitor-Diensten für Prometheus gespeichert sind. Die Warnungsregeln basieren auf PromQL, einer Open Source-Abfragesprache. Prometheus-Warnungsregeln werden nur für die Daten in Rechnung gestellt, die von den Regeln abgefragt werden. Weitere Informationen hierzu finden Sie in der Preisübersicht.

Metrikwarnungen

Eine Metrikwarnungsregel überwacht eine Ressource, indem Die Bedingungen für die Ressourcenmetriken in regelmäßigen Abständen ausgewertet werden. Wenn die Bedingungen erfüllt sind, wird eine Warnung ausgelöst. Bei einer Metrikzeitreihe handelt es sich um eine Reihe von Metrikwerten, die über einen Zeitraum erfasst werden.

Sie können Regeln mithilfe dieser Metriken erstellen:

Metrikwarnungsregeln umfassen folgende Features:

Das Ziel der Metrikwarnungsregel kann Folgendes sein:

Anwenden mehrerer Bedingungen auf eine metrische Warnungsregel

Wenn Sie eine Warnungsregel für eine einzelne Ressource erstellen, können Sie mehrere Bedingungen anwenden. Sie können beispielsweise eine Warnungsregel erstellen, um eine Azure-VM zu überwachen und eine Warnung ausgeben, wenn sowohl „Prozentualer CPU-Anteil ist höher als 90 %“ als auch „Warteschlange enthält mehr als 300 Elemente“ eintritt. Wenn eine Warnungsregel mehrere Bedingungen aufweist, wird die Warnung ausgelöst, wenn alle Bedingungen in der Warnungsregel wahr sind, und sie wird aufgelöst, wenn mindestens eine der Bedingungen für drei aufeinander folgende Prüfungen nicht mehr wahr ist.

Einschränken des Ziels mithilfe von Dimensionen

Anweisungen zum Verwenden von Dimensionen in Metrikwarnungsregeln finden Sie unter Überwachung mehrerer Zeitreihen in einer einzigen metrischen Warnregel.

Überwachen der gleichen Bedingung für mehrere Ressourcen mithilfe der Aufteilung nach Dimensionen

Um die gleiche Bedingung für mehrere Azure-Ressourcen zu überwachen, können Sie das Teilen nach Dimensionen verwenden. Das Aufteilen nach Dimensionen ermöglicht es Ihnen, ressourcenzentrierte Warnungen im großen Stil für ein Abonnement oder eine Ressourcengruppe zu erstellen. Warnungen werden durch Gruppierungskombinationen in separate Warnungen unterteilt. Wenn Sie die Aufteilung auf der Grundlage der Spalte für die Azure-Ressourcen-ID aufteilen, wird die angegebene Ressource zum Warnungsziel.

Sie können sich auch dafür entscheiden, keine Teilung vorzunehmen, wenn Sie eine Bedingung auf mehrere Ressourcen in dem Bereich anwenden möchten. Es kann beispielsweise wünschenswert sein, eine Warnung auszulösen, wenn mindestens fünf Computer im Ressourcengruppenbereich eine CPU-Auslastung von über 80 % aufweisen.

Überwachen mehrerer Ressourcen mit einer Warnungsregel

Sie können im großen Stil überwachen, indem Sie dieselbe Metrikwarnungsregel auf mehrere Ressourcen desselben Typs für Ressourcen anwenden, die in derselben Azure-Region vorhanden sind. Für jede überwachte Ressource werden einzelne Benachrichtigungen gesendet.

Die Plattformmetriken für diese Dienste in den folgenden Azure-Clouds werden unterstützt:

Dienst Ressourcenanbieter Globale Azure-Umgebung Behörden China
Virtuelle Computer Microsoft.Compute/virtualMachines Ja Ja Ja
SQL Server-Datenbanken Microsoft.Sql/servers/databases Ja Ja Ja
Pools für elastische SQL-Datenbanken Microsoft.Sql/servers/elasticpools Ja Ja Ja
NetApp Files-Kapazitätspools Microsoft.NetApp/netAppAccounts/capacityPools Ja Ja Ja
NetApp Files-Volumes Microsoft.NetApp/netAppAccounts/capacityPools/volumes Ja Ja Ja
Azure Key Vault Microsoft.KeyVault/vaults Ja Ja Ja
Azure Cache for Redis Microsoft.Cache/redis Ja Ja Ja
Azure Stack Edge-Geräte (Für diese Ressource ist kein bestimmter Ressourcenanbieter vorhanden. Aufgrund der Funktionsweise von Stack Edge-Geräten werden die Metriken von mehreren Ressourcenanbietern abgerufen. Ausführlichere Informationen zu Warnungen für diese Ressource finden Sie in dieser Dokumentation: Überprüfen von Warnungen in Azure Stack Edge.) Ja Ja Ja
Recovery Services-Tresore Microsoft.RecoveryServices/Vaults Ja Nr. Nein
Azure Database for PostgreSQL – Flexible Server Microsoft.DBforPostgreSQL/flexibleServers Ja Ja Ja
Bare-Metal-Maschinen (Operator Nexus) Microsoft.NetworkCloud/bareMetalMachines Ja Ja Ja
Speichergeräte (Operator Nexus) Microsoft.NetworkCloud/storageAppliances Ja Ja Ja
Cluster (Operator Nexus) Microsoft.NetworkCloud/clusters Ja Ja Ja
Netzwerkgeräte (Operator Nexus) Microsoft.NetworkCloud/l2Networks, Microsoft.NetworkCloud/l3Networks Ja Ja Ja
Regeln für die Datensammlung Microsoft.Insights/datacollectionrules Ja Ja Ja

Hinweis

Metrikwarnungen mit mehreren Ressourcen werden für Folgendes nicht unterstützt:

  • Warnungen für VM-Gastmetriken.
  • Warnmeldungen für Netzwerkmetriken virtueller Computer („Eingehender Netzwerkdatenverkehr gesamt“, „Ausgehender Netzwerkverkehr gesamt“, „Eingehende Datenflüsse“, „Ausgehende Datenflüsse“, „Maximale Erstellungsrate für eingehende Datenflüsse“, „Maximale Erstellungsrate für ausgehende Datenflüsse“)

Sie können den Bereich für die Überwachung mit einer einzelnen Metrikwarnungsregel auf drei Arten angeben. Bei virtuellen Computern können Sie den Bereich beispielsweise wie folgt angeben:

  • Als Liste virtueller Computer in einer einzelnen Azure-Region innerhalb eines Abonnements
  • Als alle virtuellen Computer in einer einzelnen Azure-Region in einer oder mehreren Ressourcengruppen eines Abonnements
  • Als virtuelle Computer in einer einzelnen Azure-Region in einem Abonnement

Anwenden von erweitertem maschinellem Lernen mit dynamischen Schwellenwerten

Dynamische Schwellwerte verwenden erweitertes maschinelles Lernen für:

  • Erlernen des historischen Verhaltens von Metriken.
  • Ermitteln von Mustern und Anpassen an Metrikänderungen im Laufe der Zeit, z. B. stündliche, tägliche oder wöchentliche Muster.
  • Erkennen von Anomalien, die auf mögliche Dienstprobleme hinweisen.
  • Berechnen des am besten geeigneten Schwellenwerts für die Metrik.

Machine Learning verwendet kontinuierlich neue Daten, um mehr zu erfahren und den Schwellenwert genauer zu gestalten. Da sich das System im Laufe der Zeit an das Verhalten der Metriken anpasst und Warnungen basierend auf Musterabweichungen ausgibt, müssen Sie nicht den passenden Schwellenwert für jede Metrik kennen.

Dynamische Schwellwerte helfen Ihnen bei Folgendem:

  • Erstellen Sie skalierbare Warnungen für Hunderte von Metrikreihen mit einer Warnungsregel. Wenn Sie weniger Warnungsregeln nutzen, verbringen Sie weniger Zeit mit dem Erstellen und Verwalten von Warnungsregeln.
  • Erstellen von Regeln, ohne wissen zu müssen, welcher Schwellenwert konfiguriert werden soll.
  • Konfigurieren von Metrikwarnungen mithilfe von übergeordneten Konzepten ohne umfangreiches Domänenwissen über die Metrik.
  • Verhindern von zu eng (geringe Genauigkeit) oder zu weit gefassten (geringe Abrufe) Schwellenwerten ohne erwartetes Muster.
  • Handhaben Sie ausführliche Metriken (z. B. Computer-CPU oder Arbeitsspeicher) und Metriken mit geringer Verteilung (z. B. Verfügbarkeit und Fehlerrate).

Unter Dynamische Schwellenwerte in Metrikwarnungen finden Sie eine ausführliche Anleitung zur Verwendung von dynamischen Schwellwerten in Metrikwarnungsregeln.

Protokollsuchwarnungen

Eine Regel für Protokollsuchwarnungen überwacht eine Ressource mithilfe einer Log Analytics-Abfrage, um Ressourcenprotokolle mit einer festgelegten Häufigkeit auszuwerten. Wenn die Bedingungen erfüllt sind, wird eine Warnung ausgelöst. Da Sie Log Analytics-Abfragen verwenden können, können Sie erweiterte logische Vorgänge mit Ihren Daten durchführen und die robusten KQL-Funktionen für die Bearbeitung von Protokolldaten nutzen.

Das Ziel der Regel für Protokollsuchwarnungen kann Folgendes sein:

  • Eine einzelne Ressource, z. B. eine VM.
  • Ein einzelner Ressourcencontainer, z. B. eine Ressourcengruppe oder ein Abonnement.
  • Mehrere Ressourcen, die eine ressourcenübergreifende Abfrage verwenden

Mit Protokollsuchwarnungen können zwei verschiedene Dinge gemessen werden, die für unterschiedliche Überwachungsszenarien verwendet werden können:

  • Tabellenzeilen: Die Anzahl der zurückgegebenen Zeilen kann für die Arbeit mit Ereignissen wie Windows-Ereignisprotokollen, Syslog und Anwendungsausnahmen verwendet werden.
  • Berechnung einer numerischen Spalte: Berechnungen basierend auf jeder beliebigen numerischen Spalte können verwendet werden, um eine beliebige Anzahl von Ressourcen einzuschließen. Ein Beispiel ist die prozentuale CPU-Auslastung.

Sie können konfigurieren, ob Protokollsuchwarnungen zustandsbehaftet oder zustandslos sind.
Beachten Sie, dass zustandsbehaftete Protokollsuchwarnungen die folgenden Einschränkungen haben:

  • sie können bis zu 300 Warnungen pro Auswertung auslösen.
  • Sie können maximal 5000 Warnungen mit der fired Warnungsbedingung haben.

Hinweis

Protokollsuchwarnungen funktionieren am besten, wenn Sie versuchen, bestimmte Daten in den Protokollen zu erkennen, anstatt zu versuchen, fehlende Daten in den Protokollen zu erkennen. Da Protokolle halbstrukturierte Daten sind, sind sie inhärent latenter als Metrikdaten zu Informationen wie einem VM-Heartbeat. Wenn Sie versuchen, fehlende Daten in den Protokollen zu erkennen, sollten Sie Metrikwarnungen verwenden, um Falschwarnungen zu vermeiden. Sie können Daten aus Protokollen an den Metrikspeicher senden, indem Sie Metrikwarnungen für Protokolle verwenden.

Überwachen mehrerer Instanzen einer Ressource mithilfe von Dimensionen

Sie können Dimensionen verwenden, wenn Sie Regeln für Protokollsuchwarnungen erstellen, um die Werte mehrerer Instanzen einer Ressource mit einer Regel zu überwachen. Sie können beispielsweise die CPU-Auslastung auf mehreren Instanzen überwachen, auf denen Ihre Website oder App ausgeführt werden. Jede Instanz wird einzeln überwacht. Für jede Instanz werden Benachrichtigungen gesendet.

Überwachen der gleichen Bedingung für mehrere Ressourcen mithilfe der Aufteilung nach Dimensionen

Um die gleiche Bedingung für mehrere Azure-Ressourcen zu überwachen, können Sie das Teilen nach Dimensionen verwenden. Das Aufteilen nach Dimensionen ermöglicht es Ihnen, ressourcenzentrierte Warnungen im großen Stil für ein Abonnement oder eine Ressourcengruppe zu erstellen. Warnungen werden in separate Warnungen unterteilt, indem Kombinationen unter Verwendung von numerischen oder zeichenfolgenbasierten Spalten gruppiert werden. Wenn Sie die Spalte für die Azure-Ressourcen-ID teilen, wird die angegebene Ressource in das Warnungsziel umgewandelt.

Sie können sich auch dafür entscheiden, keine Teilung vorzunehmen, wenn Sie eine Bedingung auf mehrere Ressourcen in dem Bereich anwenden möchten. Es kann beispielsweise wünschenswert sein, eine Warnung auszulösen, wenn mindestens fünf Computer im Ressourcengruppenbereich eine CPU-Auslastung von über 80 % aufweisen.

Verwenden der API für Regeln für Protokollsuchwarnungen

Verwalten Sie neue Regeln in Ihren Arbeitsbereichen mithilfe der ScheduledQueryRules-API.

Hinweis

Früher wurden Protokollsuchwarnungen für Log Analytics mit der Legacy-Log Analytics-API für Warnungen verwaltet. Informieren Sie sich über den Wechsel zur aktuellen ScheduledQueryRules-API.

Protokollsuchwarnungen auf Ihrer Azure-Rechnung

Protokollsuchwarnungen werden unter dem Ressourcenanbieter microsoft.insights/scheduledqueryrules mit folgenden Angaben aufgeführt:

  • Protokollsuchwarnungen für Application Insights werden mit dem genauen Namen der Ressource zusammen mit Ressourcengruppen- und Warnungseigenschaften angezeigt.
  • Protokollsuchwarnungen in Log Analytics werden mit dem exakten Namen der Ressource zusammen mit Ressourcengruppen- und Warnungseigenschaften angezeigt, wenn sie mit der scheduledQueryRules-API erstellt werden.
  • Protokollsuchwarnungen, die mit der Legacy-Log Analytics-API erstellt werden, sind keine nachverfolgten Azure-Ressourcen und verfügen nicht über erzwungene eindeutige Ressourcennamen. Diese Warnungen werden unter microsoft.insights/scheduledqueryrules weiterhin als ausgeblendete Ressourcen erstellt und verfügen über die folgende Struktur für die Ressourcenbenennung: <WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>. Protokollsuchwarnungen in der Legacy-API werden mit dem vorherigen verborgenen Ressourcennamen zusammen mit Ressourcengruppen- und Warnungseigenschaften angezeigt.

Hinweis

Nicht unterstützte Ressourcenzeichen wie <, >, %, &, , ? und / werden in den verborgenen Ressourcennamen durch ein Unterstrichzeichen (_) ersetzt. Diese Zeichenänderung ist auch in den Abrechnungsinformationen enthalten.

Aktivitätsprotokollwarnungen

Eine Aktivitätsprotokollwarnung überwacht eine Ressource, indem sie die Aktivitätsprotokolle für ein neues Aktivitätsprotokollereignis überprüft, das den definierten Bedingungen entspricht.

Sie können Aktivitätsprotokollwarnungen für folgende Szenarien verwenden:

  • Wenn ein bestimmter Vorgang für Ressourcen in einer bestimmten Ressourcengruppe oder einem bestimmten Abonnement auftritt. Sie können beispielsweise in folgenden Fällen benachrichtigt werden:
    • Ein virtueller Computer in einer Produktionsressourcengruppe wird gelöscht.
    • Einem Benutzer in Ihrem Abonnement werden neue Rollen zugewiesen.
  • Ein Service Health-Ereignis tritt auf. Service Health-Ereignisse umfassen Benachrichtigungen bei Incidents und Wartungsereignissen für Ressourcen Ihres Abonnements.

Sie können eine Aktivitätsprotokollwarnung für Folgendes erstellen:

Warnungsregeln des Aktivitätsprotokolls sind Azure-Ressourcen, sie können also mithilfe einer Azure Resource Manager-Vorlage erstellt werden. Sie können auch im Azure-Portal erstellt, aktualisiert oder gelöscht werden.

Eine Aktivitätsprotokollwarnung überwacht nur Ereignisse in dem Abonnement, in dem die Warnung erstellt wurde.

Service Health-Warnungen

Service Health-Warnungen sind eine Art von Aktivitätswarnungen. Mit Service Health werden Sie über Ausfälle, geplante Wartungsarbeiten und andere Integritätshinweise informiert, da die authentifizierte Service Health-Umgebung weiß, welche Dienste und Ressourcen Sie derzeit verwenden.

Um Service Health optimal nutzen zu können, wird die Einrichtung von Service Health-Warnungen empfohlen, die Sie über Ihren bevorzugten Kommunikationskanal informieren, wenn Dienstprobleme, geplante Wartungen oder andere Änderungen ggf. die von Ihnen verwendeten Azure-Dienste und -Regionen beeinträchtigen.

Resource Health-Warnungen

Resource Health-Warnungen sind eine Art von Aktivitätswarnungen. Die Resource Health-Übersicht unterstützt Sie bei der Diagnose und bei Supportanfragen, wenn Dienstprobleme Auswirkungen auf Ihre Azure-Ressourcen haben. Der Dienst erstellt Berichte zur aktuellen und früheren Integrität Ihrer Ressourcen.

Resource Health ermittelt anhand von Signalen der verschiedenen Azure-Dienste, ob eine Ressource fehlerfrei ist. Wenn eine Ressource fehlerhaft ist, analysiert Resource Health weitere Informationen, um die Quelle des Problems zu bestimmen. Der Dienst erstellt auch Berichte zu Aktionen, die von Microsoft zum Beheben des Problems ergriffen werden, und gibt Aktionen an, die Sie zur Behandlung ausführen können.

Warnungen der intelligenten Erkennung

Nachdem Sie Application Insights für Ihr Projekt eingerichtet haben und Ihre App eine gewisse Menge von Daten generiert hat, benötigt die intelligente Erkennung 24 Stunden, um das normale Verhalten Ihrer App zu ermitteln. Die Leistung Ihrer App weist ein typisches Verhaltensmuster auf. Einige Anforderungen oder Abhängigkeitsaufrufe sind anfälliger für Fehler als andere, und die gesamte Fehlerrate kann mit zunehmender Auslastung steigen.

Bei der intelligenten Erkennung werden diese Anomalien mithilfe von maschinellem Lernen ermittelt. Die intelligente Erkennung überwacht die von Ihrer App erhaltenen Daten (insbesondere die Fehlerraten). Application Insights warnt Sie automatisch und nahezu in Echtzeit, wenn es für Ihre Web-App zu einer ungewöhnlichen Häufung bei den fehlgeschlagenen Anforderungen kommt.

Wenn Daten aus Ihrer Web-App bei Application Insights eingehen, wird bei der intelligenten Erkennung das aktuelle Verhalten mit den Mustern der letzten Tage verglichen. Wenn ein ungewöhnlicher Anstieg der Fehlerrate im Vergleich zur vorherigen Leistung beobachtet wird, wird eine Analyse ausgelöst.

Um Sie bei der Selektierung und Diagnose eines Problems zu unterstützen, wird in den Warnungsdetails eine Analyse der Merkmale der Fehler und der zugehörigen Anwendungsdaten bereitgestellt. Außerdem werden Links zum Application Insights-Portal zur weiteren Diagnose bereitgestellt. Dieses Feature muss nicht eingerichtet oder konfiguriert werden, da Machine Learning-Algorithmen verwendet werden, um die normale Fehlerrate zu bestimmen.

Metrikwarnungen weisen zwar auf ein mögliches Problem hin, die intelligente Erkennung startet jedoch die Diagnosearbeit für Sie. Dabei wird ein Großteil der Analysen ausgeführt, die Sie sonst selbst erledigen müssten. Die Ergebnisse werden übersichtlich und verständlich bereitgestellt, sodass Sie schnell die Ursache des Problems ermitteln können.

Die intelligente Erkennung funktioniert für Web-Apps, die in der Cloud oder auf Ihren eigenen Servern gehostet werden und Anwendungsanforderungen oder Abhängigkeitsdaten generieren.

Prometheus-Warnungen

Prometheus-Warnungen werden verwendet, um Metriken, die in verwalteten Azure Monitor-Diensten für Prometheus gespeichert sind, zu überwachen. Prometheus-Warnungsregeln werden als Teil von Prometheus-Regelgruppen konfiguriert. Sie werden ausgelöst, wenn das Ergebnis eines PromQL-Ausdrucks „true“ ergibt. Ausgelöste Prometheus-Warnungen werden wie andere Warnungstypen angezeigt und verwaltet.

Nächste Schritte