-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
ES: Configurable query result sizes #2437
Comments
The flag
seems very similar to the proposed Can I ask what what value do you want to use to keep the impact of the query on the cluster low? |
We're limiting ES aggregation queries to 1000 at the moment, but for Jaeger queries, we're considering increasing this to 4000.
Yup, I agree. Although Perhaps we can introduce the more general It may then make sense to deprecate Does that sound reasonable? Open to other thoughts and suggestions! |
Even if use the We can introduce a new flag an deprecate the old one after a couple of releases. |
Thanks for the feedback @pavolloffay. If there are no more objections, I'll go ahead with the following as discussed:
|
Requirement - what kind of business use case are you trying to solve?
We limit the number of results returned from Elasticsearch (ES) from user queries to prevent large queries from negatively impacting the ES cluster. With ES as our Jaeger backing store, we also need to ensure jaeger-query -> ES requests abide by these limits, ideally as a configurable parameter.
Problem - what in Jaeger blocks you from solving the requirement?
Currently,
defaultDocCount
is applied to the ES query'ssize
attribute and I was not able to find a means of overriding this value. Examples:https://github.com/jaegertracing/jaeger/search?q=defaultDocCount&unscoped_q=defaultDocCount
In some cases, this value is hard-coded directly instead of using the const:
jaeger/plugin/storage/es/dependencystore/storage.go
Line 87 in 3f6f3a7
Resulting in the need for less desirable workarounds to ensure requests from jaeger-query to ES set the appropriate result size limit.
Proposal - what do you suggest to solve the problem or improve the existing situation?
Introduce a new integer flag, perhaps
es.doc-count
(ES_DOC_COUNT
env var) for consistency, that represents an override to the 10000defaultDocCount
const. Open to suggestions on better parameter names as well.Any open questions to address
Given 10,000 is applied across service/operation aggregations and dependency store (and also in OTEL), does it make sense to have the one configurable variable in all these places? Or should we separate, aggregation and dependency store doc counts?
The
es.max-num-spans
(used here) also defaults to a value of 10,000. Please let me know if there is any desire to consolidate this flag with the proposedes.doc-count
.The text was updated successfully, but these errors were encountered: