Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distributed Tracing: Add RequestChargeThreshold to CosmosThresholdOptions #4385

Closed
jcocchi opened this issue Apr 3, 2024 · 4 comments · Fixed by #4433
Closed

Distributed Tracing: Add RequestChargeThreshold to CosmosThresholdOptions #4385

jcocchi opened this issue Apr 3, 2024 · 4 comments · Fixed by #4433
Assignees

Comments

@jcocchi
Copy link
Contributor

jcocchi commented Apr 3, 2024

Customers should be able to add a filter for traces based on the RU charge of a request. This option already exists in Java https://learn.microsoft.com/en-us/java/api/com.azure.cosmos.cosmosdiagnosticsthresholds?view=azure-java-stable

@kirankumarkolli
Copy link
Member

Is Payload size based filtering also a requirement?

Even if its not for consistency, how about include both?

@jcocchi
Copy link
Contributor Author

jcocchi commented Apr 3, 2024

I didn't hear any asks for payload size but yes let's add both

@kovarikthomas
Copy link

Hi Kiran - I discussed it with Justine on Teams, the requirement here is mainly around monitoring for queries with high RU charges, but I suppose that anything that closes the gap w.r.t. Java SDK helps. (https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-cosmos/src/main/java/com/azure/cosmos/CosmosDiagnosticsThresholds.java)

@bartelink
Copy link
Contributor

For a moment my heart skipped a beat thinking that #1763 was being addressed (I'd still love to be able to define a size or RU budget for queries in general, and ChangeFeedl requests in particular).
Having to pick between ultra conservative 100 docs or setting a huge limit and getting lumpy RU costs when the documents are not of uniform size is very unfortunate in terms of delivering consistent throughput without random large requests causing rate limiting when that's absolutely not the intent of the system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
6 participants