Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure Monitor voor Azure Cosmos DB biedt een metrische weergave voor het bewaken van uw account en het maken van dashboards. De metrische gegevens van Azure Cosmos DB worden standaard verzameld. Voor deze functie hoeft u niets expliciet in te schakelen of te configureren.
Metrische definitie
Genormaliseerd RU-verbruik is een metrische waarde tussen 0% en 100% die wordt gebruikt om het gebruik van ingerichte doorvoer in een database of container te meten. De metrische waarde wordt verzonden met intervallen van 1 minuut en wordt gedefinieerd als het maximale gebruik van aanvraageenheden per seconde (RU/s) voor alle partitiesleutelbereiken in het tijdsinterval. Elk partitiesleutelbereik wordt toegewezen aan één fysieke partitie en wordt toegewezen om gegevens te bewaren voor een bereik van mogelijke hash-waarden. Hoe hoger het genormaliseerde RU-percentage, hoe meer u de geconfigureerde doorvoer hebt gebruikt. De metrische waarde kan ook worden gebruikt om het gebruik van afzonderlijke partitiesleutelbereiken in een database of container weer te geven.
Stel dat u een container hebt waarin u de maximale doorvoer voor automatische schaalaanpassing van 20.000 RU/s instelt (schaalt tussen 2000 - 20.000 RU/s) en u twee partitiesleutelbereiken (fysieke partities) P1 en P2 hebt. Omdat Azure Cosmos DB de ingerichte doorvoer gelijkmatig over alle partitiesleutelbereiken verdeelt, kunnen P1 en P2 elk tussen 1000 en 10.000 RU/s schalen. Stel dat in een interval van 1 minuut, in een bepaalde seconde , P1 6.000 RU's verbruikt en P2 8.000 RU's verbruikt. Het genormaliseerde RU-verbruik van P1 is 60% en 80% voor P2. Het totale genormaliseerde RU-verbruik van de hele container is MAX(60%, 80%) = 80%.
Als u geïnteresseerd bent in het verbruik van verzoekseenheden per seconde, samen met het bewerkingstype, kunt u de opt-in diagnostische logboeken gebruiken en de PartitionKeyRUConsumption-tabel opvragen. Als u een algemeen overzicht wilt krijgen van de bewerkingen en statuscode die uw toepassing uitvoert op de Azure Cosmos DB-resource, kunt u de ingebouwde metrische gegevens van Azure Monitor Total Requests (API for NoSQL), Mongo-aanvragen, Gremlin-aanvragen of Cassandra-aanvragen gebruiken. Later kunt u filteren op deze aanvragen door de 429-statuscode en deze splitsen op bewerkingstype.
Wat u kunt verwachten en doen wanneer genormaliseerde RU/s hoger is
Wanneer het genormaliseerde RU-verbruik 100% bereikt voor een bepaald bereik van de partitiesleutel en als een client nog steeds aanvragen indient in dat tijdvenster van 1 seconde naar dat specifieke partitiesleutelbereik, krijgt deze een frequentiebeperkingsfout (429).
Dit betekent niet noodzakelijkerwijs dat er een probleem is met uw resource. Standaard worden de SDK's en hulpprogramma's voor gegevensimport van de Azure Cosmos DB-client, zoals Azure Data Factory en bulkexecutorbibliotheek, automatisch opnieuw geprobeerd op 429s. Ze proberen het meestal maximaal negen keer. Hoewel u 429s in de metrische waarden kunt zien, zijn deze fouten mogelijk niet eens weergegeven in uw toepassing.
Over het algemeen geldt dat als u voor een productieworkload tussen 1 en 5% aanvragen met 429's ziet en uw end-to-end latentie acceptabel is, is dit een goed teken dat de RU/s volledig worden gebruikt. In dit geval betekent het genormaliseerde ru-verbruik dat 100% bereikt, alleen dat in een bepaalde seconde ten minste één partitiesleutelbereik alle ingerichte doorvoer heeft gebruikt. Dit is acceptabel omdat de totale frequentie van 429-fouten nog steeds laag is. Er is geen verdere actie vereist.
Als u wilt bepalen welk percentage van uw aanvragen voor uw database of container heeft geresulteerd in 429's, gaat u vanuit uw Azure Cosmos DB-account naar Inzichtenaanvragen>>totaal aantal aanvragen per statuscode. Filteren op een specifieke database en container. Voor API voor Gremlin gebruikt u de metrische gegevens voor Gremlin-aanvragen .
Als de metrische waarde voor genormaliseerd RU-verbruik consistent 100% is voor meerdere partitiesleutelbereiken en de snelheid van 429's groter is dan 5%, is het raadzaam om de doorvoer te verhogen. U kunt erachter komen welke bewerkingen zwaar zijn en wat hun piekgebruik is met behulp van de metrische gegevens van Azure Monitor en diagnostische logboeken van Azure Monitor. Zie Aanbevolen procedures voor het schalen van ingerichte doorvoer (RU/s) om meer te leren over beste praktijken.
Het is niet altijd het geval dat u een 429 frequentiebeperkingsfout ziet, alleen omdat de genormaliseerde RU 100%heeft bereikt. Dat komt doordat de genormaliseerde RU één waarde is die het maximale gebruik vertegenwoordigt voor alle partitiesleutelbereiken. Het ene partitiesleutelbereik is mogelijk bezet, maar de andere partitiesleutelbereiken kunnen aanvragen zonder problemen verwerken. Een enkele bewerking, zoals een opgeslagen procedure die op een partitiesleutelbereik alle RU/s verbruikt, leidt bijvoorbeeld tot een korte piek in de genormaliseerde RU-verbruik-metriek. In dergelijke gevallen zijn er geen onmiddellijke frequentiebeperkingsfouten als de totale aanvraagsnelheid laag is of aanvragen worden gedaan naar andere partities in verschillende partitiesleutelbereiken.
Zie 429 uitzonderingen vaststellen en oplossen voor meer informatie.
Controleren op dynamische partities
De metrische gegevens voor genormaliseerd RU-verbruik kunnen worden gebruikt om te controleren of uw workload een dynamische partitie heeft. Er ontstaat een dynamische partitie wanneer een of enkele logische partitiesleutels een onevenredige hoeveelheid ru/s verbruiken vanwege een hoger aanvraagvolume. Dit kan worden veroorzaakt door een partitiesleutelontwerp dat geen aanvragen gelijkmatig distribueert. Het resulteert in veel aanvragen die worden omgeleid naar een kleine subset van logische partities (wat impliceert dat partitiesleutelbereiken ) dynamisch worden. Omdat alle gegevens voor een logische partitie zich op één partitiesleutelbereik bevinden en het totale aantal RU/s gelijkmatig wordt verdeeld over alle partitiesleutelbereiken, kan een warme partitie leiden tot 429-meldingen en inefficiënt gebruik van de doorvoer.
Hoe identificeer ik een hete partitie
Als u wilt controleren of er een dynamische partitie is, gaat u naar >> Filteren op een specifieke database en container.
Elke PartitionKeyRangeId wordt toegewezen aan één fysieke partitie. Als er één PartitionKeyRangeId is met een hoger genormaliseerd RU-verbruik dan anderen (bijvoorbeeld, eentje is consistent op 100%, maar anderen op 30% of minder), kan dit een teken zijn van een hete partitie.
Als u de logische partities wilt identificeren die de meeste RU/s verbruiken, raadpleegt u Hoe u de hete partitie identificeert.
Genormaliseerd RU-verbruik en automatische schaalaanpassing
De metrische gegevens voor genormaliseerd RU-verbruik worden weergegeven als 100% als ten minste één partitiesleutelbereik alle toegewezen RU/s gebruikt in een bepaalde seconde in het tijdsinterval. Een veelvoorkomende vraag die zich voordoet, is, waarom is genormaliseerd RU-verbruik met 100%, maar Azure Cosmos DB heeft de RU/s niet geschaald naar de maximale doorvoer met automatische schaalaanpassing?
Notitie
De volgende informatie beschrijft de huidige implementatie van automatische schaalaanpassing en kan in de toekomst worden gewijzigd.
Wanneer u automatische schaalaanpassing gebruikt, schaalt Azure Cosmos DB de RU/s alleen naar de maximale doorvoer wanneer het genormaliseerde RU-verbruik 100% is voor een langdurige, continue periode in een interval van 5 seconden. Dit wordt gedaan om ervoor te zorgen dat de schaallogica kostenvriendelijk is voor de gebruiker, omdat het ervoor zorgt dat enkele tijdelijke pieken niet leiden tot onnodig schalen en hogere kosten. Wanneer er momentele pieken zijn, wordt het systeem meestal omhoog geschaald naar een waarde die hoger is dan de eerder geschaalde RU/s, maar lager is dan de maximale RU/s.
Stel dat u een container hebt met een maximale doorvoer van 20.000 RU/s (schaalt tussen 2000 - 20.000 RU/s) en twee partitiesleutelbereiken. Elk partitiesleutelbereik kan worden geschaald tussen 1000 - 10.000 RU/s. Omdat met automatische schaalaanpassing alle vereiste resources vooraf worden uitgevoerd, kunt u op elk gewenst moment maximaal 20.000 RU/s gebruiken.
Stel nu dat u een onregelmatige piek van verkeer hebt:
Partitie 1 piekt één seconde lang naar een piek van 10.000 RU/s en vervolgens daalt tot 1.000 RU/s gedurende de komende vier seconden.
Tegelijkertijd piekt partitie 2 tot 8.000 RU/s, en daalt vervolgens tot 1.000 RU/s gedurende de volgende vier seconden.
Dit is hoe metrische gegevens zich gedragen:
Genormaliseerde RU-consumptie (die het maximale gebruik gedurende het interval voor alle partities weergeeft) toont 100% verbruik, omdat Partitie 1 voor één seconde zijn maximum bereikte.
Ingerichte doorvoer en automatisch geschaalde RU-metrische gegevens worden echter niet omhoog geschaald tot maximaal RU/s vanwege een piek van 1 seconde. Het schaalt op basis van een interval van 5 seconden om rendabel te zijn. Voor het vorige voorbeeld bereikt partitie 1 en partitie 2 RU-verbruik dus niet 10.000 RU/s op basis van het interval van 5 seconden.
Als gevolg hiervan kon u zelfs als de automatische schaalaanpassing niet tot het maximale schaalde, toch het totale aantal beschikbare RU/s gebruiken in die piekseconde. Als u uw RU/s-verbruik wilt controleren, kunt u de opt-in functie voor diagnostische logboeken gebruiken om het totale RU/s-verbruik op te vragen op een niveau per seconde voor alle partitiesleutelbereiken.
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
Over het algemeen, als u bij een productieworkload met automatische schaalaanpassing tussen 1 en 5% verzoeken met HTTP 429 meldingen ziet en uw end-to-end latentie acceptabel is, is dit een goede indicatie dat de resource units per seconde (RU/s) volledig benut worden. Zelfs als het genormaliseerde RU-verbruik af en toe 100% bereikt en autoscaling niet opschaalt naar het maximale RU/s, is dit acceptabel omdat de totale frequentie van 429-errorcodes laag is. Er is geen actie vereist.
Aanbeveling
Als u automatische schaalaanpassing gebruikt en merkt dat genormaliseerd RU-verbruik consistent 100% is en u consistent naar het maximum aantal RU/s wordt geschaald, is dit een teken dat het gebruik van handmatige doorvoer rendabeler kan zijn. Als u wilt bepalen of automatische schaalaanpassing of handmatige doorvoer het meest geschikt is voor uw workload, raadpleegt u Hoe u kunt kiezen tussen standaard (handmatig) en ingerichte doorvoer voor automatische schaalaanpassing. Azure Cosmos DB verstuurt kostenaanbevelingen op basis van uw workloadpatronen, en beveelt handmatige of autoschaal doorvoer aan.
De metrische gegevens over het genormaliseerde verbruik van aanvraageenheden weergeven
Meld u aan bij het Azure-portaal.
Selecteer Monitor in de linkernavigatiebalk en selecteer Metrische gegevens.
Selecteer een resource het vereiste > en de resourcegroep. Voor het resourcetype selecteert u Azure Cosmos DB-accounts, kiest u een van uw bestaande Azure Cosmos DB-accounts en selecteert u Toepassen.
Vervolgens kunt u een metrische waarde selecteren in de lijst met beschikbare metrische gegevens. U kunt metrische gegevens selecteren die specifiek zijn voor het aanvragen van eenheden, opslag, latentie, beschikbaarheid, Cassandra en andere. Zie het artikel Metrische gegevens per categorie voor meer informatie over alle beschikbare metrische gegevens in deze lijst. In dit voorbeeld selecteren we de metrische waarde genormaliseerd RU-verbruik en Max als de aggregatiewaarde.
Naast deze details kunt u ook het tijdsbereik en de tijdgranulariteit van de metrische gegevens selecteren. U kunt maximaal metrische gegevens bekijken voor de afgelopen 30 dagen. Nadat u het filter hebt toegepast, wordt een grafiek weergegeven op basis van uw filter.
Filters voor metrische gegevens over genormaliseerd RU-verbruik
U kunt ook metrische gegevens en de grafiek filteren die worden weergegeven door een specifieke CollectionName, DatabaseName, PartitionKeyRangeID en Region. Als u de metrische gegevens wilt filteren, selecteert u Filter toevoegen en kiest u de vereiste eigenschap, zoals CollectionName en de bijbehorende waarde waarin u geïnteresseerd bent. In de grafiek worden vervolgens de genormaliseerde metrische ru-verbruiksgegevens voor de container voor de geselecteerde periode weergegeven.
U kunt metrische gegevens groeperen met behulp van de optie Splitsen toepassen . Voor gedeelde doorvoerdatabases toont de genormaliseerde RU-metrische gegevens alleen gegevens in de granulariteit van de database. Er worden geen gegevens per verzameling weergegeven. Voor een gedeelde doorvoerdatabase ziet u dus geen gegevens wanneer u splitst op naam van de verzameling.
De metrische gegevens voor genormaliseerd verbruik van aanvraageenheden voor elke container worden weergegeven, zoals wordt weergegeven in de volgende afbeelding:
