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.
Azure Monitor untuk Azure Cosmos DB menyediakan tampilan metrik untuk memantau akun Anda dan membuat dasbor. Metrik Azure Cosmos DB dikumpulkan secara default. Fitur ini tidak mengharuskan Anda mengaktifkan atau mengonfigurasi apa pun secara eksplisit.
Definisi Metrik
Konsumsi RU yang Dinormalisasi adalah metrik antara 0% hingga 100% yang digunakan untuk membantu mengukur pemanfaatan throughput yang disediakan pada database atau kontainer. Metrik dipancarkan setiap 1 menit dan dideskripsikan sebagai pemanfaatan maksimum Unit Permintaan per detik (RU/dtk) di seluruh rentang kunci partisi dalam interval waktu. Setiap rentang kunci partisi dipetakan ke satu partisi fisik dan ditugaskan untuk menyimpan data dalam rentang nilai hash yang mungkin. Secara umum, semakin tinggi persentase RU yang telah dinormalisasi, semakin banyak Anda menggunakan throughput yang disediakan. Metrik juga dapat digunakan untuk melihat pemanfaatan rentang kunci partisi individual pada database atau kontainer.
Misalnya, Anda memiliki kontainer tempat Anda mengatur throughput maksimum untuk skala otomatis 20.000 RU/dtk (skala antara 2000 - 20.000 RU/dtk) dan Anda memiliki dua rentang kunci partisi (partisi fisik) P1 dan P2. Karena Azure Cosmos DB mendistribusikan throughput yang disediakan secara merata di semua rentang kunci partisi, P1 dan P2 masing-masing dapat menskalakan antara 1.000 - 10.000 RU/dtk. Misalkan dalam interval 1 menit, pada detik tertentu, P1 mengonsumsi 6.000 RU dan P2 mengonsumsi 8.000 RU. Penggunaan RU yang dinormalisasi P1 adalah 60% dan P2 80%. Penggunaan RU yang dinormalisasi secara keseluruhan dari seluruh kontainer adalah MAX(60%, 80%) = 80%.
Jika Anda tertarik untuk melihat konsumsi unit permintaan pada interval per detik, beserta dengan jenis operasinya, Anda dapat menggunakan log diagnostik opt-in dan melakukan kueri pada tabel PartitionKeyRUConsumption. Untuk mendapatkan gambaran umum tingkat tinggi tentang operasi dan kode status yang dilakukan aplikasi Anda pada sumber daya Azure Cosmos DB, Anda dapat menggunakan metrik Permintaan Total Azure Monitor bawaan (API untuk NoSQL), Permintaan Mongo, Permintaan Gremlin, atau Permintaan Cassandra . Nantinya, Anda dapat memfilter permintaan ini dengan kode status 429 dan membaginya berdasarkan Jenis Operasi.
Apa yang diharapkan dan dilakukan ketika RU/s yang dinormalisasi lebih tinggi
Ketika konsumsi RU yang dinormalisasi mencapai 100% untuk rentang kunci partisi tertentu, dan jika klien masih membuat permintaan di jendela waktu 1 detik ke rentang kunci partisi tertentu tersebut, ia menerima kesalahan batas laju (429).
Bukan berarti sumber daya Anda bermasalah. Secara default, SDK klien Azure Cosmos DB dan alat impor data, seperti Azure Data Factory dan pustaka eksekutor massal, secara otomatis mengulangi permintaan pada 429. Biasanya percobaan ulang tersebut dilakukan hingga sembilan kali. Akibatnya, meskipun Anda mungkin melihat 429 dalam metrik, kesalahan ini bahkan mungkin belum dikembalikan ke aplikasi Anda.
Secara umum, untuk beban kerja produksi, jika Anda melihat antara 1-5% permintaan dengan status 429, dan latensi end-to-end Anda dapat diterima, ini adalah tanda sehat bahwa RU/s sedang digunakan sepenuhnya. Dalam hal ini, jika metrik penggunaan RU yang dinormalisasi mencapai 100%, artinya dalam detik tertentu, ada setidaknya satu rentang kunci partisi menggunakan semua throughput yang tersedia. Hal ini dapat diterima karena tingkat keseluruhan kode 429 masih rendah. Tidak diperlukan tindakan lebih lanjut.
Untuk menentukan persentase permintaan Anda ke database atau container yang menghasilkan 429, dari akun Azure Cosmos DB Anda, menuju ke Insights>Permintaan>Total Permintaan berdasarkan Kode Status. Lakukan pemfilteran ke database dan kontainer tertentu. Untuk API Gremlin, gunakan metrik Permintaan Gremlin.
Jika metrik penggunaan RU yang dinormalisasi konsisten menunjukkan 100% di beberapa rentang kunci partisi, dan tingkat error 429 lebih besar dari 5%, disarankan untuk menaikkan throughput. Anda dapat mengetahui operasi mana yang berat dan penggunaan puncaknya dengan menggunakan Metrik monitor Azure dan log diagnostik monitor Azure. Untuk mempelajari praktik terbaik, lihat Praktik terbaik untuk menskalakan throughput yang disediakan (RU/s).
Tidak selalu terjadi bahwa Anda melihat kesalahan pembatasan tarif 429 hanya karena RU yang dinormalisasi mencapai 100%. Itu karena RU yang dinormalisasi adalah nilai tunggal yang mewakili penggunaan maksimum di semua rentang kunci partisi. Satu rentang kunci partisi mungkin sibuk tetapi rentang kunci partisi lainnya dapat melayani permintaan tanpa masalah. Misalnya, satu operasi seperti prosedur tersimpan yang mengonsumsi semua RU/s pada rentang partisi kunci menyebabkan lonjakan singkat dalam metrik konsumsi RU yang dinormalisasi. Dalam kasus seperti itu, tidak ada kesalahan pembatasan laju segera jika tingkat permintaan keseluruhan rendah atau permintaan dibuat ke partisi lain pada rentang kunci partisi yang berbeda.
Untuk mempelajari selengkapnya, lihat Mendiagnosis dan memecahkan masalah 429 pengecualian.
Cara memantau partisi panas
Metrik penggunaan RU yang dinormalisasi dapat digunakan untuk memantau apakah beban kerja memiliki partisi panas. Partisi panas muncul ketika satu atau beberapa kunci partisi logis mengonsumsi jumlah yang tidak proporsional dari total RU/s akibat volume permintaan yang lebih tinggi. Ini dapat disebabkan oleh desain kunci partisi yang tidak mendistribusikan permintaan secara merata. Ini mengakibatkan banyak permintaan diarahkan ke subset kecil partisi logis (yang menyiratkan rentang kunci partisi) yang menjadi panas. Karena semua data untuk partisi logis berada pada satu rentang "key partisi" dan total Permintaan Unit per detik didistribusikan secara merata di antara semua rentang "key partisi", partisi panas dapat menyebabkan kode status 429 dan penggunaan kapasitas pemrosesan yang tidak efisien.
Cara mengidentifikasi partisi panas
Untuk memverifikasi apakah ada partisi panas, buka Insights>Throughput>Konsumsi RU yang Dinormalisasi (%) Berdasarkan PartitionKeyRangeID. Lakukan pemfilteran ke database dan kontainer tertentu.
Setiap PartitionKeyRangeId dipetakan ke satu partisi fisik. Jika ada satu PartitionKeyRangeId yang memiliki konsumsi RU yang dinormalisasi lebih tinggi daripada yang lain (misalnya, satu secara konsisten berada di 100%, tetapi yang lain berada di 30% atau kurang), ini bisa menjadi tanda partisi panas.
Untuk mengidentifikasi partisi logis yang paling banyak menggunakan RU/dtk, lihat Cara mengidentifikasi partisi panas.
Konsumsi RU dan skala otomatis yang dinormalisasi
Metrik konsumsi RU yang dinormalisasi menunjukkan sebagai 100% jika setidaknya satu rentang kunci partisi menggunakan semua RU/dtk yang dialokasikan dalam detik tertentu dalam interval waktu. Satu pertanyaan umum yang muncul adalah, mengapa penggunaan RU dinormalisasi berada di 100%, tetapi Azure Cosmos DB tidak menskalakan RU/dtk ke throughput maksimum dengan skala otomatis?
Nota
Informasi berikut menjelaskan implementasi skala otomatis saat ini dan mungkin dapat berubah di masa mendatang.
Saat Anda menggunakan skala otomatis, Azure Cosmos DB hanya menskalakan RU/s ke throughput maksimum ketika konsumsi RU yang dinormalisasi adalah 100% untuk periode waktu yang berkelanjutan dalam interval 5 detik. Ini dilakukan untuk memastikan logika penskalaan ramah biaya untuk pengguna, karena memastikan bahwa lonjakan tunggal dan sesaat tidak menyebabkan penskalaan yang tidak perlu dan biaya yang lebih tinggi. Ketika ada lonjakan sementara, sistem biasanya menskalakan hingga melewati nilai RU/s yang sebelumnya, tetapi tetap lebih rendah dari RU/s maksimum.
Misalnya, Anda memiliki kontainer dengan throughput maksimum skala otomatis 20.000 RU/dtk (berkisar antara 2.000 - 20.000 RU/dtk) dan dua rentang kunci partisi. Setiap rentang kunci partisi dapat beroperasi dalam skala antara 1000 - 10.000 RU/s. Karena penyediaan skala otomatis mencakup semua sumber daya yang diperlukan sejak awal, Anda dapat menggunakan hingga 20.000 RU/dtk setiap saat.
Sekarang katakanlah Anda memiliki lonjakan lalu lintas terputus-terputus:
Selama satu detik, Partisi 1 melonjak menjadi 10.000 RU/dtk, lalu turun menjadi 1.000 RU/dtk selama empat detik berikutnya.
Secara bersamaan, Partisi 2 melonjak menjadi 8.000 RU/dtk, lalu turun menjadi 1.000 RU/dtk selama empat detik berikutnya.
Beginilah perilaku metrik:
Konsumsi RU yang dinormalisasi (yang menunjukkan penggunaan maksimum selama interval di semua partisi) menunjukkan pemanfaatan 100%%, karena Partisi 1 mencapai maksimum selama satu detik.
Namun, throughput yang disediakan dan metrik RU yang diskalakan otomatis tidak meningkatkan skala hingga RU/dtk maksimum hanya karena lonjakan 1 detik. Ini menskalakan berdasarkan interval 5 detik agar hemat biaya. Jadi untuk contoh sebelumnya, konsumsi partisi 1 dan partisi 2 RU tidak mencapai 10.000 RU/s berdasarkan interval 5 detik.
Akibatnya, meskipun skala otomatis tidak menskalakan ke maksimum, Anda masih dapat menggunakan total RU/dtk yang tersedia untuk detik lonjakan tersebut. Untuk memverifikasi konsumsi RU/dtk, Anda dapat menggunakan fitur Log Diagnostik pilihan untuk melakukan kueri terhadap konsumsi RU/dtk secara keseluruhan pada tingkat per detik di semua rentang kunci partisi.
CDBPartitionKeyRUConsumption
| where TimeGenerated >= (todatetime('2022-01-28T20:35:00Z')) and TimeGenerated <= todatetime('2022-01-28T20:40:00Z')
| where DatabaseName == "MyDatabase" and CollectionName == "MyContainer"
| summarize sum(RequestCharge) by bin(TimeGenerated, 1sec), PartitionKeyRangeId
| render timechart
Secara umum, untuk beban kerja produksi yang menggunakan penyesuaian skala otomatis, jika Anda melihat antara 1-5% permintaan-permintaan dengan 429, dan latensi end-to-end Anda dapat diterima, ini adalah tanda sehat bahwa RU/s sedang dimanfaatkan sepenuhnya. Bahkan jika konsumsi RU yang dinormalisasi sesekali mencapai 100% dan skala otomatis tidak meningkatkan hingga kapasitas RU/dtk maksimum, ini baik-baik saja karena tingkat keseluruhan 429 rendah. Tidak diperlukan tindakan.
Tip
Jika Anda menggunakan autoscale dan menemukan konsumsi RU yang dinormalisasi tetap berada di angka 100% dan Anda terus menerus diskalakan ke RU/s maksimum, ini mengindikasikan bahwa menggunakan throughput manual mungkin lebih hemat biaya. Untuk menentukan apakah throughput skala otomatis atau manual adalah yang terbaik untuk beban kerja Anda, lihat Cara memilih antara throughput standar (manual) dan skala otomatis yang disediakan. Azure Cosmos DB juga mengirimkan rekomendasi biaya berdasarkan pola beban kerja Anda untuk merekomendasikan throughput manual atau skala otomatis.
Lihat metrik konsumsi unit permintaan yang dinormalisasi
Masuk ke portal Azure.
Pilih Pantau dari bilah navigasi sebelah kiri, dan pilih Metrik.
Dari panel Metrik>Pilih sumber daya> pilih langganan yang diperlukan, dan grup sumber daya. Untuk Jenis sumber daya, pilih akun Azure Cosmos DB, pilih salah satu akun Azure Cosmos DB Anda yang sudah ada, dan pilih Terapkan.
Selanjutnya, Anda dapat memilih metrik dari menu metrik yang tersedia. Anda dapat memilih metrik khusus untuk unit permintaan, penyimpanan, latensi, ketersediaan, Cassandra, dan lainnya. Untuk mempelajari secara rinci tentang semua metrik yang tersedia dalam daftar ini, lihat artikel Metrik berdasarkan kategori. Dalam contoh ini, mari pilih metrik Konsumsi RU yang Dinormalisasi dan Max sebagai nilai agregasi.
Selain detail ini, Anda juga bisa memilihRentang waktu dan Granularitas waktu metrik. Maksimal, Anda dapat melihat metrik selama 30 hari terakhir. Setelah Anda menerapkan filter, bagan ditampilkan berdasarkan filter Anda.
Filter-filter untuk metrik penggunaan RU yang dinormalisasi
Anda juga bisa memfilter metrik dan bagan yang ditampilkan oleh CollectionName,DatabaseName, PartitionKeyRangeID, dan Region tertentu. Untuk memfilter metrik, pilih Tambahkan filter dan pilih properti yang diperlukan seperti CollectionName dan nilai terkait yang Anda minati. Kemudian, grafik menampilkan metrik penggunaan RU yang dinormalisasi untuk kontainer pada periode yang dipilih.
Anda dapat mengelompokkan metrik dengan menggunakan opsi Terapkan pemisahan. Untuk database throughput bersama, metrik RU yang dinormalisasi hanya memperlihatkan data pada granularitas database, itu tidak menampilkan data apa pun per koleksi. Jadi untuk database dengan throughput bersama, Anda tidak akan melihat data apa pun saat menerapkan pemisahan berdasarkan nama koleksi.
Metrik konsumsi unit permintaan yang dinormalisasi untuk setiap kontainer ditampilkan seperti yang ditunjukkan pada gambar berikut:
