Optimieren von Abfragen für Protokollsuchewarnungen

Artikel
02/21/2024

In diesem Artikel wird beschrieben, wie Abfragen für Protokollsuchwarnungen zum Erzielen optimaler Leistung geschrieben und konvertiert werden. Optimierte Abfragen verringern die Latenz und die Auslastung durch Warnungen, die häufig ausgeführt werden.

Schreiben einer Warnungsprotokollabfrage

Warnungsabfragen beginnen mit dem Abfragen der Protokolldaten in Log Analytics, die auf das Problem hinweisen. Informationen dazu, was Sie untersuchen können, finden Sie unter Verwenden von Abfragen in Azure Monitor Log Analytics. Sie können auch mit dem Schreiben einer eigenen Abfrage beginnen.

Abfragen, die auf das Problem und nicht die Warnung hinweisen

Der Warnungsablauf wurde zum Transformieren der Ergebnisse erstellt, die auf das Problem für eine Warnung hinweisen. Ein Beispiel hierfür ist eine Abfrage der folgenden Art:

SecurityEvent
| where EventID == 4624

Wenn die Absicht des Benutzers beim Auftreten dieses Ereignistyps eine Warnung ist, wird von der Warnungslogik count an die Abfrage angefügt. Dies ist die ausgeführte Abfrage:

SecurityEvent
| where EventID == 4624
| count

Es ist nicht erforderlich, der Abfrage Warnungslogik hinzuzufügen. Dies kann sogar zu Problemen führen. Wenn Sie im vorherigen Beispiel count zu Ihrer Abfrage hinzufügen, ist das Ergebnis immer der Wert 1 Der Grund dafür ist, dass der Warnungsdienst einen count von count durchführt.

Vermeiden von limit- und take-Operatoren

Die Verwendung von limit und take in Abfragen kann die Latenz und die Auslastung durch Warnungen erhöhen, weil die Ergebnisse im Laufe der Zeit nicht konsistent sind. Verwenden Sie diese Operatoren nur bei Bedarf.

Beschränkungen für Protokollabfragen

Protokollabfragen in Azure Monitor beginnen entweder mit einer Tabelle, einem search- oder einem union-Operator.

Abfragen für Regeln für Protokollsuchewarnungen sollten immer mit einer Tabelle beginnen, um einen klaren Bereich zu definieren, was die Abfrageleistung und die Relevanz der Ergebnisse verbessert. Abfragen in Warnungsregeln werden häufig ausgeführt. Die Verwendung von search und union kann zu übermäßigem Mehraufwand und somit zu größerer Latenz für die Warnung führen, weil eine Überprüfung mehrerer Tabellen erforderlich ist. Diese Operatoren verringern auch die Fähigkeit des Warnungsdiensts zur Optimierung der Abfrage.

Das Erstellen oder Ändern von Regeln für Protokollsuchwarnungen, die search- oder union-Operatoren verwenden, wird von uns außer für ressourcenübergreifende Abfragen nicht unterstützt.

Beispielsweise ist die folgende Warnungsabfrage auf die Tabelle SecurityEvent beschränkt und sucht nach einer bestimmten Ereignis-ID. Dies ist die einzige Tabelle, die von der Abfrage verarbeitet werden muss.

SecurityEvent
| where EventID == 4624

Regeln für Protokollsuchwarnungen mit ressourcenübergreifenden Abfragen sind von dieser Änderung nicht betroffen, da ressourcenübergreifende Abfragen einen union-Typ verwenden, wodurch der Abfragebereich auf bestimmte Ressourcen beschränkt wird. Das folgende Beispiel wäre eine gültige Abfrage für Protokollwarnungen:

union
app('00000000-0000-0000-0000-000000000001').requests,
app('00000000-0000-0000-0000-000000000002').requests,
workspace('00000000-0000-0000-0000-000000000003').Perf

Hinweis

Ressourcenübergreifende Abfragen werden in der neuen scheduledQueryRules-API unterstützt. Wenn Sie noch die Legacy-Log Analytics-Warnungs-API zum Erstellen von Protokollsuchwarnungen verwenden, finden Sie unter Upgrade der Legacy-Regelverwaltung auf die aktuelle API für geplante Abfrageregeln von Azure Monitor durchführen weitere Informationen zum Wechseln.

