Ottimizzare le query di avviso di ricerca log

Articolo
02/16/2024

Questo articolo descrive come scrivere e convertire gli avvisi di ricerca log per ottenere prestazioni ottimali. Le query ottimizzate riducono la latenza e il carico degli avvisi, che vengono eseguiti di frequente.

Iniziare a scrivere una query di log degli avvisi

Le query di avviso iniziano dall'esecuzione di query sui dati di log in Log Analytics che indicano il problema. Per informazioni su cosa è possibile individuare, vedere Uso delle query in Log Analytics di Monitoraggio di Azure. È anche possibile iniziare a scrivere una query personalizzata.

Query che indicano il problema e non l'avviso

Il flusso di avviso è stato compilato per trasformare i risultati che indicano il problema in un avviso. Ad esempio, nel caso di una query come:

SecurityEvent
| where EventID == 4624

Se la finalità dell'utente è avvisare, quando si verifica questo tipo di evento, la logica di avviso viene count aggiunta alla query. La query eseguita sarà:

SecurityEvent
| where EventID == 4624
| count

Non è necessario aggiungere logica di avviso alla query ed eseguire questa operazione potrebbe anche causare problemi. Nell'esempio precedente, se si include count nella query, verrà sempre restituito il valore 1, perché il servizio di avviso eseguirà count .count

Evitare limiti e operatori take

L'uso limit di e take nelle query può aumentare la latenza e il carico degli avvisi perché i risultati non sono coerenti nel tempo. Usarli solo se necessario.

Vincoli di query di log

Le query di log in Monitoraggio di Azure iniziano con una tabella, searchun operatore o union .

Le query per le regole di avviso di ricerca log devono sempre iniziare con una tabella per definire un ambito chiaro, migliorando le prestazioni delle query e la pertinenza dei risultati. Le query nelle regole di avviso vengono eseguite frequentemente. L'uso search di e union può comportare un sovraccarico eccessivo che aggiunge latenza all'avviso perché richiede l'analisi tra più tabelle. Questi operatori riducono anche la capacità del servizio di avviso di ottimizzare la query.

Non è supportata la creazione o la modifica di regole di avviso di ricerca log che usano search o union operatori, ad eccezione delle query tra risorse.

Ad esempio, la query di avviso seguente ha come ambito la tabella SecurityEvent e cerca un ID evento specifico. È l'unica tabella che la query deve elaborare.

SecurityEvent
| where EventID == 4624

Le regole di avviso di ricerca log che usano query tra risorse non sono interessate da questa modifica perché le query tra risorse usano un tipo di , che limita l'ambito della unionquery a risorse specifiche. L'esempio seguente è una query di avviso di ricerca log valida:

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

Nota

Le query tra risorse sono supportate nella nuova API scheduledQueryRules. Se si usa ancora l'API di avviso di Log Analytics legacy per la creazione di avvisi di ricerca log, vedere Aggiornare la gestione delle regole legacy all'API regole di query pianificate di Monitoraggio di Azure corrente per informazioni sul passaggio.

Esempi

Gli esempi seguenti includono query di log che usano search e union. Forniscono i passaggi che è possibile usare per modificare queste query da usare nelle regole di avviso.

Esempio 1

Si vuole creare una regola di avviso di ricerca log usando la query seguente che recupera le informazioni sulle prestazioni usando search:

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

Per modificare questa query, iniziare usando la query seguente per identificare la tabella a cui appartengono le proprietà:
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
Il risultato di questa query indicherebbe che la proprietà CounterName proviene dalla tabella Perf.
Usare questo risultato per creare la query seguente da usare per la regola di avviso:
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

Esempio 2

Si vuole creare una regola di avviso di ricerca log usando la query seguente che recupera le informazioni sulle prestazioni 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)

Per modificare questa query, iniziare usando la query seguente per identificare la tabella a cui appartengono le proprietà:
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
Il risultato di questa query mostra che le proprietà ObjectName e CounterName provengono dalla tabella Perf .

Usare questo risultato per creare la query seguente da usare per la regola di avviso:

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)

Esempio 3

Si vuole creare una regola di avviso di ricerca log usando la query seguente che usa e searchunion per recuperare le informazioni sulle prestazioni:

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

Per modificare questa query, iniziare usando la query seguente per identificare la tabella a cui appartengono le proprietà nella prima parte della query:
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
Il risultato di questa query indicherebbe che tutte queste proprietà provengono dalla tabella Perf.
Usare union con il withsource comando per identificare la tabella di origine che ha contribuito a ogni riga:
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
Il risultato di questa query indicherebbe che anche queste proprietà provengono dalla tabella Perf.

Usare questi risultati per creare la query seguente da usare per la regola di avviso:

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

Esempio 4

Si vuole creare una regola di avviso di ricerca log usando la query seguente che unisce i risultati di due search query:

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

Per modificare questa query, iniziare usando la query seguente per identificare la tabella che contiene le proprietà nel lato sinistro del join:
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
Il risultato indica che le proprietà a sinistra del join appartengono alla tabella SecurityEvent .
Usare la query seguente per identificare la tabella contenente le proprietà sul lato destro del join:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
Il risultato indica che le proprietà sul lato destro del join appartengono alla tabella Heartbeat .