Ottimizzare le query di avviso di ricerca log

Articolo
10/15/2024

Questo articolo descrive come scrivere e convertire 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 indica il problema. Per comprendere cosa è possibile individuare, vedere Uso di 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 creato 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 è generare un avviso, quando si verifica questo tipo di evento la logica di avviso aggiunge count alla query. La query eseguita sarà:

SecurityEvent
| where EventID == 4624
| count

Non è necessario aggiungere logica di avviso alla query e tale aggiunta potrebbe anche causare problemi. Se si include count nella query dell'esempio precedente, verrà sempre restituito il valore 1, perché il servizio di avviso eseguirà count di count.

Evitare gli operatori limit e take

L'uso di limit 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 e un operatore search o union.

Le query per le regole di avviso di ricerca log devono sempre iniziare con una tabella per definire un ambito chiaro, migliorando quindi le prestazioni delle query e la pertinenza dei risultati. Le query nelle regole di avviso vengono eseguite frequentemente. L'uso di search e union può comportare un sovraccarico eccessivo che aggiunge latenza all'avviso perché richiede l'analisi in 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 operatori search o union, 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 il tipo union, che limita l'ambito della query 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 avvisi legacy di Log Analytics 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 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 per l'uso nelle regole di avviso.

Esempio 1

Si vuole creare una regola di avviso di ricerca log usando la query seguente che recupera 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 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 indicherebbe 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 sia search che union 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 comando withsource per identificare la tabella di origine da cui proviene 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 query 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

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à nel lato sinistro 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.