Övervaka och felsöka med insikter i Azure Cosmos DB
GÄLLER FÖR: NoSQL MongoDB Kassandra Gremlin Bord
Azure Cosmos DB ger insikter om dataflöde, lagring, konsekvens, tillgänglighet och svarstid. Azure-portalen innehåller en sammanställd vy över dessa mått. Du kan också Visa Azure Cosmos DB-mått från Azure Monitor-API:et. Dimensionsvärdena för måtten, till exempel containernamn, är skiftlägeskänsliga. Därför måste du använda skiftlägesokänslig jämförelse när du gör strängjämförelser på dessa dimensionsvärden. Information om hur du visar mått från Azure Monitor finns i Övervaka Azure Cosmos DB.
Den här artikeln går igenom vanliga användningsfall och hur Azure Cosmos DB-insikter kan användas för att analysera och felsöka dessa problem. Som standard samlas måttinsikterna in var femte minut och sparas i sju dagar.
I följande avsnitt beskrivs vanliga scenarier där du kan använda Azure Cosmos DB-mått.
Anteckning
När du filtrerar efter databas eller samlingar i mått är det möjligt att du kan se "__Empty" eller "<Tom>" som resourceName. Det beror på att måttdata samlas in på kontonivå för just den begäran. Därför finns det ingen associerad databas eller samling som måttvärde.
Kom igång genom att gå till Azure Portal och gå till fönstret Insikter. Öppna fliken Begäranden i det här fönstret. Fliken Begäranden visar ett diagram med det totala antalet begäranden segmenterade efter statuskod och åtgärdstyp. Mer information om HTTP-statuskoder finns i HTTP-statuskoder för Azure Cosmos DB.
Den vanligaste felstatuskoden är 429 (hastighetsbegränsning/begränsning). Det här felet innebär att begäranden till Azure Cosmos DB är mer än det etablerade dataflödet. Den vanligaste lösningen på det här problemet är att skala upp RU:erna för den angivna samlingen. Mer information finns i Introduktion till etablerat dataflöde i Azure Cosmos DB
Att ha en bra kardinalitet för dina partitionsnycklar är viktigt för alla skalbara program. Om du vill fastställa dataflödesdistributionen för en partitionerad container uppdelad efter partitionsnyckelintervall-ID:t går du till fönstret Insikter . Öppna fliken Dataflöde . Normaliserad RU/s-förbrukning för olika partitionsnyckelintervall visas i diagrammet.
Med hjälp av det här diagrammet kan du identifiera om det finns en frekvent partition. PartitionKeyRangeIDs motsvarar fysiska partitioner. Måttet Normaliserad RU-förbrukning är ett värde mellan 0 % och 100 % som hjälper till att mäta användningen av etablerat dataflöde i en databas eller container. En ojämn dataflödesdistribution kan orsaka frekventa partitioner, vilket kan leda till begränsade begäranden och kan kräva ompartitionering. När du har identifierat vilken partitionsnyckel som orsakar skevhet i distributionen kan du behöva partitionera om containern med en mer distribuerad partitionsnyckel. Mer information om partitionering i Azure Cosmos DB finns i Partitionering och horisontell skalning i Azure Cosmos DB.
Det är viktigt att fastställa lagringsdistributionen för alla partitionerade containrar efter dataanvändning, indexanvändning och dokumentanvändning. Du kan minimera indexanvändningen, maximera dataanvändningen och optimera dina frågor. Om du vill hämta dessa data går du till fönstret Insikter och öppnar fliken Lagring.
I Azure Cosmos DB är den totala förbrukade lagringen kombinationen av både datastorleken och indexstorleken. Indexstorleken är vanligtvis en bråkdel av datastorleken. Mer information finns i artikeln Indexstorlek . I fönstret Mått i Azure Portal visar fliken Lagring uppdelningen av lagringsförbrukningen baserat på data och index.
// 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);
Om du vill spara indexutrymme kan du justera indexeringsprincipen.
I API:et för NoSQL SDK:er tillhandahåller Azure Cosmos DB frågekörningsstatistik.
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 innehåller information om hur lång tid varje komponent i frågan tog att köra. Den vanligaste rotorsaken till långvariga frågor är genomsökningar, vilket innebär att frågan inte kunde tillämpa indexen. Det här problemet kan lösas med ett bättre filtervillkor.
Azure Cosmos DB tillämpar gränser för antalet metadatabegäranden som kan göras under på varandra följande 5 minuters intervall. Kontrollplansbegäranden som överskrider dessa gränser kan uppleva begränsning. Metadatabegäranden kan i vissa fall förbruka dataflöde mot ett master partition
konto som innehåller alla metadata för ett konto. Kontrollplansbegäranden som går över dataflödesbeloppet kommer att uppleva hastighetsbegränsning (429-talet).
Kom igång genom att gå till Azure Portal och gå till fönstret Insikter. Öppna fliken System i det här fönstret. Fliken System visar två diagram. En som visar alla metadatabegäranden för ett konto. Den andra visar dataflödesförbrukning för metadatabegäranden från kontot som master partition
lagrar ett kontos metadata.
Diagrammet Metadatabegäran efter statuskod ovan aggregerar begäranden vid ökad kornighet när du ökar tidsintervallet. Det största tidsintervallet som du kan använda för en tidsintervall på 5 minuter är 4 timmar. Om du vill övervaka metadatabegäranden över ett större tidsintervall med specifik kornighet använder du Azure Metrics. Skapa ett nytt diagram och välj Mått för metadatabegäranden. I det övre högra hörnet väljer du 5 minuter för Tidskornighet enligt nedan. Mått gör det också möjligt för användare att skapa aviseringar på dem, vilket gör dem mer användbara än Insights.
Du kanske vill lära dig mer om att förbättra databasprestanda genom att läsa följande artiklar: