使用 Azure Cosmos DB 中的见解进行监视和调试

适用对象: NoSQL MongoDB Cassandra Gremlin

Azure Cosmos DB 提供吞吐量、存储、一致性、可用性和延迟方面的见解。 Azure 门户提供这些指标的聚合视图。 也可通过 Azure Monitor API 查看 Azure Cosmos DB 指标。 指标的维度值(例如容器名称)不区分大小写。 因此,在对这些维度值进行字符串比较时,需要使用不区分大小写的比较。 若要了解如何从 Azure Monitor 查看指标,请参阅监视 Azure Cosmos DB

本文介绍常见用例,以及如何使用 Azure Cosmos DB 见解来分析和调试这些问题。 默认情况下,指标见解每五分钟收集一次,并保留 7 天。

从 Azure 门户查看见解

  1. 登录到 Azure 门户,导航到 Azure Cosmos DB 帐户。

  2. 可以从“指标”窗格或“见解”窗格查看帐户指标 。

    • 指标:此窗格提供定期收集的数字指标,用于描述系统在某一特定时间的某些情况。 例如,可以查看和监视服务器端延迟指标、标准化请求单位使用指标等。

    • 见解:此窗格提供 Azure Cosmos DB 的自定义监视体验。 见解使用 Azure Monitor 中收集的指标和日志,并显示帐户的聚合视图。

  3. 打开“见解”窗格。 默认情况下,“见解”窗格会显示帐户中每个容器的吞吐量、请求、存储、可用性、延迟、系统和管理操作指标。 可以选择要查看其见解的时间范围、数据库和容器 。 “概述”选项卡显示所选数据库和容器的 RU/s 使用情况、数据使用情况、索引使用情况、限制请求和标准化 RU/s 使用。

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

  4. “见解”窗格提供以下指标:

    • 吞吐量。 此选项卡显示已使用或已失败(因为已超出为容器预配的吞吐量或存储容量,响应代码为 429)的请求单元总数。

    • Requests。 此选项卡显示按状态代码、操作类型和失败请求数(响应代码 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.

按分区键范围确定吞吐量使用量

对任何可伸缩应用程序而言,均必须具有良好的分区键基数。 若要确定任何按分区键范围 ID 细分的分区容器的吞吐量分布,请导航到“见解”窗格。 打开“吞吐量”选项卡。图表中将显示不同分区键范围内的标准化 RU/s 消耗量。

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 分钟”作为“时间粒度”,如下所示。 指标还允许用户创建警报,这使得它们比 Insights 更有用。

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

后续步骤

可以阅读以下文章,进一步介绍了如何提高数据库性能: