Behandeln von Protokollsuchwarnungen in Azure Monitor

In diesem Artikel wird beschrieben, wie Sie häufig auftretende Probleme mit Protokollsuchwarnungen in Azure Monitor beheben. Er bietet auch Lösungen für häufig auftretende Probleme bezüglich der Funktionalität und der Konfiguration von Protokollwarnungen.

Mithilfe von Protokollwarnungen können Sie eine Log Analytics-Abfrage verwenden, um Ressourcenprotokolle mit einer bestimmten Häufigkeit auszuwerten und basierend auf den Ergebnissen eine Warnung auszulösen. Durch Regeln können über Aktionsgruppen einzelne oder mehrere Aktionen ausgelöst werden. Weitere Informationen zur Funktionalität und Terminologie von Protokollsuchwarnungen finden Sie unter Protokollsuchwarnungen in Azure Monitor.

Hinweis

In diesem Artikel werden keine Fälle erläutert, in denen die Warnungsregel ausgelöst wurde und Sie diese im Azure-Portal sehen können, aber keine Benachrichtigung gesendet wurde. Informationen zu solchen Fällen finden Sie unter Behandeln von Problemen bei Warnungen.

Eine Protokollsuchwarnung wurde fälschlicherweise nicht ausgelöst

Wenn die Protokollsuche fälschlicherweise nicht ausgelöst wurde, überprüfen Sie die folgenden Elemente:

1. Ist der Integritätszustand der Warnungsregel beeinträchtigt oder nicht verfügbar?

   Zeigen Sie den Integritätsstatus Ihrer Warnungsregel für die Protokollsuche an:

   1. Navigieren Sie im Portal zu Überwachen, dann Warnungen.

   2. Wählen Sie auf der oberen Befehlsleiste Warnungsregeln aus. Auf der Seite werden alle Ihre Warnungsregeln für alle Abonnements angezeigt.

   3. Wählen Sie die Regel für Protokollsuchwarnungen aus, die Sie überwachen möchten.

   4. Wählen Sie im linken Bereich unter Hilfe die Option Ressourcenintegrität aus.

      

   Weitere Informationen finden Sie unter Überwachen der Integrität von Regeln für Protokollsuchwarnungen.

2. Überprüfen Sie die Latenz bei der Protokollerfassung.

   Mit Azure Monitor werden Kundenprotokolle im Terabytebereich verarbeitet, die aus der ganzen Welt stammen, und dies kann zu Latenz bei der Protokollerfassung führen.

   Bei Protokollen handelt es sich um teilweise strukturierte Daten, die eine höhere Latenz aufweisen als Metriken. Wenn es für ausgelöste Warnungen zu einer Verzögerung von mehr als vier Minuten kommt, sollten Sie die Verwendung von Metrikwarnungen erwägen. Sie können Daten aus Protokollen an den Metrikspeicher senden, indem Sie Metrikwarnungen für Protokolle verwenden.

   Die Bewertung von Warnungen wird bei Bedarf mehrmals wiederholt, um die Latenz zu verringern. Sobald die Daten empfangen werden, wird die Warnung ausgelöst. In den meisten Fällen entspricht dies nicht der Dauer für die Protokollaufzeichnung.

3. Sind die Aktionen stummgeschaltet, oder wurde die Regel so konfiguriert, dass Warnungen automatisch aufgelöst werden?

   Häufig wird fälschlicherweise vermutet, dass die Warnung nicht ausgelöst wurde. Tatsächlich wurde die Regel jedoch so konfiguriert, dass die Warnung nicht ausgelöst wird. Sehen Sie sich die erweiterten Optionen der Regel für Protokollsuchwarnungen an, um zu überprüfen, dass keine der beiden folgenden Optionen ausgewählt ist:

   • Mit dem Kontrollkästchen Aktionen unterdrücken können Sie ausgelöste Warnungsaktionen für einen festgelegten Zeitraum stummschalten.
   • Mit dem Kontrollkästchen Warnungen automatisch auflösen konfigurieren Sie die Regel so, dass nur eine Warnung pro erfüllter Bedingung ausgelöst wird.

   

