-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Query Clause Level Stats in OpenSearch #5983
Comments
At a high level this seems like a good idea to me, provided it's very generic. |
@dblock Can we core team prioritize this in their roadmap? |
@navneet1v I doubt it AFAIK they are focused on storage and extensibility, but feel free to contribute! |
@dblock @navneet1v I'd like to keep the Core focus on storage and extensibility unless we have volumes of community members asking for this, or as @dblock feel free to contribute! |
@vamshin can you clarify that you are thinking this would not send metrics to anywhere for customers of open source opensearch, but would allow customers (managed service providers, customers, etc.) to send their own cluster data to their self-designated endpoint? |
This can probably be covered with an addition to #10724 One thing to note is that we're trying to move away from stats APIs for everything (at least some of us are pushing in that direction). Instead, we're trying to embrace more of a tracing/telemetry-based approach, which should give us much better numbers, rather than silly point-in-time "how is the cluster right now?" data. |
#10724 My use case is cc: @msfroh |
The best bet would probably be to emit the metrics based on the Can we make the counters dynamic instead? Like instead of having a bunch of counter fields, we could have a |
@msfroh Yes that would make sense and will cover all the query types. Let me look into adding something like this in 2.13. Will add a task for it. Thanks @vibrantvarun |
@deshsidd is this still planned for 2.13? |
Hi, cc: @msfroh |
This is not prioritized for 2.13 but is in the roadmap. As mentioned earlier we would have to make the counters dynamic where we allocate the counters based on the query types we see. |
This will make the feature half baked. :( |
@navneet1v If you or @vibrantvarun have the bandwidth it should not be a large change and you can contribute! :) Unfortunately, we are focused on items related to our performance roadmap for now : https://github.com/orgs/opensearch-project/projects/153 |
@navneet1v I have already tried to extend it in plugins but the infrastructure is created like that it does not have feature to extend in plugin. Therefore, there is a need to do work at infrastructure level. cc: @navneet1v @deshsidd |
In theory, you shouldn't need to extend anything in a plugin. The change in #12601 just emits counters based on the query type. |
@navneet1v @vibrantvarun As mentioned in the PR, the system now supports dynamic query types, eliminating the need to track specific query types exclusively. Instead, counters for all query types encountered including custom query types introduced by plugins will be created and incremented as needed. This ensures that accounting for any custom query types issued by plugins is also handled seamlessly. |
Is your feature request related to a problem? Please describe.
With the release of Neural Search plugin we release added a new query clause called as "neural". The query clause takes up a query text and model_id and re-writes the query to a k-NN based query. We want to add the stats for this new query clause in OpenSearch which will provide information like: how many times this query clause was invoked, latency, errors etc.
This is a problem for all the query clauses and not the neural query clause. Hence the solution should be OpenSearch specific and not plugin specific.
Describe the solution you'd like
Given that currently we don't have any mechanism to track the metrics described above for all the different query clauses, solution is to implement a stats api that can provide this information.
Describe alternatives you've considered
The only alternative that I can think of is plugins create a new profile/stats api that can provide stats for the query clauses. But this will make every plugin to reinvent the wheel and won't be consistent across different query clauses.
The Stats api present in OpenSearch provide results for the search api combined but it doesn't give metrics around specific query clauses.
Additional context
The text was updated successfully, but these errors were encountered: