使用 Azure Cosmos DB 的深入解析監視和偵錯

適用於:NoSQL MongoDB Cassandra Gremlin Table

Azure Cosmos DB 為輸送量、儲存體、一致性、可用性和延遲提供深入解析。 Azure 入口網站會提供這些計量的彙總檢視。 您也可以從 Azure 監視器 API 檢視 Azure Cosmos DB 計量。 容器名稱等計量的維度值會區分大小寫。 因此,對這些維度值執行字串比較時,您必須使用不區分大小寫的比較。 若要了解如何從 Azure 監視器檢視計量,請參閱監視 Azure Cosmos DB

本文將逐步解說常見的使用案例,以及如何使用 Azure Cosmos DB 深入解析來分析和偵錯這些問題。 根據預設,系統會每隔 5 分鐘收集一次計量深入解析,並保留 7 天。

從 Azure 入口網站檢視深入解析

  1. 登入 Azure 入口網站並瀏覽至 Azure Cosmos DB 帳戶。

  2. 您可以從 [計量] 窗格或 [深入解析] 窗格檢視您的帳戶計量。

    • 計量:此窗格提供定期收集的數值計量,這些計量會描述系統在特定時間的某些層面。 例如,您可以檢視和監視伺服器端延遲計量標準化的要求單位使用量計量等等。

    • 深入解析:此窗格會提供 Azure Cosmos DB 的自訂監視體驗。 深入解析使用的計量和記錄與 Azure 監視器所收集的一樣,並且會顯示帳戶的彙總檢視。

  3. 開啟 [深入解析] 窗格。 依預設,[深入解析] 窗格會顯示您的帳戶中每個容器的輸送量、要求、儲存體、可用性、延遲、系統和管理作業計量。 您可以選取想要檢視其深入解析的 [時間範圍]、[資料庫] 和 [容器]。 [概觀] 索引標籤會顯示所選資料庫和容器的 RU/秒使用量、資料使用量、索引使用量、已節流的要求,以及標準化的 RU/秒使用量。

    Screenshot of Azure Cosmos DB performance metrics in the Azure portal.

  4. 您可以從 [深入解析] 窗格取得下列計量:

    • 輸送量。 此索引標籤會顯示所使用的要求單位總數,或因為容器所佈建的輸送量或儲存體容量已超過而失敗的要求單位總數 (429 回應碼)。

    • 要求。 此索引標籤會依狀態碼、依作業類型顯示已處理的要求總數,以及失敗要求計數 (429 回應碼)。 為容器佈建的輸送量或儲存體容量超過時,要求就會失敗。

    • 儲存空間。 此索引標籤會顯示所選時間週期內的資料和索引使用量大小。

    • 可用性。 此索引標籤會顯示每小時內的成功要求數目佔要求總數的百分比。 Azure Cosmos DB SLA 會定義成功率。

    • 延遲。 此索引標籤會顯示您帳戶運作所在區域內的 Azure Cosmos DB 所觀察到的讀取和寫入延遲。 您可以針對異地複寫的帳戶,將不同區域的延遲視覺化。 您也可以檢視不同作業的伺服器端延遲。 此計量不代表完整的要求延遲。

    • 系統。 此索引標籤會顯示主要分割區所處理的中繼資料要求數目。 其也有助於識別已節流的要求。

    • 管理作業。 此索引標籤會顯示帳戶管理活動的計量,例如帳戶建立、刪除、金鑰更新、網路和複寫設定。

下列各節會說明可以使用 Azure Cosmos DB 計量的常見案例。

了解有多少要求成功或導致錯誤

首先,請前往 Azure 入口網站,並瀏覽至 [深入解析] 窗格。 在此窗格中,開啟 [要求] 索引標籤。[要求] 索引標籤會顯示一個圖表,其中有依狀態碼和作業類型來劃分的要求總數。 如需 HTTP 狀態碼的詳細資訊,請參閱 Azure Cosmos DB 的 HTTP 狀態碼 \(英文\)。

