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

[Monitoring] Get ready for hits total format change #26442

Merged
merged 3 commits into from
Jan 22, 2019

Conversation

chrisronline
Copy link
Contributor

@chrisronline chrisronline commented Nov 29, 2018

Relates to #26356

This PR prepares the Monitoring UI codebase for the incoming changes to hits.total.

@chrisronline chrisronline added v7.0.0 Team:Monitoring Stack Monitoring team labels Nov 29, 2018
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-monitoring

@elasticmachine
Copy link
Contributor

💔 Build Failed

@timroes
Copy link
Contributor

timroes commented Nov 30, 2018

Jenkins, test this - Change should now be on master snapshot

@elasticmachine
Copy link
Contributor

💔 Build Failed

@chrisronline
Copy link
Contributor Author

@timroes I see the PR as still open though?

@timroes
Copy link
Contributor

timroes commented Nov 30, 2018

Sorry for the confusion, the change, that allows that parameter empty (elastic/elasticsearch#36051) should now be there, and that would prevent CI from failing that it doesn't know the parameter. not the PR that actually changes the behavior. But it seems our CI has troubles picking up the ES changes.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@chrisronline
Copy link
Contributor Author

@mattapperson @justinkambic Feel free to review this if you have the time. No rush

@chrisronline
Copy link
Contributor Author

@justinkambic Thanks for the review. I've gone ahead and changed approach and only updated the few, specific api calls that need hits.total. Feel free to give it another pass!

@elasticmachine
Copy link
Contributor

💔 Build Failed

@chrisronline
Copy link
Contributor Author

retest

Copy link
Member

@pickypg pickypg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could probably be even a little more surgical.

@@ -56,6 +56,7 @@ export function getLastRecovery(req, esIndexPattern) {
const params = {
index: esIndexPattern,
size: 1,
rest_total_hits_as_int: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this one, we can change the handler code to just see if hits.hits.length === 1 (we only request size: 1), then do the work. This would remove the need for this parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, will adjust

@@ -55,6 +55,7 @@ export async function getNodes(req, esIndexPattern, clusterStats, shardStats) {
index: esIndexPattern,
size: config.get('xpack.monitoring.max_bucket_size'),
ignoreUnavailable: true,
rest_total_hits_as_int: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're using hits.total here, but we could also change to checking hits.hits.length > 0 again. In this particular case, we are using field collapsing, so hits.total is inherently incorrect anyway (an overestimate), so it was really just a matter of simplicity to check hits.total for not being 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, will adjust

@@ -43,6 +43,7 @@ export function getShardStats(req, esIndexPattern, cluster, { includeNodes = fal
index: esIndexPattern,
size: 0,
ignoreUnavailable: true,
rest_total_hits_as_int: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case we're actually interested in the hits.total being non-zero, but we cannot rely on hits.hits.length because we use size: 0.

In this case though, we can just check the indices.buckets to see if it has a length > 0, then use it that way. Alternatively, we could just drop the parameter and rely on the by-default inaccurate count coming back to still be >= 1 by changing it to hits.total.value from hits.total.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, will adjust

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@chrisronline
Copy link
Contributor Author

retest

@elasticmachine
Copy link
Contributor

💔 Build Failed

@chrisronline
Copy link
Contributor Author

retest

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@pickypg pickypg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM. I have not run this though.

Copy link
Contributor

@justinkambic justinkambic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@chrisronline chrisronline merged commit c37cf1e into elastic:master Jan 22, 2019
@chrisronline chrisronline deleted the hits_total_format branch January 22, 2019 17:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Monitoring Stack Monitoring team v7.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants