【问题标题】:DataPlaneRequests partitionID in CosmosDB diagnostic logs always seems to be emptyCosmosDB 诊断日志中的 DataPlaneRequests partitionID 似乎总是为空
【发布时间】:2020-01-28 05:15:08
【问题描述】:

我已启用 Cosmos 帐户(SQL 接口)的诊断日志记录。诊断日志数据正在发送到存储帐户 - 我可以看到每 5 分钟创建一个新的 DataPlaneRequests blob。 到目前为止,一切顺利。

我正在对 Cosmos 帐户中的集合执行 CRUD 请求。我可以在 DataPlaneRequest 日志中看到如下所示的条目(“*”用于保护无辜者)...

{ "time": "2020-01-28T03:04:59.2606375Z", "resourceId": "/SUBSCRIPTIONS/****/RESOURCEGROUPS/****/PROVIDERS/MICROSOFT.DOCUMENTDB/DATABASEACCOUNTS/* *********", "category": "DataPlaneRequests", "operationName": "Query", "properties": {"activityId": "38f497ee-7e37-435f-8b4a-a2f0d8d65d12","re​​questResourceType ": "DocumentFeed","re​​questResourceId": "/dbs/****/colls/****/docs","collectionRid": "","databaseRid": "","statusCode": "200" ,"持续时间": "4.588500","userAgent": "Windows/10.0.14393 documentdb-netcore-sdk/2.8.1","clientIpAddress": "52...***","re​​questCharge": "4.160000","re​​questLength": "278","re​​sponseLength": "5727","re​​sourceTokenUserRid": "","re​​gion": "美国西部 2"," partitionId": ""}}

DataPlaneRequests 日志中的每个条目都有一个空的 partitionId 属性值。 (日志中的 operationName 属性值为“Create”或“Query”)。

所以我的问题是 - 为什么这个属性是空的?

Here is the documentation for DataPlaneRequests


我实际上想要完成的是获取有关放置在集合的物理分区上的负载的信息。 例如我想知道在过去的 10 分钟内,物理分区“1”中执行了 10k 次创建操作,而物理分区“3”中执行了 55k 次操作。 这将使我能够更深入地了解为什么集合会遇到节流等问题。

【问题讨论】:

  • 为什么要知道数据是从哪个物理分区写入或查询的?您是否查看过门户中 Cosmos 刀片中的指标选项卡?顶部有一个吞吐量选项卡,可以为您提供有关热分区的详细信息。
  • ...因为当发生限制时,我想知道谁负责每个物理分区上的负载。因为我想知道应该责备谁(从 PartitionKey-value 和 UserAgent 的角度),以及哪些 PartitionKey-values(租户)可能会受到限制的影响。
  • 一个假设的例子:微服务“A”正在发出大量请求,所有请求都映射到同一个物理分区“1”——因此分区“1”中的节流可以归咎于“A” .微服务“B”正在发出请求,映射到所有物理分区 - 因此分区“1”中的限制(由“A”引起的将影响“B”执行的请求的子集)。因此,我希望能够将“1”中的限制归咎于“A”,并且我希望能够告知“B”其请求的哪个子集可能性能下降。
  • 我认为解决这个问题的方法是找出哪些操作占用的 RU/s 最多。看看这篇文章在这里。我认为前两个查询将为您提供您正在寻找的数据。 docs.microsoft.com/en-us/azure/cosmos-db/…希望这会有所帮助。
  • 感谢@MarkBrown 的输入 - 我已向 Microsoft 提出支持请求。我会发布任何解决方案。

标签: azure-cosmosdb azure-log-analytics


【解决方案1】:

当您连接到 Cosmos 时,有两种连接模式可用:网关和直连。事实证明,只有 Direct 模式会导致 partitionId 包含在日志中。 (如果您了解这两种模式的工作方式(不同),那么这很有意义)。

无论如何,日志中的 partitionId 并不是对集合的物理分区的引用。所以我无法使用该数据来解决问题,我正在尝试解决。

日志中有一个可用的物理分区 ID - 但它的用途也有限 - 因为它仅跟踪每个物理分区的 3 个最大(逻辑)PartitionKey 值,只有当键值包含 >=1Gb 的文档。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-02-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-06-22
    • 2017-07-24
    • 1970-01-01
    相关资源
    最近更新 更多