Normalizált RU/s monitorozása Azure Cosmos DB-tároló vagy -fiók esetén
A KÖVETKEZŐKRE VONATKOZIK: 
Nosql MongoDB Cassandra Gremlin Táblázat
Az Azure Cosmos DB-hez készült Azure Monitor metrikanézetet biztosít a fiók figyeléséhez és irányítópultok létrehozásához. Az Azure Cosmos DB-metrikákat alapértelmezés szerint gyűjti a rendszer, ez a funkció nem követeli meg, hogy bármit explicit módon engedélyezzen vagy konfiguráljon.
Metrikadefiníció
A normalizált ru-használat metrika egy 0% és 100% közötti metrika, amely az adatbázison vagy tárolón kiosztott átviteli sebesség kihasználtságának mérésére szolgál. A metrika 1 perces időközönként kerül kibocsátásra, és az időintervallum összes partíciókulcs-tartományának maximális RU/s kihasználtságaként van definiálva. Each partition key range maps to one physical partition and is assigned to hold data for a range of possible hash values. In general, the higher the Normalized RU percentage, the more you've utilized your provisioned throughput. A metrikával megtekintheti az egyes partíciókulcs-tartományok kihasználtságát egy adatbázisban vagy tárolóban.
Tegyük fel például, hogy van egy tárolója, ahol az automatikus skálázás maximális átviteli sebessége 20 000 RU/s (2000 és 20 000 RU/s közötti skálázás), és két partíciókulcs-tartomány (fizikai partíció) P1 és P2. Mivel az Azure Cosmos DB egyenlően osztja el a kiosztott átviteli sebességet az összes partíciókulcs-tartomány között, a P1 és a P2 skálázható 1000–10 000 RU/s között. Tegyük fel, hogy egy 1 perces intervallumban, egy adott másodpercben a P1 6000 kérelemegységet, a P2 pedig 8000 kérelemegységet használt fel. A P1 normalizált RU-felhasználása 60%, P2 esetén 80%. A teljes tároló általános normalizált RU-felhasználása MAX(60%, 80%) = 80%.
Ha a kérelemegység-felhasználást másodpercenként szeretné látni, a művelettípussal együtt használhatja az opt-in funkció diagnosztikai naplóit , és lekérdezheti a PartitionKeyRUConsumption táblát . Az alkalmazás által az Azure Cosmos DB-erőforráson végrehajtott műveletek és állapotkódok magas szintű áttekintéséhez használhatja a beépített Azure Monitor Total Requests (API for NoSQL), a Mongo Requests, a Gremlin Requests vagy a Cassandra Requests metrikát. Később szűrheti ezeket a kéréseket a 429-es állapotkód alapján, és feloszthatja őket művelettípus szerint.
Mi várható és mi a teendő, ha a normalizált RU/s magasabb
Ha a normalizált ru-használat eléri a 100%-ot egy adott partíciókulcs-tartomány esetében, és ha egy ügyfél továbbra is az adott partíciókulcs-tartományhoz tartozó 1 másodperces időkeretben küld kéréseket, korlátozott sebességű hibát (429) kap.
Ez nem feltétlenül jelenti azt, hogy probléma van az erőforrással. Alapértelmezés szerint az Azure Cosmos DB ügyféloldali SDK-k és adatimportáló eszközök, például az Azure Data Factory és a tömeges végrehajtói kódtár automatikusan újrapróbálkoznak a 429-eseken. Általában legfeljebb 9 alkalommal próbálkoznak újra. Ennek eredményeképpen előfordulhat, hogy 429-et lát a metrikákban, de előfordulhat, hogy ezeket a hibákat nem is adták vissza az alkalmazásnak.
Általánosságban, ha az éles számítási feladatok esetén a kérések 1–5%-ánál jelenik meg 429-es hiba, és a végpontok közötti késés mértéke elfogadható, az azt jelzi, hogy a másodpercenkénti kérelemegységek teljes mértékben ki vannak használva. Ebben az esetben a normalizált RU fogyasztási metrika csak azt jelenti, hogy egy adott másodpercben legalább egy partíciókulcs-tartomány felhasználta az összes kiosztott átviteli sebességet. This is acceptable because the overall rate of 429s is still low. No further action is required.
Annak megállapításához, hogy az adatbázisra vagy tárolóra irányuló kérések hány százaléka 429-et eredményezett, az Azure Cosmos DB-fiók paneljén keresse meg a Elemzések> Requests>Total Requests by Status Code parancsot. Szűrés adott adatbázisra és tárolóra. A Gremlin API-hoz használja a Gremlin Requests metrikát.
Ha a normalizált RU-használat metrika több partíciókulcs-tartományon belül következetesen 100%-os, és a 429s sebesség nagyobb, mint 5%, javasoljuk, hogy növelje az átviteli sebességet. You can find out which operations are heavy and what their peak usage is by using the Azure monitor metrics and Azure monitor diagnostic logs. Follow the best practices for scaling provisioned throughput (RU/s).
Nem mindig jelenik meg 429 sebességkorlátozó hiba, csak azért, mert a normalizált RU elérte a 100%-ot. Ennek az az oka, hogy a normalizált ru egyetlen érték, amely az összes partíciókulcs-tartomány maximális használatát jelöli. Előfordulhat, hogy az egyik partíciókulcs-tartomány foglalt, de a többi partíciókulcs-tartomány problémamentesen kiszolgálhatja a kéréseket. Például egy olyan művelet, mint egy tárolt eljárás, amely egy partíciókulcs-tartomány összes RU/s-ját felhasználja, a normalizált RU-használati metrika rövid kiugrásához vezet. Ilyen esetekben nem lesznek azonnali sebességkorlátozási hibák, ha a teljes kérési arány alacsony, vagy a kérések más partíciókra irányulnak a különböző partíciókulcs-tartományokban.
További információk a 429-es sebességkorlátozó hibák értelmezéséről és elhárításáról.
Gyakori elérésű partíciók figyelése
A normalizált ru-használati metrikával figyelheti, hogy a számítási feladat rendelkezik-e gyakori elérésű partícióval. Gyakori partíció akkor fordul elő, ha egy vagy néhány logikai partíciókulcs aránytalanul nagy mennyiségű ru/s-t használ fel a nagyobb kérelemmennyiség miatt. Ezt olyan partíciókulcs-kialakítás okozhatja, amely nem egyenletesen osztja el a kéréseket. Ez azt eredményezi, hogy a rendszer számos kérést irányít a logikai partíciók egy kis részhalmazára (ami partíciókulcs-tartományokra utal), amelyek "gyakori" értékké válnak. Mivel egy logikai partíció összes adata egy partíciókulcs-tartományban található, és a teljes RU/s egyenletesen oszlik el az összes partíciókulcs-tartomány között, a gyakori partíciók 429-et eredményezhetnek, és nem hatékony az átviteli sebesség.
Gyakori elérésű partíció azonosítása
Ha ellenőrizni szeretné, hogy van-e gyakori partíció, keresse meg a Elemzések> Throughput>Normalized RU Consumption (%) By PartitionKeyRangeID (%) lehetőséget. Szűrés adott adatbázisra és tárolóra.
Minden PartitionKeyRangeId egy fizikai partícióra van leképzve. Ha van egy PartitionKeyRangeId, amely jelentősen magasabb normalizált RU-használattal rendelkezik, mint mások (például az egyik konzisztensen 100%-os, míg mások 30%-os vagy kisebb), ez a gyakori elérésű partíciók jele lehet.
A legtöbb RU/s-t használó logikai partíciók és az ajánlott megoldások azonosításához tekintse meg az Azure Cosmos DB-kérelmek túl nagy (429) kivételeinek diagnosztizálása és hibaelhárítása című cikket.
Normalizált ru-használat és automatikus skálázás
A normalizált ru-használat metrika 100%-os értékként jelenik meg, ha legalább 1 partíciókulcs-tartomány az időintervallum bármely másodpercében használja a lefoglalt RU/s-t. Gyakori kérdés, hogy miért 100%-os a normalizált ru-használat, de az Azure Cosmos DB nem skálázta a ru/s-t az automatikus skálázás maximális átviteli sebességére?
Megjegyzés:
Az alábbi információk az automatikus skálázás aktuális megvalósítását ismertetik, és a jövőben változhatnak.
Automatikus skálázás használata esetén az Azure Cosmos DB csak akkor skálázza az RU/s-t a maximális átviteli sebességre, ha a normalizált RU-használat 100%-os tartós, folyamatos időtartamra 5 másodperces időközzel. Ez annak érdekében történik, hogy a skálázási logika költségbarát legyen a felhasználó számára, mivel biztosítja, hogy az egyszeri, pillanatnyi csúcsok ne vezessenek szükségtelen skálázáshoz és magasabb költségekhez. Pillanatnyi kiugró értékek esetén a rendszer általában a korábban ru/s-ra skálázott értéknél magasabb értékre skálázható, de alacsonyabbra, mint a maximális RU/s.
Tegyük fel például, hogy rendelkezik egy 20 000 RU/s maximális átviteli sebességgel rendelkező tárolóval (2000–20 000 RU/s közötti skálázás) és 2 partíciókulcs-tartománylal. Minden partíciókulcs-tartomány 1000–10 000 RU/s között skálázható. Mivel az automatikus skálázás minden szükséges erőforrást előre kioszt, bármikor legfeljebb 20 000 RU/s használható. Tegyük fel, hogy időszakosan megugrik a forgalom, ahol egyetlen másodpercig az egyik partíciókulcs-tartomány használata 10 000 RU/s. A következő másodpercben a használat 1000 RU/s-ra csökken. Mivel a normalizált RU-használat metrika az időszak legmagasabb kihasználtságát mutatja az összes partíción, 100%-ot fog mutatni. Mivel azonban a kihasználtság csak 100%-os volt 1 másodpercig, az automatikus skálázás nem fog automatikusan a maximális értékre skálázni.
Ennek eredményeképpen annak ellenére, hogy az automatikus skálázás nem a maximálisra skálázható, továbbra is használhatta a rendelkezésre álló teljes RU/s-t. Az RU/s használatának ellenőrzéséhez a diagnosztikai naplókban lekérdezheti a teljes RU/s-felhasználást másodpercenkénti szinten az összes partíciókulcs-tartományon.
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
Általánosságban elmondható, hogy az automatikus skálázást használó éles számítási feladatok esetében, ha a kérések 1–5%-át látja 429-zel, és a végpontok közötti késés elfogadható, ez jó jel arra, hogy a kérelemegységek teljes mértékben kihasználva vannak. Még akkor is, ha a normalizált RU-használat időnként eléri a 100%-ot, és az automatikus skálázás nem skálázható fel a maximális RU/s-ra, ez rendben van, mert a 429s teljes aránya alacsony. No action is required.
Tipp.
Ha automatikus skálázást használ, és úgy találja, hogy a normalizált ru-használat következetesen 100%, és folyamatosan a maximális RU/s-ra van skálázva, ez azt jelzi, hogy a manuális átviteli sebesség használata költséghatékonyabb lehet. Annak megállapításához, hogy az automatikus skálázás vagy a manuális átviteli sebesség a legjobb-e a számítási feladathoz, tekintse meg , hogyan választhat a standard (manuális) és az automatikus skálázási kiosztott átviteli sebesség között. Az Azure Cosmos DB emellett azure Advisor-javaslatokat is küld a számítási feladatok mintái alapján, hogy manuális vagy automatikus skálázási átviteli sebességet javasoljon.
A normalizált kérelemegység-használati metrika megtekintése
Jelentkezzen be az Azure Portalra.
Válassza a Figyelés lehetőséget a bal oldali navigációs sávon, és válassza a Metrikák lehetőséget.
A Metrikák panelen >válassza ki az erőforrást>, és válassza ki a szükséges előfizetést és erőforráscsoportot. Az erőforrástípushoz válassza az Azure Cosmos DB-fiókokat, válasszon egy meglévő Azure Cosmos DB-fiókot, és válassza az Alkalmaz lehetőséget.
Ezután kiválaszthat egy metrikát az elérhető metrikák listájából. Kiválaszthatja a kérelemegységekre, a tárolásra, a késésre, a rendelkezésre állásra, a Cassandra-ra és másokra vonatkozó metrikákat. A listában szereplő összes elérhető metrika részletes megismeréséhez tekintse meg a Metrikák kategória szerint című cikket. Ebben a példában a Normalized RU Consumption metrika és a Max elemet jelöljük ki összesítési értékként.
Ezen részletek mellett kiválaszthatja a metrikák időtartományát és időrészletességét is. Legfeljebb az elmúlt 30 nap metrikáit tekintheti meg. A szűrő alkalmazása után egy diagram jelenik meg a szűrő alapján.
Normalizált RU-használati metrikák szűrői
A metrikákat és az adott CollectionName, DatabaseName, PartitionKeyRangeID és Régió által megjelenített diagramot is szűrheti. A metrikák szűréséhez válassza a Szűrő hozzáadása lehetőséget, és válassza ki a szükséges tulajdonságot, például a CollectionName és a megfelelő értéket, amely érdekli. A gráf ezután megjeleníti a tároló normalizált RU-használati metrikáit a kiválasztott időszakra vonatkozóan.
A metrikákat az Alkalmaz felosztás beállítással csoportosíthatja. Megosztott átviteli sebességű adatbázisok esetében a normalizált RU-metrika csak az adatbázis részletességében jeleníti meg az adatokat, gyűjteményenként nem jelenít meg adatokat. A megosztott átviteli sebességű adatbázisok esetében tehát nem fog megjelenni semmilyen adat a gyűjteménynév szerinti felosztás alkalmazásakor.
Az egyes tárolókhoz tartozó normalizált kérelemegység-fogyasztási metrika az alábbi képen látható módon jelenik meg:
Következő lépések
- Az Azure Cosmos DB-adatok monitorozása diagnosztikai beállításokkal az Azure-ban.
- Az Azure Cosmos DB vezérlősík-műveleteinek naplózása
- Diagnose and troubleshoot Azure Cosmos DB request rate too large (429) exceptions