Memantau permintaan kueri di Azure AI Search
Artikel ini menjelaskan cara mengukur performa dan volume kueri menggunakan metrik bawaan dan pengelogan sumber daya. Ini juga menjelaskan cara mendapatkan string kueri yang dimasukkan oleh pengguna aplikasi.
Portal Microsoft Azure menunjukkan metrik dasar tentang latensi kueri, beban kueri (QPS), dan pembatasan. Data historis yang masuk ke metrik ini dapat diakses di portal selama 30 hari. Untuk retensi yang lebih lama, atau untuk melaporkan data operasional dan string kueri, Anda harus menambahkan pengaturan diagnostik yang menentukan opsi penyimpanan untuk mempertahankan operasi dan metrik yang dicatat. Kami merekomendasikan ruang kerja Log Analytics sebagai tujuan untuk operasi yang dicatat. Kueri Kusto dan eksplorasi data menargetkan ruang kerja Analitik Log.
Kondisi yang memaksimalkan integritas pengukuran data meliputi:
Menggunakan layanan yang dapat ditagih (layanan yang dibuat di tingkat Dasar atau Standar). Layanan gratis dibagikan oleh beberapa pelanggan, yang memperkenalkan sejumlah volatilitas sebagai pergeseran beban.
Menggunakan satu replika dan partisi jika memungkinkan untuk membuat lingkungan yang terisolasi dan terkontrol. Jika Anda menggunakan beberapa replika, metrik kueri dirata-ratakan di beberapa node, yang dapat menurunkan presisi hasil. Demikian pula, beberapa partisi berarti bahwa data dibagi, dengan potensi bahwa beberapa partisi mungkin memiliki data yang berbeda jika pengindeksan juga sedang berlangsung. Saat Anda menyetel performa kueri, satu simpul dan partisi memberikan lingkungan yang lebih stabil untuk pengujian.
Tip
Dengan kode sisi klien tambahan dan Application Insights, Anda juga dapat menangkap data clickthrough untuk wawasan yang lebih mendalam tentang apa yang menarik minat pengguna aplikasi Anda. Untuk informasi selengkapnya, lihat Mencari analitik lalu lintas.
Volume kueri (QPS)
Volume diukur sebagai Kueri Pencarian Per Detik (QPS), metrik bawaan yang dapat dilaporkan sebagai nilai rata-rata, jumlah, minimum, atau maksimum kueri yang dijalankan dalam satu menit. Interval satu menit (TimeGrain = "PT1M") untuk metrik diperbaiki dalam sistem.
Kueri umum dijalankan dalam milidetik, jadi hanya kueri yang mengukur saat detik muncul dalam metrik.
| Jenis Agregasi | Deskripsi |
|---|---|
| Rata-rata | Jumlah rata-rata detik dalam satu menit saat eksekusi kueri terjadi. |
| Hitung | Jumlah metrik yang dipancarkan ke log dalam interval satu menit. |
| Maksimum | Jumlah pencarian kueri tertinggi per detik yang didaftarkan selama satu menit. |
| Minimum | Jumlah pencarian kueri terendah per detik yang didaftarkan selama satu menit. |
| Jumlah total | Jumlah total semua kueri yang dieksekusi dalam menit. |
Contohnya, dalam satu menit, Anda mungkin memiliki pola seperti ini: satu detik dari beban tinggi yang merupakan nilai maksimum untuk SearchQueriesPerSecond, diikuti oleh 58 detik beban rata-rata, dan akhirnya satu detik dengan hanya satu kueri, yang merupakan nilai minimum.
Contoh lain: jika node memancarkan 100 metrik, saat nilai setiap metrik adalah 40, maka "Jumlah" adalah 100, "Jumlah total" adalah 4000, "Rata-rata" adalah 40, dan "Maksimum" adalah 40.
Performa Kueri
Performa kueri di seluruh layanan diukur sebagai latensi pencarian (berapa lama kueri selesai) dan kueri yang dibatasi dan ditinggalkan sebagai akibat dari pertikaian sumber daya.
Latensi pencarian
| Jenis Agregasi | Latensi |
|---|---|
| Rata-rata | Durasi kueri rata-rata dalam milidetik. |
| Hitung | Jumlah metrik yang dipancarkan ke log dalam interval satu menit. |
| Maksimum | Kueri terlama dalam sampel. |
| Minimum | Kueri terpendek dalam sampel. |
| Total | Total waktu eksekusi semua kueri dalam sampel, dieksekusi dalam interval (satu menit). |
Pertimbangkan contoh metrik Latensi Pencarian berikut: 86 kueri diambil sampelnya, dengan durasi rata-rata 23,26 milidetik. Minimal 0 menunjukkan beberapa kueri dihilangkan. Kueri terlama membutuhkan 1000 milidetik untuk diselesaikan. Total waktu eksekusi adalah 2 detik.
Kueri yang dibatasi
Kueri yang dibatasi mengacu pada kueri yang dihilangkan alih-alih diproses. Dalam kebanyakan kasus, pembatasan adalah bagian normal dari menjalankan layanan. Ini belum tentu merupakan indikasi bahwa ada sesuatu yang salah.
Pembatasan terjadi ketika jumlah permintaan dalam eksekusi melebihi kapasitas. Anda mungkin melihat peningkatan permintaan yang dibatasi saat replika diambil dari rotasi atau selama pengindeksan. Permintaan kueri dan pengindeksan ditangani oleh set sumber daya yang sama.
Layanan ini menentukan apakah akan menghilangkan permintaan berdasarkan konsumsi sumber daya atau tidak. Persentase sumber daya yang dikonsumsi di seluruh memori, CPU, dan IO disk dirata-ratakan selama periode waktu tertentu. Jika persentase ini melebihi ambang batas, semua permintaan ke indeks akan dibatasi hingga volume permintaan dikurangi.
Bergantung pada klien Anda, permintaan yang dibatasi ditunjukkan dengan cara berikut:
- Layanan mengembalikan kesalahan
"You are sending too many requests. Please try again later." - Layanan mengembalikan kode kesalahan 503, yang menunjukkan bahwa saat ini layanan tidak tersedia.
- Jika Anda menggunakan portal (misalnya, Search Explorer), kueri dihilangkan secara diam-diam dan Anda perlu memilih Cari lagi.
Untuk mengonfirmasi kueri yang dibatasi, gunakan metrik kueri pencarian yang dibatasi. Anda dapat menjelajahi metrik di portal atau membuat metrik pemberitahuan seperti yang dijelaskan dalam artikel ini. Untuk kueri yang dihilangkan dalam interval pengambilan sampel, gunakan Total untuk mendapatkan persentase kueri yang tidak dijalankan.
| Jenis Agregasi | Pembatasan |
|---|---|
| Rata-rata | Persentase kueri yang dihilangkan dalam interval. |
| Hitung | Jumlah metrik yang dipancarkan ke log dalam interval satu menit. |
| Maksimum | Persentase kueri yang dihilangkan dalam interval. |
| Minimum | Persentase kueri yang dihilangkan dalam interval. |
| Total | Persentase kueri yang dihilangkan dalam interval. |
Untuk Persentase Kueri Pencarian yang Dibatasi, minimum, maksimum, rata-rata, dan total, semuanya memiliki nilai yang sama: persentase kueri pencarian yang dibatasi, dari jumlah total kueri pencarian selama satu menit.
Dalam cuplikan layar berikut, angka pertama adalah jumlah (atau jumlah metrik yang dikirim ke log). Agregasi lain, yang muncul di bagian atas atau saat mengarahkan mouse ke atas metrik, termasuk rata-rata, maksimum, dan total. Dalam sampel ini, tidak ada permintaan yang dihilangkan.
Menjelajahi metrik di portal
Untuk melihat sekilas jumlah yang ada saat ini, tab Pemantauan pada halaman Ringkasan layanan memperlihatkan tiga metrik (Latensi pencarian, Kueri pencarian per detik (per unit pencarian), Persentase Kueri Pencarian yang Dibatasi) selama interval tetap yang diukur dalam jam, hari, dan minggu, dengan opsi mengubah jenis agregasi.
Untuk penjelajahan yang lebih dalam, buka penjelajah metrik dari menu Pemantauan sehingga Anda dapat melapisi, memperbesar, dan memvisualisasikan data untuk menjelajahi tren atau anomali. Pelajari selengkapnya tentang penjelajah metrik dengan menyelesaikan tutorial tentang membuat bagan metrik ini.
Di bawah bagian Pemantauan, pilih Metrik untuk membuka penjelajah metrik dengan cakupan yang diatur ke layanan pencarian Anda.
Di Metrik, pilih salah satu dari daftar tarik turun dan tinjau daftar agregasi yang tersedia untuk jenis yang dipilih. Agregasi menentukan bagaimana nilai yang dikumpulkan diambil sampelnya setiap interval waktu.
Di pojok kanan atas, atur interval waktu.
Pilih visualisasi. Defaultnya adalah diagram garis.
Lapisan lebih banyak agregasi dengan memilih Tambahkan metrik dan pilih agregasi yang berbeda.
Perbesar area yang diinginkan pada diagram garis. Letakkan penunjuk mouse di awal area, pilih dan tahan tombol mouse kiri, seret ke sisi lain area, dan lepaskan tombol. Bagan memperbesar rentang waktu tersebut.
Menampilkan string kueri yang dimasukkan oleh pengguna
Saat Anda mengaktifkan pengelogan sumber daya, sistem menangkap permintaan kueri dalam tabel AzureDiagnostics. Sebagai prasyarat, Anda harus sudah menentukan tujuan untuk operasi yang dicatat, baik ruang kerja analitik log atau opsi penyimpanan lainnya.
Di bawah bagian Pemantauan, pilih Log untuk membuka jendela kueri kosong di Analitik Log.
Jalankan ekspresi berikut untuk operasi pencarian
Query.Search, mengembalikan kumpulan hasil tabular yang terdiri dari nama operasi, string kueri, indeks yang dikueri, dan jumlah dokumen yang ditemukan. Dua pernyataan terakhir mengecualikan string kueri yang terdiri dari pencarian kosong atau tidak ditentukan melalui indeks sampel, yang mengurangi gangguan dalam hasil Anda.AzureDiagnostics | project OperationName, Query_s, IndexName_s, Documents_d | where OperationName == "Query.Search" | where Query_s != "?api-version=2023-07-01-preview&search=*" | where IndexName_s != "realestate-us-sample-index"Secara opsional, atur filter Kolom di Query_s untuk mencari sintaks atau string tertentu. Misalnya, Anda dapat memfilter sama dengan
?api-version=2023-11-01&search=*&%24filter=HotelName.
Meskipun teknik ini berfungsi untuk investigasi ad hoc, membuat laporan memungkinkan Anda mengonsolidasikan dan menyajikan string kueri dalam tata letak yang lebih kondusif untuk analisis.
Mengidentifikasi kueri yang sudah berjalan lama
Tambahkan kolom durasi guna mendapatkan angka untuk semua kueri, bukan hanya yang diambil sebagai metrik. Mengurutkan data ini memperlihatkan kepada Anda kueri mana yang membutuhkan waktu paling lama untuk diselesaikan.
Di bawah bagian Pemantauan, pilih Log untuk informasi log yang akan dikueri.
Jalankan kueri dasar berikut untuk menampilkan kueri, diurutkan berdasarkan durasi dalam milidetik. Kueri terlama ada di bagian atas.
AzureDiagnostics | project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s | where OperationName == "Query.Search" | sort by DurationMs
Membuat peringatan metrik
Pemberitahuan metrik menetapkan ambang batas untuk mengirim pemberitahuan atau memicu tindakan korektif yang Anda tentukan sebelumnya. Anda dapat membuat pemberitahuan yang terkait dengan eksekusi kueri, tetapi Anda juga dapat membuatnya untuk kesehatan sumber daya, perubahan konfigurasi layanan pencarian, eksekusi keterampilan, dan pemrosesan dokumen (pengindeksan).
Semua ambang batas ditentukan pengguna, jadi Anda harus memiliki gambaran tentang tingkat aktivitas apa yang harus memicu pemberitahuan.
Untuk pemantauan kueri, biasanya membuat pemberitahuan metrik untuk latensi pencarian dan kueri yang dibatasi. Jika Anda tahu kapan kueri dihilangkan, Anda dapat mencari solusi yang mengurangi beban atau meningkatkan kapasitas. Misalnya, jika kueri yang dibatasi meningkat selama pengindeksan, Anda dapat menundanya hingga aktivitas kueri mereda.
Jika Anda mendorong batas konfigurasi partisi replika tertentu, menyiapkan pemberitahuan untuk ambang batas volume kueri (QPS) juga berguna.
Di bawah Pemantauan, pilih Pemberitahuan lalu pilih Buat aturan pemberitahuan.
Di bawah Kondisi, pilih Tambahkan.
Mengonfigurasi logika sinyal. Untuk jenis sinyal, pilih metrik lalu pilih sinyal.
Setelah memilih sinyal, Anda dapat menggunakan bagan guna memvisualisasikan data historis untuk keputusan berdasarkan informasi tentang cara melanjutkan pengaturan kondisi.
Berikutnya, gulir ke bawah ke logika Pemberitahuan. Untuk bukti konsep, Anda dapat menentukan nilai yang rendah yang dibuat-buat untuk tujuan pengujian.
Berikutnya, tentukan atau buat Grup Tindakan. Ini adalah respons untuk digunakan saat ambang batas terpenuhi. Respons ini dapat berupa pemberitahuan push atau respons otomatis.
Terakhir, tentukan Detail pemberitahuan. Beri nama dan jelaskan pemberitahuan, tetapkan nilai tingkat kepentingan, dan tentukan jika Anda akan membuat aturan dalam status diaktifkan atau dinonaktifkan.
Jika Anda menentukan pemberitahuan email, Anda menerima email dari "Microsoft Azure" dengan baris subjek "Azure: Activated Severity: 3 <your rule name>".
Langkah berikutnya
Jika Anda belum melakukannya, tinjau dasar-dasar pemantauan layanan pencarian untuk mempelajari tentang seluruh kemampuan pengawasan.