Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Dalam proses penyerapan yang diantrekan, Azure Data Explorer mengoptimalkan penyerapan data untuk throughput tinggi dengan mengumpulkan potongan kecil data yang masuk ke dalam batch berdasarkan kebijakan batching penyerapan yang dapat dikonfigurasi. Kebijakan batching memungkinkan Anda mengatur kondisi pemicu untuk menyegel batch (ukuran data, jumlah blob, atau waktu yang dilewati). Batch ini kemudian diserap secara optimal untuk hasil kueri cepat.
Dalam artikel ini, Anda akan mempelajari cara menggunakan metrik untuk memantau penyerapan antrean ke Azure Data Explorer di portal Azure.
Tahap batching
Tahapan yang dijelaskan di bagian ini berlaku untuk semua penyerapan batching. Untuk penyerapan Azure Event Grid, Azure Event Hubs, Azure IoT Hub, dan Cosmos DB, sebelum data diantrekan untuk penyerapan , koneksi data mendapatkan data dari sumber eksternal dan melakukan pengaturan ulang data awal.
Penyerapan antrean terjadi secara bertahap:
- Manajer Batching mendengarkan antrean untuk pesan penyerapan dan memproses permintaan.
- Manajer Batching mengoptimalkan throughput penyerapan dengan mengambil potongan data ingress kecil yang diterima dan batching URL berdasarkan kebijakan batching penyerapan.
- Manajer Penyerapan mengirimkan perintah penyerapan ke Mesin Penyimpanan Azure Data Explorer.
- Azure Data Explorer Storage Engine menyimpan data yang diserap, membuatnya tersedia untuk kueri.
Azure Data Explorer menyediakan sekumpulan metrik penyerapan Azure Monitor sehingga Anda dapat memantau penyerapan data di semua tahap dan komponen proses penyerapan yang diantrekan.
Metrik penyerapan Azure Data Explorer memberi Anda informasi terperinci tentang:
- Hasil dari penyerapan antrean.
- Jumlah data yang diserap.
- Latensi penyerapan antrean dan di mana itu terjadi.
- Proses batching itu sendiri.
- Untuk penyerapan Event Hubs, Event Grid, dan IoT Hub: Jumlah peristiwa yang diterima.
Dalam artikel ini, Anda akan mempelajari cara menggunakan metrik penyerapan di portal Azure untuk memantau penyerapan antrean ke Azure Data Explorer.
Prasyarat
- Langganan Azure. Membuat akun Azure gratis.
- Kluster dan database Azure Data Explorer. Membuat kluster dan database.
- Penyerapan antrean aktif, seperti Event Hubs, IoT Hub, atau Event Grid.
Membuat bagan metrik dengan penjelajah metrik Azure Monitor
Berikut ini adalah penjelasan umum tentang cara menggunakan metrik Azure Monitor yang kemudian akan diimplementasikan di bagian berikutnya. Gunakan langkah-langkah berikut untuk membuat bagan metrik dengan penjelajah metrik Azure Monitor di portal Azure:
Masuk ke portal Azure dan navigasi ke halaman gambaran umum untuk kluster Azure Data Explorer Anda.
Pilih Metrik dari bilah navigasi sebelah kiri untuk membuka panel metrik.
Buka panel pemilih waktu di kanan atas panel metrik dan ubah Rentang waktu ke waktu yang ingin Anda analisis. Dalam artikel ini, kami menganalisis penyerapan data ke Azure Data Explorer selama 48 jam terakhir.
Pilih Cakupan dan Namespace Metrik:
- Cakupan adalah nama kluster Azure Data Explorer Anda. Dalam contoh berikut, kita akan menggunakan kluster bernama demo11.
- Namespace Metrik harus diatur ke metrik standar Kluster Kusto. Ini adalah namespace layanan yang berisi metrik Azure Data Explorer.
Pilih Nama metrik dan nilai Agregasi yang relevan.
Untuk beberapa contoh dalam artikel ini, kita akan memilih Tambahkan Filter dan Terapkan Pemisahan untuk metrik yang memiliki dimensi. Kita juga akan menggunakan Tambahkan metrik untuk memplot metrik lain dalam bagan yang sama dan + Bagan baru untuk melihat beberapa bagan dalam satu tampilan.
Setiap kali menambahkan metrik baru, Anda akan mengulangi langkah empat dan lima.
Catatan
Untuk mempelajari selengkapnya tentang cara menggunakan metrik untuk memantau Azure Data Explorer secara umum dan cara bekerja dengan panel metrik, lihat Memantau performa, kesehatan, dan penggunaan Azure Data Explorer dengan metrik.
Dalam artikel ini, Anda akan mempelajari metrik mana yang dapat digunakan untuk melacak penyerapan antrean, dan cara menggunakan metrik ini.
Menampilkan hasil penyerapan
Metrik Hasil penyerapan memberikan informasi tentang jumlah total sumber yang berhasil diserap dan yang gagal diserap.
Dalam contoh ini, kita akan menggunakan metrik ini untuk melihat hasil upaya penyerapan dan menggunakan informasi status untuk membantu memecahkan masalah upaya yang gagal.
- Di panel Metrik di Azure Monitor, pilih Tambahkan Metrik.
- Pilih Hasil penyerapan sebagai nilai Metrik dan Jumlah sebagai nilai Agregasi . Pilihan ini memperlihatkan hasil penyerapan dari waktu ke waktu dalam satu garis bagan.
- Pilih tombol Terapkan pemisahan di atas bagan dan pilih Status untuk mensegmentasi bagan Anda berdasarkan status hasil penyerapan. Setelah memilih nilai pemisahan, klik menjauhi pemilih terpisah untuk menutupnya.
Sekarang informasi metrik dibagi berdasarkan status, dan kita dapat melihat informasi tentang status hasil penyerapan dibagi menjadi tiga baris:
- Biru untuk operasi penyerapan yang berhasil.
- Oranye untuk operasi penyerapan yang gagal karena Entitas tidak ditemukan.
- Ungu untuk operasi penyerapan yang gagal karena Permintaan buruk.
Pertimbangkan hal berikut saat melihat bagan hasil penyerapan:
- Saat menggunakan hub peristiwa atau penyerapan hub IoT, ada pra-agregasi peristiwa di komponen Koneksi data. Selama tahap penyerapan ini, peristiwa diperlakukan sebagai satu sumber yang akan diserap. Oleh karena itu, beberapa peristiwa muncul sebagai satu hasil penyerapan setelah pra-agregasi.
- Kegagalan sementara dicoba kembali secara internal dalam sejumlah upaya terbatas. Setiap kegagalan sementara dilaporkan sebagai hasil penyerapan sementara. Itulah sebabnya satu penyerapan dapat menyebabkan lebih dari satu hasil penyerapan.
- Kesalahan penyerapan dalam bagan dicantumkan berdasarkan kategori kode kesalahan. Untuk melihat daftar lengkap kode kesalahan penyerapan menurut kategori dan mencoba untuk lebih memahami kemungkinan alasan kesalahan, lihat Kode kesalahan penyerapan di Azure Data Explorer.
- Untuk mendapatkan detail selengkapnya tentang kesalahan penyerapan, Anda dapat mengatur log diagnostik penyerapan yang gagal. Namun, penting untuk dipertimbangkan bahwa menghasilkan log menghasilkan pembuatan sumber daya tambahan, dan oleh karena itu peningkatan COGS (biaya barang yang dijual).
Menampilkan jumlah data yang diserap
Metrik Blob yang Diproses, Diterima Blob, dan Blob yang Dihilangkan memberikan informasi tentang jumlah blob yang diproses, diterima, dan dihilangkan oleh komponen penyerapan selama tahapan penyerapan antrean.
Dalam contoh ini, kita akan menggunakan metrik ini untuk melihat berapa banyak data yang diteruskan melalui alur penyerapan, berapa banyak data yang diterima oleh komponen penyerapan, dan berapa banyak data yang dihilangkan.
Blob Diproses
- Di panel Metrik di Azure Monitor, pilih Tambahkan Metrik.
- Pilih Blob yang Diproses sebagai nilai Metrik dan Jumlah sebagai nilai Agregasi .
- Pilih tombol Terapkan pemisahan dan pilih Jenis Komponen untuk mensegmentasi bagan dengan komponen penyerapan yang berbeda.
- Untuk fokus pada database tertentu di kluster Anda, pilih tombol Tambahkan filter di atas bagan lalu pilih nilai database mana yang akan disertakan saat memplot bagan. Dalam contoh ini, kami memfilter blob yang dikirim ke database GitHub dengan memilih Database sebagai Properti, = sebagai Operator, dan GitHub di menu dropdown Nilai . Setelah memilih nilai filter, klik menjauh dari pemilih filter untuk menutupnya.
Sekarang bagan menunjukkan berapa banyak blob yang dikirim ke database GitHub yang diproses di setiap komponen penyerapan dari waktu ke waktu.
- Perhatikan bahwa pada 13 Februari ada penurunan jumlah blob yang diserap ke database GitHub dari waktu ke waktu. Perhatikan juga bahwa jumlah blob yang diproses di setiap komponen serupa, yang berarti bahwa kira-kira semua data yang diproses dalam komponen Koneksi Data juga berhasil diproses oleh komponen Batching Manager, Ingestion Manager, dan Azure Data Explorer Storage Engine. Data ini siap untuk kueri.
Blob Diterima
Untuk lebih memahami hubungan antara jumlah blob yang diterima di setiap komponen dan jumlah blob yang berhasil diproses di setiap komponen, kita akan menambahkan bagan baru:
- Pilih + Bagan Baru.
- Pilih nilai yang sama seperti di atas untuk Cakupan, Namespace Metrik, dan Agregasi, dan pilih metrik Blob yang Diterima.
- Pilih tombol Terapkan pemisahan dan pilih Jenis Komponen untuk membagi metrik Blob yang Diterima berdasarkan jenis komponen.
- Pilih tombol Tambahkan filter dan atur nilai yang sama seperti sebelumnya untuk memfilter hanya blob yang dikirim ke database GitHub .
- Membandingkan bagan, perhatikan bahwa jumlah blob yang diterima oleh setiap komponen sangat cocok dengan jumlah blob yang diproses oleh setiap komponen. Perbandingan ini menunjukkan bahwa tidak ada blob yang dihilangkan selama penyerapan.
Gumpalan Dihilangkan
Untuk menentukan apakah ada blob yang dihilangkan selama penyerapan, Anda harus menganalisis metrik Blob yang Dihilangkan . Metrik ini menunjukkan berapa banyak blob yang dihilangkan selama penyerapan dan membantu Anda mendeteksi apakah ada masalah dalam pemrosesan pada komponen penyerapan tertentu. Untuk setiap blob yang dihilangkan, Anda juga akan mendapatkan metrik Hasil Penyerapan dengan informasi lebih lanjut tentang alasan kegagalan.
Melihat latensi penyerapan
Latensi Tahap metrik dan latensi pemantauan Latensi Penemuan dalam proses penyerapan, dan memberi tahu Anda apakah ada latensi panjang yang terjadi baik di Azure Data Explorer, atau sebelum data tiba di Azure Data Explorer untuk diserap.
- Latensi Tahap menunjukkan rentang waktu sejak pesan ditemukan oleh Azure Data Explorer hingga kontennya diterima oleh komponen penyerapan untuk diproses.
- Latensi penemuan digunakan untuk alur penyerapan dengan koneksi data (seperti event hub, IoT hub, dan Event Grid). Metrik ini memberikan informasi tentang rentang waktu dari antrean data hingga penemuan oleh koneksi data Azure Data Explorer. Rentang waktu ini adalah upstream ke Azure Data Explorer, sehingga tidak disertakan dalam metrik Latensi Tahap yang hanya mengukur latensi di Azure Data Explorer.
Catatan
Menurut kebijakan batching default, waktu batching default adalah lima menit. Oleh karena itu, jika batch tidak disegel oleh pemicu lain, batch akan disegel setelah lima menit.
Saat Anda melihat latensi panjang hingga data siap untuk kueri, menganalisis Latensi Tahap dan Latensi Penemuan dapat membantu Anda memahami apakah latensi panjang karena latensi panjang di Azure Data Explorer, atau hulu ke Azure Data Explorer. Saat latensi berada di Azure Data Explorer itu sendiri, Anda juga dapat mendeteksi komponen tertentu yang bertanggung jawab atas latensi panjang.
Latensi Tahap (pratinjau)
Mari kita lihat terlebih dahulu latensi tahap penyerapan antrean kita. Untuk penjelasan tentang setiap tahap, lihat Tahapan batching.
- Di panel Metrik di Azure Monitor, pilih Tambahkan Metrik.
- Pilih Latensi Tahap sebagai nilai Metrik dan Rata-rata sebagai nilai Agregasi .
- Pilih tombol Terapkan pemisahan dan pilih Jenis Komponen untuk mensegmentasi bagan dengan komponen penyerapan yang berbeda.
- Pilih tombol Tambahkan filter , dan filter pada data yang dikirim ke database GitHub . Setelah memilih nilai filter, klik menjauh dari pemilih filter untuk menutupnya. Sekarang bagan menunjukkan latensi operasi penyerapan yang dikirim ke database GitHub di setiap komponen melalui penyerapan dari waktu ke waktu:
Kita dapat mengetahui informasi berikut dari bagan ini:
- Latensi pada komponen Koneksi Data Azure Event Hubs sekitar 0 detik. Ini masuk akal, karena Latensi Tahap hanya mengukur latensi dari saat pesan ditemukan oleh Azure Data Explorer.
- Waktu terpanjang dalam proses penyerapan (sekitar 5 menit) berlalu dari saat komponen Pengelola Batching menerima data ke ketika komponen Manajer Penyerapan menerima data. Dalam contoh ini, kami menggunakan kebijakan batching default untuk database GitHub . Seperti yang disebutkan, batas waktu latensi untuk kebijakan batching default adalah 5 menit, jadi kemungkinan besar ini menunjukkan bahwa hampir semua data di-batch berdasarkan waktu, dan sebagian besar waktu latensi untuk penyerapan yang diantrekan disebabkan oleh batching itu sendiri.
- Latensi mesin penyimpanan dalam bagan mewakili latensi hingga data disimpan di Azure Data Explorer Storage Engine dan siap untuk kueri. Anda dapat melihat bahwa latensi total rata-rata dari waktu penemuan data oleh Azure Data Explorer hingga siap untuk kueri adalah 5,2 menit.
Latensi Penemuan
Jika Anda menggunakan penyerapan dengan koneksi data, Anda mungkin ingin memperkirakan latensi upstream ke Azure Data Explorer dari waktu ke waktu, selama latensi juga dapat terjadi sebelum Azure Data Explorer mendapatkan data untuk penyerapan. Untuk tujuan itu , Anda dapat menggunakan metrik Latensi Penemuan.
- Pilih + Bagan Baru.
- Pilih Latensi Penemuan sebagai nilai Metrik dan Rata-rata sebagai nilai Agregasi .
- Pilih tombol Terapkan pemisahan dan pilih Jenis Komponen untuk mensegmentasi bagan berdasarkan jenis komponen koneksi data yang berbeda. Setelah memilih nilai pemisahan, klik menjauhi pemilih terpisah untuk menutupnya.
- Anda dapat melihat bahwa selama sebagian besar durasi latensi penemuan mendekati 0 detik, menunjukkan bahwa Azure Data Explorer mendapatkan data tepat setelah antrean data. Puncak tertinggi sekitar 300 milidetik adalah sekitar 13 Februari pukul 14.00, menunjukkan bahwa saat ini kluster Azure Data Explorer menerima data sekitar 300 milidetik setelah antrean data.
Memahami proses batching
Pada tahap kedua alur penyerapan yang diantrekan, komponen Pengelola Batching mengoptimalkan throughput penyerapan dengan mengumpulkan data yang diterimanya berdasarkan kebijakan batching penyerapan.
Kumpulan metrik berikut membantu Anda memahami bagaimana data Anda di-batch selama penyerapan:
- Batch Diproses: Jumlah batch yang diselesaikan untuk penyerapan.
- Ukuran Batch: Perkiraan ukuran data yang tidak dikompresi dalam batch yang dikumpulkan untuk penyerapan.
- Durasi Batch: Durasi setiap batch individu sejak batch dibuka hingga penyegelan batch.
- Jumlah Blob Batch: Jumlah blob dalam batch yang diselesaikan untuk penyerapan.
Batch diproses
Mari kita mulai dengan tampilan keseluruhan proses batching dengan melihat metrik yang diproses Batch.
- Di panel Metrik di Azure Monitor, pilih Tambahkan Metrik.
- Pilih Batch Yang Diproses sebagai nilai Metrik dan Jumlah sebagai nilai Agregasi .
- Pilih tombol Terapkan pemisahan dan pilih Jenis Batching untuk mensegmentasi bagan berdasarkan alasan batch disegel. Untuk daftar lengkap jenis batching, lihat Jenis batching.
- Pilih tombol Tambahkan filter dan filter pada batch yang dikirim ke database GitHub . Setelah memilih nilai filter, klik menjauh dari pemilih filter untuk menutupnya.
Bagan menunjukkan jumlah batch yang disegel dengan data yang dikirim ke database GitHub dari waktu ke waktu, dibagi berdasarkan Jenis Batching.
- Perhatikan bahwa ada 2-4 batch per unit waktu dari waktu ke waktu, dan semua batch disegel berdasarkan waktu seperti yang diperkirakan di bagian Latensi Tahap di mana Anda dapat melihat bahwa dibutuhkan sekitar 5 menit untuk batch data berdasarkan kebijakan batching default.
Durasi, ukuran, dan jumlah blob batch
Sekarang mari kita karakterisasi batch yang diproses lebih lanjut.
- Pilih tombol + Tambahkan Bagan untuk setiap bagan untuk membuat lebih banyak bagan untuk Nilai metrik Durasi Batch, Ukuran Batch, dan Jumlah Blob Batch.
- Gunakan Rata-rata sebagai nilai Agregasi .
- Seperti pada contoh sebelumnya, pilih tombol Tambahkan filter , dan filter pada data yang dikirim ke database GitHub .
Dari bagan Durasi Batch, Ukuran Batch, dan Jumlah Blob Batch, kita dapat menyimpulkan beberapa wawasan:
Durasi batch rata-rata adalah lima menit (sesuai dengan kebijakan batching default). Anda harus memperhitungkan hal ini saat melihat total latensi penyerapan.
Dalam bagan Ukuran Batch, Anda dapat melihat bahwa ukuran rata-rata batch sekitar 200-500 MB dari waktu ke waktu. Ukuran optimal data yang akan diserap adalah 1 GB data yang tidak dikompresi, dan ukuran ini juga didefinisikan sebagai kondisi segel dengan kebijakan batching default. Karena tidak ada data 1 GB yang akan di-batch dari waktu ke waktu, kita tidak melihat batch apa pun yang disegel berdasarkan ukuran.
Jumlah rata-rata blob dalam batch adalah sekitar 160 blob dari waktu ke waktu, yang kemudian berkurang menjadi 60-120 blob. Berdasarkan kebijakan batching default, batch dapat menutup ketika jumlah blob adalah 1000 blob. Karena kami tidak tiba di nomor ini, kami tidak melihat batch disegel berdasarkan hitungan.
Membandingkan peristiwa yang diterima dengan peristiwa yang dikirim untuk penyerapan
Saat menerapkan hub peristiwa, hub IoT, atau penyerapan Event Grid, mungkin berguna untuk membandingkan jumlah peristiwa yang diterima oleh Azure Data Explorer dengan jumlah peristiwa yang dikirim dari sumber peristiwa ke Azure Data Explorer. Metrik Peristiwa yang Diterima, Peristiwa Diproses, dan Peristiwa yang Dihilangkan memungkinkan Anda membuat perbandingan ini.
Peritiwa Diterima
- Di panel Metrik di Azure Monitor, pilih Tambahkan Metrik.
- Pilih Peristiwa yang Diterima sebagai nilai Metrik dan Jumlah sebagai nilai Agregasi .
- Pilih tombol Tambahkan filter di atas bagan dan pilih Nilai properti Nama Komponen untuk memfilter peristiwa yang diterima oleh koneksi data tertentu yang ditentukan pada kluster Anda. Dalam contoh ini, kami memfilter koneksi data GitHubStreamingEvents . Setelah memilih nilai filter, klik menjauh dari pemilih filter untuk menutupnya.
Sekarang bagan memperlihatkan jumlah peristiwa yang diterima oleh koneksi data yang dipilih dari waktu ke waktu:
- Dalam bagan ini, koneksi data GitHubStreamingEvents menerima sekitar 200-500 peristiwa per unit waktu dari waktu ke waktu.
Peristiwa yang Diproses dan Peristiwa Dihilangkan
Untuk melihat apakah ada peristiwa yang dihilangkan oleh Azure Data Explorer, gunakan metrik Peristiwa yang Diproses dan Peristiwa yang Dihilangkan.
- Pada bagan yang telah Anda buat, pilih Tambahkan metrik.
- Pilih Peristiwa yang Diproses sebagai nilai Metrik dan Jumlah sebagai nilai Agregasi .
- Pilih Tambahkan metrik lagi dan pilih Peristiwa yang Dihilangkan sebagai nilai Metrik dan Jumlah sebagai nilai Agregasi .
Bagan sekarang menunjukkan jumlah Peristiwa yang diterima, diproses, dan dihilangkan oleh koneksi data GitHubStreamingEvents dari waktu ke waktu.
- Hampir semua peristiwa yang diterima berhasil diproses oleh koneksi data. Ada satu peristiwa yang dihilangkan, yang kompatibel dengan hasil penyerapan yang gagal karena permintaan buruk yang kita lihat saat melihat metrik hasil penyerapan.
Membandingkan peristiwa yang diterima di Azure Data Explorer dengan pesan keluar dari hub peristiwa
Anda mungkin juga ingin membandingkan jumlah peristiwa yang diterima dengan jumlah peristiwa yang dikirim dari pusat aktivitas ke Azure Data Explorer, dengan membandingkan metrik Peristiwa yang Diterima dan Pesan Keluar.
Pada bagan yang telah Anda buat untuk Peristiwa yang Diterima, pilih Tambahkan metrik.
Pilih Cakupan dan dalam dialog Pilih cakupan , telusuri, dan pilih namespace pusat aktivitas yang mengirim data ke koneksi data Anda.
Pilih Terapkan
Pilih Pesan Keluar sebagai nilai Metrik dan Jumlah sebagai nilai Agregasi.
Klik menjauh dari pengaturan untuk mendapatkan bagan lengkap yang membandingkan jumlah peristiwa yang diproses oleh koneksi data Azure Data Explorer dengan jumlah peristiwa yang dikirim dari pusat aktivitas.
- Perhatikan bahwa semua peristiwa yang dikirim dari pusat aktivitas berhasil diproses oleh koneksi data Azure Data Explorer.
- Jika Anda memiliki lebih dari satu hub peristiwa di namespace layanan pusat aktivitas, Anda harus memfilter metrik Pesan Keluar menurut dimensi Nama Entitas untuk hanya mendapatkan data dari hub peristiwa yang diinginkan di namespace pusat aktivitas Anda.
Catatan
Tidak ada opsi untuk memantau pesan keluar per grup konsumen. Metrik Pesan Keluar menghitung jumlah total pesan yang digunakan oleh semua grup konsumen. Jadi, jika Anda memiliki beberapa grup konsumen di pusat aktivitas, Anda mungkin mendapatkan jumlah Pesan Keluar yang lebih besar daripada Peristiwa yang Diterima.