Beispiele

Die folgenden Beispiele umfassen Protokollabfragen, die search und union verwenden. Sie enthalten Schritte, mit denen Sie diese Abfragen für die Verwendung in Warnungsregeln ändern können.

Beispiel 1

Sie möchten eine Regeln für Protokollsuchwarnungen mit der folgenden Abfrage erstellen, die Leistungsinformationen mithilfe von search abruft:

search *
| where Type == 'Perf' and CounterName == '% Free Space'
| where CounterValue < 30

Zum Ändern dieser Abfrage beginnen Sie mit der folgenden Abfrage, um die Tabelle anzugeben, der die Eigenschaften angehören:
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
Das Ergebnis dieser Abfrage zeigt, dass die Eigenschaft CounterName aus der Tabelle Perf stammt.
Verwenden Sie dieses Ergebnis, um die folgende Abfrage erstellen, die Sie für die Warnungsregel verwenden:
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

Beispiel 2

Sie möchten eine Regeln für Protokollsuchwarnungen mit der folgenden Abfrage erstellen, die Leistungsinformationen mithilfe von search abruft:

search ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage =avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)

Zum Ändern dieser Abfrage beginnen Sie mit der folgenden Abfrage, um die Tabelle anzugeben, der die Eigenschaften angehören:
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
Das Ergebnis dieser Abfrage zeigt, dass die Eigenschaften ObjectName und CounterName aus der Tabelle Perf stammen.

Verwenden Sie dieses Ergebnis, um die folgende Abfrage erstellen, die Sie für die Warnungsregel verwenden:

Perf
| where ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage=avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)

Beispiel 3

Sie möchten eine Regeln für Protokollsuchwarnungen mit der folgenden Abfrage erstellen, die sowohl search als auch union zum Abrufen von Leistungsinformationen verwendet:

search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| where Computer !in (
    union *
    | where CounterName == "% Processor Utility"
    | summarize by Computer)
| summarize Avg_Idle_Time = avg(CounterValue) by Computer

Zum Ändern dieser Abfrage beginnen Sie mit der folgenden Abfrage, um die Tabelle anzugeben, der die Eigenschaften im ersten Teil der Abfrage angehören:
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
Das Ergebnis dieser Abfrage zeigt, dass alle diese Eigenschaften aus der Tabelle Perf stammen.
Verwenden Sie union mit dem Befehl withsource, um anzugeben, welche Quelltabelle die jeweilige Zeile beigetragen hat:
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
Das Ergebnis dieser Abfrage zeigt, dass diese Eigenschaften ebenfalls aus der Tabelle Perf stammen.

Verwenden Sie diese Ergebnisse, um die folgende Abfrage zu erstellen, die Sie für die Warnungsregel verwenden:

Perf
| where ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total"
| where Computer !in (
    (Perf
    | where CounterName == "% Processor Utility"
    | summarize by Computer))
| summarize Avg_Idle_Time = avg(CounterValue) by Computer

Beispiel 4

Sie möchten eine Regeln für Protokollsuchwarnungen mithilfe der folgenden Abfrage erstellen, welche die Ergebnisse von zwei search-Abfragen verknüpft:

search Type == 'SecurityEvent' and EventID == '4625'
| summarize by Computer, Hour = bin(TimeGenerated, 1h)
| join kind = leftouter (
    search in (Heartbeat) OSType == 'Windows'
    | summarize arg_max(TimeGenerated, Computer) by Computer , Hour = bin(TimeGenerated, 1h)
    | project Hour , Computer
) on Hour

Zum Ändern der Abfrage beginnen Sie mit der folgenden Abfrage, um die Tabelle anzugeben, die die Eigenschaften auf der linken Seite der Verknüpfung enthält:
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
Das Ergebnis zeigt, dass die Eigenschaften auf der linken Seite der Verknüpfung zur Tabelle SecurityEvent gehören.
Verwenden Sie die folgende Abfrage, um die Tabelle anzugeben, die die Eigenschaften auf der rechten Seite der Verknüpfung enthält:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
Das Ergebnis zeigt, dass die Eigenschaften auf der rechten Seite der Verknüpfung zur Tabelle Heartbeat gehören.