Share via


Bewaken en fouten opsporen met inzichten in Azure Cosmos DB

VAN TOEPASSING OP: NoSQL MongoDB Cassandra Gremlin Tafel

Azure Cosmos DB biedt inzicht in doorvoer, opslag, consistentie, beschikbaarheid en latentie. De Azure-portal biedt een geaggregeerde weergave van deze metrische gegevens. U kunt ook metrische gegevens uit Azure Cosmos DB bekijken vanuit de Azure Monitor API. De dimensiewaarden voor de metrische gegevens, zoals containernaam, zijn niet hoofdlettergevoelig. Daarom moet u hoofdlettergevoelige vergelijkingen gebruiken bij het uitvoeren van tekenreeksvergelijkingen op deze dimensiewaarden. Zie Azure Cosmos DB bewaken voor meer informatie over het weergeven van metrische gegevens van Azure Monitor.

In dit artikel worden veelvoorkomende use cases beschreven en wordt uitgelegd hoe Azure Cosmos DB-inzichten kunnen worden gebruikt om deze problemen te analyseren en op te sporen. De metrische inzichten worden standaard om de vijf minuten verzameld en worden zeven dagen bewaard.

In de volgende secties worden veelvoorkomende scenario's beschreven waarin u metrische gegevens van Azure Cosmos DB kunt gebruiken.

Begrijpen hoeveel aanvragen slagen of fouten veroorzaken

Als u aan de slag wilt gaan, gaat u naar Azure Portal en gaat u naar het deelvenster Inzichten . Open vanuit dit deelvenster het tabblad Aanvragen . Op het tabblad Aanvragen ziet u een grafiek met het totale aantal aanvragen dat is gesegmenteerd op basis van de statuscode en het bewerkingstype. Zie HTTP-statuscodes voor Azure Cosmos DB voor meer informatie over HTTP-statuscodes.

De meest voorkomende foutcode is 429 (snelheidsbeperking/bandbreedtebeperking). Deze fout betekent dat aanvragen voor Azure Cosmos DB meer zijn dan de ingerichte doorvoer. De meest voorkomende oplossing voor dit probleem is het omhoog schalen van de RU's voor de opgegeven verzameling. Zie Inleiding tot ingerichte doorvoer in Azure Cosmos DB voor meer informatie

Schermopname van het totale aantal aanvragen per statuscode, vertraagde aanvragen en het totale aantal aanvragen per bewerkingstype.

Het doorvoerverbruik bepalen op basis van een partitiesleutelbereik

Het hebben van een goede kardinaliteit van uw partitiesleutels is essentieel voor elke schaalbare toepassing. Als u de doorvoerdistributie van een gepartitioneerde container wilt bepalen, opgesplitst op partitiesleutelbereik-id's, gaat u naar het deelvenster Inzichten . Open het tabblad Doorvoer . Het genormaliseerde RU/s-verbruik in verschillende partitiesleutelbereiken wordt weergegeven in de grafiek.

Schermopname van het tabblad Doorvoer, met het RU/s-verbruik.

Met behulp van deze grafiek kunt u vaststellen of er een dynamische partitie is. De PartitionKeyRangeIDs komen overeen met fysieke partities. De metrische waarde genormaliseerd RU-verbruik is een waarde tussen 0% en 100% waarmee het gebruik van ingerichte doorvoer op een database of container wordt gemeten. Een ongelijke doorvoerdistributie kan dynamische partities veroorzaken, wat kan leiden tot beperkte aanvragen en mogelijk opnieuw partitioneren vereist. Nadat u hebt geïdentificeerd welke partitiesleutel de scheefheid in de distributie veroorzaakt, moet u de container mogelijk opnieuw partitioneren met een meer gedistribueerde partitiesleutel. Zie Partitionering en horizontaal schalen in Azure Cosmos DB voor meer informatie over partitionering in Azure Cosmos DB.

Het gegevens- en indexgebruik bepalen

Het is belangrijk om de opslagdistributie van een gepartitioneerde container te bepalen op basis van gegevensgebruik, indexgebruik en documentgebruik. U kunt het indexgebruik minimaliseren, het gegevensgebruik maximaliseren en uw query's optimaliseren. Als u deze gegevens wilt ophalen, gaat u naar het deelvenster Inzichten en opent u het tabblad Opslag .

Schermopname van het deelvenster Inzichten, waarin het tabblad Opslag wordt gemarkeerd.