4. Wurde die Ressource für die Warnungsregel verschoben oder gelöscht?

   Wenn die Ressource der Warnungsregel verschoben, umbenannt oder gelöscht wird, kommt es für alle Protokollwarnungsregeln, die auf diese Ressource verweisen, zu einem Fehler. Um dieses Problem zu beheben, müssen Warnungsregeln mithilfe einer gültigen Zielressource für den Bereich neu erstellt werden.

5. Verwendet die Warnungsregel eine systemseitig zugewiesene verwaltete Identität?

   Wenn Sie eine Protokollwarnungsregel mit systemseitig zugewiesener verwalteter Identität erstellen, wird die Identität ohne Berechtigungen erstellt. Nachdem Sie die Regel erstellt haben, müssen Sie der Identität der Regel die entsprechenden Rollen zuweisen, damit sie auf die Daten zugreifen kann, die Sie abfragen möchten. Beispielsweise kann es erforderlich sein, ihr eine Leserrolle für die relevanten Log Analytics-Arbeitsbereiche oder eine Leserrolle und eine Datenbank-Viewer-Rolle für den relevanten ADX-Cluster zuzuweisen. Weitere Informationen zur Verwendung von verwalteten Identitäten in Protokollwarnungen finden Sie unter verwaltete Identitäten.

6. Ist die in der Warnungsregel für die Protokollsuche verwendete Abfrage gültig?

   Wenn eine Protokollwarnungsregel erstellt wird, wird die Abfrage auf die richtige Syntax überprüft. Es kann jedoch vorkommen, dass für die in der Protokollwarnungsregel angegebene Abfrage ein Fehler auftritt. Häufige Gründe:

   • Regeln wurden über die API erstellt, und die Überprüfung wurde vom Benutzer übersprungen.
   • Die Abfrage wird auf mehreren Ressourcen ausgeführt, und mindestens eine der Ressourcen wurde gelöscht oder verschoben.
   • Für die Abfrage tritt ein Fehler auf, weil Folgendes passiert:
     • Da die Protokollierungslösung nicht im Arbeitsbereich bereitgestellt wurde, werden keine Tabellen erstellt.
     • Seit über 30 Tagen sind in eine Tabelle in der Abfrage keine Daten mehr geflossen.
     • Es wurden keine benutzerdefinierten Protokolltabellen erstellt, da der Datenfluss noch nicht gestartet wurde.
   • Änderungen an der Abfragesprache beinhalten ein überarbeitetes Format für Befehle und Funktionen, sodass die zuvor bereitgestellte Abfrage nicht mehr gültig ist.

   Azure Advisor warnt Sie vor diesem Verhalten. Es wird eine Empfehlung zur betroffenen Regel für Protokollsuchwarnungen hinzugefügt. Als Kategorie wird „Hochverfügbarkeit“ mit mittlerer Auswirkung und zusätzlich die Beschreibung „Reparieren Ihrer Protokollwarnungsregel, um die Überwachung sicherzustellen“ verwendet.

7. Wurde die Warnungsregel für die Protokollsuche deaktiviert?

   Wenn bei der Abfrage einer Warnungsregel für die Protokollsuche eine Woche lang kontinuierlich ein Fehler auftritt, wird sie von Azure Monitor automatisch deaktiviert.

   In den folgenden Abschnitten sind einige Gründe aufgeführt, warum Azure Monitor eine Regel für Protokollsuchwarnungen allenfalls deaktiviert. Außerdem finden Sie hier ein Beispiel für das Aktivitätsprotokollereignis, das gesendet wird, wenn die Regel deaktiviert wird.

Aktivitätsprotokollbeispiel bei Deaktivierung der Regel

{
    "caller": "Microsoft.Insights/ScheduledQueryRules",
    "channels": "Operation",
    "claims": {
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
    },
    "correlationId": "abcdefg-4d12-1234-4256-21233554aff",
    "description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing consistently with the same exception for the past week",
    "eventDataId": "f123e07-bf45-1234-4565-123a123455b",
    "eventName": {
        "value": "",
        "localizedValue": ""
    },
    "category": {
        "value": "Administrative",
        "localizedValue": "Administrative"
    },
    "eventTimestamp": "2019-03-22T04:18:22.8569543Z",
    "id": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "level": "Informational",
    "operationId": "",
    "operationName": {
        "value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
    },
    "resourceGroupName": "<Resource Group>",
    "resourceProviderName": {
        "value": "MICROSOFT.INSIGHTS",
        "localizedValue": "Microsoft Insights"
    },
    "resourceType": {
        "value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
        "localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
    },
    "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "status": {
        "value": "Succeeded",
        "localizedValue": "Succeeded"
    },
    "subStatus": {
        "value": "",
        "localizedValue": ""
    },
    "submissionTimestamp": "2019-03-22T04:18:22.8569543Z",
    "subscriptionId": "<SubscriptionId>",
    "properties": {
        "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
        "subscriptionId": "<SubscriptionId>",
        "resourceGroup": "<ResourceGroup>",
        "eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
        "eventTimeStamp": "03/22/2019 04:18:22",
        "issueStartTime": "03/22/2019 04:18:22",
        "operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "status": "Succeeded",
        "reason": "Alert has been failing consistently with the same exception for the past week"
    },
    "relatedEvents": []
}

Eine Protokollsuchwarnung wurde fälschlicherweise ausgelöst

Unter Umständen wird unerwarteterweise eine konfigurierte Protokollwarnungsregel in Azure Monitor ausgelöst. In den folgenden Abschnitten werden einige häufige Gründe beschrieben.

1. Wurde die Warnung aufgrund von Latenzproblemen ausgelöst?

   Mit Azure Monitor werden weltweit Kundenprotokolle im Terabytebereich verarbeitet. Dies kann zu Latenz bei der Protokollerfassung führen. Zwar sind integrierte Funktionen zum Verhindern von falschen Warnungen vorhanden, diese können für Daten mit sehr hoher Latenz (mehr als ca. 30 Minuten) und mit Latenzspitzen jedoch trotzdem auftreten.

   Bei Protokollen handelt es sich um teilweise strukturierte Daten, die eine höhere Latenz aufweisen als Metriken. Falls bei Ihnen viele Warnungen fälschlicherweise ausgelöst werden, sollten Sie erwägen, Metrikwarnungen zu nutzen. Sie können Daten aus Protokollen an den Metrikspeicher senden, indem Sie Metrikwarnungen für Protokolle verwenden.

   Protokollsuchwarnungen funktionieren am besten, wenn Sie versuchen, bestimmte Daten in den Protokollen zu erkennen. Sie sind weniger effektiv, wenn Sie versuchen, in den Protokollen das Fehlen von Daten zu erkennen, z. B. Warnungen zum VM-Heartbeat.

Fehlermeldungen beim Konfigurieren von Warnungsregeln für die Protokollsuche

In den folgenden Abschnitten finden Sie spezifische Fehlermeldungen und dazu passende Lösungsvorschläge.

Die Abfrage konnte nicht validiert werden, weil Sie Berechtigungen für die Protokolle benötigen

Wenn beim Erstellen oder Bearbeiten der Abfrage für die Warnungsregel diese Fehlermeldung angezeigt wird, stellen Sie sicher, dass Sie über Berechtigungen zum Lesen der Zielressourcenprotokolle verfügen.

• Erforderliche Berechtigungen zum Lesen von Protokollen im Zugriffsmodus „Arbeitsbereichskontext“: Microsoft.OperationalInsights/workspaces/query/read
• Erforderliche Berechtigungen zum Lesen von Protokollen im Zugriffsmodus „Ressourcenkontext“ (einschließlich arbeitsbereichsbasierter Application Insights-Ressource): Microsoft.Insights/logs/tableName/read

Weitere Informationen zu Berechtigungen finden Sie unter Verwalten des Zugriffs auf Log Analytics-Arbeitsbereiche.

Die 1-Minuten-Frequenz wird für diese Abfrage nicht unterstützt

Es gibt einige Einschränkungen bei der Verwendung einer Warnungsregelfrequenz von einer Minute. Wenn Sie die Warnungsregelfrequenz auf eine Minute festlegen, wird eine interne Manipulation zur Optimierung der Abfrage durchgeführt. Diese Manipulation kann dazu führen, dass die Abfrage fehlschlägt, wenn sie nicht unterstützte Vorgänge enthält.

Eine Liste der nicht unterstützten Szenarios finden Sie in diesem Hinweis.

Der Skalarausdruck namens <> konnte nicht aufgelöst werden

Diese Fehlermeldung kann in folgenden Fällen beim Erstellen oder Bearbeiten der Warnungsregelabfrage zurückgegeben werden:

• Sie verweisen auf eine Spalte, die im Tabellenschema nicht vorhanden ist.
• Sie verweisen auf eine Spalte, die in einer früheren Projektklausel der Abfrage nicht verwendet wurde.

Um dieses Problem zu beheben, können Sie die Spalte entweder zur vorherigen Projektklausel hinzufügen oder den Operator columnifexists verwenden.

Die ScheduledQueryRules-API wird für schreibgeschützte OMS-Warnungen nicht unterstützt

Diese Fehlermeldung wird zurückgegeben, wenn Sie versuchen, mithilfe des Azure-Portals Regeln zu aktualisieren oder zu löschen, die mit der Legacy-API-Version erstellt wurden.

1. Bearbeiten oder löschen Sie die Regel programmgesteuert mithilfe der Log Analytics-REST-API.
2. Empfohlen: Führen Sie ein Upgrade Ihrer Warnungsregeln durch, um die API für geplante Abfrageregeln zu verwenden (die Legacy-API wird nicht mehr weiterentwickelt).

Der Grenzwert für den Warnungsregeldienst wurde erreicht.

Einzelheiten zur Anzahl von Warnungsregeln für die Protokollsuche pro Abonnement und die Höchstwerte für Ressourcen finden Sie unter Azure Monitor-Diensteinschränkungen. Unter Überprüfen der Gesamtanzahl der verwendeten Protokollwarnungsregeln finden Sie Informationen darüber, wie Sie sehen können, wie viele Metrikwarnungsregeln derzeit verwendet werden. Wenn Sie die Kontingentgrenze erreicht haben, helfen Ihnen die folgenden Schritte ggf. bei der Problembehebung.

1. Löschen oder deaktivieren Sie Warnungsregeln für die Protokollsuche, die nicht mehr verwendet werden.

2. Verwenden Sie die Aufteilung nach Dimensionen, um die Anzahl der Regeln zu reduzieren. Wenn Sie die Aufteilung nach Dimensionen verwenden, kann eine Regel viele Ressourcen überwachen.

3. Wenn die Kontingentgrenze erhöht werden muss, können Sie damit fortfahren, eine Supportanfrage mit den folgenden Informationen zu erstellen:

   • Abonnement-IDs und Ressourcen-IDs, für die die Kontingentgrenze erhöht werden muss
   • Grund für die Kontingenterhöhung
   • Ressourcentyp für die Kontingenterhöhung, z. B. Log Analytics oder Application Insights
   • Angeforderte Kontingentgrenze

Nächste Schritte

• Erfahren Sie mehr über Protokollwarnungen in Azure.
• Informieren Sie sich über das Konfigurieren von Protokollwarnungen.
• Weitere Informationen zum Analysieren von Protokolldaten in Azure Monitor.