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 Asztal
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. Minden partíciókulcs-tartomány egy fizikai partícióra van leképezve, és egy lehetséges kivonatérték-tartomány adatainak tárolására van hozzárendelve. Általánosságban, minél magasabb a normalizált RU százalékos értéke, Ön annál jobban kihasználta a kiosztott átviteli sebességet. 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. Ez elfogadható, mert a 429-es hibák teljes aránya még mindig alacsony. További művelet nem szükséges.
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 az Insights-kérelmek>összes kérését>állapotkód alapján. 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. Az Azure Monitor mutatóinak és az Azure Monitor diagnosztikai naplóinak használatával megtudhatja, melyek a nagy terhelésű műveletek, és mekkora a csúcsfelhasználásuk. Kövesse az Ajánlott eljárások a kiosztott átviteli sebesség (RU/s) skálázásához részben leírtakat.
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 az Insights>átviteli sebesség>normalizált RU-használatát (%) PartitionKeyRangeID szerint. 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?
Feljegyzé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. Semmit nem kell tenni.
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
- Az Azure Cosmos DB túl magas kérelemmennyiség miatti kivételeinek (429-es hibáinak) diagnosztizálása és hibaelhárítása