Gegevensgrootte vergelijken met indexgrootte

In Azure Cosmos DB is de totale verbruikte opslag de combinatie van zowel de gegevensgrootte als de indexgrootte. Normaal gesproken is de indexgrootte een fractie van de gegevensgrootte. Zie het artikel Indexgrootte voor meer informatie. In het deelvenster Metrische gegevens in Azure Portal toont het tabblad Storage de uitsplitsing van het opslagverbruik op basis van gegevens en indexen.

// Measure the document size usage (which includes the index size)  
ResourceResponse<DocumentCollection> collectionInfo = await client.ReadDocumentCollectionAsync(UriFactory.CreateDocumentCollectionUri("db", "coll"));
 Console.WriteLine("Document size quota: {0}, usage: {1}", collectionInfo.DocumentQuota, collectionInfo.DocumentUsage);

Als u indexruimte wilt besparen, kunt u het indexeringsbeleid aanpassen.

Fouten opsporen in trage query's

In de API voor NoSQL SDK's biedt Azure Cosmos DB queryuitvoeringsstatistieken.

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
 UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName),
 "SELECT * FROM c WHERE c.city = 'Seattle'",
 new FeedOptions
 {
 PopulateQueryMetrics = true,
 MaxItemCount = -1,
 MaxDegreeOfParallelism = -1,
 EnableCrossPartitionQuery = true
 }).AsDocumentQuery();
FeedResponse<dynamic> result = await query.ExecuteNextAsync();

// Returns metrics by partition key range Id
IReadOnlyDictionary<string, QueryMetrics> metrics = result.QueryMetrics;

QueryMetrics bevat details over hoe lang elk onderdeel van de query heeft geduurd om uit te voeren. De meest voorkomende hoofdoorzaak voor langlopende query's is scans, wat betekent dat de query de indexen niet kan toepassen. Dit probleem kan worden opgelost met een betere filtervoorwaarde.

Aanvragen van besturingsvlak bewaken

Azure Cosmos DB past limieten toe voor het aantal metagegevensaanvragen dat kan worden gedaan via opeenvolgende intervallen van vijf minuten. Aanvragen van besturingsvlak die deze limieten overschrijden, kunnen beperkingen ondervinden. Metagegevensaanvragen kunnen in sommige gevallen doorvoer verbruiken voor een master partition account dat alle metagegevens van een account bevat. Aanvragen van het besturingsvlak die de doorvoerhoeveelheid overschrijden, ondervinden snelheidslimieten (429s).

Als u aan de slag wilt gaan, gaat u naar Azure Portal en gaat u naar het deelvenster Inzichten . Open vanuit dit deelvenster het tabblad Systeem . Op het tabblad Systeem worden twee grafieken weergegeven. Een met alle metagegevensaanvragen voor een account. De tweede toont het verbruik van doorvoeraanvragen voor metagegevens van het account master partition waarin de metagegevens van een account worden opgeslagen.

Schermopname van het deelvenster Inzichten, waarin de grafiek met metagegevensaanvragen op het tabblad Systeem wordt gemarkeerd.

Schermopname van het deelvenster Inzichten, waarin de grafiek met metagegevensaanvragen 429 op het tabblad Systeem wordt gemarkeerd.

In de grafiek metagegevensaanvraag op statuscode hierboven worden aanvragen geaggregeerd bij het vergroten van de granulariteit wanneer u het tijdsbereik verhoogt. Het grootste tijdsbereik dat u voor een tijdsbak van 5 minuten kunt gebruiken, is 4 uur. Als u aanvragen voor metagegevens gedurende een groter tijdsbereik met specifieke granulariteit wilt bewaken, gebruikt u Metrische gegevens van Azure. Maak een nieuwe grafiek en selecteer metrische gegevens voor metagegevensaanvragen. Selecteer in de rechterbovenhoek vijf minuten voor tijdgranulariteit, zoals hieronder wordt weergegeven. Metrische gegevens bieden gebruikers ook de mogelijkheid om waarschuwingen voor hen te maken, waardoor ze nuttiger zijn dan Inzichten.

Schermopname van het deelvenster Metrische gegevens, waarin de metagegevensaanvragen voor een account en tijdgranulariteit van 5 minuten worden gemarkeerd.

Volgende stappen

Mogelijk wilt u meer informatie over het verbeteren van de databaseprestaties door de volgende artikelen te lezen: