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

Add stats api. #308

Merged
merged 9 commits into from
Aug 28, 2020
Merged

Add stats api. #308

merged 9 commits into from
Aug 28, 2020

Conversation

adnapibar
Copy link
Contributor

@adnapibar adnapibar commented May 29, 2020

Issue #302

The /_ltr/stats 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.

@nathancday
Copy link
Member

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?

@nathancday nathancday requested a review from nomoa May 29, 2020 14:02
@nathancday
Copy link
Member

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

@nathancday
Copy link
Member

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 docs/advanced-functionality.rst?

Copy link
Collaborator

@nomoa nomoa left a 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!

src/main/java/com/o19s/es/ltr/LtrQueryParserPlugin.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/LtrQueryParserPlugin.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/LtrQueryParserPlugin.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/LtrQueryParserPlugin.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/action/LTRStatsAction.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/utils/StoreUtils.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/stats/LTRStats.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/rest/RestLTRStats.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/rest/RestLTRStats.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/utils/StoreUtils.java Outdated Show resolved Hide resolved
@adnapibar
Copy link
Contributor Author

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!

@adnapibar adnapibar requested a review from nomoa August 4, 2020 18:08
Copy link
Collaborator

@nomoa nomoa left a 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.

@nomoa
Copy link
Collaborator

nomoa commented Aug 6, 2020

Forgot to mention the blocking calls:
I think it's OK to leave them, it is generally not great to call get() on client requests, reason is that you hold 2 threads from the threadpool for the operation: one waiting and another one doing the job.

Just for reference the way to fix this is to switch to async calls using the execute method with an ActionListener but this seems hard in the current state of the PR since it relies on Supplier::get() to gather its metrics.

@nathancday
Copy link
Member

Thanks again @adnapibar for all of the new functionality and @nomoa for all of the review. I just requested a second set of @worleydl

Copy link
Collaborator

@softwaredoug softwaredoug left a 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

  1. The bug @nomoa pointed out on the feature store aggregation (and an accompanying test ideally)
  2. We should rename stats => _stats because I just know someone will want to create a feature store named stats and we use _ for reserved names

See other various stylistic changes of various degrees of importance...

}
}

public static class LTRStatsNodesRequest extends BaseNodesRequest<LTRStatsNodesRequest> {
Copy link
Collaborator

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

Copy link
Contributor Author

@adnapibar adnapibar Aug 11, 2020

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/LTRStat.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/stats/LTRStat.java Outdated Show resolved Hide resolved
src/main/java/com/o19s/es/ltr/stats/StatName.java Outdated Show resolved Hide resolved
@adnapibar
Copy link
Contributor Author

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.

@nathancday
Copy link
Member

@softwaredoug and @nomoa green-light for merge?

@nomoa
Copy link
Collaborator

nomoa commented Aug 24, 2020

@nathancday LGTM

Copy link
Collaborator

@softwaredoug softwaredoug left a 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

Rabi Panda and others added 8 commits August 27, 2020 16:01
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.
@adnapibar
Copy link
Contributor Author

@nathancday Can we merge it now?

@worleydl
Copy link
Collaborator

Merging now. Should see a release next week.

@worleydl worleydl merged commit 0455051 into o19s:master Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants