Cara memantau RU/dtk yang dinormalisasi untuk kontainer Azure Cosmos DB atau akun

BERLAKU UNTUK: NoSQL MongoDB Cassandra Gremlin Meja

Azure Monitor untuk Azure Cosmos DB menyediakan tampilan metrik untuk memantau akun Anda dan membuat dasbor. Metrik Azure Cosmos DB dikumpulkan secara default, dengan fitur ini, Anda tidak perlu mengaktifkan atau mengonfigurasikan apa pun secara eksplisit.

Definisi Metrik

Metrik Penggunaan RU yang Dinormalisasi adalah metrik antara 0% hingga 100% yang digunakan untuk membantu mengukur pemanfaatan throughput yang tersedia pada database atau kontainer. Metrik dipancarkan pada interval 1 menit dan didefinisikan sebagai pemanfaatan RU/dtk maksimum di semua rentang kunci partisi dalam interval waktu tersebut. Setiap rentang kunci partisi memetakan ke satu partisi fisik dan ditugaskan untuk menyimpan data untuk rentang nilai hash yang memungkinkan. Secara umum, semakin tinggi persentase RU yang Dinormalisasi, semakin banyak Anda menggunakan throughput yang tersedia. 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 tersedia secara merata di semua rentang kunci partisi, P1 dan P2 masing-masing dapat menskalakan antara 1000 - 10.000 RU/dtk. Misalkan dalam interval 1 menit, dalam detik tertentu, P1 menggunakan 6000 unit permintaan dan P2 menggunakan 8000 unit permintaan. 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 penggunaan unit permintaan pada interval per detik, bersama dengan jenis operasi, Anda dapat menggunakan fitur keikutsertaan Log Diagnostik dan mengkueri 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 Tipe Operasi.

Apa yang diharapkan dan dilakukan ketika RU/s yang dinormalisasi lebih tinggi

Ketika penggunaan RU yang dinormalisasi mencapai 100% pada rentang kunci partisi yang diberikan, dan jika klien masih membuat permintaan dalam jeda waktu 1 detik pada rentang kunci partisi tertentu - rentang tersebut menerima kesalahan tingkat terbatas (429).

Bukan berarti sumber daya Anda bermasalah. Secara default, SDK klien Azure Cosmos DB dan alat pengimpor data, seperti Azure Data Factory dam pustaka eksekutor massal, akan secara otomatis mencoba ulang permintaan saat mengalami kesalahan 429. Biasanya percobaan ulang tersebut dilakukan hingga 9 kali. Akibatnya, meskipun Anda mungkin melihat 429 dalam metrik, kesalahan ini bahkan mungkin belum ditampilkan di aplikasi Anda.

Secara umum, untuk beban kerja produksi, jika Anda melihat permintaan berpresentase antara 1-5% dengan 429s, dan latensi menyeluruh Anda dapat diterima, hal ini merupakan indikator bagus bahwa RU/s sepenuhnya dimanfaatkan. 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 429 masih rendah. Tidak ada tindakan lebih lanjut yang diperlukan.

Untuk menentukan berapa persen permintaan ke database atau kontainer yang menghasilkan 429 detik, dari bilah akun Azure Cosmos DB, buka Wawasan>Permintaan>Total Permintaan berdasarkan Kode Status. Lakukan pemfilteran ke database dan kontainer tertentu. Untuk API untuk Gremlin, gunakan metrik Permintaan Gremlin.

Jika metrik penggunaan RU yang dinormalisasi secara konsisten 100% di beberapa rentang kunci partisi dan tingkat 429 lebih besar dari 5%, sebaiknya tingkatkan throughput. Anda dapat mengetahui operasi mana yang berat dan penggunaan puncaknya dengan menggunakan Metrik monitor Azure dan log diagnostik monitor Azure. Ikuti Praktik terbaik untuk menskalakan throughput yang tersedia (RU/dtk).

Kesalahan tingkat terbatas 429 tidak selalu muncul hanya karena RU yang dinormalisasi telah mencapai 100%. Karena RU yang dinormalisasi adalah nilai tunggal yang mewakili penggunaan maksimal di semua rentang kunci partisi. Ketika satu rentang kunci partisi sibuk, rentang kunci partisi lainnya dapat melayani permintaan tanpa masalah. Misalnya, operasi tunggal seperti prosedur tersimpan yang menggunakan semua RU/dtk pada rentang kunci partisi akan menyebabkan lonjakan singkat dalam metrik penggunaan RU/dtk yang dinormalisasi. Dalam kasus seperti itu, tidak akan ada kesalahan tingkat terbatas langsung jika tingkat permintaan keseluruhan rendah atau permintaan dibuat ke partisi lain pada rentang kunci partisi yang berbeda.

Pelajari selengkapnya cara menginterpretasikan dan men-debug kesalahan pembatasan laju 429.

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. Akibatnya, banyak permintaan yang diarahkan ke subset kecil dari partisi logis (yang menyiratkan rentang kunci partisi) yang menjadi "panas." Karena semua data untuk partisi logis berada pada satu rentang kunci partisi dan total RU/dtk didistribusikan secara merata di antara semua rentang kunci partisi, partisi yang panas dapat menyebabkan 429 detik dan penggunaan throughput yang tidak efisien.

Cara mengidentifikasi apakah ada 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 menggunakan RU ternormalisasi yang jauh lebih tinggi daripada yang lain (misalnya, ada satu yang secara konsisten berada di 100%, tetapi yang lain berada di 30% atau di bawahnya), bisa jadi ini tanda partisi yang panas.

Untuk mengidentifikasi partisi logis yang paling banyak menggunakan RU/dtk, serta solusi yang disarankan, lihat artikel Mendiagnosis dan memecahkan masalah pengecualian tingkat permintaan Azure Cosmos DB terlalu besar (429).

Penggunaan RU yang dinormalisasi dan skala otomatis

Metrik penggunaan RU yang dinormalisasi akan ditampilkan sebagai 100% jika ada setidaknya 1 rentang kunci partisi yang menggunakan semua RU/dtk yang dialokasikan dalam detik tertentu pada 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?

Catatan

Informasi di bawah ini menjelaskan implementasi skala otomatis saat ini dan dapat berubah di masa mendatang.

Saat Anda menggunakan skala otomatis, Azure Cosmos DB hanya menskalakan RU/s ke throughput maksimum saat konsumsi RU yang dinormalisasi adalah 100% untuk jangka waktu berkelanjutan dan berkesinambungan dalam interval 5 detik. Hal ini dilakukan untuk memastikan logika penskalaan hemat bagi pengguna, karena memastikan bahwa lonjakan tunggal dan sesaat tidak menyebabkan penskalaan yang tidak diperlukan dan biaya yang lebih tinggi. Ketika ada lonjakan sesaat, sistem biasanya menskalakan hingga nilai yang lebih tinggi dibandingkan dengan yang sebelumnya diskalakan ke RU/s, tetapi lebih rendah dari RU/s maksimumnya.

Misalnya, Anda memiliki kontainer dengan throughput maksimum skala otomatis 20.000 RU/dtk (skala antara 2000 - 20.000 RU/dtk) dan 2 rentang kunci partisi. Setiap rentang kunci partisi dapat menskalakan antara 1000 - 10.000 RU/dtk. Karena skala otomatis menyediakan semua sumber daya yang diperlukan di awal, Anda dapat menggunakan hingga 20.000 RU/dtk kapan saja. Katakanlah lonjakan lalu lintas Anda terputus-terputus, di mana penggunaan salah satu rentang kunci partisi adalah 10.000 RU/dtk dalam satu detik. Untuk detik berikutnya, penggunaan kembali turun ke 1000 RU/dtk. Karena metrik penggunaan RU yang dinormalisasi menunjukkan pemanfaatan tertinggi dalam periode waktu di semua partisi, metrik tersebut akan menunjukkan 100%. Namun, karena pemanfaatannya hanya 100% selama 1 detik, skala otomatis tidak akan menskalakan ke maksimum secara otomatis.

Akibatnya, meskipun skala otomatis tidak menskalakan hingga maksimum, Anda masih dapat menggunakan total RU/dtk yang tersedia. Untuk memverifikasi penggunaan RU/dtk, Anda dapat menggunakan fitur keikutsertaan Log Diagnostik untuk mengkueri penggunaan 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 skala otomatis, jika Anda melihat antara 1-5% permintaan bernilai 429 detik, dan latensi ujung ke ujung dapat diterima, maka ini adalah tanda yang baik bahwa RU/dtk digunakan sepenuhnya. Meskipun penggunaan RU yang dinormalisasi terkadang mencapai 100% dan skala otomatis tidak naik ke RU/dtk maksimum, tidak masalah karena tingkat keseluruhan 429d dinilai rendah. Tidak diperlukan tindakan.

Tip

Jika Anda menggunakan skala otomatis dan menemukan bahwa penggunaan RU yang dinormalisasi secara konsisten berada di 100% dan Anda secara konsisten menskalakan ke RU/dtk maksimum, maka ini adalah tanda bahwa menggunakan throughput manual mungkin lebih hemat biaya. Untuk menentukan apakah skala otomatis atau throughput manual adalah yang terbaik untuk beban kerja Anda, lihat cara memilih antara throughput yang tersedia standar (manual) dan skala otomatis. Azure Cosmos DB juga mengirim rekomendasi Azure Advisor berdasarkan pola beban kerja Anda untuk merekomendasikan throughput manual atau skala otomatis.

Lihat metrik konsumsi unit permintaan yang dinormalisasi

1. Masuk ke portal Azure.

2. Pilih Pantau dari bilah navigasi sebelah kiri, dan pilih Metrik.

   

3. 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.

   

4. Selanjutnya, Anda dapat memilih metrik dari menu metrik yang tersedia. Anda dapat memilih metrik khusus untuk meminta unit, 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 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 throughput bersama, Anda tidak akan melihat data apa pun saat Anda menerapkan pemisahan berdasarkan nama koleksi.

Metrik konsumsi unit permintaan yang dinormalisasi untuk setiap kontainer ditampilkan seperti yang ditunjukkan pada gambar berikut:

Langkah berikutnya

• Pantau data Azure Cosmos DB dengan menggunakan pengaturan diagnostik di Azure.
• Audit operasi sarana kontrol Azure Cosmos DB
• Mendiagnosis dan memecahkan masalah pengecualian tingkat permintaan terlalu besar (429) dalam Azure Cosmos DB