Memecahkan masalah pemberitahuan pencarian log di Azure Monitor

Artikel ini menjelaskan cara mengatasi masalah umum dengan pemberitahuan pencarian log di Azure Monitor. Artikel ini juga menyediakan solusi untuk masalah umum fungsionalitas dan konfigurasi pemberitahuan log.

Anda dapat menggunakan pemberitahuan log untuk mengevaluasi log sumber daya setiap frekuensi yang ditetapkan dengan menggunakan kueri Analitik Log, dan memberikan pemberitahuan berdasarkan hasilnya. Aturan dapat memicu satu atau beberapa tindakan menggunakan Grup Tindakan. Untuk mempelajari selengkapnya tentang fungsionalitas dan terminologi pemberitahuan pencarian log, lihat Pemberitahuan log di Azure Monitor.

Catatan

Artikel ini tidak membahas kasus di mana aturan pemberitahuan dipicu, Anda dapat melihatnya di portal Azure, tetapi pemberitahuan tidak dikirim. Lihat pemberitahuan pemecahan masalah untuk kasus seperti ini.

Pemberitahuan pencarian log tidak diaktifkan ketika seharusnya

Jika pemberitahuan pencarian log Anda tidak diaktifkan saat seharusnya, periksa item berikut:

  1. Apakah aturan pemberitahuan dalam status kesehatan terdegradasi atau tidak tersedia?

    Lihat status kesehatan aturan pemberitahuan pencarian log Anda:

    1. Di portal, pilih Pantau lalu pilih Peringatan.

    2. Dari bilah perintah atas, pilih Aturan pemberitahuan. Halaman ini memperlihatkan semua aturan pemberitahuan Anda di semua langganan.

    3. Pilih aturan pemberitahuan pencarian log yang ingin Anda pantau.

    4. Dari panel kiri, di bawah Bantuan, pilih Kesehatan sumber daya.

      Screenshot of the Resource health section in a log search alert rule.

    Lihat Memantau kesehatan aturan pemberitahuan pencarian log untuk mempelajari selengkapnya.

  2. Periksa latensi penyerapan log.

    Azure Monitor memproses terabyte log pelanggan dari seluruh dunia, yang dapat menyebabkan latensi pemrosesan log.

    Log adalah data semi terstruktur dan secara inheren lebih laten daripada metrik. Jika Anda mengalami penundaan pemberitahuan lebih dari 4 menit, Anda harus mempertimbangkan menggunakan pemberitahuan metrik. Anda dapat mengirim data ke penyimpanan metrik dari log menggunakan pemberitahuan metrik untuk log.

    Untuk mengurangi latensi, sistem mencoba kembali evaluasi pemberitahuan beberapa kali. Setelah data ada, pemberitahuan akan diterapkan, yang dalam banyak kasus tidak sama dengan waktu rekaman log.

  3. Apakah tindakan dibisukan atau apakah aturan pemberitahuan dikonfigurasi untuk diselesaikan secara otomatis?

    Masalah umumnya adalah Anda berpikir bahwa pemberitahuan tidak diaktifkan, tetapi aturan dikonfigurasi sehingga pemberitahuan tidak akan diaktifkan. Lihat opsi tingkat lanjut dari aturan pemberitahuan pencarian log untuk memverifikasi bahwa kedua hal berikut ini tidak dipilih:

    • Kotak centang Matikan suara tindakan: memungkinkan Anda mematikan suara tindakan pemberitahuan yang diaktifkan untuk jumlah waktu yang ditetapkan.
    • Mengatasi pemberitahuan secara otomatis: mengonfigurasi pemberitahuan agar hanya diaktifkan sekali per kondisi terpenuhi.

    Suppress alerts

  4. Apakah sumber daya aturan pemberitahuan dipindahkan atau dihapus?

    Jika sumber daya aturan pemberitahuan dipindahkan, diganti namanya, atau dihapus, semua aturan pemberitahuan log yang mengacu pada sumber daya tersebut akan rusak. Untuk memperbaiki masalah ini, aturan pemberitahuan perlu dibuat ulang menggunakan sumber daya target yang valid untuk cakupan.

  5. Apakah aturan pemberitahuan menggunakan identitas terkelola yang ditetapkan sistem?

    Saat Anda membuat aturan pemberitahuan log dengan identitas terkelola yang ditetapkan sistem, identitas dibuat tanpa izin apa pun. Setelah membuat aturan, Anda perlu menetapkan peran yang sesuai ke identitas aturan sehingga dapat mengakses data yang ingin Anda kueri. Misalnya, Anda mungkin perlu memberinya peran Pembaca untuk ruang kerja Analitik Log yang relevan, atau peran Pembaca dan peran Penampil Database untuk kluster ADX yang relevan. Lihat identitas terkelola untuk informasi selengkapnya tentang menggunakan identitas terkelola dalam pemberitahuan log.

  6. Apakah kueri yang digunakan dalam aturan pemberitahuan pencarian log valid?

    Saat aturan pemberitahuan log dibuat, kueri divalidasi untuk sintaks yang benar. Tetapi terkadang kueri yang disediakan dalam aturan pemberitahuan log dapat mulai gagal. Beberapa alasan umum adalah:

    • Aturan dibuat melalui API, dan pengguna melewati validasi.
    • Kueri berjalan pada beberapa sumber daya, dan satu atau beberapa sumber daya dihapus atau dipindahkan.
    • Kueri gagal karena:
      • Solusi pembuatan log tidak diterapkan di ruang kerja, sehingga tabel tidak dibuat.
      • Data berhenti mengalir ke tabel dalam kueri selama lebih dari 30 hari.
      • Tabel log kustom belum dibuat karena aliran data belum dimulai.
    • Perubahan dalam bahasa kueri menyertakan format yang direvisi untuk perintah dan fungsi, sehingga kueri yang disediakan sebelumnya tidak lagi valid.

    Azure Advisor memperingatkan Anda tentang aturan ini. Ini menambahkan rekomendasi tentang aturan pemberitahuan pencarian log yang terpengaruh. Kategori yang digunakan adalah 'Ketersediaan Tinggi' dengan dampak sedang dan deskripsi 'Perbaiki aturan peringatan log Anda untuk memastikan pemantauan'.

  7. Apakah aturan pemberitahuan pencarian log dinonaktifkan?

    Jika kueri aturan pemberitahuan pencarian log gagal dievaluasi terus menerus selama seminggu, Azure Monitor menonaktifkannya secara otomatis.

    Bagian berikut ini mencantumkan beberapa alasan mengapa Azure Monitor mungkin menonaktifkan aturan pemberitahuan pencarian log. Selain itu, ada contoh peristiwa log Aktivitas yang dikirimkan saat aturan dinonaktifkan.

Contoh log aktivitas saat aturan dinonaktifkan

{
    "caller": "Microsoft.Insights/ScheduledQueryRules",
    "channels": "Operation",
    "claims": {
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
    },
    "correlationId": "abcdefg-4d12-1234-4256-21233554aff",
    "description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing consistently with the same exception for the past week",
    "eventDataId": "f123e07-bf45-1234-4565-123a123455b",
    "eventName": {
        "value": "",
        "localizedValue": ""
    },
    "category": {
        "value": "Administrative",
        "localizedValue": "Administrative"
    },
    "eventTimestamp": "2019-03-22T04:18:22.8569543Z",
    "id": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "level": "Informational",
    "operationId": "",
    "operationName": {
        "value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
    },
    "resourceGroupName": "<Resource Group>",
    "resourceProviderName": {
        "value": "MICROSOFT.INSIGHTS",
        "localizedValue": "Microsoft Insights"
    },
    "resourceType": {
        "value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
        "localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
    },
    "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "status": {
        "value": "Succeeded",
        "localizedValue": "Succeeded"
    },
    "subStatus": {
        "value": "",
        "localizedValue": ""
    },
    "submissionTimestamp": "2019-03-22T04:18:22.8569543Z",
    "subscriptionId": "<SubscriptionId>",
    "properties": {
        "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
        "subscriptionId": "<SubscriptionId>",
        "resourceGroup": "<ResourceGroup>",
        "eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
        "eventTimeStamp": "03/22/2019 04:18:22",
        "issueStartTime": "03/22/2019 04:18:22",
        "operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "status": "Succeeded",
        "reason": "Alert has been failing consistently with the same exception for the past week"
    },
    "relatedEvents": []
}

Pemberitahuan pencarian log diaktifkan ketika seharusnya tidak

Aturan pemberitahuan log di Azure Monitor yang dikonfigurasi mungkin dipicu secara tidak terduga. Bagian berikut ini menjelaskan beberapa alasan umum.

  1. Apakah pemberitahuan dipicu karena masalah latensi?

    Azure Monitor memproses terabyte log pelanggan secara global, yang dapat menyebabkan latensi penyerapan log. Ada kemampuan bawaan untuk mencegah pemberitahuan palsu, tetapi masih dapat terjadi pada data yang sangat laten (lebih dari ~ 30 menit) dan data dengan lonjakan latensi.

    Log adalah data semi terstruktur dan secara inheren lebih laten daripada metrik. Jika Anda mengalami banyak kesalahan tembakan dalam pemberitahuan yang diaktifkan, pertimbangkan untuk menggunakan pemberitahuan metrik. Anda dapat mengirim data ke penyimpanan metrik dari log menggunakan pemberitahuan metrik untuk log.

    Pemberitahuan pencarian log berfungsi paling baik saat Anda mencoba mendeteksi data tertentu dalam log. Ini kurang efektif ketika Anda mencoba mendeteksi kurangnya data dalam log, seperti peringatan pada heartbeat komputer virtual.

Pesan kesalahan saat mengonfigurasi aturan pemberitahuan pencarian log

Lihat bagian berikut untuk pesan kesalahan tertentu dan resolusinya.

Kueri tidak dapat divalidasi karena Anda memerlukan izin untuk log

Jika Anda menerima pesan kesalahan ini saat membuat atau mengedit kueri aturan pemberitahuan, pastikan Anda memiliki izin untuk membaca log sumber daya target.

  • Izin yang diperlukan untuk membaca log dalam mode akses konteks ruang kerja: Microsoft.OperationalInsights/workspaces/query/read.
  • Izin yang diperlukan untuk membaca log dalam mode akses konteks sumber daya (termasuk sumber daya Application Insights berbasis ruang kerja): Microsoft.Insights/logs/tableName/read.

Lihat Mengelola akses ke ruang kerja Analitik Log untuk mempelajari selengkapnya tentang izin.

Frekuensi satu menit tidak didukung untuk kueri ini

Ada beberapa batasan untuk menggunakan frekuensi aturan pemberitahuan satu menit. Saat Anda mengatur frekuensi aturan pemberitahuan menjadi satu menit, manipulasi internal dilakukan untuk mengoptimalkan kueri. Manipulasi ini dapat menyebabkan kueri gagal jika berisi operasi yang tidak didukung.

Untuk daftar skenario yang tidak didukung, lihat catatan ini.

Gagal mengatasi ekspresi skalar bernama <>

Pesan kesalahan ini dapat dikembalikan saat membuat atau mengedit kueri aturan pemberitahuan Anda jika:

  • Anda mereferensikan kolom yang tidak ada dalam skema tabel.
  • Anda merujuk kolom yang tidak digunakan dalam klausa proyek kueri sebelumnya.

Untuk mengurangi hal ini, Anda dapat menambahkan kolom ke klausa proyek sebelumnya atau menggunakan operator columnifexists .

API ScheduledQueryRules tidak didukung untuk Pemberitahuan OMS baca saja

Pesan kesalahan ini dikembalikan saat mencoba memperbarui atau menghapus aturan yang dibuat dengan versi API warisan dengan menggunakan portal Azure.

  1. Edit atau hapus aturan secara terprogram menggunakan REST API Analitik Log.
  2. Disarankan: Tingkatkan aturan pemberitahuan Anda untuk menggunakan API Aturan Kueri Terjadwal (API warisan berada di jalur penghentian).

Batas layanan aturan pemberitahuan tercapai

Untuk detail tentang jumlah aturan pemberitahuan pencarian log per langganan dan batas maksimum sumber daya, lihat Batas layanan Azure Monitor. Lihat Memeriksa jumlah total aturan pemberitahuan log yang digunakan untuk melihat berapa banyak aturan pemberitahuan metrik yang saat ini digunakan. Jika Anda telah mencapai batas kuota, langkah-langkah berikut dapat membantu mengatasi masalah tersebut.

  1. Hapus atau nonaktifkan aturan pemberitahuan pencarian log yang tidak digunakan lagi.

  2. Gunakan pemisahan menurut dimensi untuk mengurangi jumlah aturan. Saat Anda menggunakan pemisahan menurut dimensi, satu aturan dapat memantau banyak sumber daya.

  3. Jika Anda memerlukan penambahan batas kuota, harap lanjutkan membuka permintaan dukungan, dan berikan informasi berikut:

    • ID Berlangganan dan ID Sumber Daya yang batas kuotanya perlu ditingkatkan
    • Alasan peningkatan kuota
    • Jenis sumber daya untuk peningkatan kuota: Analitik Log atau Wawasan Aplikasi
    • Batas kuota yang diminta

Langkah berikutnya