Naplókeresési riasztási lekérdezések optimalizálása

Cikk
11/05/2024

Ez a cikk bemutatja, hogyan írhat és alakíthat át naplókeresési riasztásokat az optimális teljesítmény elérése érdekében. Az optimalizált lekérdezések csökkentik a gyakran futó riasztások késését és terhelését.

Riasztásnapló-lekérdezés írásának megkezdése

A riasztási lekérdezések a Log Analytics naplóadatainak lekérdezéséből indulnak ki, amely a problémát jelzi. A felderíthető adatok megismeréséhez tekintse meg a Lekérdezések használata az Azure Monitor Log Analyticsben című témakört. Saját lekérdezés írását is megkezdheti.

A problémát jelző lekérdezések, nem pedig a riasztás

A riasztási folyamat úgy lett létrehozva, hogy a problémát jelző eredményeket riasztássá alakítsa át. Például egy lekérdezés esetében, például:

SecurityEvent
| where EventID == 4624

Ha a felhasználó szándéka riasztás, akkor az eseménytípus bekövetkezésekor a riasztási logika hozzáfűzi count a lekérdezést. A futtatott lekérdezés a következő lesz:

SecurityEvent
| where EventID == 4624
| count

Nem kell riasztási logikát hozzáadni a lekérdezéshez, és ez akár problémákat is okozhat. Az előző példában, ha belefoglalja count a lekérdezésbe, az mindig az 1 értéket fogja eredményezni, mert a riasztási szolgáltatás a következőt fogja tenni count count: .

A korlátozás elkerülése és az operátorok átvétele

A lekérdezések használata limit és take használata növelheti a riasztások késését és terhelését, mivel az eredmények nem konzisztensek az idő függvényében. Csak szükség esetén használja őket.

Napló lekérdezési korlátozások

A napló lekérdezések az Azure Monitorban táblával vagy searchunion operátorral kezdődnek.

A naplókeresési riasztási szabályok lekérdezéseinek mindig egy táblával kell kezdődnie, amely egyértelmű hatókört határoz meg, ami javítja a lekérdezés teljesítményét és az eredmények relevanciáját. A riasztási szabályok lekérdezései gyakran futnak. union A riasztáshoz search késést adó többletterhelést okozhat, mivel több táblán keresztüli vizsgálatra van szükség. Ezek az operátorok csökkentik a riasztási szolgáltatás azon képességét is, hogy optimalizálja a lekérdezést.

Az erőforrás-alapú lekérdezések kivételével nem támogatjuk a naplókeresési search riasztási szabályok létrehozását vagy union módosítását.

Az alábbi riasztási lekérdezés például a SecurityEvent táblára terjed ki, és egy adott eseményazonosítót keres. Ez az egyetlen tábla, amelyet a lekérdezésnek fel kell dolgoznia.

SecurityEvent
| where EventID == 4624

Az erőforrás-alapú lekérdezéseket használó naplókeresési riasztási szabályokat nem érinti ez a változás, mert az erőforrás-alapú lekérdezések olyan típusúak, amelyek a lekérdezés hatókörét unionadott erőforrásokra korlátozzák. A következő példa egy érvényes naplókeresési riasztási lekérdezés:

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

Feljegyzés

Az erőforrásközi lekérdezések támogatottak az új scheduledQueryRules API-ban. Ha továbbra is az örökölt Log Analytics Alert API-t használja naplókeresési riasztások létrehozásához, a váltásról további információt az örökölt szabályok kezelésének frissítése az aktuális Azure Monitor ütemezett lekérdezési szabályok API-ra című témakörben talál.

Példák

Az alábbi példák közé tartoznak a használt search napló lekérdezések és uniona . Ezek a lépések a lekérdezések riasztási szabályokban való használatához történő módosításához használhatók.

1. példa

Hozzon létre egy naplókeresési riasztási szabályt a következő lekérdezéssel, amely a teljesítményadatokat a következő használatával searchkéri le:

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

A lekérdezés módosításához először használja az alábbi lekérdezést annak a táblának a azonosításához, amelyhez a tulajdonságok tartoznak:
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
A lekérdezés eredménye azt mutatja, hogy a CounterName tulajdonság a Perf táblából származik.
Ezzel az eredménnyel hozza létre a következő lekérdezést, amelyet a riasztási szabályhoz használna:
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

2. példa

Hozzon létre egy naplókeresési riasztási szabályt a következő lekérdezéssel, amely a teljesítményadatokat a következő használatával searchkéri le:

search ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage =avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)

A lekérdezés módosításához először használja az alábbi lekérdezést annak a táblának a azonosításához, amelyhez a tulajdonságok tartoznak:
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
A lekérdezés eredménye azt mutatja, hogy az ObjectName és a CounterName tulajdonságok a Perf táblából származnak.

Ezzel az eredménnyel hozza létre a következő lekérdezést, amelyet a riasztási szabályhoz használna:

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)

3. példa

A naplókeresési riasztási szabályt a következő lekérdezéssel szeretné létrehozni, amely mindkettőt search használja, és union a teljesítményadatokat kéri le:

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

A lekérdezés módosításához először használja az alábbi lekérdezést annak a táblának a azonosításához, amelyhez a lekérdezés első részében a tulajdonságok tartoznak:
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
A lekérdezés eredménye azt mutatja, hogy ezek a tulajdonságok a Perf táblából származnak.
A union paranccsal withsource azonosíthatja, hogy melyik forrástábla járult hozzá az egyes sorokhoz:
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
A lekérdezés eredménye azt mutatja, hogy ezek a tulajdonságok a Perf táblából is származnak.

Ezeket az eredményeket használva hozza létre a következő lekérdezést, amelyet a riasztási szabályhoz használna:

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

4. példa

A naplókeresési riasztási szabályt a következő lekérdezéssel szeretné létrehozni, amely két search lekérdezés eredményeit illeszti össze:

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

A lekérdezés módosításához először használja az alábbi lekérdezést az illesztés bal oldalán található tulajdonságokat tartalmazó tábla azonosításához:
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
Az eredmény azt jelzi, hogy az illesztés bal oldalán lévő tulajdonságok a SecurityEvent táblához tartoznak.
Az alábbi lekérdezés segítségével azonosíthatja az illesztés jobb oldalán található tulajdonságokat tartalmazó táblát:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
Az eredmény azt jelzi, hogy az illesztés jobb oldalán lévő tulajdonságok a Szívverés táblához tartoznak.