azure-sdk-for-net
azure-sdk-for-net copied to clipboard
Azure
Get Cosmos Consumption RU value
Library name and version
Microsoft.Azure.Cosmos 3.29.0
Query/Question
I am trying to get the current RU consumption value on Cosmos but I don't see any API to get this value. I have gone through this API but it doesn't provide the current RU consumption value, it gives the current RU value configured on the container.
Container.ReadThroughputAsync https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.cosmos.container.readthroughputasync?view=azure-dotnet
Is there any way I can get the live RU consumption value when hit to a container through an API?
Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Cosmos:0.5278417,Container Registry:0.09283096,Container Instances:0.06364891'
Thank you for your feedback. This has been routed to the support team for assistance.
@kranthikumar-kvs-by We are looking into it and get back to you for any additional information.
@kranthikumar-kvs-by You can try checking the RequestCharge property as mentioned in Request unit charge for operations in Azure Cosmos DB SQL API document to get cost of all database operations.
Thanks, @SaurabhSharma-MSFT,
I am not looking for the RU's of a given request, I am aware of that, it is already present. As stated earlier I am looking to know the RU's consumption at the DB when I make a call with an API.
For an example if the throughput configured on the Cosmos with Autoscaling option enabled is set with 5000 then the total RU's consumed would range between 500 to 5000 based on load on the Cosmos. Just for this scenario assume that due to high load it is consuming 70% of all the RU's configured.
In this scenario when there are too many request hit on Cosmos, at this point of time if I want to know what is the overall consumption of RU's on Cosmos I should expect it gives me 70% or 3500 RU's consumed, I don't have any API to know this response.
My request is that I want to know the total current consumption of RU's at any point of time by using any API.
@kranthikumar-kvs-by sorry for the delay. I believe the you can use the Azure Monitor REST API to query the “TotalRequestUnits” metric. Please refer to Database - List Metrics. Please let me know.
Hi, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!
@SaurabhSharma-MSFT, I have gone through the List Metric documentation you shared and formed this request -
https://management.azure.com/subscriptions/29dcf6d6-4c5c-4cd6-8198-c70cc7e368fb/resourceGroups/p-catman-pd-psr03-us-staging/providers/Microsoft.DocumentDB/databaseAccounts/o5319onx3642yef8lj6ughak/databases/sa-document-db/metrics?api-version=2021-04-01-preview&$filter=$filter=(name.value eq 'Total Requests')
But everytime I get BadRequest, please can you suggest what's wrong in this URL -
Error - { "code": "BadRequest", "message": "Failed to parse query $filter=(value eq 'total requests')\r\nActivityId: f248684e-35e0-4be1-b006-99ddd3f9c82b, Microsoft.Azure.Documents.Common/2.14.0" }
Also please suggest how to get the "Normalized RU Consumption" value from this API call.
@kranthikumar-kvs-by Can you please use name.value i.e. $filter=(name.value eq 'Total Requests') and let me know if you still still have any problems.
@SaurabhSharma-MSFT, I have used the same filter earlier as well and see the same error again.
https://management.azure.com/subscriptions/29dcf6d6-4c5c-4cd6-8198-c70cc7e368fb/resourceGroups/p-catman-pd-psr03-us-staging/providers/Microsoft.DocumentDB/databaseAccounts/o5319onx3642yef8lj6ughak/databases/sa-document-db/metrics?api-version=2021-04-01-preview&$filter=$filter=(name.value eq 'Total Requests')
Please suggest how to get the "Normalized RU Consumption" value from this API call.
@kranthikumar-kvs-by I could see the same happening for me as well. I am checking internally and get back to you.
@kranthikumar-kvs-by We have identified that when you pass -
(name.value eq 'Total Requests') and timeGrain eq duration'PT5M' and startTime eq '2022-09-20T00:00:00Z' and endTime eq '2022-09-21T00:00:00Z'
into the $filter field, the command runs successfully. However, if I only specify the name.value part and omit timeGrain, it fails with bad syntax.
I have escalated this internally to cosmosdb monitoring team to look into, however, you can continue using the REST endpoint with timeGrain to get the required results.
Please let me know if you see any issues. Thanks.
Hi @kranthikumar-kvs-by. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.
This discuss was started to get the "Normalized RU Consumption" value from this API call. Which still I don't have. The one we discussed above was exploring the metric API.
Please suggest how to the get the "Normalized RU Consumption" using metric API.
@kranthikumar-kvs-by
You can retrieve Normalized RU Consumption from the Metrics API as follows:
Go to Metrics - List - REST API (Azure Monitor) and click on Try It. Fill in value for resource id of your Cosmos DB account and add header metricnames and set its value to "NormalizedRUConsumption". You may add other optional headers such as timespan, interval etc.
Example:
Hope this helps. Thanks.
Hi @kranthikumar-kvs-by. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.
Hi @kranthikumar-kvs-by, since you haven’t asked that we “/unresolve” the issue, we’ll close this out. If you believe further discussion is needed, please add a comment “/unresolve” to reopen the issue.