Otimizar consultas de alerta de pesquisa de log

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.

Iniciando a gravação de uma consulta de log de alertas

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.

Consultas que indicam o problema e não o alerta

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
  1. 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.

  2. 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)  
  1. 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.

  2. 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
  1. 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.

  2. 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.

  3. 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
  1. 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.

  2. 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.

  3. Use esses resultados para criar a seguinte consulta que você usaria para a regra de alertas:

    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
    

Próximas etapas