Bagikan melalui

Mengoptimalkan kueri pemberitahuan pencarian log

  • Artikel

Artikel ini menjelaskan cara menulis dan mengonversi pemberitahuan pencarian log untuk mencapai performa optimal. Kueri yang dioptimalkan mengurangi latensi dan beban pemberitahuan, yang sering berjalan.

Mulai menulis kueri pemberitahuan pencarian log

Kueri pemberitahuan dimulai dari mengkueri data log di Analitik Log yang menunjukkan masalah. Untuk memahami hal yang dapat Anda temukan, lihat Menggunakan kueri di Analitik Log Azure Monitor. Anda juga dapat mulai menulis kueri Anda sendiri.

Pastikan kueri Anda mengidentifikasi masalah dan bukan pemberitahuan itu sendiri

Alur pemberitahuan dibuat untuk mengubah hasil yang menunjukkan adanya masalah ke sebuah pemberitahuan. Misalnya, dalam kasus kueri seperti:

SecurityEvent
| where EventID == 4624

Jika maksud pengguna adalah untuk memperingatkan, ketika jenis peristiwa ini terjadi, logika pemberitahuan ditambahkan count di kueri. Kueri yang berjalan akan menjadi:

SecurityEvent
| where EventID == 4624
| count

Tidak perlu menambahkan logika pemberitahuan ke kueri, dan melakukan hal tersebut dapat menyebabkan masalah. Pada contoh sebelumnya, jika Anda menyertakan count dalam kueri, tindakan tersebut akan selalu menghasilkan nilai 1, karena layanan pemberitahuan akan melakukan count dari count.

Hindari batas dan ambil operator

Menggunakan limit dan take dalam kueri dapat meningkatkan latensi dan beban pemberitahuan karena hasilnya tidak konsisten dari waktu ke waktu. Gunakan hanya jika diperlukan.

Batasan kueri log

Kueri log di Azure Monitor dimulai dengan operator tabel, search, atau union.

Kueri untuk aturan pemberitahuan pencarian log harus selalu dimulai dengan tabel untuk menentukan cakupan yang jelas, yang meningkatkan performa kueri dan relevansi hasil. Kueri dalam aturan pemberitahuan sering dijalankan. Menggunakan search dan union dapat mengakibatkan overhead berlebih yang menambah latensi pada pemberitahuan karena memerlukan pemindaian di beberapa tabel. Operator ini juga mengurangi kemampuan memberi tahu layanan untuk mengoptimalkan kueri.

Kami tidak mendukung pembuatan atau modifikasi aturan pemberitahuan pencarian log yang menggunakan search atau union operator, kecuali untuk kueri lintas sumber daya.

Misalnya, kueri pemberitahuan berikut dicakup ke tabel SecurityEvent dan mencari ID peristiwa tertentu. Ini adalah satu-satunya tabel yang harus diproses oleh kueri.

SecurityEvent
| where EventID == 4624

Aturan pemberitahuan pencarian log menggunakan kueri lintas sumber daya tidak terpengaruh oleh perubahan ini karena kueri lintas sumber daya menggunakan jenis union, yang membatasi cakupan kueri ke sumber daya tertentu. Contoh berikut adalah kueri pemberitahuan pencarian log yang valid:

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

Catatan

Kueri lintas sumber daya didukung di API scheduledQueryRules yang baru. Jika Anda masih menggunakan API Pemberitahuan Analitik Log warisan untuk membuat pemberitahuan pencarian log, lihat Meningkatkan manajemen aturan warisan ke API Aturan Kueri Terjadwal Azure Monitor saat ini untuk mempelajari tentang beralih.

Contoh

Contoh berikut mencakup kueri log yang menggunakan search dan union. Mereka menyediakan langkah-langkah yang dapat Anda gunakan untuk mengubah kueri ini untuk digunakan dalam aturan pemberitahuan.

Contoh 1

Anda ingin membuat aturan pemberitahuan pencarian log dengan menggunakan kueri berikut yang mengambil informasi performa menggunakan search:

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

  1. Untuk mengubah kueri ini, mulailah dengan menggunakan kueri berikut untuk mengidentifikasi tabel tempat properti berada:

    search *
| where CounterName == '% Free Space'
| summarize by $table

    Hasil kueri ini akan menunjukkan bahwa properti CounterName berasal dari tabel Perf.

  2. Gunakan hasil ini untuk membuat kueri berikut yang akan Anda gunakan untuk aturan pemberitahuan:

    Perf
| where CounterName == '% Free Space'
| where CounterValue < 30

Contoh 2

Anda ingin membuat aturan pemberitahuan pencarian log dengan menggunakan kueri berikut yang mengambil informasi performa menggunakan 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. Untuk mengubah kueri ini, mulailah dengan menggunakan kueri berikut untuk mengidentifikasi tabel tempat properti berada:

    search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table

    Hasil kueri ini akan menunjukkan bahwa properti ObjectName dan CounterName berasal dari tabel Perf.

  2. Gunakan hasil ini untuk membuat kueri berikut yang akan Anda gunakan untuk aturan pemberitahuan:

    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)

Contoh 3

Anda ingin membuat aturan pemberitahuan pencarian log dengan menggunakan kueri berikut yang menggunakan dan search union untuk mengambil informasi performa:

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. Untuk mengubah kueri ini, mulailah dengan menggunakan kueri berikut untuk mengidentifikasi tabel tempat properti di bagian pertama kueri berada:

    search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table

    Hasil kueri ini akan menunjukkan bahwa semua properti ini berasal dari tabel Perf.

  2. Gunakan union dengan perintah withsource untuk mengidentifikasi tabel sumber mana yang telah mengisi setiap baris:

    union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table

    Hasil kueri ini akan menunjukkan bahwa properti ini juga berasal dari tabel Perf.

  3. Gunakan hasil ini untuk membuat kueri berikut yang akan Anda gunakan untuk aturan pemberitahuan:

    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

Contoh 4

Anda ingin membuat aturan pemberitahuan pencarian log dengan menggunakan kueri berikut yang menggabungkan hasil dua search kueri:

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. Untuk mengubah kueri, mulailah dengan menggunakan kueri berikut untuk mengidentifikasi tabel yang berisi properti di sisi kiri gabungan:

    search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table

    Hasilnya menunjukkan bahwa properti di sisi kiri gabungan milik tabel SecurityEvent.

  2. Gunakan kueri berikut untuk mengidentifikasi tabel yang berisi properti di sisi kanan gabungan:

    search in (Heartbeat) OSType == 'Windows'
| summarize by $table

    Hasilnya menunjukkan bahwa properti di sisi kanan gabungan milik tabel Heartbeat.

  3. Gunakan hasil ini untuk membuat kueri berikut yang akan Anda gunakan untuk aturan pemberitahuan:

    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

Langkah berikutnya