根据Interpret your logs中的属性表，不存在使用罗斯记录确切查询的属性。
事实上，Cosmos DB上的任何操作都将消耗罗斯和诊断日志，通过OperationName属性区分操作类型。
你可以在上面的链接得到以下线索：
1.TimeGenerated，操作发生的日期和时间（UTC
2.OperationName，该值可以是以下任意操作：创建、更新、读取、ReadFeed、删除、替换、执行、SqlQuery、查询、JSQuery、标题、标题提要或向上插入。
3.activityId_g，记录的操作的唯一GUID。
4.ResourceId，根据执行的操作，该值可以指向databaseRid、collectionRid或documentRid。
5.requestCharge_s，由操作使用的罗斯的数目。
我想基本上可以定位到客户端发送查询的位置，如果确实想知 prop 体的查询sql，可以在客户端添加打印SQL的日志，辅以运行时间来定位。

为了找到消耗量最大的Cosmos查询，我找到了this article。从那时起，我对该查询做了一些改进，并提出了以下查询：

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DOCUMENTDB"
| where Category == "DataPlaneRequests"
| where collectionName_s == "Global"
| project activityId_g, requestCharge_s
| join kind = inner (
       AzureDiagnostics
       | where ResourceProvider == "MICROSOFT.DOCUMENTDB"
       | where Category == "QueryRuntimeStatistics"
       | project activityId_g, querytext_s
) on $left.activityId_g == $right.activityId_g
| summarize sumRU = sum(todouble(requestCharge_s)), 
    avgRU = avg(todouble(requestCharge_s)), 
    countQueries = count() by querytext_s
| project sumRU, avgRU, countQueries, querytext_s
| order by sumRU desc
| limit 20

轻松获取此数据的主要问题是，消耗的RU/s记录在DataPlaneRequests中，而具体的查询在QueryRuntimeStatistics中可用。令人高兴的是，两者共享相同的activityId，并且可以连接以获取两个条目之间的链接。
如果您在日志查询中运行此命令，您的结果将如下所示，这非常有助于查找有问题的查询（根据您的需要，您可能必须按平均值或计数排序）：