Optimización de las consultas de alertas de búsqueda de registros

Artículo
10/15/2024

En este artículo se describe cómo escribir y convertir alertas de búsqueda de registros para lograr un rendimiento óptimo. Las consultas optimizadas reducen la latencia y la carga de alertas, que se ejecutan con frecuencia.

Empezar a escribir una consulta de alertas de búsqueda de registros

Las consultas de alerta comienzan a partir de la consulta de los datos de registro en Log Analytics que indican el problema. Para comprender lo que puede detectar, consulte Uso de consultas en Azure Monitor Log Analytics. También puede empezar a escribir su propia consulta.

Asegúrese de que la consulta identifica el problema y no la propia alerta

El flujo de alerta se ha creado de forma que transforme los resultados que indican la emisión de una alerta. Por ejemplo, en un caso de una consulta como la siguiente:

SecurityEvent
| where EventID == 4624

Si la intención del usuario es enviar una alerta, cuando se produce este tipo de evento la lógica de alerta anexa count a la consulta. La consulta que se ejecuta será:

SecurityEvent
| where EventID == 4624
| count

No es necesario agregar lógica de alertas a la consulta y hacerlo puede incluso provocar problemas. En el ejemplo anterior, si incluye count en la consulta, siempre da como resultado el valor 1, porque el servicio de alertas realiza un count de count.

Evitación de los operadores de límite y toma

El uso de limit y take en las consultas puede aumentar la latencia y la carga de alertas, ya que los resultados no son coherentes a lo largo del tiempo. Úselos solo si es necesario.

Restricciones de la consulta de registro

Las consultas de registro de Azure Monitor comienzan con una tabla o con un operador search o union.

Las consultas para las reglas de alertas de búsqueda de registros siempre deben empezar con una tabla que defina un ámbito claro que mejore el rendimiento de las consultas y la pertinencia de los resultados. Las consultas de las reglas de alerta se ejecutan con frecuencia. El uso de search y union puede producir una sobrecarga excesiva que suma latencia a la alerta, ya que requiere el examen de varias tablas. Estos operadores también reducen la capacidad del servicio de alertas para optimizar la consulta.

No se admite la creación o modificación de reglas de alertas de búsqueda de registros que utilicen los operadores search o union, excepto en consultas entre recursos.

Por ejemplo, la siguiente consulta de alertas tiene como ámbito la tabla SecurityEvent y busca un identificador de evento específico. Es la única tabla que debe procesar la consulta.

SecurityEvent
| where EventID == 4624

A las reglas de alertas de búsqueda de registros que usan consultas entre recursos no les afecta este cambio, ya que usan un tipo de operador union que limita el ámbito de la consulta a recursos específicos. El ejemplo siguiente sería una consulta de alerta de búsqueda de registros 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:

Las consultas entre recursos se admiten en la nueva versión scheduledQueryRules API. Si sigue usando la API de alertas de Log Analytics heredada para crear alertas de búsqueda de registros, consulte Actualización de la administración de reglas heredadas a la API de reglas de consulta programadas de Azure Monitor actual para obtener información sobre cómo hacer el cambio.

Ejemplos

Los ejemplos siguientes incluyen consultas de registro que usan search y union. Proporcionan los pasos que puede utilizar para modificar estas consultas para su uso en las reglas de alerta.

Ejemplo 1

Desea crear una regla de alertas de búsqueda de registros mediante la siguiente consulta que recupera información de rendimiento mediante search:

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

Para modificar esta consulta, empiece por usar la consulta siguiente para identificar la tabla a la que pertenecen las propiedades:
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
El resultado de esta consulta muestra que la propiedad CounterName procede de la tabla Perf.
Use este resultado para crear la siguiente consulta, que podría usar para la regla de alertas:
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

Ejemplo 2

Desea crear una regla de alertas de búsqueda de registros mediante la siguiente consulta que recupera información de rendimiento mediante 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 esta consulta, empiece por usar la consulta siguiente para identificar la tabla a la que pertenecen las propiedades:
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
El resultado de esta consulta muestra que las propiedades ObjectName y CounterName procedían de la tabla Perf.

Use este resultado para crear la siguiente consulta, que podría usar para la regla 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)

Ejemplo 3

Desea crear una regla de alertas de búsqueda de registros mediante la siguiente consulta que usa search y union para recuperar información de rendimiento:

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 esta consulta, empiece por usar la consulta siguiente para identificar la tabla a la que pertenecen las propiedades de la primera parte de la consulta:
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
El resultado de esta consulta muestra que todas estas propiedades proceden de la tabla Perf.
Use union con el comando withsource para identificar qué tabla de origen ha contribuido a cada fila.
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
El resultado de esta consulta muestra que estas propiedades también proceden de la tabla Perf.

Use estos resultados para crear la siguiente consulta, que podría usar para la regla 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

Ejemplo 4

Desea crear una regla de alertas de búsqueda de registros mediante la siguiente consulta que combina los resultados de dos 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 la consulta, empiece por usar la consulta siguiente para identificar la tabla que contiene las propiedades del lado izquierdo de la combinación:
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
El resultado indica que las propiedades del lado izquierdo de la combinación pertenecen a la tabla SecurityEvent.
Use la consulta siguiente para identificar la tabla que contiene las propiedades del lado derecho de la combinación:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
El resultado indica que las propiedades del lado derecho de la combinación pertenecen a la tabla Heartbeat.