Otimizar consultas de alerta de pesquisa de log

Artigo
12/19/2024

Este artigo descreve como escrever e converter alertas de pesquisa de log para obter o desempenho ideal. As consultas otimizadas reduzem a latência e a carga de alertas, que são executados com frequência.

Começar a escrever uma consulta de alerta de pesquisa de log

As consultas de alerta começam consultando os dados de log no Log Analytics que indicam o problema. Para entender o que você pode descobrir, consulte Usando consultas no Azure Monitor Log Analytics. Você também pode começar a escrever sua própria consulta.

Certifique-se de que a sua consulta identifica o problema e não o alerta em si

O fluxo de alerta foi criado para transformar os resultados que indicam o problema em um alerta. Por exemplo, no caso de uma consulta como:

SecurityEvent
| where EventID == 4624

Se a intenção do usuário for alertar, quando esse tipo de evento acontecer, a lógica de alerta será acrescentada count à consulta. A consulta executada será:

SecurityEvent
| where EventID == 4624
| count

Não há necessidade de adicionar lógica de alerta à consulta, e fazer isso pode até causar problemas. No exemplo anterior, se você incluir count em sua consulta, isso sempre resultará no valor 1, porque o serviço de alerta fará count de count.

Evite limitar e leve operadores

Usar limit e take em consultas pode aumentar a latência e a carga de alertas porque os resultados não são consistentes ao longo do tempo. Use-os apenas se necessário.

Restrições de consulta de log

As consultas de log no Azure Monitor começam com uma tabela, searchou union operador.

As consultas para regras de alerta de pesquisa de log devem sempre começar com uma tabela para definir um escopo claro, o que melhora o desempenho da consulta e a relevância dos resultados. As consultas nas regras de alerta são executadas com frequência. Usar search e union pode resultar em sobrecarga excessiva que adiciona latência ao alerta porque requer varredura em várias tabelas. Esses operadores também reduzem a capacidade do serviço de alerta de otimizar a consulta.

Não suportamos a criação ou modificação de regras de alerta de pesquisa de log que usam search operadores OR union , exceto para consultas entre recursos.

Por exemplo, a consulta de alerta a seguir tem como escopo a tabela SecurityEvent e procura uma ID de evento específica. É a única tabela que a consulta deve processar.

SecurityEvent
| where EventID == 4624

As regras de alerta de pesquisa de log usando consultas entre recursos não são afetadas por essa alteração porque as consultas entre recursos usam um tipo de , que limita o escopo da unionconsulta a recursos específicos. O exemplo a seguir seria uma consulta de alerta de pesquisa de log válida:

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

Nota

Há suporte para consultas entre recursos na nova API scheduledQueryRules. Se você ainda usa a API de Alerta do Log Analytics herdada para criar alertas de pesquisa de log, consulte Atualizar o gerenciamento de regras herdadas para a API atual de Regras de Consulta Agendada do Azure Monitor para saber mais sobre a alternância.

Exemplos

Os exemplos a seguir incluem consultas de log que usam search e union. Eles fornecem etapas que você pode usar para modificar essas consultas para uso em regras de alerta.

Exemplo 1

Você deseja criar uma regra de alerta de pesquisa de log usando a seguinte consulta que recupera informações de desempenho usando search:

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

Para modificar essa consulta, comece usando a seguinte consulta para identificar a tabela à qual as propriedades pertencem:
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
O resultado dessa consulta mostraria que a propriedade CounterName veio da tabela Perf .
Use este resultado para criar a seguinte consulta que você usaria para a regra de alerta:
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

Exemplo 2

Você deseja criar uma regra de alerta de pesquisa de log usando a seguinte consulta que recupera informações de desempenho usando 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)

Para modificar essa consulta, comece usando a seguinte consulta para identificar a tabela à qual as propriedades pertencem:
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
O resultado dessa consulta mostraria que as propriedades ObjectName e CounterName vieram da tabela Perf .

Use este resultado para criar a seguinte consulta que você usaria para a regra de alerta:

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)

Exemplo 3

Você deseja criar uma regra de alerta de pesquisa de log usando a seguinte consulta que usa ambos search e union para recuperar informações de desempenho:

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

Para modificar essa consulta, comece usando a seguinte consulta para identificar a tabela à qual as propriedades na primeira parte da consulta pertencem:
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
O resultado dessa consulta mostraria que todas essas propriedades vieram da tabela Perf .
Use union com o withsource comando para identificar qual tabela de origem contribuiu com cada linha:
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
O resultado dessa consulta mostraria que essas propriedades também vieram da tabela Perf .

Use estes resultados para criar a seguinte consulta que você usaria para a regra de alerta:

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

Exemplo 4

Você deseja criar uma regra de alerta de pesquisa de log usando a seguinte consulta que une os resultados de duas search consultas:

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

Para modificar a consulta, comece usando a seguinte consulta para identificar a tabela que contém as propriedades no lado esquerdo da associação:
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
O resultado indica que as propriedades no lado esquerdo da junção pertencem à tabela SecurityEvent .
Use a consulta a seguir para identificar a tabela que contém as propriedades no lado direito da associação:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
O resultado indica que as propriedades no lado direito da junção pertencem à tabela Heartbeat .