Оптимизация запросов оповещений поиска по журналам

Статья
11/05/2024

В этой статье описывается, как записывать и преобразовывать оповещения поиска по журналам для достижения оптимальной производительности. Оптимизированные запросы уменьшают задержку и нагрузку, связанную с оповещениями, которые часто генерируются.

Создание запроса оповещений журнала

Прежде всего нужно запросить данные журнала Azure Monitor, указывающие на проблему. Сведения о том, что можно обнаружить, см. в статье Использование запросов в Azure Monitor Log Analytics. Вы также можете приступить к созданию собственного запроса.

Запросы, обнаруживающие проблему, а не оповещение

Поток оповещений был создан для преобразования результатов, указывающих на проблему, в оповещение. Например, взгляните на этот запрос:

SecurityEvent
| where EventID == 4624

Если пользователь хочет сгенерировать оповещение, когда возникает событие такого типа, в соответствии с логикой оповещений в запрос добавляется оператор count. Запрос, который выполняется, будет следующим:

SecurityEvent
| where EventID == 4624
| count

Добавлять в запрос логику оповещений нет необходимости, и это может даже привести к проблемам. В предыдущем примере, если включить count в запрос, всегда будет получаться значение 1, поскольку служба оповещений выполняет count из count.

Избегайте операторов ограничения и принятия

Использование limit и take в запросах может увеличить задержку и нагрузку, связанную с оповещениями, поскольку результаты не будут единообразными с течением времени. Используйте их только при необходимости.

Ограничения для запросов журналов

Запросы журналов в Azure Monitor начинаются с таблицы, оператора search или оператора union.

Запросы правил генерации оповещений поиска по журналам всегда должны начинаться с таблицы для определения четкой области, что повышает производительность запросов и релевантность результатов. Запросы в правилах генерации оповещений выполняются часто, поэтому применение операторов search и union может привести к чрезмерной нагрузке и задержке оповещения, так как потребуется сканировать несколько таблиц. Эти операторы также снижают способность службы оповещений оптимизировать запрос.

Мы не поддерживаем создание или изменение правил генерации оповещений поиска журналов, использующих search или union операторов, за исключением запросов между ресурсами.

Например, приведенный ниже запрос оповещений относится к таблице SecurityEvent и ищет в ней определенный идентификатор события. Это единственная таблица, которую должен обработать запрос.

SecurityEvent
| where EventID == 4624

Правила генерации оповещений поиска по журналам, использующие запросы между ресурсами, не влияют на это изменение, так как запросы между ресурсами используют тип union, который ограничивает область запроса определенными ресурсами. В следующем примере будет допустимый запрос оповещений поиска по журналам:

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

Примечание.

Запросы к нескольким ресурсам поддерживаются в новом API правил запросов по расписанию. Если вы по-прежнему используете устаревший API оповещений Log Analytics для создания оповещений поиска по журналам, см . статью "Обновление устаревших правил правил" до текущего API правил запланированных запросов Azure Monitor, чтобы узнать о переключении.

Примеры

Ниже приведены примеры запросов к журналам, которые используются search и union. В них представлены действия, которые можно выполнить для изменения запросов для использования в правилах генерации оповещений.

Пример 1

Вы хотите создать правило генерации оповещений поиска по журналам с помощью следующего запроса, который получает сведения о производительности с помощью search:

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

Чтобы изменить этот запрос, нужно определить таблицу, к которой относятся свойства. Это делает следующий запрос:
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
В результате запроса будет показано, что свойство CounterName получено из таблицы Perf.
С учетом этого результата вы можете создать следующий запрос, который можно использовать для правила генерации оповещений:
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

Пример 2

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

Чтобы изменить этот запрос, нужно определить таблицу, к которой относятся свойства. Это делает следующий запрос:
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
В результате запроса будет показано, что свойства ObjectName и CounterName получены из таблицы Perf.
С учетом этого результата вы можете создать следующий запрос, который можно использовать для правила генерации оповещений:
```
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)
```

Пример 3

Вы хотите создать правило генерации оповещений поиска по журналам с помощью следующего запроса, который использует оба search union и для получения сведений о производительности:

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

Чтобы изменить этот запрос, нужно определить таблицу, к которой относятся свойства в первой части запроса:
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
В результате запроса будет показано, что все свойства получены из таблицы Perf.
Используйте union с командой withsource, чтобы определить исходную таблицу, которая повлияла на каждую запись.
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
В результате запроса будет показано, что эти свойства также получены из таблицы Perf.

С учетом этих результатов вы можете создать следующий запрос, который можно использовать для правила генерации оповещений:

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

Пример 4

Вы хотите создать правило генерации оповещений поиска по журналам с помощью следующего запроса, который присоединяет результаты двух search запросов:

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

Чтобы изменить этот запрос, нужно определить таблицу, которая содержит свойства в левой части объединения:
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
В результате показано, что свойства в левой части объединения принадлежат таблице SecurityEvent.
Используйте следующий запрос, чтобы определить таблицу, которая содержит свойства в правой части объединения:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
В результате показано, что свойства в правой части объединения принадлежат таблице Heartbeat.

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

Следующие шаги

Сведения о оповещениях поиска по журналам в Azure Monitor.
Дополнительные сведения о запросах журналов.

Поделиться через