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

Expose agg usage in Feature Usage API #55732

Merged
merged 21 commits into from
Apr 30, 2020

Conversation

imotov
Copy link
Contributor

@imotov imotov commented Apr 24, 2020

Counts usage of the aggs and exposes them on the /_nodes/usage.

Closes #53746

Counts usage of the aggs and exposes them on the _nodes/usage/.

Closes elastic#53746
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

@imotov imotov marked this pull request as draft April 24, 2020 15:29
* Returns the name of the Values Source Type for stats purposes
* @return the name of the Values Source Type
*/
String value();
Copy link
Member

Choose a reason for hiding this comment

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

Maybe typeName() instead? we're already using value for a lot of things in aggregations support.

}
}

private static class MultiRegistryEntry extends RegistryEntry {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think Multi should be it's own case. Instead, we can loop in the list version of register and just create multiple SingleRegistryEntry records. That way, report usage can still track to a single ValuesSourceType, and the only "special case" is around Any, which we're planning to remove.

* @param aggregatorSupplier An Aggregation-specific specialization of AggregatorSupplier which will construct the mapped aggregator
* from the aggregation standard set of parameters.
*/
public void registerAny(String aggregationName, AggregatorSupplier aggregatorSupplier) {
register(aggregationName, (ignored) -> true, aggregatorSupplier);
register(aggregationName, new AnyRegistryEntry(aggregatorSupplier));
Copy link
Member

Choose a reason for hiding this comment

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

So, @csoulios is working on a near term plan to get rid of the literal any, and replace registerAny with just registering all the CoreValuesSourceTypes. We could adopt something like that here, and just register an explicit list of SingleRegistryEntry cases instead. Or leave this as is and change it over when the rest of Christos's ANY work merges.

Copy link
Contributor

@csoulios csoulios Apr 24, 2020

Choose a reason for hiding this comment

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

Just pushed PR #55747 that removes registerAny() method

@imotov
Copy link
Contributor Author

imotov commented Apr 24, 2020

After talking to @polyfractal I think I might need to redo this one. I feel like placement might have been wrong. We have aggregations that have 0, 1 or 2 ValuesSources, and this is not going away. So, I probably need to move this logic somewhere higher.

@imotov imotov marked this pull request as ready for review April 27, 2020 18:26
@imotov
Copy link
Contributor Author

imotov commented Apr 28, 2020

@polyfractal @not-napoleon I think it is ready for review.

Copy link
Contributor

@polyfractal polyfractal left a comment

Choose a reason for hiding this comment

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

Left some comments, mainly around the periphery and with javadocs/comments/etc. I looked over the changes to the VSRegistry and they look fine to me, but I'll defer to @not-napoleon on the final say for that.

final Request index = new Request("POST", "/test/_doc/" + i);
index.setJsonEntity("{\"str\": \"val\", \"foo\":\"bar\", \"num\": 5, \"start\": \"2020-03-15\"}");
client().performRequest(index);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we refresh after indexing? Or does it not matter for the usage stats if the fields are potentially unmapped?

If it doesn' matter, maybe we could skip indexing to save some time?

"org.elasticsearch.rest.action.document.RestGetAction": 1,
"org.elasticsearch.rest.action.search.RestSearchAction": 19, <3>
"org.elasticsearch.rest.action.admin.cluster.RestNodesInfoAction": 36
"nodes_usage_action": 1,
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this name change due to the PR, or were the docs always incorrect?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, we ignore this section. So when it was refactored in May 2017 we didn't update the docs.

@@ -483,6 +488,8 @@ private void registerAggregation(AggregationSpec spec, ValuesSourceRegistry.Buil
Consumer<ValuesSourceRegistry.Builder> register = spec.getAggregatorRegistrar();
if (register != null) {
register.accept(builder);
} else {
usageService.registerAggregationUsage(spec.getName().getPreferredName());
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add a comment here, to the effect of the registry handles usage tracking, but since not all aggs use it we need to track the other ones explicitly? I feel like I'll stumble on this in the future and be confused :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, I was 100% I had this comment there. Strange.

@@ -238,4 +240,7 @@ protected static Aggregator asMultiBucketAggregator(final AggregatorFactory fact
return new MultiBucketAggregatorWrapper(bigArrays, searchContext, parent, factory, first);
}

public String getStatsSubtype() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add a javadoc for what this is/used for?


registerAggregation(new AggregationSpec(AvgAggregationBuilder.NAME, AvgAggregationBuilder::new, AvgAggregationBuilder.PARSER)
.addResultReader(InternalAvg::new)
.setAggregatorRegistrar(AvgAggregationBuilder::registerAggregators), builder);
registerAggregation(new AggregationSpec(WeightedAvgAggregationBuilder.NAME, WeightedAvgAggregationBuilder::new,
WeightedAvgAggregationBuilder.PARSER).addResultReader(InternalWeightedAvg::new), builder);
WeightedAvgAggregationBuilder.PARSER).addResultReader(InternalWeightedAvg::new)
.setAggregatorRegistrar(WeightedAvgAggregationBuilder::registerUsage), builder);
Copy link
Contributor

Choose a reason for hiding this comment

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

Heh, this is a bit cheeky...took me a minute to figure out what was going on here :)


public void incAggregationUsage(String aggregationName, String valuesSourceType) {
Map<String, LongAdder> valuesSourceMap = aggs.get(aggregationName);
// Not all aggs register their usage at the moment we also don't register them in test context
Copy link
Contributor

Choose a reason for hiding this comment

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

Are there other aggs that aren't caught by the else in SearchModule (using registerAggregationUsage(String aggregationName) )?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, good point. Let's find out.

if (adder != null) {
adder.increment();
} else {
throw new IllegalArgumentException("Unknown subtype [" + aggregationName + "][" + valuesSourceType + "]");
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we should just log an error but not actually throw an exception? I'm thinking if we end up breaking something on the usage side, it'd be a shame if it actually broke the aggs until we got a bugfix out

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That helped me to find a lot of strange behaving aggregations. But you are right, I might just replace this with assert for now.

@@ -105,6 +105,7 @@ public AnalyticsPlugin() { }
TTestAggregationBuilder::new,
usage.track(AnalyticsStatsAction.Item.T_TEST, checkLicense(TTestAggregationBuilder.PARSER)))
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm... we should probably discuss if we still want these being tracked separately? Unrelated to this PR though, just something I hadn't thought about :)

@imotov
Copy link
Contributor Author

imotov commented Apr 30, 2020

@elasticmachine update branch

@imotov imotov merged commit b909cee into elastic:master Apr 30, 2020
imotov added a commit to imotov/elasticsearch that referenced this pull request Apr 30, 2020
Suppresses bwc tests for backport of elastic#55732
imotov added a commit to imotov/elasticsearch that referenced this pull request Apr 30, 2020
Counts usage of the aggs and exposes them on the _nodes/usage/.

Closes elastic#53746
imotov added a commit that referenced this pull request Apr 30, 2020
Suppresses bwc tests for backport of #55732
imotov added a commit that referenced this pull request Apr 30, 2020
Counts usage of the aggs and exposes them on the _nodes/usage/.

Closes #53746
imotov added a commit to imotov/elasticsearch that referenced this pull request Apr 30, 2020
Updates the serialization version and re-enables bwc tests for nodes
usage api after backport of elastic#55732
imotov added a commit that referenced this pull request Apr 30, 2020
Updates the serialization version and re-enables bwc tests for nodes
usage api after backport of #55732
@imotov imotov deleted the issue-53746-aggs-usage branch May 1, 2020 22:22
russcam added a commit to elastic/elasticsearch-net that referenced this pull request Jun 4, 2020
russcam added a commit to elastic/elasticsearch-net that referenced this pull request Jun 10, 2020
github-actions bot pushed a commit to elastic/elasticsearch-net that referenced this pull request Jun 10, 2020
github-actions bot pushed a commit to elastic/elasticsearch-net that referenced this pull request Jun 10, 2020
russcam added a commit to elastic/elasticsearch-net that referenced this pull request Jun 10, 2020
Relates: #4718, elastic/elasticsearch#55732

Co-authored-by: Russ Cam <russ.cam@elastic.co>
russcam added a commit to elastic/elasticsearch-net that referenced this pull request Jun 10, 2020
Relates: #4718, elastic/elasticsearch#55732

Co-authored-by: Russ Cam <russ.cam@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose agg usage in Feature Usage API
7 participants