Optymalizowanie zapytań alertów przeszukiwania dzienników

Artykuł
11/05/2024

W tym artykule opisano sposób zapisywania i konwertowania alertów przeszukiwania dzienników w celu uzyskania optymalnej wydajności. Zoptymalizowane zapytania zmniejszają opóźnienia i obciążenie alertów, które są często uruchamiane.

Rozpoczynanie pisania zapytania dziennika alertów

Zapytania alertów zaczynają się od wykonywania zapytań dotyczących danych dziennika w usłudze Log Analytics , które wskazują problem. Aby dowiedzieć się, co można odnajdywać, zobacz Używanie zapytań w usłudze Azure Monitor Log Analytics. Możesz również rozpocząć pisanie własnego zapytania.

Zapytania wskazujące problem, a nie alert

Przepływ alertu został skompilowany w celu przekształcenia wyników wskazujących problem na alert. Na przykład w przypadku zapytania, takiego jak:

SecurityEvent
| where EventID == 4624

Jeśli celem użytkownika jest alert, po wystąpieniu tego typu zdarzenia logika alertów count dołącza do zapytania. Zapytanie, które zostanie uruchomione, będzie następujące:

SecurityEvent
| where EventID == 4624
| count

Nie ma potrzeby dodawania logiki zgłaszania alertów do zapytania i może to nawet powodować problemy. W poprzednim przykładzie, jeśli uwzględnisz count w zapytaniu, zawsze będzie to skutkować wartością 1, ponieważ usługa alertów countwykona count polecenie .

Unikanie limitu i przejmowanie operatorów

Użycie limit zapytań i take w zapytaniach może zwiększyć opóźnienie i obciążenie alertów, ponieważ wyniki nie są spójne w czasie. Używaj ich tylko w razie potrzeby.

Ograniczenia zapytań dzienników

Zapytania dzienników w usłudze Azure Monitor rozpoczynają się od tabeli, searchlub union operatora.

Zapytania dotyczące reguł alertów przeszukiwania dzienników powinny zawsze rozpoczynać się od tabeli w celu zdefiniowania jasnego zakresu, co zwiększa wydajność zapytań i istotność wyników. Zapytania w regułach alertów są często uruchamiane. Użycie i search union może spowodować nadmierne obciążenie, które dodaje opóźnienie do alertu, ponieważ wymaga skanowania w wielu tabelach. Te operatory zmniejszają również możliwość optymalizacji zapytania przez usługę alertów.

Nie obsługujemy tworzenia ani modyfikowania reguł alertów przeszukiwania dzienników, które używają operatorów lub union korzystają search z nich, z wyjątkiem zapytań obejmujących wiele zasobów.

Na przykład następujące zapytanie alertów jest ograniczone do tabeli SecurityEvent i wyszukuje określony identyfikator zdarzenia. Jest to jedyna tabela, którą musi przetworzyć zapytanie.

SecurityEvent
| where EventID == 4624

Ta zmiana nie ma wpływu na reguły alertów przeszukiwania dzienników przy użyciu zapytań obejmujących wiele zasobów, ponieważ zapytania obejmujące wiele zasobów używają typu union, który ogranicza zakres zapytań do określonych zasobów. Poniższy przykład będzie prawidłowym zapytaniem alertu przeszukiwania dzienników:

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

Uwaga

Zapytania obejmujące wiele zasobów są obsługiwane w nowym interfejsie API scheduledQueryRules. Jeśli nadal używasz starszego interfejsu API alertów usługi Log Analytics do tworzenia alertów przeszukiwania dzienników, zobacz Uaktualnianie zarządzania starszymi regułami do bieżącego interfejsu API zaplanowanych reguł zapytań usługi Azure Monitor, aby dowiedzieć się więcej o przełączaniu.

Przykłady

W poniższych przykładach znajdują się zapytania dzienników, które używają poleceń search i union. Udostępniają one kroki, których można użyć do modyfikowania tych zapytań do użycia w regułach alertów.

Przykład 1

Chcesz utworzyć regułę alertu przeszukiwania dzienników przy użyciu następującego zapytania, które pobiera informacje o wydajności przy użyciu polecenia search:

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

Aby zmodyfikować to zapytanie, zacznij od użycia następującego zapytania, aby zidentyfikować tabelę, do których należą właściwości:
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
Wynik tego zapytania pokazuje, że właściwość CounterName pochodzi z tabeli wydajności .
Użyj tego wyniku, aby utworzyć następujące zapytanie, które będzie używane dla reguły alertu:
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

Przykład 2

Chcesz utworzyć regułę alertu przeszukiwania dzienników przy użyciu następującego zapytania, które pobiera informacje o wydajności przy użyciu polecenia search:

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

Aby zmodyfikować to zapytanie, zacznij od użycia następującego zapytania, aby zidentyfikować tabelę, do których należą właściwości:
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
Wynik tego zapytania pokazuje, że właściwości ObjectName i CounterName pochodzą z tabeli Wydajności.

Użyj tego wyniku, aby utworzyć następujące zapytanie, które będzie używane dla reguły alertu:

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)

Przykład 3

Chcesz utworzyć regułę alertu przeszukiwania dzienników przy użyciu następującego zapytania, które używa funkcji search i union do pobierania informacji o wydajności:

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

Aby zmodyfikować to zapytanie, zacznij od użycia następującego zapytania, aby zidentyfikować tabelę, do których należą właściwości w pierwszej części zapytania:
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
Wynik tego zapytania pokazuje, że wszystkie te właściwości pochodzą z tabeli wydajności .
Użyj polecenia union , withsource aby zidentyfikować, która tabela źródłowa przyczyniła się do każdego wiersza:
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
Wynik tego zapytania pokazuje, że te właściwości pochodzą również z tabeli Wydajności .

Użyj tych wyników, aby utworzyć następujące zapytanie, które będzie używane dla reguły alertu:

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

Przykład 4

Chcesz utworzyć regułę alertu przeszukiwania dzienników przy użyciu następującego zapytania, które łączy wyniki dwóch search zapytań:

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

Aby zmodyfikować zapytanie, zacznij od użycia następującego zapytania, aby zidentyfikować tabelę zawierającą właściwości po lewej stronie sprzężenia:
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
Wynik wskazuje, że właściwości po lewej stronie sprzężenia należą do tabeli SecurityEvent .
Użyj następującego zapytania, aby zidentyfikować tabelę zawierającą właściwości po prawej stronie sprzężenia:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
Wynik wskazuje, że właściwości po prawej stronie sprzężenia należą do tabeli Puls .