-
Notifications
You must be signed in to change notification settings - Fork 369
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
Add stats api. #308
Add stats api. #308
Conversation
Thanks for building this out and contributing it! I'm checking it out locally now and I'm sure this will be useful to a lot of plugin users. @nomoa would you review this PR when you have a chance? |
Also @ebernhardson if you want to take a look, I'm interested if this would work to resolve the issue you raised about cache churn in #140 |
Hey @adnapibar could you do a quick brain dump to about how you designed the stats api to work and add a new section for its usage to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks!
I haven't fully reviewed the patch yet but I wanted to send a first round of comments.
The main concern I have is the blocking call in StoreUtils on the Client to get the counts of the various elements stored. I think this is problematic to have a blocking call there and we should flip the logic to use the async APIs like everything else. But overall what StoreUtils is extracting should probably be clarified a bit more.
One thing that would be very nice is implementing some tests in src/test/resources/rest-api-spec/
.
Thanks!
Thanks @nomoa for your review. I couldn't get to resolve the comments earlier, sorry about that. I have resolved most of your earlier comments. I agree the StoreUtils was not abstracting much, so I have removed that and moved the code to the suppliers. The code to get the counts is now replaced with an aggregate query (not sure if that resolves the blocking concern that you have, any pointers on that would be great!). Also, added some tests in the rest-api-specs. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adnapibar thanks and sorry for the late response!
I left some minor comments (mostly cleanups) but overall this looks great.
This is a big PR so another pair of eyes might be welcome to make sure that I did not miss anything important.
src/main/java/com/o19s/es/ltr/action/TransportLTRStatsAction.java
Outdated
Show resolved
Hide resolved
src/main/java/com/o19s/es/ltr/stats/suppliers/StoreStatsSupplier.java
Outdated
Show resolved
Hide resolved
src/main/java/com/o19s/es/ltr/stats/suppliers/StoreStatsSupplier.java
Outdated
Show resolved
Hide resolved
src/main/java/com/o19s/es/ltr/stats/suppliers/StoreStatsSupplier.java
Outdated
Show resolved
Hide resolved
Forgot to mention the blocking calls: Just for reference the way to fix this is to switch to async calls using the |
Thanks again @adnapibar for all of the new functionality and @nomoa for all of the review. I just requested a second set of @worleydl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @adnapibar! Aside from various stylistic questions, I think the two most important fixes we would want to see
- The bug @nomoa pointed out on the feature store aggregation (and an accompanying test ideally)
- We should rename
stats
=>_stats
because I just know someone will want to create a feature store namedstats
and we use_
for reserved names
See other various stylistic changes of various degrees of importance...
} | ||
} | ||
|
||
public static class LTRStatsNodesRequest extends BaseNodesRequest<LTRStatsNodesRequest> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit - Not sure there's any way we could better differentiate this is a Nodes and the other request/response are singular Node
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept it as per existing conventions in the repo. One alternative convention might be to use LTRStatsNodeRequest
for single node and LTRStatsRequest
for nodes. (example)
src/main/java/com/o19s/es/ltr/stats/suppliers/StoreStatsSupplier.java
Outdated
Show resolved
Hide resolved
src/main/java/com/o19s/es/ltr/stats/suppliers/PluginHealthStatusSupplier.java
Outdated
Show resolved
Hide resolved
Thanks @nomoa and @softwaredoug for taking time to review my PR. I have addressed your comments and made the requested changes. Please let me know if there is anything else that I have missed or should add. |
@softwaredoug and @nomoa green-light for merge? |
@nathancday LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 from me, thanks for all the hard work
The api provides basic information on the plugin usage and performance, including, - overall status of the plugin health. - statistics on the feature stores. - statistics on the internal caches used by the plugin.
- Refactor to remove the LTRStats dependency from RestLTRStats - Remove client and clusterService instance variables from LtrQueryParserPlugin. - Minor Refactoring
- move the operations inside the stat suppliers.
@nathancday Can we merge it now? |
Merging now. Should see a release next week. |
Issue #302
The
/_ltr/stats
api provides basic information on the plugin usage and performance, including,