Otimizar consultas de alerta de pesquisa de log

Artigo
10/15/2024

Este artigo descreve como gravar e converter alertas de pesquisa de log para obter o desempenho ideal. Consultas otimizadas reduzem a latência e a carga de alertas executados com frequência.

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

As consultas de alertas começam com a consulta dos dados de log na análise de logs que indica o problema. Para entender o que você pode descobrir, confira Usando consultas no Log Analytics do Azure Monitor. Você também pode começar a gravar a sua própria consulta.

Verifique se a consulta identifica o problema e não o alerta em si

O fluxo de alertas foi criado para transformar os resultados que indicam o problema para 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 ocorre, a lógica de alerta acrescentará count à consulta. A consulta que é executada será:

SecurityEvent
| where EventID == 4624
| count

Não há necessidade de adicionar lógica de alerta à consulta, e fazer isso pode até mesmo causar problemas. No exemplo anterior, se count for incluído na sua consulta, o valor 1 sempre será o resultado, pois o serviço de alerta realizará count de count.

Evitar limites e usar operadores

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

Restrições de consultas de log

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

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. Consultas em regras de alerta são executadas com frequência. Usar search e union pode resultar em sobrecarga excessiva que adiciona latência ao alerta, pois exige um exame em várias tabelas. Esses operadores também reduzem a capacidade do serviço de alerta de otimizar a consulta.

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

Por exemplo, a seguinte consulta de alertas é limitada à tabela SecurityEvent e pesquisa a ID específica do evento. É 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 union, o que limita o escopo da consulta 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

Observação

As consultas entre recursos são compatíveis com a nova API scheduledQueryRules. Se você ainda usar 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 de Regras de Consulta Agendadas do Azure Monitor atual para saber mais sobre como alternar.

Exemplos

Os exemplos a seguir incluem consultas de log que usam search e union. Eles fornecem as etapas que você pode usar para modificar essas consultas para usar 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 consulta a seguir para identificar a tabela à que 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 esse resultado para criar a seguinte consulta que você usaria para a regra de alertas:
```
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 consulta a seguir para identificar a tabela à que 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 esse resultado para criar a seguinte consulta que você usaria para a regra de alertas:

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 consulta a seguir para identificar a tabela à que 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 as propriedades vieram da tabela Perf.
Use union com o comando withsource 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 esses resultados para criar a seguinte consulta que você usaria para a regra de alertas:

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 consultas 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

Para modificar a consulta, comece usando a consulta a seguir para identificar a tabela que contém as propriedades no lado esquerdo da junçã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 junção:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
O resultado indica que as propriedades no lado esquerdo da junção pertencem à tabela Pulsação.