最常見的錯誤狀態碼是 429 (速率限制/節流)。 此錯誤表示對 Azure Cosmos DB 的要求數目多於佈建的輸送量。 此問題最常見的解決方案是為指定的集合擴大 RU。 如需詳細資訊,請參閱簡介 Azure Cosmos DB 中已佈建的輸送量

Screenshot showing total requests by status code, throttled requests, and total requests by operation type.

判斷分割區索引鍵範圍的輸送量使用量

良好的磁碟分割索引鍵基數對於任何種類的可調整應用程式都很重要。 若要判斷任何已分割容器的輸送量分佈且能細分至分割區索引鍵範圍識別碼,請瀏覽至 [深入解析] 窗格。 開啟 [輸送量] 索引標籤。圖表中會顯示不同分割區索引鍵範圍的標準化 RU/秒使用量。

Screenshot of the Throughput tab, showing the RU/s consumption.

透過此圖表的協助,您可以識別其中是否有熱分割區。 輸送量分佈不平均可能會造成分割區過度使用,這可能會導致節流要求,而且可能需要重新分割磁碟。 找出導致資料分佈扭曲的分割區索引鍵之後,便可能必須用更分散的分割區索引鍵來重新分割容器。 如需關於在 Azure Cosmos DB 中進行資料分割的詳細資訊,請參閱在 Azure Cosmos DB 中進行資料分割和水平調整

判斷資料和索引的使用量

請務必依資料使用量、索引使用量和文件使用量來判斷任何已分割容器的儲存體分佈。 您可以將索引使用量降至最低、將資料使用量最大化,並將查詢最佳化。 若要取得此資料,請瀏覽至 [深入解析] 窗格,然後開啟 [儲存體] 索引標籤。

Screenshot of the Insights pane, highlighting the Storage tab.

比較資料大小與索引大小

在 Azure Cosmos DB 中,已使用的總儲存體空間為資料大小和索引大小的加總。 一般來說,索引大小只佔資料大小的一小部分。 若要深入了解,請參閱索引大小一文。 在 Azure 入口網站的 [計量] 窗格中,[儲存體] 索引標籤會顯示資料和索引使用之儲存體空間的明細。

// 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);

如果要節省索引空間,可以調整編製索引原則

對緩慢的查詢進行偵錯

在 API for NoSQL SDK 中,Azure Cosmos DB 會提供查詢執行的統計資料。

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 提供查詢中每個元件的執行時間長度詳細資料。 長時間執行查詢的最常見根本原因是掃描,這表示查詢無法套用索引。 使用較好的篩選條件,就可以解決這個問題。

監視控制平面要求

Azure Cosmos DB 會針對可在連續 5 分鐘的間隔內進行的中繼資料要求數目套用限制。 超過這些限制的控制平面要求,可能會受到節流。 在某些情況下,中繼資料要求可能會對包含帳戶所有中繼資料之帳戶內的 master partition 消耗輸送量。 超過輸送量的控制平面要求將遇到速率限制 (429)。

首先,請前往 Azure 入口網站,並瀏覽至 [深入解析] 窗格。 在此窗格中,開啟 [系統] 索引標籤。[系統] 索引標籤會顯示兩個圖表。 其中一個顯示帳戶的所有中繼資料要求。 另一個則顯示帳戶中儲存帳戶中繼資料的 master partition 所消耗的中繼資料要求輸送量。

Screenshot of the Insights pane, highlighting the metadata requests graph on the System tab.

Screenshot of the Insights pane, highlighting the metadata requests 429 graph on the System tab.

當您增加時間範圍時,上方「依狀態碼排序的中繼資料要求」圖表會以更大的細微性來彙總要求。 5 分鐘的時間間隔可使用的最大時間範圍是 4 小時。 若要使用特定細微性監視更大時間範圍內的中繼資料要求,請使用 Azure 計量。 建立新的圖表,然後選取中繼資料要求計量。 在右上角選取 [5 分鐘] 的 [時間細微性],如下所示。 計量也可讓使用者對其建立警示,使其比深入解析更有用。

Screenshot of Metrics pane, highlighting the metadata requests for an account and time granularity of 5 minutes.

下一步

若要深入了解如何提升資料庫效能,請閱讀下列文章: